Blog Post

ITOps Talk Blog
4 MIN READ

Deep Dive: Windows hybrid join single-sign-on to Azure Active Directory

SoniaCuff's avatar
SoniaCuff
Icon for Microsoft rankMicrosoft
Aug 03, 2021

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?

 

Pre-requisites

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 an Announce Cred process 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?)

 

The Windows hybrid single sign on process 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.

 

Troubleshooting

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.

 

 

 

 

 

 

 

+----------------------------------------------------------------------+
| Device State                                                         |
+----------------------------------------------------------------------+

             AzureAdJoined : NO
          EnterpriseJoined : NO
              DomainJoined : YES
               Device Name : DESKTOP-123

+----------------------------------------------------------------------+
| Device Details                                                       |
+----------------------------------------------------------------------+

                  DeviceId : 4d908954-123
                Thumbprint : 123
 DeviceCertificateValidity : [ 2020-12-22 10:49:16.000 UTC -- 2030-12-22 11:19:16.000 UTC ]
            KeyContainerId : e308c7cb-123
               KeyProvider : Microsoft Platform Crypto Provider
              TpmProtected : YES
          DeviceAuthStatus : SUCCESS

+----------------------------------------------------------------------+
| SSO State                                                            |
+----------------------------------------------------------------------+

                AzureAdPrt : YES
      AzureAdPrtUpdateTime : 2021-08-03 03:48:51.000 UTC
      AzureAdPrtExpiryTime : 2021-08-17 03:48:50.000 UTC
       AzureAdPrtAuthority : https://login.microsoftonline.com/123
             EnterprisePrt : NO
    EnterprisePrtAuthority : https://123:443/adfs
     AcquirePrtDiagnostics : PRESENT
      Previous Prt Attempt : 2021-08-03 03:48:55.619 UTC
            Attempt Status : 0xc000006d
             User Identity : me@123

 

 

 

 

 

 

 

 

And that's it - a conversation to exchange tokens - validated, encrypted and decrypted!

 

Learn  more

Hybrid Azure AD joined devices

What is a Primary Refresh Token?

Understanding Hybrid Azure AD join and co-management

 

 

Updated Aug 04, 2021
Version 4.0
  • patilp-appmodz's avatar
    patilp-appmodz
    Copper Contributor

    Sonia Cuff Great article. Is there anything similar for how sign in frequency and MFA using conditional access is supposed to work for hybrid AD joined devices? We are finding that sign in frequency doesn't work for domain joined hybrid AD devices. I think i have read all the documentation surrounding this topic but can't find any authoritative info on this one way or other. On non domain joined machine, it seems like the sign in frequency kicks in. Is this issue due to PRT and if so, any workarounds?

     

    Our goal for example is to force MFA for every login for one app using Conditional access and allow other apps to rely on persistent session (ex. 90 days remember setting).

     

    Thanks in advance.

  • fred_educ's avatar
    fred_educ
    Copper Contributor

    Hello,
    In Hybrid AD-Entra joined Windows 11 PC, Office Apps licence activation is blocked by error [2604]; error is not before join AD. What information is change on user profile to blocked internet request, please?

    Regards,

    Fred