Adfs, AADSync and Exchange Online (O365) Integration scenarios and facts

Today I am trying to focus light on O365 – Exchange Online scenarios
I am covering Exchange Online outlook and outlook web app scenarios wrt Adfs and AADSync

MSOL Domain SSO & AADSync: AADSync is “Same Sign On” and not “Single Sign On”
If you have on premise active directory, you can use AADSync only to get SSO (same sign on).
AADSync won’t give you true SSO (Single Sign on) experience.
You can skip AADSync by creating cloud only identities which will eliminate to install AADSync, but in this case you have to maintain same passwords manually for cloud only identities and on premise active directory OR you need to maintain multiple passwords

———————————————————————————————————————-

MSOL domain SSO and Adfs federation: O365 exchange online federation with Adfs won’t work with out AADSync.
If you want to leverage Adfs for SSO (single sign on), you must use AADSync as well in addition to Adfs. You can’t simply skip AADSync.
Now you will ask me why you want to skip AADSync?
Here we are trying to avoid need for deployment of AADSync in scenarios where you have single on premise active directory and multiple O365 tenants (One AADSync instance will be required per O365 tenant)
*You can sync multiple active directory forests with single O365 tenant via AADSync, however you cannot sync single active directory forest with multiple O365 tenant unless you deploy multiple AADSync server in same active directory domain for each O365 tenant*
One should be able to create cloud only identities (mailboxes) in O365 for federated domain, create corresponding on premise active directory accounts and authentication requests should flow down to Adfs.
Seems that scenario is ideal, however once you federated MSOL domain with Adfs, federation will work only for existing cloud identities but did not work for new cloud identities. You cannot create new cloud only identities for federated domain anymore in O365 and you must have to deploy AADSync on premise and from there you need to create users and sync it to O365.

Let’s take an example:

  1. You have on premise active directory named contoso.local
  2. You have standalone cloud only SMTP domain named Contoso.com and Fabrikam.com in O365
  3. Contoso.com and fabrikam.com are part of separate O365 tenants.
    1. Contoso.com – TenantA.onmicrosoft.com
    2. Fabrikam.com – TenantB.onmicrosoft.com
  4. You have created user1@contoso.com in TenantA and user2@fabrikam.com in TenantB as cloud only identity in O365 and assigned them exchange online mailbox.
  5. Now you created above users in on premise active directory as user1@contoso.com and user2@fabikam.com (you have to add contoso.com and fabrikam.com as UPN in on premise active directory) so that post federation those users can be authenticated with on premise active directory.
  6. Now you deployed Adfs in Contoso.local active directory and you federated Adfs with both O365 tenants as mentioned in this link
  7. Now if user1@contoso.com OR user2@fabrikam.com user tried to access his cloud mailbox via webmail / outlook, he will be prompted for on premise password via Adfs and once authenticated successfully will be granted access to his cloud mailbox.
  8. Now here is fact!                                                                                                                                                          Post federation, you want to create new O365 cloud user named user3@contoso.com OR user4@fabrikam.com and you start user creation wizard in O365, O365 won’t allow you to set contoso.com or fabrikam.com as UPN in cloud for new user ID. Those federated domains are unavailable from list of available list of domains. You cannot create user in cloud for federated domains. This is limitation by default. The alternative to this problem is to deploy TWO separate DirSync Servers in same active directory domain and Sync them with each tenant and create required users with on premise active directory. You can filter email users for each tenant based on OU in AADSync tool.

