Enabling UPN (Dit e-mailadres wordt beveiligd tegen spambots. JavaScript dient ingeschakeld te zijn om het te bekijken.) in Sophos UTM

We often use the UPN feature in Active Directory. If you don’t know what this is: it lets us use the people’s emailname as the login like Dit e-mailadres wordt beveiligd tegen spambots. JavaScript dient ingeschakeld te zijn om het te bekijken. instead of 360ict\dennis. You can find more on the UPN here and here.

The trouble was that we couldn’t get this to work in UTM, so i started a thread  a year ago and finally got Sophos support involved. Support did get it to work but i (on our test systems) and our reseller Contec ISC (on their test systems) couldn’t. They were silent after a while, so i decided to do some more digging myself. It turns out you shouldn’t use the test button in the authentication server section when using LDAP, how foolish of me..  :evil:. After i used the userportal to test everything went fine. I’ve sent an email to the sophos support to get more explanation on this, i suspect a bug in that test button.

So, that’s the short story. Here comes the long version on how to configure UPN logins on your UTM and more importantly, how to test UPN logins. This might work on other LDAP attributes like emailadress, but i haven’t tried that.

First you need to set a LDAP Authentication Server;

To read objects from the LDAP server, the UTM needs an user account to read out the LDAP server. So you need to create a user account (no special or admin rights needed) and fill the LDAP path to this object.

You can find the LDAP path in the “Active Directory Users and Computers tool” (or in adsiedit), i chose ADUC with the advanced features enabled and opened up the “attributes editor” tab and scrolled to “distinguished name”, opened it and copied it out and pasted it in the UTM under “Bind DN”;

You need to set a Base DN, this is the point from where the UTM is looking at your LDAP server. If you want your whole AD to be seen from the UTM, just point it to the root of you AD, like i did;

Click on Save (else you can’t test it). The server test should display;

And the user in the UTM should display;

But don’t be alarmed as the account has no other user groups than LDAP, as i found out the hard way (re-read the intro about that).

If you want to troubleshoot user authentication, you can use the logfiles in the webadmin gui, you want the “User authentication daemon”.

On the console you can look at aua.log. To set it in debug mode, run this command on the console;

killall -USR2 aua.bin

Be aware debug mode will show you all. And i mean all because it will display the passwords in plain text, so be sure to reset the debug mode to normal (run the command again) and to wipe the logfile.

A normal logging level while doing a bind test will show you this;

2013:12:19-12:37:47 abn-tsasg1 aua[23503]: id=”3006″ severity=”info” sys=”System” sub=”auth” name=”Spawned child for authentication test”
2013:12:19-12:37:47 abn-tsasg1 aua[23503]: id=”3006″ severity=”info” sys=”System” sub=”auth” name=”Bind test request: adirectory”
2013:12:19-12:37:47 abn-tsasg1 aua[23503]: id=”3006″ severity=”info” sys=”System” sub=”auth” name=”Bind test successfull. Method: adirectory

And debug mode shows;

2013:12:19-12:36:01 abn-tsasg1 aua[3398]: id=”3007″ severity=”debug” sys=”System” sub=”auth” name=”handle_client:
test:adirectory,10.100.129.225,0,389,Vel0cett3,CN=Administrator,CN=Users,DC=velocette,DC=internal”
2013:12:19-12:36:02 abn-tsasg1 aua[3398]: id=”3007″ severity=”debug” sys=”System” sub=”auth” name=”Request: $VAR1 = [
2013:12:19-12:36:02 abn-tsasg1 aua[3398]: ‘test:adirectory’,
2013:12:19-12:36:02 abn-tsasg1 aua[3398]: ‘10.100.129.225’,
2013:12:19-12:36:02 abn-tsasg1 aua[3398]: ‘0’,
2013:12:19-12:36:02 abn-tsasg1 aua[3398]: ‘389’,
2013:12:19-12:36:02 abn-tsasg1 aua[3398]: ‘Vel0cett3’,
2013:12:19-12:36:02 abn-tsasg1 aua[3398]: ‘CN=Administrator,CN=Users,DC=velocette,DC=internal’
2013:12:19-12:36:02 abn-tsasg1 aua[3398]: ];
2013:12:19-12:36:02 abn-tsasg1 aua[3398]: “
2013:12:19-12:36:03 abn-tsasg1 aua[3398]: id=”3007″ severity=”debug” sys=”System” sub=”auth” name=”Client requested bind test of method: adirectory”
2013:12:19-12:36:03 abn-tsasg1 aua[3398]: id=”3007″ severity=”debug” sys=”System” sub=”auth” name=”Master: waiting for new connection.”
2013:12:19-12:36:03 abn-tsasg1 aua[23181]: id=”3006″ severity=”info” sys=”System” sub=”auth” name=”Spawned child for authentication test”
2013:12:19-12:36:03 abn-tsasg1 aua[23181]: id=”3006″ severity=”info” sys=”System” sub=”auth” name=”Bind test request: adirectory”
2013:12:19-12:36:03 abn-tsasg1 aua[23181]: id=”3007″ severity=”debug” sys=”System” sub=”auth” name=”performing bind test for method: adirectory”
2013:12:19-12:36:03 abn-tsasg1 aua[23181]: id=”3007″ severity=”debug” sys=”System” sub=”auth” name=”performing bind test to ldap://10.100.129.225:389″
2013:12:19-12:36:05 abn-tsasg1 aua[23181]: id=”3006″ severity=”info” sys=”System” sub=”auth” name=”Bind test successfull. Method: adirectory”
2013:12:19-12:36:05 abn-tsasg1 aua[23181]: id=”3007″ severity=”debug” sys=”System” sub=”auth” name=”sending result to client”
2013:12:19-12:36:05 abn-tsasg1 aua[23181]: id=”3007″ severity=”debug” sys=”System” sub=”auth” name=”test finished”

