In my previous blogpost I discussed Azure AD Connect Pass-Through Authentication (PTA), how it works and how it can be configured. In that blogpost I did not enable Single Sign-On (SSO) and that was also the first comment I got, within one or two days. Enabling SSO and how it works it this blogpost’s topic.
I already explained the authentication flow when using PTA. When accessing a service in Office 365 you are redirected to Azure AD, you enter your credentials and the credentials are placed in the Azure Service Bus. The Azure AD Connect server retrieves these credentials from the Service Bus and presents them to the on-premises Domain Controller. The result is returned to the service bus and you’re granted access, or denied when something is wrong of course.
So, what happens if you enable SSO in the Azure AD Connect wizard? Enabling SSO is just a matter of checking the Enable single sign-on checkbox in the Azure AD Connect wizard:
Note. I skipped most of the configuration steps since this is identical to the configuration steps in the previous blogpost.
During the Azure AD Connect wizard you also must enter your on-premises administrator credentials, these are needed to configure your on-premises Active Directory to enable SSO with PTA.
To be fair, it’s not true SSO as with federation (through ADFS), but it is seamless Single-Sign On (sSSO). When enabling SSO in the Azure AD Connect wizard, users only need to enter their logon name when accessing services in Office 365, for example with Outlook Web App:
When you are on a domain joined workstation that has access to a Domain Controller, you only have to select the appropriate user account. The password is automatically returned to Azure AD and if all is well you are granted access to Outlook Web App.
If you don’t want to select or enter a logon name you can also use domain hints. In combination with Outlook Web App you would use a URL like https://outlook.office.com/owa/contoso.com. If you do so your current credentials (again, on a domain joined workstation that has access to a Domain Controller) are automatically passed through and you are granted access.
Seamless Single-Sign On under the hood
But how does this sSSO actually work under the hood.
When enabling SSO in the Azure AD Connect wizard you have to enter your on-premises domain administrator account. This is used to create an additional computer object in Active Directory called AZUREADSSOACC.
This computer account is used to create a shared Kerberos key between your on-premises Active Directory and Azure Active Directory, needed for creating the sSSO experience.
During logon in this scenario, the following 8 steps occur:
- The client accesses a service in the Microsoft cloud, for example OWA via https://outlook.office.com/owa.
- The request is redirected from Office 365 to Azure Active Directory.
- Access is denied, and a 401 error is returned to the client.
- The client accesses a local Domain Controller and requests a Kerberos token.
- A Kerberos session ticket is returned to the client.
- The session ticket is presented to Azure Active Directory. Since Azure Active Directory has a shared ticket with your on-premises Active Directory is can generate a Kerberos token for the client to use.
- The Kerberos token is returned to the client
- The Kerberos token is presented to Office 365 and access is granted. The user can now start using OWA.
As you can see this only works for domain joined clients that have access to a local Domain Controller. If they don’t have access to a local Domain Controller the regular PTA process as shown in the beginning of this blogpost (and previous blogpost) is followed.
Note. For the client to automatically pass the credentials, the Azure AD endpoints must be in the intranet zone
Tip. Use GPO to change this for all clients in your network.
If you use your browser and navigate to Exchange Online you will still be prompted to enter your username (or select a username when used previously) but you are not required to enter your password:
If you use a domain hint in your URL like https://outlook.office.com/owa/inframan.nl, then the account is automatically logged on. One small but strange note, this is supported by Microsoft Internet Explorer, but not by the Microsoft Edge browser (at least not at the moment of writing, early November 2017). This might change in the future though.
To get this working with Outlook 2016 (or fully patched Outlook 2013 that supports Modern Authentication) we need to enable OAuth on a tenant level. To achieve this, logon use Remote PowerShell in Exchange Online using the following commands:
$Cred= Get-Credential 'firstname.lastname@example.org' $Session= New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/PowerShell-LiveID -Credential $Cred -Authentication Basic -AllowRedirection Import-PSSession -Session $Session
And when logged in enter the following command:
Next time you start Outlook you will see that it will automatically logon to Exchange Online (whereas it didn’t when Oauth was not enabled).
Note. As outlined earlier in this post there’s a shared key between the computer account in your on-premises Active Directory and Azure Active Directory. It is strongly recommended to roll-over these keys every 30 days. For more information check the Microsoft FAQ on this: https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-sso-faq
You can use Pass-through authentication if you have a requirement to keep all user passwords on-premises (and thus not store them in the Microsoft cloud). When using Pass-through authentication you can also enable seamless Single-Sign On or sSSO. This way domain joined clients (that have access to a Domain Controller) can use Kerberos authentication to access services in the Microsoft cloud.
A number of issues to be aware of: not all clients do support PTA or sSSO as outlined in this article. For example, Internet Explorer does support it, but the Edge browser doesn’t. Outlook 2013/2016 do support it (modern authentication) but Outlook 2010 does not. Also, the Lync/Skype for business clients do not support this at all. I expect this to change in the (near) future, and when it does I will update this article.
Azure Active Directory Seamless Single Sign-On: Frequently asked questions – https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-sso-faq
11 thoughts on “Single Sign-On and Azure AD Connect Pass-Through Authentication”
Very helpful! Thanks a lot!
LikeLiked by 1 person
Can we also use SPO domain acceleration for bypassing the username part (instead of ‘smartlink’ ?
Also an idea when S4B Will support modern auth?
“Rommel Kast”? 🙂
I have no idea what “SPO domain acceleration” is (I’m a former Exchange consultant, never worked with SharePoint) but I’m always willing to learn so if you can explain a bit more, then please.
S4B does support modern authentication as in ADFS, but not for PTA, and I’m disappointed it does not. I expect it to be supported anytime soon, but let me ask.
I normally post (a lot 🙂 ) as Trekveer Harry, ok that’s rather strange name too but on my iPhone i cannot use the Facebook login method on your blog. So i used my Google+ account that you blog does support 🙂
Anyways, i’m also an Exchange consultant but these days with Office 365 we have to broaden our knowledge. SPO Domain Acceleration is described here -> https://support.office.com/en-us/article/Enable-or-disable-auto-acceleration-for-your-SharePoint-Online-tenancy-74985ebf-39e1-4c59-a74a-dcdfd678ef83 , it is a kind of where are you from (domain) principle for ADFS, works like a charm for SPO and the default portal.office.com URL.
I have your blog in my fav so will see when S4B supports PTA then!
Why am I not surprised? But I still don’t know who’s behind Trekveer Harry or Rommel Kast 🙂
I’ll make a note about SPO Domain Acceleration, thanks.
Hi Jaap, Sorry has been a busy Exchange 2013 Hybrid week and some Intune projects. But I work for one of the “better” IT companies in The Netherlands (no not inspark) 😉 You don’t know me so or my name 🙂 just a regular reader/poster.
Its a brilliant article with the relevant details easy to understand. I have a query here, actually 2 of them:
First, you mentioned that Lync/Skype for Business is not supported with PTA. However, this article is from 2017. Any ideas, if skype for business is not supported or its still a No.
Secondly, we use Office applications including Outlook via O365 in the domain environment. When the password for the user is changed every n number of weeks, they have to enter the new password in outlook, skype for business etc (we use password sync). How does this behaviour changes when PTA is deployed?
According to this link this is supported:
Hi Jaap, I have a question with the following scenario:
Customer has a On-prem domain with AD Connect (option PTA on) running, users are synced with Azure AD.
Now i am building a new environment with a complete new AD Forest. Can I use PTA in the new AD forest without installing AD connect until migration for test purpose? In the new AD forest I need to install a netscaler access gateway with the Azure NPS extension for MFA but I don’t know if its possible without AD connect in the new forest to test MFA.
Do you have any idea’s about this scenario?
I’m afraid this wouldn’t work since requests are redirect to the existing forest, based on information from Azure AD. It’s not possible to use multiple forests for authentication purposes (I get similar questions regarding ADFS).