O365 and UserPrincipalName attribute:
Every O365 user requires UserPrincipalName attribute in cloud to authenticate with MS federation Gateway.
Normally this attribute match with user primary email address. It means it must be publically routable domain. Because O365 do not recognize non routable domains such as .local
If you are using Adfs for O365 authentication, Adfs can authenticate users with on premise active directory SamAccountName OR UserPrincipalName attribute (Contoso\user1 OR user1@contoso.com)
But obvious you have to use AADSync to sync on premise accounts to cloud / to create new cloud users in federated MSOL domain.
Now here is fact!
In above scenario, whenever you use AADSync to sync on premise accounts to cloud, if your on premise active directory UPN is non routable, you cannot use this UPN value to authenticate with O365 and you must provide user SamAccountName value to Adfs server while authenticating with on premise active directory.
Because this non routable UPN value such as user1@contoso.local stamped on premise active directory user account did not match with O365 user account in cloud which is having routable UPN value such as user1@contoso.com, as a fact O365 federation gateway did not accept .local values.
To overcome this issue, there are TWO options:
Option 1 (Preferred): Sync routable UPN to cloud
Set routable UPN value for on premise active directory accounts, it means change all accounts UPN to match user primary SMTP address before it’s get synced with O365.
By default AADSync sync and set on premise account UPN with cloud identity as UPN unless it is set non routable on premise.
The below figure shows AADSync setting where on premise account UPN will be synced in cloud as UPN attribute and all is set.

DirSync Default Method

Option 2: Sync alternate attribute (mail) as UPN attribute to cloud
If 1st option is not possible, then while Configuring AADSync, change UserPrincipalName attribute to mail attribute as shown below.

DirSync Custom Method

However you need more configuration here because here what you are doing, you are telling Azure AD that accept user mail attribute as UPN for authentication.
However on premise Adfs server did not accept this story because the email attribute is not set as UPN with on premise user account to authenticate with.
You need to set Adfs server to accept alternate attribute (mail) as authentication attribute with on premise active directory.
You need to run below command on primary Adfs server via PowerShell (assuming Adfs 3.0 setup is deployed).

Set-AdfsClaimsProviderTrust -TargetIdentifier “AD AUTHORITY” -AlternateLoginID mail -LookupForests contoso.com,fabrikam.com

The process is well explained in below TechNet article
https://technet.microsoft.com/en-us/library/dn659436.aspx

This method has its own advantages and limitations.

——————————————————————————————————————-

Changing UPN – federated Identity:
You have O365 user belong to one federated domain (contoso.com) and now you want to change this user UPN to another federated domain (fabrikam.com) domain.
Ideally what you will do, you will change on premise user UPN to match new domain UPN (from contoso.com to fabrikam.com) and during next Cycle, AADSync will update changes to cloud identity.
Now here is fact!
After changing on premise user UPN, DirSync will not update same in cloud identity
When the user object is being synced to the cloud service, you receive the following error message in the synchronization error report:
Unable to update this object in Microsoft Online Services, because the attribute Federated User UserPrincipalName is not valid. Update the value in your local Active Directory
Ex: Existing user UPN and primary email address is user1@contoso.com where contoso.com is federated with Adfs.
Now you want to change this user UPN and primary email address to user1@fabrikam.com
You can add new primary SMTP address and UPN to on premise AD user account; however with DirSync sync process only primary SMTP address will get updated in cloud; however UPN is not getting updated in cloud. The UPN for cloud identity is nothing but user login ID for cloud based services
Now you have to connect to Azure active directory via Azure AD PowerShell and need change it manually.

Set-MsolUserPrincipalName -UserPrincipalName user1@constoso.com -NewUserPrincipalName user1@contoso.onmicrosoft.com

The above command will 1st change user UPN to onmicrosoft default domain. Then you need to run same command again for new UPN

Set-MsolUserPrincipalName -UserPrincipalName user1@contoso.onmicrosoft.com -NewUserPrincipalName user1@fabrikam.com

The process is described in below TechNet article
https://support.microsoft.com/en-us/kb/2669550

——————————————————————————————————————-

Adfs & O365-outlook SSO – authentication prompt
I have seen many blogs which states that Adfs proxy is not required if you are using outlook only from corporate network where Adfs server is available within corporate network internally. Unfortunately this is not true.
https://support.microsoft.com/en-us/kb/2466333
No matter you use outlook from intranet / internet, Adfs proxy / Adfs servers must be published on internet, because O365 servers always reach out to Adfs server to get STS token on behalf of outlook users, if Adfs is not available on internet, you cannot access O365 mailbox with outlook either from corporate network / external network.
Check below link.
https://technet.microsoft.com/en-us/library/dn509513.aspx
Outlook is not Adfs aware and hence do not provide True SSO experience.
No matter you use outlook from intranet / internet, if you want SSO kind of experience, You have to save / store outlook password in cache and then it will not prompt password until you reset AD password or until it get expired. This is the case for all outlook versions including outlook 2007 / 2010 /2013 / O365 proPlus
http://office365evangelist.com/?p=1144

