Battling Complicated Identities and Multiple Domains
For most organizations, synchronizing identities to Office 365 is fairly straightforward. What tends to cause an issue is larger organizations with several domains, perhaps in the case of offices in various countries, or those who have recently gone through a merger or acquisition.
The issue is that Microsoft authenticates based on username and/or user domain while many of these organizations authenticate based on email address. While any user can tell you his or her email address, he likely does not know the correct username unless they happen to match on the backend. So the user goes to the portal to login, is prompted to enter their username, and can’t login because they don’t know the difference.
Let’s take a look at how this plays out with your company, Cloud Komodo (Congrats! You’ve been promoted to CEO of a totally fake company).
Short on time? Skip to the end for a Too Long, Didn’t Read summary.
Active Directory Authentication
Just a quick background on Active Directory – there are two forms of logons/authentication to Active Directory. Any time an authentication is made to Active Directory, it will need one of two options for authentication, outlined below. It is important to note that the two types do not have to match and both options will work, so you do not need to choose one or the other.
- samAccountName – oftentimes, this is unofficially referred to as the “short name” of logging into your computer. When you press CTRL + ALT + Delete, you typically just enter your “username” and password. This type of logon actually requires three parts: the username (which is the samAccountName), your password and the “domain” – this domain is an internal Active Directory Domain (more on that below).
Within Active Directory, you can have multiple domains – domains are just a logical group of objects – some organizations use them to separate environments, locations, or business/organizations in the case of an acquisition, for example. In this case, your workstations have a bound trust to an Active Directory domain (komodo.internal.local is your Active Directory domain), so it defaults to it, and most users never even know about this third component. This was a traditional or legacy type of authentication. Users may also specify their “username” in the form of a domain\\username (samAccountName). If users have a two digit alpha + 4 digit numeric username, tw1234 would be my username (samAccountName). In this case, I’d login with KOMODO\\tw1234.
- userPrincipalName (or UPN) – this is a newer authentication type which uses a fully qualified address. Very similar to how the above uses domain\\username – this uses the format username@domain. Using the same example above, my samAccountName is tw1234 and the Active Directory domain is internal.local so my User Logon would be email@example.com.
In the case of our userPrincipalName example, we have an Active Directory domain of @komodo.internal.local. The top level of this domain is “.local” which means exactly that – it’s local or internal and cannot be publically routed to the internet. This is a very popular method for segregating internal servers and objects and publically accessible objects. (Fun fact: Active Directory can create almost any domain format to be used internally. We may use the term “fun” a bit loosely here, but it remains true nonetheless).
Publically, almost everything these days uses DNS – if you don’t actually own the domain, you won’t be able to point services to it. Why is this important? Because while your Active Directory domain is set to @komodo.internal.local we can also create an internal domain of @cloudkomodo.org. How does this help? Now you can create a “friendly” logon for users, which would typically match their email address for simplicity! So, while my samAccountName is tw1234, my email address is firstname.lastname@example.org and my userPrinicpalName is email@example.com. Pretty confusing that I need to remember three usernames as a user. So, to eliminate this, we can set the userPrincipalName to be the same as the email: firstname.lastname@example.org. So, while behind the scenes there are still three unique attributes, two of the three match, eliminating the need for the user to remember which to put where.
Still following? At this point we need to take a look at how Office 365’s authentication works:
First of all, Office 365 also runs Active Directory behind the scenes, which includes a userPrinicpalName. There is a samAccountName, but because we don’t have any objects (workstations or servers) joined/bound to the Office 365 Active Directory domain, we wouldn’t be able to use that. This requires us to use a userPrinicpalName.
Secondly, Office 365 is a virtual shared space, meaning other organizations also exist in the Office 365 infrastructure. To ensure all organizations have unique users and there aren’t any duplicates, Office 365 requires all users to have a “validated” domain – to do this, we have to validate that we own the domain. Remember, we can only prove we own a domain through internet DNS records. That means we can’t use the @komodo.internal.local domain. Instead, we can add the @cloudkomodo.org domain as it is owned by you and you can use your internet-facing DNS zone to prove it. Now when we create users, we ensure their userPrinicpalName in Active Directory is set to the @cloudkomodo.org domain and Directory Synchronization will ensure the user is synced out to Office 365.
So, where is the issue and what are the recommendations?
We now know that Office 365 uses the userPrinicpalName as the primary source of authentication, and that it must be unique and in the format of an internet routable domain name. From the example above, that would be email@example.com.
Microsoft wants to ensure things are easy for users, so they cater to their experience. How? Every page that requires a user to authenticate or logon will state: “Please enter your email address and password.” This is not a customizable field, unfortunately. So this would mean that a user enters their email address (firstname.lastname@example.org) and their password. Office 365 goes and looks for a userPrincipalName matching that, and guess what? Not found! The user wouldn’t be able to login.
There are a few fixes for this:
- Update the Active Directory userPrinicpalName to match email addresses. This means that users login to their workstations using either KOMODO\\samAccountName or just their samAccountName on a domain joined workstation (as it is already joined to the Active Directory Domain)
- What this changes: email@example.com becomes firstname.lastname@example.org
- What the user sees: Anywhere that a userPrincipalName is required, they would type in their email address (which is also the same value of their userPrincipalName). When they setup Outlook on their PC, at home or on their mobile phone, they will not be prompted by an additional screen to provide their username.
This is by far the least disruptive method and can be easily reverted for a user or all users. This makes for a very seamless end user experience.
- Introduce Active Directory Federation Services (ADFS) for Office 365 – ADFS now includes the notion of “alternate logon” attributes, which allow a user to logon using either their userPrinicpalName OR their email address. There are a few cases where this can cause issues, specifically in a hybrid Exchange deployment when used in a case of free/busy and/or AutoDiscover.
- What the user sees: While connected to the internal network, they’d have Single Sign On access, meaning they would not need to login to a company portal, it would be an “auto” login. Outside of the network, you would be able to control and customize the login page.
- Leave Active Directory attributes as is, but create a transformation within the Directory Synchronization tool, which allows the ability to “re-write” a value on the export.
- What this affects: In Active Directory, the attribute values do not need to change, however, when we export the user information (such as first name, last name, samAccountName, UserPrincipalName, etc.) we create a rule stating “If the userPrincipalName is samAccountName@cloudkomodo.org – make the Office 365 userPrincipalName in the format of: mail”
To further complicate the situation, portal logins are not the only experience affected by mismatched usernames. You also need to consider Skype for Business and Outlook:
Skype for Business Online
- The client will also integrate with Outlook and Exchange – it will attempt to login to Exchange using the same credentials. If the sign in address and email address don’t match, the user will have a warning that the client can’t sign in to Outlook/Exchange – this is necessary if you wish to store conversation history or use the meeting functionality of Skype for Business.
- Through its integration with Outlook, the client will also look for other Outlook users to query users on an email chain for presence – if the email address does not match the user’s sign in address, it won’t show presence unless the users are added to that user’s contact list.
The first time a user logs in, the client will ask the user to enter their sign in address. This is also a unique attribute and in the same format of an email address. The client will then take the user’s sign in address and password combination and attempt to logon to the Skype for Business server. If the user’s sign in address does not match the userPrinicpalName, the user is then prompted on a second screen with an error, and asked to provide their username as well. This is only necessary the first time, as subsequent logons on the same machine will be cached.
- Users mailboxes may be located on several different mailbox serves and/or databases – in order to provide a quick, seamless connection for the user to their mailbox, Exchange uses a process called AutoDiscover. This process will look for the user’s mailbox via their email address. Once the request is routed to the email address, the mail server will provide the server name, database, and location to the client requesting, but ONLY if they are successfully authenticated. If the user’s email address is not the same as the userPrincipalName, Exchange will deny the request and ask the user to login. To prevent this, it is highly recommended the email address, the userPrinicpalName, and the sign in addresses all match when possible.
There may be valid use cases for the username (samAccountName) or the userPrincipalName to not match, and in that case, it just becomes an end user training method of knowing when to use email address verse when to use their actual userPrincipalName. If you are able to update your Active Directory userPrincipalName to match email addresses, future applications you add in will be able to take advantage as well. More often than not, you will find you can make this change without any user impact.
In short (i.e. too long, didn’t read):
A user knows his email address is email@example.com. On the back end, his login is set to “jons” and his UPS is firstname.lastname@example.org. When you sync for the first time through ADConnect and don’t apply any configurations, if the UPS is email@example.com he’s going to have to login to the portal as firstname.lastname@example.org. The portal, however, asks for email address, which he knows to be email@example.com.
To avoid an immense amount of end user confusion and IT headaches, update ADConnect so everything matches before your sync. Or, if for some reason different values are required, make Office 365 configure through Directory Synchronization and use something specific, like email address, instead of UPN. This way, instead of copying UPN to UPN, it’ll copy email address to UPN, no changes will need to be made in ADConnect and your end users have a seamless experience.