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.
DirSync Configuration
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
Considerations Post-Sync
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
Additional Links
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.
Hi, Just to confirm. The claim rule you have no longer has the query=”samAccountName={0}; information howerver, the following post leaves the information in the claim? http://social.technet.microsoft.com/wiki/contents/articles/24096.using-alternate-login-ids-with-azure-active-directory.aspx
Can you advise which would be the correct claim?
Thanks for the write up its very handy.
Matt-
Looking at the revision history of that article, Microsoft changed the guidance on 05/02 to what you see now; I have updated the above documentation to be consistent with that guidance.
Thanks for the feedback!
Joe
Thanks for the insight!
In considerations for post-sync, I have a customer that have on premise active directory and office 365 in the cloud. All the users have licenses already in the cloud. This will be a fresh ad sync turn on and install of dirsync. Should I unassign licenses for all cloud accounts to thwart any mishaps?
Ed-
If the tenant is not being used yet and cloud accounts were created manually and licensed, I would probably consider clearing out those accounts (from both active and the recycle bin) and allowing DirSync to do the provisioning. This of course will depend on your individual situation, there may be a reason the accounts were licensed. If the account has a license, DirSync will not update that account’s UPN in the cloud. You can work around this by changing the cloud UPN back to the “@tenant.onmicrosoft.com” suffix via PowerShell and DirSync should update it from there.
Thanks for the comment!
Joe
hello, can i use this solution to login to office 365 with my local domain name but federate with Public domain name.
Ahmed-
The login you use would still required the domain to be publicly routable (i.e. you could not use a “.local” domain). What this feature does is allow you to avoid changing your UPN from the .local and instead use something like the email address as a login.
Thanks for the question!
Joe
If you are just using DirSync and not ADFS, does the solution stil work?
great article. One question – where do I run the “Set-AdfsClaimsProviderTrust”? is it on On-Premises ADFS or O365 environment. I think it is to be run in O365 as our On-Premises AD (ADFS) is the claims provider whereas the o365 is the RP!?
That is correct, you would run this on your primary AD FS server on-premises.
Thanks for the feedback!
Joe
Yes, this will work if you’re doing Password Sync as well.
From my testing it seems Alternate logon does not seem to work unless the immutableid is Objectguid. If you change the immutabelid to eg mail then try and logon to o365 you get an error.
Is the process the same if the initial sync was already done? Initial sync with a non routable UPN has left my EOP users with .onmicrosoft.com domains even though utilizing dir sync, Will the same scenario work to correct this is users were previously synched incorrectly?
Unfortunately I have not tested that scenario however I suspect it would work. My thought here is that it’s basically just a change of the userPrincipalName attribute in the cloud which is similar to if you just corrected their on-premises UPN.
However, if you can change the UPN in the on-premises AD to match the user’s email address, that would be preferable.
Hitesh-
Sorry to hear you’re having issues. I have successfully configured immutableID using one of the Exchange extension attributes so you might want to confirm all the steps.
Thanks
Joe
Hi, I am just learning about Office 365, Federation Services and Single Sign-On at present, whilst building my test lab. As it’s a test lab, and I don’t have any publicly available DNS names, I have added .onmicrosoft.com into my alternative UPN suffixes in Domains and Trusts and plan to use this for the Single Sign-On, DirSync and password sync. Is this OK? Will I have any issues using the *.onmicrosoft.com address?
Unfortunately I don’t think you’re going to be able to get by without public DNS names, at least not for AD FS.
If you don’t have a publically routable name, Microsoft will default your users in Office 365 to the .onmicrosoft.com suffix. You could still test out Password Sync using that login but you’re not going to be able to setup AD FS without a public name and certificate.
Joe
If using multiple forests behind the same ADFS, with forest trust in place, how would the logon request traverse the forest trusts when using alternate login ID ( with Mail attribute) in this example below and not the UPN?
For example: Lets say Forest A has UPN=Contoso.Internal and a SMTP domain=@contoso.com This forest also hosts the ADFS servers.
Forest B has UPN=Litware.Internal and SMTP Mail domain=@Litware.com
Lets say they cant change the UPN because of legacy apps and other reasons
Additionally the forest also share their SMTP namespace, meaning some accounts in Contoso or Litware can have email addresses with both @Contoso.com or @Litware.com.
I use AAD Sync instead of FIM since it supports the multi-forest scenario and joining/syncing the mail attribute can also be done.
Scenario- a user in Forest-B logon to 0365 after his identity is synced up to O365 and assuming alternate login mail Attribute is configured.
UPN=UserB@contoso.internal
Primary SMTP and Mail attribute=UserB@Litware.com
So the first question, would the script for ADFS then look like something like this including both domains?
Set-AdfsClaimsProviderTrust -TargetIdentifier “AD AUTHORITY” -AlternateLoginID mail -LookupForests Contoso.com,Litware.com ?
Secondly how would the logon request traverse the trust to go look for the user if its not upn but mail attribute. As you know Forest trusts uses UPN suffix routing but we cant use that since they share the routable namespace for mail?
Thanks
JP
JP-
It’s the “-LookupForests” switch that is important here.
In your example, you would actually use “-LookupForests contoso.internal, litware.internal”, not “-LookupForests contoso.com, litware.com”. This is what tells AD FS what AD forests it should try and check for the alternate login ID. Basically an LDAP query is done based on the supplied value in an attempt to find the samAccountName, canonical name and distinguished name for the object; this is what is in turn used to authenticate the user. It’s important that the alternate login ID that you select only exist in one of the forests.
As far as sharing the SMTP namespace, I have tested this and it works fine as long as the value only exists once.
If considering Alt-ID, you will want to read this for supportability concerns/known issues – https://blogs.office.com/2014/05/06/alternate-login-id-for-office-365-reduces-dependence-on-upn/
Thanks Pat, I’ve compiled a list here as well: https://blogs.perficient.com/microsoft/2015/02/office-365-the-limitations-of-alternate-login-id/
Thank you for the page. Extremely helpful.
Thanks Joe! The “Lookup forest” correction makes sense.
Back on that scenario of mine, will any services in office 365 suffer from this configuration (Using Alternate Login). For example SharePoint online communications, Yammer login…compared to the MS recommended of Primary SMTP address matching UPN approach?
JP- Check out link above to my “limitations article” and it will give you some insight of some of the issues.
Does anyone have any ideas on how to rectify that second login that my users see before logging using ADFS. It redirects them to the ADFS server then a webpage from ADFS appears for another login. Once they login there Office 365 opens no problem. Now using some browers I can have it save password and it will redirect and work everytime. It is the browsers that won’t save the password so, I need to fix this totally. Please help if you have any ideas.
Jason-
AD FS should leverage Windows Integrated Authentication (WIA) assuming it’s enabled in the browser, the workstation is domain-joined and on the internal network. Usually this means making sure that the URL for your AD FS site is in the “Intranet” zone in IE which uses WIA by default.
Thanks for the informative article Joe. I’m currently implementing Azure AD Connect with .local domain. I’ve setup the UPN suffix to match the Office 365 domain suffix. Each users Office 365 account is same the login (minus the suffix) as domain account. After sync occurs do you recommend that users login to their PCs with the UPN account “test@1234.com” or stick with the DOMAINNAME\SAMAccountName?
Anthony-
The login to the workstation isn’t really relevant. Whether they user the new UPN or the SamAccountName, either will work. When authenticating to Office 365 they will need to use the UPN or if you have AD FS and SSO is configured, it will pass through either credentials.
Thanks
Joe
Hi Joe, great article. I have an question thou. On premise our UPN and email is the same, I have federated domains and sync users (ou filtering) to azure ad.
I noticed lately when an user is created in Windows by Azure ad join the display name is shown but whoami is samaccountname, example contososamaccountname but when I try to connect to a server on premise locally in domain with RDP than it prompt me cause the credentials are incorrect contosofirstname.lastname@federateddomain.com) any idea how I can avoid the netbiosname (contoso) cause in read this is due to federated domains? Hope my question makes any sense:)
Dyan-
I’m not sure I follow the issue that you’re experiencing. If you have your UPN matching your SMTP address, that’s the ideal configuration. There should be no impact to any login activity on-premises and you should be able to login with either DOMAIN\sAMAccountName or with the UPN.
Thanks
Joe
Hi great tutorial thanks. I have almost the same kind of problem that I can’t seem to solve: we use an onmicrosoft.com tenant simply to activate Office licences. I have changed the UPN suffix to match the public domain name, dirsync works fine the licences are activated but not connected (ie no connected services, like save in SharePoint from Word for example, or OneDrive Enterprise) can’t connect (using either the xxx.onmicrosoft.com address or the new one). I always get an error saying the username can’t be found. Any idea about this because I haven’t found any solution anywhere). Thanks 😉