The Adfs authentication flow for outlook is shown below.

O365 Architecture-outlookO365 mailbox access via Outlook client in corporate network

  1. Outlook client try to access O365 mailbox (See numbering in golden)
  2. O365 mailbox only trusts Microsoft federation gateway, it requests authentication from MS federation gateway
  3. Microsoft federation gateway) see that there is federated trust with on premise Adfs and contact on premise federation server via federation proxy servers and get SAML token on behalf of O365 mailbox (federated user) and same time redirect user to Adfs service portal to get authentication ticket.
  4. User will get authentication prompt from corporate Adfs server and user enters his credentials. Once authenticated, O365 federation gateway will get required STS along with UPN claims from adfs server and grant mailbox access to federated user.

 O365 mailbox access via Outlook client over internet

  1. Outlook client try to access O365 mailbox (see numbering in Pink)
  2. O365 mailbox only trusts Microsoft federation gateway, it requests authentication from MS federation gateway
  3. Microsoft federation gateway see that there is federated trust between and contact on premise federation server via federation proxy servers and get SAML token on behalf of O365 mailbox (federated user) and same time redirect user to Adfs service portal to get authentication ticket
  4. User will get authentication prompt from Adfs proxy server and user enters his credentials. Once authenticated, O365 federation gateway will get required STS along with UPN claims from adfs server and grant mailbox access to federated user.

Note: In any case, user must click on save / store credentials while opening outlook, otherwise every time when user tries to connect to O365 mailbox, he will get authentication prompt.

———————————————————————————————————————–

Adfs & outlook web app SSO Architecture

O365 Architecture-webapp

Access to O365 web app from internal network

  1. Corporate Client tries to access O365 mailbox via web app (see numbering in green)
  2. O365 mailbox only trusts Microsoft federation gateway, it requests authentication from MS federation gateway via Websso
  3. Microsoft federation gateway redirect user to Adfs URL, user get connected to Adfs server from internal network and provide authentication (If Adfs URL is entered in intranet zone, then user will automatically get authenticated because then logged on user credentials automatically get forwarded to Adfs server because Adfs internally accepts windows integrated authentication)Once authenticated, Adfs will generate STS along with UPN claim and pass it to user via browser and redirect user to O365 portal. Browser will pass STS to O365 federation gateway, it will accept it and generate new STS and grant access to mailbox. This process is very seamless and do not require user intervention (password prompt).

https://support.microsoft.com/en-us/kb/2535227

Access to O365 web app from External network

  1. Client tries to access O365 mailbox via web app (see numbering in Yellow)
  2. O365 mailbox only trusts Microsoft federation gateway, it requests authentication from MS federation gateway via Websso
  3. Microsoft federation gateway redirect user to Adfs URL, user gets connected to Adfs proxy server from internet and provide authentication.

          Once authenticated, Adfs will generate STS along with UPN claim and pass it to user   via browser and redirect user to O365 portal. Browser will pass STS to O365 federation  gateway, it will accept it and generate new STS and grant access to mailbox.
Note: Addition of Adfs url in intranet zone will not help here because IE cannot pass credentials to Adfs Proxy URL and you have to enter credentials on Adfs Proxy authentication page. (Adfs Proxy URL accepts only form based authentication and not windows integrated authentication).

————————————————————————————————————————

What happens if Adfs / Adfs proxy server gone down
Users will simply not able to access O365 services (mailbox)
There is command you can use to convert federated domain to standard one (turn off Adfs authentication and switch back to cloud only authentication).

Convert-MsolDomainToStandard -DomainName contoso.com –SkipUserConversion $true –PasswordFile C:\temp.txt

But above command cannot convert MSOL domain to standard because it requires that Adfs server infrastructure must be online. You will get error as shown below.

Convert_MSOLDomainToStandard

The only alternative to this situation is to turn off Adfs authentication by running below command

Set-MsolDomainAuthentication -DomainName contoso.com –Authentication Managed