(these logs are from sophos support)

This is enough to let the users authenticate with UPN, but to make it a bit more useful we will configure the user portal so you can see how the groups should be set up. Go to “Users & Groups” in the webadmin and configure a LDAP group;

You can’t test the group memberships except use debug mode and look at the console. Again, don’t trust the test button on the “server authentication” as explained earlier.

I’m not gonna explain how the user portal and it’s features work, you can find that in the help of UTM. If you want to authenticate using the UPN in the user portal, you need to add the LDAP group to the user portal;

If you logon to the user portal with an UPN name and you have debug mode enabled, you should see this in the logs;

2013:11:20-11:10:59 UTM9 aua[3268]: id=”3007″ severity=”debug” sys=”System” sub=”auth” name=”handle_client: portal,Dit e-mailadres wordt beveiligd tegen spambots. JavaScript dient ingeschakeld te zijn om het te bekijken.,password,192.168.70.3″
2013:11:20-11:11:00 UTM9 aua[8198]: id=”3007″ severity=”debug” sys=”System” sub=”auth” name=”Entering do_auth_ldap”
2013:11:20-11:11:00 UTM9 aua[8198]: id=”3007″ severity=”debug” sys=”System” sub=”auth” name=”Entering do_auth_directory: server=10.128.13.150 port=389 ssl=0 bind_dn=cn=administrator, cn=users, DC=astarosupport, dc=de base_dn=DC=astarosupport, dc=de”
2013:11:20-11:11:00 UTM9 aua[8198]: id=”3007″ severity=”debug” sys=”System” sub=”auth” name=”ldapFilter: (&(objectClass=*)(userPrincipalName=Dit e-mailadres wordt beveiligd tegen spambots. JavaScript dient ingeschakeld te zijn om het te bekijken.))”
2013:11:20-11:11:00 UTM9 aua[8198]: id=”3007″ severity=”debug” sys=”System” sub=”auth” name=”server_groups: memberof:cn=local_group-sid,cn=users,dc=astarosupport,dc=de,memberof:*,memberof:cn=internet_full-access,cn=users,dc=astarosupport,dc=de,memberof:*,memberof:cn=internet_limitited,cn=users,dc=astarosupport,dc=de,memberof:*,memberof:cn=esx

You can see the memberof being correctly read as it shows you the group memberships (this log is actually from Sophos support) but don’t test with the test button on the authentication server page, this will yield no results and makes the whole thing even harder to troubleshoot.

I also found out that the LDAP authentication tries to create the user again and fails if it’s already created using an AD server. In my testing i had set the “create users automatically” set to on;

Most of the time i want this on, as SSO otherwise don’t has much use. This had created the user “Dennis” and conflicted with the user creation of Dit e-mailadres wordt beveiligd tegen spambots. JavaScript dient ingeschakeld te zijn om het te bekijken.. The debug log showed me;

that could be easily solved: delete the user “dennis” and after that i could succesfully login into the user portal.

UTM showed the newly created user as Dit e-mailadres wordt beveiligd tegen spambots. JavaScript dient ingeschakeld te zijn om het te bekijken.;

I think this has to do with the uniqueness of the email adress property in the UTM, but that’s just a hunch.

Update: i tested on a system that hasn’t set the email property in the AD account (=has no exchange in the domain) and on that system i could login with both the UPN name and the AD name and both users got created in UTM. So my guess is that having set the same email property in 2 accounts in the AD prevents UTM to have both users automatically created.