AD SSO for users with alternative UPNs

Hi, and welcome to the UTM Community!

Are you doing AD in the Cloud for xyz.org.uk?  There must be some way to get the two ADs to trust each other.  There is no way to get the UTM to join two separate domains simultaneously.

Cheers - Bob

Hi, thanks for the reply. However perhaps I didn't explain the scenario very well. We are not trying to join the UTM to two domains are the same time :)

Allow me to explain in more detail (apologies if any of this is too basic :) ).

So, we are a school in the UK and have an on premises domain of <school_name>.internal and an internet domain <school_name>.<county>.sch.uk. A few years ago we enrolled in MS Office 365. To use Azure AD Connect to sync on premises AD users with 365 you need to add an alternative UPN suffix to your domain that matches your Internet routable domain, and then change all your users' UPN suffix to this. There's some info here: https://support.office.com/en-gb/article/Prepare-to-provision-users-through-directory-synchronization-to-Office-365-01920974-9e6f-4331-a370-13aea4e82b3e?ui=en-US&rs=en-GB&ad=GB and here https://technet.microsoft.com/en-us/library/cc772007(v=ws.11).aspx

Adding additional UPN suffixes is a fairly standard and widely used procedure. It shouldn't affect user authenticating against AD all. Kerberos canonacalises all users' account names so if I login as user@<school_name>.<county>.sch.uk then AD actually issues a ticket for user@<school_name>.local. All our systems that implement AD SSO work fine, including our current filtering solution (Smoothwall). However, the Sophos UTM will not authenticate users with the @<school_name>.<county>.sch.uk UPN suffix against AD, and the filter logs return a winbind error (users with the @<school_name>.interal UPN suffix are suthenticated just fine). Even more bizarrely, is that when a user with the alternate UPN logs in, we can see the Kerberos request from the UTM hit the DC defined on the UTM as the authentication server. The ticket is issued successfully and if I run klist on the client, it has the ticket and lists the UTM in the server field.

In an attempt to solve this issue I have visited other schools with exactly the same setup and the authentication works and did work as soon as AD SSO was set up (as is to be expected).

Its a really odd one and Sophos support are now looking a lot deeper into the UTM and our AD to try and work out what's going on. Though there is still a lot of head scratching going on. I posted here in hope that someone might have come across something similar but it kinda looks like this issue hasn't been seen before.

Thanks for your time.

I think you should be able to solve your problem by using LDAP Authentication Servers instead of Active Directory.  

This assumes that your alternate identifier exists in Active Directory somewhere, and can be extracted by choosing the userattribute = ">" (custom) option in the LDAP setup.

Note that Active Directory authentication lookups are always unqualified (e.g. "johndoe"), so maybe your issue is moot.   We use Active Directory authentication for our primary domain, which keep things simple for those users.  LDAP lookups are used for all of our alternate domains.  We match on userPrincipalName, which is fully qualfied (e.g. "johndoe@example.com"), so there is no risk of ambiguity with Active Directory user identifiers.

Newcomers to LDAP may struggle with the setup, so the following hints are offered to help:

The login account is specified in LDAP syntax, not active directory syntax, and must include the active directory folder structure.  Assume that UTM will be doing LDAP checks using a service account named LDAP_SERVICE which exists in Active Driectory in the path "\myorgunit\mysubunit", within domain example.com. The LDAP syntax for Bind DN will be:

   cn=LDAP_SERVICE,ou=mysubunit,ou=myorgunit,dc=example,dc=com"

NOTE:  If someone decides to rearrange Active Directory and drag LDAP_SERVICE to another folder, your UTM LDAP lookups will break.

There are a few special folders in Active Directory (most notably "Users" and "Computers").  These are referenced using cn=value rather than ou=value, because they are "containers", not "Organizational Units".

The Base DN for lookups is simpler, assuming that you want to open the entire domain to the LDAP login function:

   dc=example,dc=com

Of course, you will probably not want to allow every account in the domain to use UTM, and further limiting the Bind DN would be one way of doing so.   But this switches us from Authentication issues to Authorization issues, and I have found Authentication with LDAP groups provides all the capability that I need.

LDAP Group definitions are similar:  Group type = "Backend membership", Group ID specified in LDAP syntax, and match attribute = "memberOf" 

Also note that because of a bug in firmware version 9.408-4, you will have trouble testing user login processes and group membership from the Authentication Server [test] button.   I don't believe any earlier or later version has this problem.

Thanks for the reply.

That is indeed a great idea and actually one that Support have now tried. The server test and the user auth test both work fine from the admin interface, but we are still seeing the winbind error when users try and browse the Internet! Investigations are ongoing...

Hello sparkeh.

I recently came across an article that might help you.

Regards - Giovani

Thanks for the article Giovani, that's how support set it up. And it doesn't work :(

Please PM me your case # so I can get a Sophos person to look up the information and post the solution here.

Cheers - Bob

Please PM me your case # so I can get a Sophos person to look up the information and post the solution here.

Cheers - Bob