As Office 365 adoption continues to grow and more organisations are starting to take advantage of identity federation. One of the most common issues I’ve seen over the last couple of years when helping my clients adopt Office 365 services is the disconnect between user principal name (UPN), sAMAccountName (The user name typically used at logon) and the ‘mail’ attribute in Active Directory. There are many reasons for this and I won’t go into that in this post, but it is quite common to see one of the following scenarios:
- sAMAccountName = JSmith, UPN = JSmith@internal.local, Mail = John.Smith@domain.com
- sAMAccountName = ID123456, UPN = ID123456@internal.local, Mail = John.Smith@domain.com – I’ve seen this scenario quite often when working with .gov and .edu clients.
In the past, the typical recommendation is to add the public domain to the UPN suffix list and change the UPN for each user to match their email address. This causes much less confusion for end users as you won’t need to try and explain the different between their UPN and their email address even though they both appear to be the same.
*Update: I'd like to call out that implementing "Alternate Login ID" with an Exchange Hybrid deployment is not a good idea. Microsoft has the following warning posted on the TechNet wiki.
The April 2014 Windows Server 2012 R2 Update (KB 2919355) includes a new feature called “Alternate Login ID” which will allow you to configure an alternate attribute to be used to identify a user object in Active Directory. In other words, you can now use a different attribute, for example ‘mail’ during login instead of UPN.
This is great news for those organisations who use of employee ID or payroll numbers as their domain user names. As always, there are a few things to consider. In order for the authentication request to succeed, the attribute configured as the alternate login ID must satisfy the following requirements:
- The attribute must be indexed.
- The attribute must be in the global catalog.
- The attribute must be a well-formed SMTP address and conform to the UPN rules outlined here.
- The attribute must have a single value.
- The CanonicalName attribute on the user object must be accessible to the service account that is used for AD FS.
- The value of the alternate login ID attribute must be unique across all the forests that AD FS is configured to use when enabling this feature.
The configuration process is really simple as well, for example let’s assume we already have AD FS 3.0 implemented with Office 365. My test environment is configured as follows:
- Internal AD domain name: lab365.com.au – NOT configured in Office 365
- Public (SMTP) domain name: o365testlab.com – This domain is also configured in Office 365
- sAMAccountName = ID123456, UPN = ID123456@lab365.com.au, Mail = John.Smith@o365testlab.com
We would like to allow our users to log in using their email addresses (‘mail’ attribute) instead of their UPN.
It is important to note that if you are not using a routable UPN suffix, you will most likely want to pre-configure the correct SMTP and SIP addresses for your user accounts before you synchronise them. This can be done via the “proxyAddresses” attribute of the user account:
Once the user has been synchronised to Azure AD and assigned the relevant licenses in Office 365 it should look something like:
To configure AD FS, the first thing to do is install the April 2014 Windows Server 2012 R2 Update (KB 2919355), this can easily be done via Windows Update:
Warning: There is a known issue with the April 2014 Windows Server 2012 R2 Update (KB 2919355) that may effect you if you are using Windows Server Update Services. Be sure to read KB 2959977 before installing this update in your environment. As always, planning and testing is very important!
Next, update the AD FS configuration by running the following PowerShell cmdlet on any of the federation servers in your farm, starting with the primary AD FS server in your farm, obviously you would need to adjust the “AlternateLoginID” and “LookupForests” parameters to suite your particular requirements:
[powershell]Set-AdfsClaimsProviderTrust -TargetIdentifier "AD AUTHORITY" -AlternateLoginID mail -LookupForests lab365.com.au[/powershell]
Next, we need to update one of our AD FS claims rules. We locate the “Microsoft Office 365 Identity Platform” relying party trust and edit issuance transform rule number 1:
The new rule should look like this:
Lastly, we need to update our DirSync attribute flow to ensure the correct attribute is synchronised. Run the miisclient.exe which can be located in "C:\Program Files\Windows Azure Active Directory Sync\SYNCBUS\Synchronization Service\UIShell”. Select the “Management Agents” tab, right-click to view the properties of “Active Directory Connector”. Under “Configure Attribute Flow”, expand “Object Type: user” and find the “Data Source Attribute” of “
- Change the “Mapping Type” from “Advanced” to “Direct”
- Select the appropriate attribute (“mail” in my case) as the “Data source attribute”.
Ensure that the “Metaverse attribute” is set to “userPrincipalName” and click “Edit” and then “OK” to save your changes.
Once you have completed a successful synchronisation, you will be able to log into the Office 365 portal using your email address as login attribute.
I’d like to conclude this post with the following.. just because something is possible, it doesn't mean it should be done. Unless you have a very specific requirements and/or constraints, I would recommend using UPN as your login attribute even if this means having to go through the process of changing all your user UPNs. In most environments this change will have little or no effect on other systems and may be the best approach.
For more information on Alternate Login ID, see: