The eighth part of John Craddock’s series into Azure Active Directory shows you how to integrate on-premise Active Directory identities with your Azure AD. Once we have represented the on-premise users within the Azure AD, it is a matter of how we authentication the users and here there are some choices including AD FS, Pass-through Authentication (PTA) and Password Hash Synchronization (PHS).
As I write this blog, I am just I am about to jump on a plane to speak at Microsoft Ignite 2017. My two sessions are:
BRK 3015 Deep-dive: Azure Active Directory Authentication and Single-Sign-On
THR3088 A quick guide to modern authentication protocols
In addition to the two technical sessions, I am doing a couple of Microsoft Ignite introduction sessions with Andy Malone. When putting together some slides, I realised the first TechEd I attended was in the UK in 1994, the one and only UK TechEd!
In this series, I will take you through the key aspects of Azure Active Directory, and you will discover how by using Azure AD you can build identity solutions for the future. The series is about the technology rather than the marketing hype. It’s also something I cover in more depth in my masterclass, which is a deep-dive into the technologies and goes into the real technical detail. For an introduction to this series and some background on myself, see Episode 1: Introductions all round.
Caveat: To the best of my knowledge the information was accurate at the time of writing this blog but changes to Azure AD and the portals are frequently happening, and the precise details may change. The reality is that a lot has changed since I started writing the series. However, the principals remain the same.
Episode 8: Integrating with on-premises AD and AD FS
My BRK 3015 Deep-dive: Azure Active Directory Authentication and Single-Sign-On session will bring you right up-to-date on the topic of this very blog, and I recommend you view the recording on Channel 9 for more details when it becomes available. For those who want a quick synopsis, read on.
I can create a user directly in Azure AD, and this user will be a cloud-only user that can authenticate with Azure AD and leverage all the benefits of SSO to a plethora of applications. Applications which can be selected from the Gallery, registered by our own organisation or register by a different organisation. If a Windows 10 device is used by the user, that device can be Azure AD joined to provided additional SSO benefits and enhance security through Windows Hello.
Your first job is to synchronise your AD users into the Azure AD so that the benefits of Azure AD can be realised. When one of your users attempts to authenticate to Azure AD, they can be identified as an on-premises AD user, and the chosen authentication mechanism can be processed. Other key benefits of having the users synchronised to the Azure AD are that they can be:
- Added to Azure AD groups
- Assigned to applications
- Assigned a license
- Added as guest users in other directories
- Queried using the Graph API
- Enabled for self-service-password-reset
So how do we synchronise our users into Azure AD? The answer is Azure AD Connect; this is a synchronisation engine as shown in Figure 1.
Figure 1: Azure AD Connect
Azure AD Connect is way more than just a synchronisation engine, it provides:
- Write-back for passwords, devices and groups
- Health monitoring, reported by Azure AD Connect Health
- Health agents are also available for AD FS and on-premises AD
- A choice of sign-in options which can be seen in Figure 2
Figure 2: Sign-in options
Our options for authenticating the user are Password Hash Synchronization (PHS), Pass-through Authentication (PTA), AD FS or a third-party federated solution (select 'Do not configure'). Seamless SSO (sSSO) can be used in combination with PHS and PTA.
Sign-in via AD FS
I want to start with AD FS, as this method has been chosen in the past for providing the best user SSO experience and the being most secure solution. With AD FS sign-in enabled, when a user attempts to sign-in and as soon as the user enters their sign-in name, Azure AD detects the user’s domain and redirects the user to the AD FS server that manages authentication for their domain. If the user is connected to their corporate network, a Kerberos token will be automatically obtained for accesses to the AD FS server, and the user will not be prompted for any credentials. If the user is connecting to AD FS via a proxy, they will be prompted for credentials. AD FS will create a security token that identifies the user as authenticated, and this token is passed back to Azure AD as proof of authentication. Azure AD can then produce a token to provide the user access to the protected resource. This flow can be seen in Figure 3.
Figure 3: Federated sign in
In the list below I have shown the originally perceived advantages of AD FS, but things have changed, and I have added the changes in blue italic.
- SSO via on-premises AD credentials
- Seamlessly authenticate to AD FS when the client is attached to the corporate network
- Now supported by Seamless SSO for PHS and PTA
- Passwords remain on-premises
- Now supported via PTA
- On-premises authentication policies
- Now supported via PTA
- On-premises authentication methods (multi-factor)
- Conditional access via AD FS
- Capabilities++ provided by Azure AD
- Seamlessly authenticate to AD FS when the client is attached to the corporate network
The only remaining advantage of AD FS is that we can use on-premise authentication methods, so if you have invested heavily in an on-premises MFA solution, this could be for you.
The disadvantages of AD FS are the requirements for:
- On-premises AD FS infrastructure with high-availability
- High-availability for the company’s Internet connection
- Remote workers will not be able to authenticate to Azure AD If the link is down
- Planned recovery from the loss of AD FS availability
- Ongoing certificate maintenance
Password hash synchronisation
Microsoft didn’t do themselves any favours when they announced this technology as password synchronisation. Chief Security Offices were seen to tear their hair out while screaming “No way are my passwords going to be synchronised into Azure AD”. Finally, it was documented as to how the synchronisation was implemented. To summarise in a nutshell, before leaving your network the on-premises MD4 password hash is expanded, salted and input to a password-based key derived function (RFC 2898) which performers 1000 iterations of HMAC-SHA256. Even if the password hashes are stolen, they are protected against Rainbow attacks due to the salt and computationally “impossible” to crack within a reasonable time. Of course, nothing is impossible to crack, but this will be secure enough for most organisations.
PHS the facts:
- On-premises password complexity applies to synchronised users
- If an administrator changes the cloud password using PowerShell, the Azure AD password policy applies
- An expired/disabled on-premises account can still be active in the cloud
- The cloud password for a PHS user is set to never expire
- Synchronisation of a new password will have no impact on a user signed into Azure AD
- Password synchronisation can be used in addition to federation and used as a fall-back
- Provided your CSO can keep her/his hair!
Pass-through authentication
As part of PTA, an AuthN agent is deployed on Premises, Figure 4.
Figure 4: Pass-through authentication
The agent securely connects to the Azure AD, and sign-in requests are sent from Azure AD to the on-premises agent. The agent then uses the Win32 LogonUser API to attempt to log the user onto the on-premises AD. The results of the API call: success, username/password incorrect, password expired, account locked out… are returned to Azure AD.
PTA the facts:
- No on-premises passwords in the cloud
- All on-premises password policies operational
- Account expired/disabled operational
- Does not support on-premises MFA
- Azure AD MFA supported
- Works with Alternate ID
- Does not provide SSO for on-premises credentials
- Requires Seamless SSO
- Requires high-availability for the company’s Internet connection
- Remote workers will not be able to authenticate to Azure AD If the link is down
Seamless SSO
Seamless SSO works by allowing a Kerberos token to be used to authenticate to Azure AD. When the client accesses the authentication endpoint, if SSO is enabled, Javascript is deployed to the browser and this tests to see if the browser is capable of SSO. If the browser is capable, Azure AD returns an HTTP 401 to the browser telling the browser to perform Windows Integrated Authentication (WIA). The browser then obtains a Kerberos token for Azure AD.
For this to work, when SSO is enabled a dummy computer account object is created in the on-premises AD, this object holds the SPNs of the Azure AD endpoints and a Kerberos key that is shared with Azure AD. When the browser performs WIA, it makes a request to the on-premises AD for a Kerberos token to the SPN represented by the endpoint. The AD creates the token and encrypts it with the key on the dummy computer account. Azure AD can then validate the Kerberos token with its own key.
SSO the facts:
- Works with pass-through authentication or password sync
- Users only need to type their name to authenticate to Azure AD
- It is possible for applications to pass a login_hint for seamless SSO
- Supports Windows 7 and above
- Windows 10 Edge not currently supported
- Machine must be domain joined and have access to a DC
- On corporate network or via remote access technology
- Authenticates to Azure AD with a Kerberos token
- Available with all versions of Azure AD
- Supports Alternate ID
- Support for multiple browsers and OSs
- Including Safari and Mac
Here’s my summary table that I created, I’m really pleased with it 
.
And some recommendations:
- New customers:
- Use cloud authentication (PTA or PHS)
- Leverage conditional access and Azure AD MFA
- If AD FS is deployed to support on-premises applications, consider managing authentication for those apps via Azure AD
- Enable Seamless SSO if you're using PTA or PHS
- Simple to deploy
- Immediately enhances the sign-in experience for your users
- Implement domain_hint
Please watch the Channel 9 video of my Microsoft Ignite Session BRK 3015 Deep-dive: Azure Active Directory Authentication and Single-Sign-On. That’s it until next time.
For details of all the episodes in this series, look here. To learn and become skilled in implementing identity systems based on Azure AD, on-premises AD and AD FS join me at one of my Masterclasses. To find out more visit XTSeminars.