This post has been republished via RSS; it originally appeared at: ITOps Talk Blog articles.
In a previous article, we explored the process of logging on to Windows and authenticating with an on-premises Active Directory domain, against a Windows Server domain controller. Many organizations are now using both on-premises and cloud resources, and users want to be able to log on once to access both. But with Azure Active Directory not understanding Active Directory credentials (and vice versa), how does this single sign on process work?
To start with, let us assume that the Windows 10 device you are logging on with is Hybrid Joined. By that I mean the computer account is registered in and managed by Active Directory as the "authoritative source" and you've logged on with your domain credentials (as per the previous linked article). Your organization has connected your Active Directory domain to your Azure Active Directory tenant via Azure AD Connect.
The hybrid join single-sign-on process
The computer's Local Security Authority has already done its thing, using Keberos to authenticate you to the Active Directory Domain.
Then a TransferCredentials() kicks in. This says "hey, other authentication packages, I have these credentials, can you do anything with them?"
Cloud AP, the Cloud Authentication Provider package) knows about Azure AD accounts and says "Sure, I can!" It uses the AAD plugin to go and talk to Azure Active Directory via the OAuth protocol. OAuth is an HTTP-based open standards protocol, used by many different applications and websites.
(EXCEPT if you’ve already logged in recently and that is cached in Windows, then it still honours that login. First we check do I have information already present on this machine to allow that user to be logged on to Azure AD?)
So, we're doing a refresh of your Primary Refresh Token (PRT) which is like the Keberos Ticket Granting Ticket (TGT). You can exchange a valid PRT for tokens for specific services, like Outlook or Teams. And while you're actively using Azure AD supported services, your PRT will refresh automatically every 4 hours.
So what's a PRT?
A PRT is issued to a user on a specific device. It contains a Device ID and a Session Key.
The Device ID is used when your login to Azure AD is protected by Conditional Access, requiring your device to be in a certain state or compliance.
The Session Key is an encrypted, symmetric key generated by the Azure AD authentication service, issued as part of the PRT. The session key validates that you have a current, authenticated session, when your PRT is used to request a token to access an application.
Your session key is encrypted with the public transport key (tkpub) that was generated and sent to Azure AD as part of your original device registration (the very first time you added your Azure AD account to that device). Your session key can only be decrypted by your private transport key (tkpriv) which is secured by the Trusted Platform Module (TPM) on your device. This TPM provides a local, virtualized environment that no other operating system component can access, which is why TPM has become a crucial part of securing the login process.
The session key is used to sign requests for tokens and requests to renew your PRT.
Accessing an application
When you open an application that has Azure Active Directory as its identity provider, another part of the process kicks in.
The application asks the Web Application Manager to go and get a token, and the Azure AD WAM plugin picks up the request.
The WAM plugin uses the PRT to request an access token, signing the token request with the session key that's in the included PRT.
Azure AD validates the session key signature by comparing it against the session key in the PRT, verifies that the device is valid and issues an access token and a refresh token for the application. Azure AD can also issue a new, refreshed PRT.
The WAM plugin then asks the Cloud AP to decrypt the tokens (which in turn asks the TPM to decrypt them with the session key), and the WAM gets back the decrypted tokens. It gives the access token to the application, re-encrypts the application refresh token with a Data Protection API (DPAPI) and stores that in its own cache.
It also hands the new PRT to the Cloud AP, which validates it with Azure AD then updates its cache with the new PRT.
If you want to see some of the details of your device and single-sign-on status, the command dsregcmd /status can be used to display details or to force a refresh of your PRT. (Details in the example below have been removed or altered).
For more information, visit Troubleshooting devices with the dsregcmd command.
And that's it - a conversation to exchange tokens - validated, encrypted and decrypted!