Above command will allow you to authenticate O365 mailbox with cloud only credentials, however you need to reset user’s password in cloud
You may configure AADSync with Password synchronization and can reset all user passwords with on premise active directory so that on premise user passwords will get synced with cloud identities

———————————————————————————————————————-

Password Sync and Federated Identities
The AADSync password sync feature will not synchronize passwords for users with Federated Identities.

  • If an initially managed user with a password that has been synchronized to the cloud is converted to a federated user and then converted back to a managed user, the password that was initially synchronized is lost.
  • In short even if you keep password sync and federation both, after removing federated authentication, you have to reset user password on premise

https://msdn.microsoft.com/en-us/library/azure/dn246918.aspx

———————————————————————————————————————–

Deploy Adfs infrastructure in Azure
Now you are aware that Adfs servers must be accessible over internet no matter you use outlook from corporate network / Internet.
Its good idea to put Adfs and adfs proxy servers in Azure cloud directly and then publish Adfs Proxy on internet. In this scenario, actually you are creating VPN tunnel between your on premise network and Azure tunnel.
Lets see below diagram:

O365 Architecture5

In diagram Domain controllers, Adfs, Adfs proxy and AADSync all placed in Azure and connected to corporate network over site to site VPN
Now to connect to Adfs server from corporate network there are TWO ways
Either you can connect to Adfs servers private IP through site to site VPN tunnel
OR
you can connect to Adfs proxy servers through internet directly.
You can look numbering in dark blue color for corporate outlook connectivity
Connecting to Adfs server private IP is fine where you have only single site (physical location), however when you have multiple sites, VPN tunnel can be single point of failure.
Hence its recommended to route all Adfs requests from corporate network as well to Adfs proxy server public IP. This will avoid dependency on VPN tunnel.
This will not affect outlook authentication flow because no mater how you authenticate O365 mailbox, you have to store / cache passwords for outlook users
Note that internet must be available to access Adfs Proxy server, you already aware that internet is mandatory to access O365 mailbox also.
In this case, users are able to access O365 mailbox as long as internet is available and even if VPN tunnel is down because Adfs can authenticate users from cloud DCs deployed in Azure.

————————————————————————————————————————

Facts when Moving from 3rd party messaging platforms to O365

When you are moving from 3rd party messaging platforms suchas Lotus Notes and groupware to O365 (Assuming you have on premise active directory), you must deploy on premise Exchange 2013 hybrid server to create mail enabled users and sync them in cloud with AADSync
This is mandatory requirement if you want to keep your deployment and setup in Microsoft Supported scenario.
The below diagram is showing one Exchange 2013 hybrid server deployed on premise.
Microsoft has provided prerequisites when you move from 3rd party on premise messaging platforms to O365 as given below.
Prerequisites:

  1. Subscription to Office 365 (must be an enterprise subscription)
  2. On-premises organization must be running Active Directory with the Microsoft Exchange 2013 database schema updates.
  3. Exchange Management Shell and the Exchange Server Active Directory schema are required for managing email-related users in this scenario. To meet these requirements, you must install the Exchange 2013 Client Access and Mailbox server roles on a server in your on-premises organization. A license for Hybrid Edition of Exchange Server 2013 is available with your Office 365 subscription for enterprises.
  4. Every mailbox in third-party system needs to have corresponding user object in local Active Directory.

You have to follow below article to deploy and configure hybrid Exchange 2013 server on premise:
https://technet.microsoft.com/en-us/library/dn720476(v=exchg.150).aspx

In reality you don’t need full flesh Exchange server.
All you need to do is to extend active directory with exchange 2013 schema updates and put one AAD Sync server
Now you can manually update below AD attributes for respective users and sync them to O365 with AADSync.

  • Mail
  • ProxyAddresses
  • UserPrincipalName
  • TargetAddress
  • MailNickName

This setup works great, but Microsoft do not support this setup from product support stand point. You have to run this setup on your own risk.

I hope this article will be informative for O365 administrators, implementers.

Happy reading

Thanks
Mahesh

Advertisements

1 Comment (+add yours?)

  1. B
    Sep 09, 2016 @ 15:47:45

    Excellent information!

    Reply

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: