When deploying AD FS for Office 365, the ideal deployment scenario is to have the userPrincipalName (UPN) value in Active Directory configured to match the user’s email address; at a minimum, your UPN suffix needs to be a publically routable domain. For many organizations, changing user UPNs is a fairly easily scriptable change with little to no impact. However, for some organizations, existing applications are using the current UPN values and making the recommended change would require significant effort.
A recent update to AD FS 3.0 (Windows Server 2012 R2) and updated guidance for Directory Sync now allow for using an “alternate login ID” with AD FS and Office 365. The end result is you can now use a value such as “mail” as the user’s login in Office 365 and avoid changes to the on-premises Active Directory objects.
The instructions for this configuration are somewhat buried in two links so I’ve consolidated them in the article below.
AD FS Configuration
Requires: AD FS 3.0 (Windows Server 2012 R2) + KB2919355
Once the required update is installed, you can modify the AD FS configuration to use an alternate login ID. To change set the alternate login ID to the “mail” attribute for the “iwitl.com” domain, you’d use the following:
Set-AdfsClaimsProviderTrust -TargetIdentifier "AD AUTHORITY" -AlternateLoginID mail -LookupForests iwitl.com
For Office 365, you now need to modify the AD FS Issuance Transform Claim Rules using the following process:
- Open up the “AD FS Management” console
- Expand “Trust Relationships” and select “Relying Party Trusts”
- Right-click “Microsoft Office 365 Identity Platform” and select “Edit Claim Rules…”
- Highlight claim rule #1 and select “Edit Rule…”
- Edit the rule as below (replacing userPrincipalName with the attribute you chose)
After saving the claim rule changes, the AD FS configuration change is completed.
For DirSync, the default rules will continue to try and sync the on-premises UPN to Azure Active Directory and if the UPN suffix is not valid, the user will be provisioned with a “.onmicrosoft.com” suffix. The configuration change below allows you to modify DirSync such that the on-premises “mail” attribute is used in Azure Active Directory.
DirSync can be modified with the following process:
- Open “miisclient.exe” on the DirSync server (Located in “C:\Program Files\Windows Azure Active Directory Sync\SYNCBUS\Synchronization Service\UIShell”)
- Select the “Management Agents” tab
- Right-click the “Active Directory Connector” and select “Properties”
- Select “Configure Attribute Flow”
- Expand “Object Type: user” and scroll until you find the “Data Source Attribute” of “<dn>,sAMAccountName,userPrincipalName”
- Change the “Mapping Type” from “Advanced” to “Direct”
- Select “mail” as the “Data source attribute” and confirm that the “Metaverse attribute” is set to “userPrincipalName”
- Click “Edit” and then “OK” to save the changes
If you have previously run a synchronization job with DirSync, you may run into one of the following scenarios:
- If the current UPN for the user is a federated domain, DirSync will not change the user’s UPN in Azure Active Directory
- If the user has a license assigned, DirSync will not change the user’s UPN in Azure Active Directory
In the above situations, you will need to update the user’s UPN in Azure Active Directory using the process documented by my peer Erik Enger: Changing UPN for Office 365 account between two SSO domains
Alternate Login in Exchange Hybrid Environments
While “Alternate Login” may seem like a great feature, it’s important to test this functionality out and understand the potential implications of such a configuration. I would recommend that this feature is used in the situation when an organization “can’t change their UPN” as opposed to when they “don’t want to change their UPN”. Aside from the additional complexity in the configuration, there is a specific scenario in regards to Exchange Hybrid environments that may become confusing for your end users.
UPDATE – I’ve put together an article discussing some of the issues around Alternate Login ID that you should definitely checkout before deciding to implement: Office 365 – The Limitations of Alternate Login ID
For additional information on the above configuration, please see the links below:
Did you find this article helpful?
Leave a comment below or follow me on Twitter (@JoePalarchio) for additional posts and information on Office 365.