In a previous post I talked about the three ways to setup Windows 10 devices for work with Azure AD. I later covered in detail how Azure AD Join and auto-registration to Azure AD of Windows 10 domain joined devices work, and in an extra post I explained how Windows Hello for Business (a.k.a. Microsoft Passport for Work) works. In this post I will cover how Single Sign-On (SSO) works once devices are registered with Azure AD for domain joined, Azure AD joined or personal registered devices via Add Work or School Account.
SSO in Windows 10 works for the following types of applications:
- Azure AD connected applications, including Office 365, SaaS apps, applications published through the Azure AD application proxy and LOB custom applications integrating with Azure AD.
- Windows Integrated authentication apps and services.
- AD FS applications when using AD FS in Windows Server 2016.
The Primary Refresh Token
SSO relies on special tokens obtained for each of the types of applications above. These are in turn used to obtain access tokens to specific applications. In the traditional Windows Integrated authentication case using Kerberos, this token is a Kerberos TGT (ticket-granting ticket). For Azure AD and AD FS applications we call this a Primary Refresh Token (PRT). This is a JSON Web Token containing claims about both the user and the device.
The PRT is initially obtained during Windows Logon (user sign-in/unlock) in a similar way the Kerberos TGT is obtained. This is true for both Azure AD joined and domain joined devices. In personal devices registered with Azure AD, the PRT is initially obtained upon Add Work or School Account (in a personal device the account to unlock the device is not the work account but a consumer account e.g. hotmail.com, live.com, outlook.com, etc.).
The PRT is needed for SSO. Without it, the user will be prompted for credentials when accessing applications every time. Please also note that the PRT contains information about the device. This means that if you have any device-based conditional access policy set on an application, without the PRT, access will be denied.
PRT validity
The PRT has a validity of 90 days with a 14 day sliding window. If the PRT is constantly used for obtaining tokens to access applications it will be valid for the full 90 days. After 90 days it expires and a new PRT needs to be obtained. If the PRT has not been used in a period of 14 days, the PRT expires and a new one needs to be obtained. Conditions that force expiration of the PRT outside of these conditions include events like user’s password change/reset.
For domain joined and Azure AD joined devices, renewal of the PRT is attempted every 4 hours. This means that the first sign-in/unlock, 4 hours after the PRT was obtained, a new PRT is attempted to be obtained.
Now, there is a caveat for domain joined devices. Attempting to get a new PRT only happens if the device has a line of sight to a DC (for a Kerberos full network logon which triggers also the Azure AD logon). This is a behavior we want to change and hope to make for the next update of Windows. This would mean that even if the user goes off the corporate network, the PRT can be updated. The implication of this behavior today, is that a domain joined device needs to come into the corporate network (either physically or via VPN) at least once every 14 days.
Domain joined/Azure AD joined devices and SSO
The following step-by-step shows how the PRT is obtained and how it is used for SSO. The diagram shows the flow in parallel to the long standing Windows Integrated authentication flow for reference and comparison.
(1) User enter credentials in the Window Logon UI
In the Windows Logon UI the user enters credentials to sign-in/unlock the device. The credentials are obtained by a Credential Provider. If using username and password the Credential Provider for username and password is used, if using Windows Hello for Business (PIN or bio-gesture), the Credential Provider for PIN, fingerprint or face recognition is used.
(2) Credentials are passed to the Cloud AP Azure AD plug-in for authentication
The Credential Provider gets the credentials to WinLogon which will call LsaLogonUser() API with the user credentials (to learn about the authentication architecture in Windows see Credentials Processes in Windows Authentication). The credentials get to a new component in Windows 10 called the Cloud Authentication Provider (Cloud AP). This is a plug-in based component running inside the LSASS (Local Security Authority Subsystem) process with one plug-in being the Azure AD Cloud AP plug-in. For simplicity in the diagram these two are shown as one Cloud AP box.
The plug-in will authenticate the user against Azure AD and AD FS (if Windows Server 2016) to obtain the PRT. The plug-in will know about the Azure AD tenant and the presence of the AD FS by the information cached during device registration time. I explain this at the end of step #2 in the post Azure AD Join: what happens behind the scenes? when the information from the ID Token is obtained and cached just before performing registration (the explanation applies to both to domain joined devices registered with Azure AD and Azure AD joined devices).
(3) Authentication of user and device to get PRT from Azure AD (and AD FS if federated and version of Windows Server 2016)
Depending on what credentials are used the plug-in will obtain the PRT via distinct calls to Azure AD and AD FS.
PRT based in username and password
To obtain the Azure AD PRT using username and password, the plug-in will send the credentials directly to Azure AD (in a non-federated configuration) or to AD FS (if federated). In the federated case, the plug-in will send the credentials to the following WS-trust end-point in AD FS to obtain a SAML token that is then sent to Azure AD.
adfs/services/trust/13/usernamemixed
Note: This post has been updated to reflect that the end-point used is the usernamemixed and not the windowstransport as it was previously stated.
Azure AD will authenticate the user with the credentials obtained (non-federated) or with verifying the SAML token obtained from AD FS (federated). After authentication Azure AD will build a PRT with both user and device claims and will return it to Windows.
PRT based in the Windows Hello for Business credential
To obtain the Azure AD PRT using the Windows Hello for Business credential, the plug-in will send a message to Azure AD to which it will respond with a nonce. The plug-in will respond with the nonce signed with the Windows Hello for Business credential key.
Azure AD will authenticate the user by checking the signature based on the public key that it registered at credential provisioning as explained in the post Azure AD and Microsoft Passport for Work in Windows 10 (please note that Windows Hello for Business is the new name for Microsoft Passport for Work). The PRT will contain information about the user and the device as well, however a difference with the PRT obtained using username and password is that this one will contain a “strong authentication” claim.
"acr":"2"
Regardless of how the PRT was obtained, a session key is included in the response which is encrypted to the Kstk (one of the keys provisioned during device registration as explained in step #4 in the post Azure AD Join: what happens behind the scenes?).
The session key is decrypted by the plug-in and imported to the TPM using the Kstk. Upon re-authentication the PRT is sent over to Azure AD signed using a derived version of the previously imported session key stored in the TPM which Azure AD can verify. This way we are bounding the PRT to the physical device reducing the risk of PRT theft.
(4) Cache of the PRT for the Web Account Manager to access it during app authentication
Once the PRT is obtained it is cached in the Local Security Authority (LSA). It is accessible by the Web Account Manager which is also a plug-in based component that provides an API for applications to get tokens from a given Identity Provider (IdP). It can access the PRT through the Cloud AP (who has access to the PRT) which checks for a particular application identifier for the Web Account Manager. There is a plug-in for the Web Account Manager that implements the logic to obtain tokens from Azure AD and AD FS (if AD FS in Windows Server 2016).
You can see whether a PRT was obtained after sign-in/unlock by checking the output of the following command.
dsregcmd.exe /status
Under the ‘User State’ section check the value for AzureAdPrt which must be YES.
A value of NO will indicate that no PRT was obtained. The user won’t have SSO and will be blocked from accessing service applications that are protected using device-based conditional access policy.
A note on troubleshooting
To troubleshoot why the PRT is not obtained can be a topic for a full post, however one test you can do is to check whether that same user can authenticate to Office 365, say via browser to SharePoint Online, from a domain joined computer without being prompted for credentials. If the UPN suffix of users in Active Directory on-premises don’t route to the verified domain (alternate login ID) please make sure you have the appropriate issuance transform rule(s) in AD FS for the ImmutableID claim.
One other reason that I have seen PRT not being obtained, is when the device has a bad transport key (Kstk). I have seen this in devices that have been registered in a very early version of Windows (which upgraded to 1607 eventually). As the PRT is protected using a key in the TPM this could be a reason why the PRT is not obtained at all. One remediation for this case is to reset the TPM and let the device register again.
(5, 6 and 7) Application requests access token to Web Account Manager for a given application service
When a client application connects to a service application that relies in Azure AD for authentication (for example the Outlook app connecting to Office 365 Exchange Online) the application will request a token to the Web Account Manager using its API.
The Web Account Manager calls the Azure AD plug-in which in turn uses the PRT to obtain an access token for the service application in question (5).
There are two interfaces in particular that are important to note. One that permits an application get a token silently, which will use the PRT to obtain an access token silently if it can. If it can’t, it will return a code to the caller application telling it that UI interaction is required. This could happen for multiple reasons including the PRT has expired or when MFA authentication for the user is required, etc. Once the caller application receives this code, it will be able to call a separate API that will display a web control for the user to interact.
WinRT API
WebAuthenticationCoreManager.GetTokenSilentlyAsync(...) // Silent API WebAuthenticationCoreManager.RequestTokenAsync(...) // User interaction API
Win32 API
IWebAuthenticationCoreManagerStatics::GetTokenSilentlyAsync(...) // Silent API IWebAuthenticationCoreManagerInterop::RequestTokenForWindowAsync(...) // UI API
After returning the access token to the application (6), the client application will use the access token to get access to the service application (7).
Browser SSO
When the user accesses a service application via Microsoft Edge or Internet Explorer the application will redirect the browser to the Azure AD authentication URL. At this point, the request is intercepted via URLMON and the PRT gets included in the request. After authentications succeeds, Azure AD sends back a cookie that will contain SSO information for future requests. Please note that support for Google Chrome is available since the Creators update of Windows 10 (version 1703) via the Windows 10 Accounts Google Chrome extension.
Note: This post has been updated to state the support for Google Chrome in Windows 10.
Final thoughts
Remember that registering your domain joined computers with Azure AD (i.e. becoming Hybrid Azure AD joined) will give you instant benefits and it is likely you have everything you need to do it. Also, if you are thinking in deploying Azure AD joined devices you will start enjoying some additional benefits that come with it.
Please let me know you thoughts and stay tuned for other posts related to device-based conditional access and other related topics.
See you soon,
Jairo Cadena (Twitter: @JairoC_AzureAD)
Devices, Security and Identity in #Microsoft365 by Jairo Cadena 
Great post as always Jairo. Thank you! Do you have an eta on Chrome support?
LikeLike
Also interested in ETA on Chrome support
LikeLike
What Azure AD license is required for auto-registration to Azure AD of Windows 10 domain joined devices to work? We have O365 AzureAD is that enough or is Premium required?
LikeLike
Hi Jairo,
Thanks for the very detailed article.
One thing I can’t understand is the PRT validity time. Maybe I’m a little bit slow here…
Is my understanding right…
On personal registered devices via Add Work or School Account,
1. The initial PRT is obtained during Add Work or School Account process.
2. It’s valid for full 90 days only if I access an AzureAD protected resource during the first 14 days. One AzureAD protected resource will be enough.
3. New PRT will only be obtained if the initial expired which mean after 90 days or 14 days.
On devices that are registered Azure AD for domain joined or Azure AD joined.
1. The initial PRT is obtained during first Sign-on/Unlock if the previous one has not expired.
2. It’s valid for full 90 days, but the end-user doesn’t need to access an AzureAD protected resource during the first 14 days to have full life time of 90 day. The reason being is that it’s all handle silently and automatically by Windows every 4 hours.
Question. Regarding #3 in the personal registered devices via Add Work or School Account. What will the end-user experience be if I’m signed in to my desktop and try to access AzureAD protected resource with a PRT that just got expired?
Question. From an Admin Point view what do I have to do to revoke the Credentials. Will it suffice to disable the User Account In Azure AD? Is there something more that has to be done on the device side?
LikeLike
Hi Jairo,
Thanks for such detailed articles on this topic. I’m having issues getting my domain-joined Windows 10 PCs to join Azure AD. Your articles (and comments) have helped get me past some initial bumps, but I seem to have hit a roadblock.
In my environment, I’m using Azure AD Connect to sync our local AD users to Azure AD, and we use ADFS for authentication. I followed Microsoft’s documentation to add the additional required claims rules to the relying party trust, enable the ‘adfs/services/trust/13/windowstransport’ endpoint, configured group policy to register the PCs as devices, etc.
But in the User Device Registration logs on my PC I’m seeing a few token-related errors:
* Error 305: Automatic registration failed at authentication phase. Unable to acquire access token.
* Error 304: Automatic registration failed at join phase.
* Warning 308: This Device is joined to Azure AD, however, the user did not sign-in with an Azure AD account. Microsoft Passport provisioning will not be enabled.
The user account I’m logging into my PC with is a local AD user account that is synced to Azure AD with Azure AD Connect.
In contradiction to the Warning 308 that gets logged, when I run ‘dsregcmd /status’, it’s showing the device as “AzureAdJoined: NO”, my user as “IsUserAzureAD: NO”
Not sure what I’m doing wrong. I’d appreciate any light you can shed on this.
Thanks
LikeLike
I am having the same issue. Has this been resolved for you?
LikeLike
same problem here also, any updates?
LikeLike
Have you made sure that you sync the computer objects that you are trying to register?
LikeLike
Pingback: (2016-12-16) Automatic Azure AD Join With ADFS v3.0 And Higher And Conditional Access – What You Really Need In Detail « Jorge's Quest For Knowledge!
Pingback: (2016-12-28) Joining Devices To Azure AD – The Options And The Differences « Jorge's Quest For Knowledge!
What happens to an interactive windows 10 login if the domain is federated to a third party IdP? To detail the use case- I’ve got a cloud-only set-up. Our users are in Office 365/Azure AD. I’ve configured Office 365 to use a third party IdP- OneLogin. So when a user logs into Office 365, all requests are forwarded to OneLogin to authenticate the user.
What happens to the user logging into the Azure AD joined device? If they log in with an Azure AD account, but the tenant is federated to OneLogin, against what name and password will the windows login be done? It would be great if it were federated as well, but I suspect that’s not really built out…
Pls. advise.
LikeLike
Any idea how to change the user authentication pin length requirement for Azure AD joined devices? Once a device is joined to AzureAD w/O365, the default pin goes from 4 to 6 digits. Would like to change it back to 4.
LikeLike
The only way I’ve been able to change any of those settings is via Policy editor, locally on the machine. AFAIK, you can’t push a group policy out to domain machines using Azure AD / InTune, so I’ve had to set any of those PIN policies directly on each machine using
LikeLike
Hi cairo, very very interesting article.
I ‘v a question
We have on-premise AD federated domain with azure, ADconnect for sync et password write back enabled. So we have ADFS 3.0 on-premise relying trust with SAAS application.
ow we have integrated à workstation windows 10 totally in Azure (Azure Ad join) and configured Service now application in azure portal application, i settings application for use SSO on premise.
But when i’m connected on workstation with azure AD account, SSO work fine for Office 365 but when i started the service now app in office 365 portal (myapps.microsoft.com) i’m redirect to STS but SSO not work i’m prompted, if i enter my UPN and password, the app work fine.
i don’t have enable the endpoint ADFS on-prem : /adfs/services/trust/13/windowstransport.
you have an idea ?
thx
LikeLike
Hi FDZ,
I have the same issue. I was wondering if you managed to implement SSO to work with apps accessed through the browser?
Thanks
LikeLike
Hi Jairo,
very good series of articles, thank you.
Our clients are AAD-joined-only, there is no line of sight to a KDC. Users are federated, so password logons are based on ADFS.
As I know, the endpoint “adfs/services/trust/13/windowstransport” will only be used by domain-joined clients. AAD-joined device logins use the endpoint “/adfs/services/trust/13/usernamemixed”, if the user-login is done with username/password.
I think this is the same process as with EXOL and ActiveSync – AAD / EXOL will get the ticket on-behalf of the user. The credential providers from AAD-joined clients have no idea what ADFS is. Is this correct ?
A critical point in this scenario is resetting the user password. Normally, this is done with setting the user flag “user must change password at next logon”. ADFS will deny requests with “user must change the password before logon” (what a surprise). The client denies password-logons with “user or password is wrong” (really a surprise) because it has no information about the flag and the AAD-request is not successful. Logon with Hello or cached credentials (client offline, old password) works. If the user does not know PIN and password, you have to reset the password without setting the Flag “user must CHGPWD at next logon”.
Is there a chance to change the password of federated users at client-logon ?
Another tricky thing are cached credentials. As I mean, logons with Hello will never update cached credentials.
Users can / must change the password using the ADFS-change-pwd-URL, which is accessed via Internet Explorer. The client logon is normally always done with Hello PIN. After one or more pwd changes, the user is not able to logon with his actual password in that case the client is offline and the user can not remember the PIN. This scenario cames up when you use Intune / NDES to connect the client to LAN based on certificates or the user is in a hotel with WLAN-captive-portal.
I except the only way to get the user logged on with the new password is getting the client online on a free LAN.
Do you see a way to update the cached creds while using Hello ?
Otherwise, if the user has changed his password on ADFS, he have to do a password logon on the client.
Thanks for your help.
Dominique
LikeLike
Pingback: Windows 10 Domain Join + AAD and MFA Trusted IPs | Kloud Blog
Pingback: #AzureAD device-based conditional access and #Windows 7/8.1 | [Azure] Active Directory by Jairo Cadena
Hi Jairo,
Thank you for your blog, it’s very instructive for me.
I have one question : When the user (or machine depending on the case) certificate issued by MS-Organisation-Access is used ? You explained in another post how this one is issued but I can’t find in which step it is used.
I’m also trying to understand when WS-Trust, and which WS-Trust endpoint (usernamemixed or windowstransport) for either user or machine.
So, my assumption is the following (in a hybrid AAD/AD context with federated domain)
– On registration : Device authenticates against the WS-Trust with the kerberos token, thus on windowstransport endpoint. I assume that’s the case from W7 to W10.
– Once registration of the device is done:
– For W7, a client certificate is issued for the user, including device id
– For W10, a client certificate is issed for the machine, including device id
Regarding authentication:
You said “Azure AD will authenticate the user with the credentials obtained (non-federated) or with verifying the SAML token obtained from AD FS (federated). After authentication Azure AD will build a PRT with both user and device claims and will return it to Windows.”
In my case (federated), I guess it’s actually done in two steps:
1. Calling the WS-Trust endpoint, either the usernamemixed if no KDC is there, or windowstransport endpoint if KDC is there (and we have a kerberos token for the matching realm)
2. Once we have a SAML user token, challenging device authentication on Azure TLS endpoint (https://login.microsoftonline.com/common/DeviceAuthTls/ ?), requesting for a client certificate signed by MS-Organisation-Access Certificate Authority.
For W7, I guess this is done in WEB-SSO mode, meaning only from a browser (executed in a user context, so using the user certificate) when logging to Azure services.
For W10… no idea what it’s actually done, I wonder if SYSTEM (thus using the machine certificate) is doing it while the user is logging in W10.
3. PRT is build with both user and device information, and returns claims to Windows.
LikeLike
The MS-Organization-Access issued certificate is the device certificate issued by Azure AD during device registration. It is the identifier passed during auth requests to Azure AD to authenticate the device.
Authentication to Windows when the user enters credentials and these are used to obtain the PRT. Along with the user credentials, the device certificate is sent to Azure AD and after authentication of both the user and device the PRT is issued back with claims for both the user and device identities.
After sign-in it is mainly the PRT that is used. The Web Account Manager which has access to the PRT will include it at any time an authentication request is sent to Azure AD so Azure AD knows authenticates both user and device. Apps using the Web Account Manager API will use this. Browser apps sign-in to Azure AD get the PRT from the Web Account Manager and puts it in the authentication request to Azure AD.
In the case the Web Account Manager needs to do a force authentication (due to an app requesting so, or a force expiration of tokens for example) the Web Account Manager will have access to the device certificate to do a full fresh sign-in to Azure AD so along with the user creds obtained in a web view the cert is sent to Azure AD.
In respect to the end-points used in AD FS for authentication during registration you are mainly right in your assumptions with some clarifications:
1. Registration of Win10 uses the windowstransport end-point indeed for authentication prior to registration. Win7 authentication for registration doesn’t rely on WS-Trust but rather on WS-Fed. It uses a hidden Internet Explorer window to do a federated passive flow (in AD FS this is the adfs/ls end-point).
2. You are right about the certificates issued to the user context (Win7) and to the computer context (Win10). The certificate thumbprint is what is stored in the device object in Azure AD and what is used to find the device during authentication. So the thumbprint is the identifier of that device to Azure AD (you can see the thumbprint in the output of dsregcmd.exe /status). The device ID is part of the subject of the certificate.
About authentication of user and device after registration you are also mainly correct. Let me do some clarifications:
1. In Win10, during user auth to Windows (WinLogon), we send user credentials to the usernamemixed end-point only (we don’t rely on the windowstransport) get the SAML token and send it to Azure AD along with the device certificate via an OAuth auth request. This is not a passive flow so the device TLS end-point is not involved. Once this completes Windows gets the PRT and afterwards it is the PRT (which contains both user and device claims) that is used as I explained at the top of my response.
2. Win7 doesn’t do authentication to Azure AD during user sign-in to Windows (WinLogon). Built-in SSO is only available in Win10. When the user signs-in to Azure AD afterwards, passive authentication is used (either a browser or an ADAL web view) so in this case the device TLS end-point is indeed used.
LikeLike
Thanks a lot Jairo for your clarifications.
One point is still not clear for me for device registration in W7 😦
So W7 uses WS-Fed authentication protocol with IWA (managed by the hidden IE) so that it is transparent under the user context.
Autoworkplace is then a process than run under the interactive user. Assuming the fact that the device is authenticated with IWA, I don’t understand how a user process can do that. Is there an elevation of privileges with the LOCAL SYSTEM account inside the process ?
LikeLike
You sir are brilliant. Thank you so much for taking the time to explain the variety of MS technologies and enabling IT professionals reading this making life a lot easier. Very much so appreciated, please keep up the good work.
LikeLiked by 1 person
Thanks your for this Article Jairo! very usefull. To share with French people and with your permission i have made a french version. thanks
LikeLiked by 1 person
Pingback: Comment fonctionne le SSO avec les périphériques Windows 10 « Office Servers and Services
Jairo, I have a WPJ machine and I cannot see the PRT cached for the user through the “dsregcmd.exe /status”, still SSO is working, was there any behavior change? When I activate my Office ProPlus subscription it will perform a WPJ of the device and SSO will start to happen, on a scenario where we have shared devices, the SSO will always happen, regardless the user authenticated on the machine, with the first person who WPJ the device, how should we proceed in such scenario? Is there an easy way to disable/prevent WPJ devices? Besides the “User may register their devices..” in AAD?
LikeLike
Jairo states, “To troubleshoot why the PRT is not obtained can be a topic for a full post.” I need that post!!! XD Any chance of some assistance? I realize this article is a tad dated.
LikeLike
Pingback: Setting up Windows Hello for Business with Intune – Micro-Scott – Blogging Windows and Device Management
Thanks, Jairo,
“In the federated case, the plug-in will send the credentials to the following WS-trust end-point in AD FS to obtain a SAML token that is then sent to Azure AD”
adfs/services/trust/13/usernamemixed
What about for using 3rd party IDP federation instead of ADFS? Any configuration to modify the WS-trust end-point string?
LikeLike
Well, we discover the WS-trust end-point via the STS MEX file. In the case of AD FS the end-point mentioned in the post that you refer to is the one, but for others we will use whatever end-point shows in the MEX filed published by the STS.
LikeLike
Jairo,
In the consequent process of re-authentication or app token request, how does Azure AD retrieve the user/device’s session key to decrypt the PRT which is sent back to it and encrypted with the session key? Does Azure AD store the session key per user/device somewhere in the directory? Or does Azure AD actually include a copy of the session key within the PRT and encrypt it with something which is only known to itself?
(In Kerberos, we know the DC just saves the session key within the TGT, and it can simply retrieve the session key by decrypting the TGT with its own secret once the TGT is sent back from the client along with the TGS request.)
Thanks.
LikeLike
Hi Sean, upon device registration, along with the certificate issued for the device identity, an additional asymmetric key is generated (Kstk or storage key). The public portion of the key pair is stored in the device object in Azure AD. This key is the one that protects the session keys generated upon authentication. So when a new session key is generated (for example when the PRT is issued), it is sent to Windows encrypted with the Kstk [public] which then Windows stores in the TPM (using the Kstk [private]). Session keys are derived from previous ones using random salts upon subsequent authentications (e.g. getting an access token from the PRT).
LikeLike
Hi, Jairo,
Thanks for replying.
” Upon re-authentication the PRT is sent over to Azure AD signed using a derived version of the previously imported session key stored in the TPM which Azure AD can verify” – So it means, during the subsequent re-authentication or request for access tokens, the authenticator(re-using the Kerberos term here) which the client sends to Azure AD should also contain something like below:
{PRT}Keysession + {KeySession}Kstk, where {} stands for being encrypted/signed by.
Thus Azure AD itself doesn’t need to store the session key somewhere. Is my understanding correct?
Thanks again.
Sean
LikeLike
Hi Jairo,
First of all thanks for this brilliant post.
We have issues in an Alternate Login scenario, i.e. our local AD UPNs (contoso.local) differ from AAD tenant domain (contoso.com). Everything works fine except for CondAccess on W10 because we cannot get PRT. Fiddler showed me that system (I assume it’s Cloud AP) queries Azure tenant information for internal UPN (contoso.local). Any way to fix this? Is this a known issue? Or have you seen other environments where this works?
Thanks a lot, Michael
LikeLike
Hi Michael, this is a known issue that we are fixing in the next update of Windows. In an alternate-login-ID environment, sign-in to Azure AD upon Windows logon fails (the PRT is not obtained) therefore failing access to resources protected with device-based conditional access policies. If you are curious why, this is because we are currently relying on the local UPN suffix to do user-realm discovery at WinLogon time to find where to send the credentials for authentication (in the federated case, knowing the AD FS/on-prem-STS to go first). We are solving this case by introducing a policy (registry key) that you can set in the organization to override the domain suffix for discovery. Once we find the right IdP (Identity Provider) the rest will work.
LikeLike
Hi Jairo, thanks a lot for your detailed answer. Highly appreciated.
LikeLike
Hi Jairo, I now had a chance to test W10 1803 device registration which seems to work now with Alternate UPN scenario. Looks like the AD SCP is now used for constructing the “user@domain” lookup in order to identify the right STS (was previously done using logged in user’s UPN). I still have one issue: One of our domains is federated with a different ADFS server than the other – but the SCP is a forest wide entry. Is there a registry key (as you mentioned in your first reply) such that we can override forest wide SCP for machines of that domain? Haven’t found any documentation on such.
KR Michael
LikeLike
Great write up Jairo
LikeLiked by 1 person
Hi Jairo
Is it enough that PRT is used just one time to retrieve an access token during the 14 day sliding window to make the PRT valid for it’ s full lifetime.
LikeLike
Yes, as soon as the PRT is used the window slides from that point. But also remember that a new PRT is attempted to be obtained every 4 hours upon Windows unlock. This behavior means that if you use your device while connected to the Internet, in general, you will have a PRT 4 hours old at the most. If you go on vacation for two weeks, upon sign in to Windows you’ll get a new PRT. So in other words, although the behavior on the authentication service side is to constrain the refresh tokens as the PRT to 14 and 90 days, the use of them in Windows will make that you will truly have a fresh PRT almost always.
LikeLiked by 1 person
Thanks Jairo. Jut one follow up question on your answer. You mention refreshtokens. Are they also issued on a succesfull authentication to Azure AD? I thougt that in this scenario there is only PRT and couple of access tokens that get issued when accessing an Azure Ad connected application.
LikeLike
Good question. I meant that a PRT, as a “refresh token”, it is subject to same refresh token lifetime policy.
During WinLogon there are two tokens that come back: the PRT and an ID Token that is for consumption of the client. There are no other tokens or refresh tokens. During authentication to an application, the PRT is exchanged by an access token. This happens via the Web Account Manager. The client calls this API to get the access token.
LikeLike
Hi Jairo,
I have a tricky question that I’m trying to understand the WHY.
My Azure AD is federated with on an onprem AD FS 2016.
I’m running Domain Joined Windows 10 Enterprise 10 1709 and they are Azure AD Hybrid Joined.
Everything is working fine. I can see with Dsregcmd /status that a Azure AD PRT is received on the Windows 10 computers. Now comes the WHY…
If open Edge Browser on anyone of the Windows 10 devices and try to access an Azure AD connected WebApp like portal.office.com, I can see that Azure AD device redirects me to my AD FS onprem.
Why Come? I have a PRT that’s valid that should Suffice for Azure AD so I can receive an Access Token. Why does it bounce me back to AD FS? Shouldn’t the WAM intercept this authentication request and provide the PRT to Azure AD?
I’m perfectly alright with AD FS has to be contacted during Initial PRT retrieval because I’m federated which happens during the initial Desktop Logon/Unlock to Windows.
LikeLike
Hmmm… that is certainly a strange behavior. If you have a PRT the browser should reach out to WAM to get the PRT for SSO. This should be true, unless the application is requiring something else that is not met by the PRT. For example if the PRT was obtained with username/password and the application requires MFA then depending where you have your MFA it might redirect you to AD FS. But if the PRT meets the policy, no redirections to AD FS should occur. I can help you taking a look at a Fiddler trace if you have one or can get one.
LikeLike
I re-installed the device, and after that I didn’t see the strange behaviour anymore. I have also verified It with Fiddler, where I can see that when I access for example myapps then In the Azure AD Sign-In request there is Cookie called AADSSO. I belive that refresh_Token is stored there.
LikeLiked by 1 person
Despite the re-install of the device, I still needed to find the reason why I managed to observed the redirect back to AD FS despite I had PRT that i thought where valid. What I found was that we have a shorter Refresh-Token lifetime from the default one in Azure-AD. I rememberd that you said in a earlier reply that the same constraints are applicable for PRT.
Regards Mikael
LikeLike
Hi Jairo,
Please can you clarify. I have a WebApp that’s connected to Azure AD directly. The WebApp is using OpenID Connect. What the WebApp does is that it just outputs all the content from an ID_token to the Web browser.
Here comes the thing I don’t understand. I’m running a Win 10 that’s Hybrid AzureAD Joined. Shouldn’t the ID_token also contain the claims that contains the claims that are specifically used in Device-Bases Conditional Access? I can just see the basic claims + core claims that Azure AD produce during authentication.
Regards Mikael
LikeLike
Hi Jario. I think I mixed things up. Sorry. If my conclusions are right then It’s only the PRT that will include the Device related claims and not the ID_Token. To get a deeper insight and understanding of the PRT retrieval during Winlogon I need to capture the transaction with Azure AD. It seems that it’s not doable with for example Fiddler during Winlogon because it gets started only after the desktop appears.
Regards Mikael
LikeLike
Hi Jairo,
More of the trying to understand. Running Windows 10 Hybrid Azure AD Join and are federated with AD FS. Doing a WinLogon with Username/Password and after that I start fiddler. What I can se is av couple of Post request to common/Oauth/Token Endpoint where the Windows 10 is Posting following
grant_type=srv_challange
redirect_uri = ms-appx-web://Microsoft.AAD.BrokerPlugin/{6F7E0F60-9401-4F5b-98E2-CF15BD5Fd5E3}.
How come? I’m not using Windows Hello for Business yet, so srv_challenge/nonce should not be there.
Kind regards
Mikael
LikeLike
Pingback: Windows Hello for Business: Registration and Authentication with #AzureAD | [Azure] Active Directory by Jairo Cadena
Hi Jairo
Thanks for this great series of Posts dealing with SSO in Windows 10 to quite some details. There are still some aspects I don’t understand. Maybe you can help me out with that:
When the user is authenticated by AzureAD you state, that AzureAD builds the PRT and sends it back to the client together with a sessionKey which is encrypted using ktsk public key (which is device-specific). In case I have several devices registered: how does AzureAD figures out which ktsk public key it shoud use for encryption, since there is no information about the device?
When it comes to authentication using PRT you mention that the PRT is signed using the SessionKey (I assume this is some form of HMAC). That leads me to the conclusion, that when I only have a PRT I cannot authenticate. Only the combination PRT+SessionKey can be used to authenticate, right?
kind regards
Pirmin
LikeLike
Hi Pirmin, those are good questions.
In order to get a PRT both the user credentials (username/password or proof of possession of Windows Hello for Business key) and device credentials (device certificate) are sent to Azure AD. Azure AD identifies the device with the device credential. This is how it identifies the appropriate storage key public (Kstk). Even if you have multiple devices registered, there is one particular device authenticating to Azure AD.
In respect to authentication using the PRT, you are right. The PRT alone is not good enough. The payload where the PRT is sent over to Azure AD needs to be signed with the session key in a way that Azure AD can verify. That is how we are preventing authentication with a “stolen” PRT for example.
Jairo
LikeLiked by 1 person
Thanks for this great post. We having this strange issues, where devices that get registered i.e. Hybrid Azure AD joined, gets unregistered for some reason when users resets their password, and the user is triggered for MFA in ADFS ( This is a 3rd party MFA). You did mention that, If the PRT is already obtained for a user it would continue until it expires or the user password is reset. Is there a solution to skip MFA specifically for device registration and obtaining PRT?
LikeLike
Hi James,
It is unlikely that the computer gets unregistered upon user resetting their password. What does happen is that the PRT expires and a new one must be obtained to regain access to Azure AD apps. If some of these apps require MFA for access, maybe a conditional access policy, or per-user MFA enabled, these users will be prompted for MFA at the time of access. You can use dsregcmd.exe /status which will give you the registration status of the device and the authentication status of the user. You might want to check AzureAdJoined:YES and DomainJoined:YES to make sure that the device is already registered. You might want to see AzureAdPrt:YES to make sure that the user successfully authenticate to Azure AD upon WinLogon.
Jairo
LikeLike
Thanks for that reaponse. When this happens, the device looses its MDM in the Intune portal, and hence our CA for device compliance does not work. Is there a way around this?
LikeLike
James, it is not clear to me what is it that you are experiencing. I am not sure what do you mean with losing its MDM in the Intune portal. If you have hybrid Azure AD joined devices you can use the CA for policy that reads “require Hybrid Azure AD joined device” which doesn’t require the device to be enrolled into Intune/MDM. You can also manage hybrid Azure AD joined devices with Intune. If that’s what you are doing you should be able to use the policy “require device to be marked as compliant”. If that is the case and it is not working it could be rather an authentication issue. You can see the output of dsregcmd.exe /status on the device that is failing per my previous response and see if you see the expected outputs.
LikeLike
Great information in this post.
I came across it as we recently configured a conditional based access policy which requires uses to provide MFA if they access any O365 apps from outside the corporate network. We have disabled persistent cookies so that the tokens aren’t stored across reboots and the users will be prompted for an MFA response every time they open a new browser session.
However what we have seen is that if a user configures a Work or School Account on their personal device (i.e. Azure AD Registered), they are no longer prompted for MFA when accessing O365 from outside our corporate network. I presume this is because the PRT is storing the MFA token. Do you know if there’s any way for us to get around this?
LikeLike
Ste, you explained well why the user is not prompted for MFA. When MFA is required for registration the PRT will have the MFA claim and will persist it over time (this is true in particular as the user using the device is the same user who registered the device).
This is a behavior that is well known to the internal teams and it is being discussed. A good alternative regardless of the MFA setting is to move to a CA policy that requires a device that is marked as compliant. I am not sure if this is something that you can consider in your environment. Of course the other alternative is to remove the setting to require MFA upon registration while leaving the MFA CA policy on. This of course may have some implications, specially if you support Azure AD Join as well.
LikeLike
Hi Jairo,
Thanks for your response. I had a call open with the Azure AD team and they gave me the same understanding.
Longer term we are looking to implement InTune but it is an issue for us until we get to that point.
We might have to look into changing token lifetimes. Is there anything different in how PRTs are affected by token lifetimes?
Thanks,
Ste
LikeLike
Thank you so much for this information. I have been looking to integrate this with a windows desktop application that is registered to Azure AD. Is there an article that describes the application configuration process to enable it to use PRT device authentication? Does the adal library handle this?
LikeLike
1. I modify the following registry to force IWebBrowser2 to use IE11 kernel.
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Internet Explorer\MAIN\FeatureControl\FEATURE_BROWSER_EMULATION
Name Type Value
Test.exe REG_DWORD 11000
2. Connect to Azure AD in Windows 10 using an Azure AD work account.
3. Open the AAD OAuth in IE11 browser, it shows that the work account connected to Azure AD in Windows 10 can be listed. I can select the work account to log in automaticlly and do not need to input password again.
4. But when I use IWebBrowser2 to navigate to AAD OAuth by following codes,
m_browser.Navigate(csURL, NULL, NULL, NULL, NULL);
the work account cannot be listed. I have to input password again.
How can IWebBrowser2 work the same as IE11 browser? Can anyone help? Thanks.
LikeLike
good
LikeLike
Pingback: The case of “Reduced UI” in the Security and Compliance Center in Office 365 | Blog
Jairo, I am implementing a Windows Hello for Business Hybrid with key trust for one of our customers but they have in one domain different upn-suffixes.
Is it possible to sync multiple upn-suffixes via AD-connect ? I read somewere in the above postings that W10 1803 can handle? more upn-suffixes? Is this right?
Thanks in advance!
Rob Kemna
rkemna@gmail.com
LikeLike
Hello Jaïro,
Thanks for this great post!
I do have some questions, perhaps you can help?
1. What if the Windows 10 PC isn’t Azure domain-joined?
2. What if users only have userid/password (no pin or Windows Hello)?
3. When does the 90 days period of the PRT start? Is this everytime a user accesses a cloud-resource or is this a static period (with a fixed start date/time)?
Some context: I’ve got a client who’s using Windows 10 PCs and accessing Office 365. They want MFA, but want to know when the user is prompted (again) for MFA and at what intervall. The PCs aren’t Azure AD joined but AD on-premises joined.
Hope you can help!
Thanks in advance and kind regards,
Albert
LikeLike
Pingback: Moving away from passwords with Windows 10, Windows Hello for Business & Microsoft Intune – Modern Workplace
Hello Jairo,
One question regarding Azure PRT. In (3) you explain that PRT retrieval is based upon Username/Password or Windows Hello Credentials. How about Smart Card authentication? In our current setup users don’t know their passwords. They can only login using smart card. But now we are stuck enrolling for WH4B because enrollment seems to depend on PRT which in turn initially depends upon password known to the user. Is this correct? So no smart card support for WH4B and for Conditional Access (which depends on PRT) without initially knowing the password?
Thanks, Michael
P.S.: Any chance to see a more flexible workaround for the Alternate Login scenario. Currently it’s limited to a forest-wide SCP setting. We’d like to see a more flexible approach (GPO/RegKey/…) as we have clients of the same forest using Alternate Login with different tenants.
LikeLike
Hello Jairo,
I am not sure whether we miss some configuration or it’s not working by design.
If we have a smart card only environment (so user’s don’t know their ADpassword) – do users have a chance to get an AAD PRT and/or enroll Windows Hello?
Thanks, Michael
LikeLike
Hi Michael,
To enroll for WHfB while bootstrapping it through SC/PIN, in ADFS you must have cert based authn enabled globally. see: https://jorgequestforknowledge.wordpress.com/2019/05/25/windows-hello-for-business-wh4b-bootstrapping/
Best Regards,
Jorge
LikeLike
Pingback: Azure AD Conditional Access policies troubleshooting – Device State: Unregistered – Sergii's Blog
Hi Jairo,
thanks for that great article. can you please let me know how a PRT can be revoked in case that a computer is compromized? And a admin want to ensure that the current prt can not longer be used?
Thanks Klaus
LikeLike
Pingback: (2019-05-22) Some Basic Steps For Troubleshooting PRTs « Jorge's Quest For Knowledge!
Hello Jairo, first of all, thank you for posting these detailed articles, it has been very helpful to see some of the back-end of how this all works.
I work in an environment where we are struggling with some strange AAD registration behavior. We have on prem AD, ADFS with a few 3rd part web federated apps. We have AAD setup to Hybrid Join our Windows 10 devices with AD connect doing devicewrite back for registered devices. We are using conditional access in azure to qualify devices as not needing MFA if they are registered to AAD.
Here are the issues we have been having. All of our devices are Win10 1809, and are both showing up in AAD as Hybrid, and their objects are showing up in registered devices. But since implementing this we have some users who get strange certificate pop-ups in Chrome (with the Windows Accounts Extension enabled) when trying to access ADFS federated on premise websites. The SubjectID of the cert does not match anything I can find in AAD, certlm or in the registry. If the user is not on premise, they do not get the cert pop-up, but rather get prompted for credentials.The only way I have been able to solve this was deleting their entire user profile from the device, or re-imaging it. I have tried dsregcmd \leave as described by s4erka in that blog. MS support says re-image. But there is more I think going on. All of our devices have event logs in the AAD operational event log that state both:
AAD Cloud AP plugin call GenericCallPkg returned error: 0xC0048512
and
Error: 0xCAA70004 The server or proxy was not found.
Also when users in this state change their PW it sometimes makes the Outlook client and other O365 C2R apps unable to authenticate until their user profile is deleted and recreated on that device.
Any Ideas?
LikeLike
Where is the PRT Token store in c:\ ? I seem to recall there is some path to delete a file which will cause Outlook or other application to present modern auth prompt to the user. The computer does not have ADAL entry in credential manager.
LikeLike
Re: Now, there is a caveat for domain joined devices. Attempting to get a new PRT only happens if the device has a line of sight to a DC (for a Kerberos full network logon which triggers also the Azure AD logon). This is a behavior we want to change and hope to make for the next update of Windows.
Question: Do you happen to know if this has been implemented in the new Win 10 versions? If yes, which versions?
Question 2:
-Users are part of an on prem AD DS domain that is verified and federated with Azure AD.
-These users have hybrid Azure AD joined devices.
-However, these users have a different UPN that is setup in Azure AD as a custom domain, but is NOT verified or federated in Azure AD.
-For these users, the AzureAdPrt is changing to No, and not refreshing when the users change their on prem passwords.
To correct this, does the custom domain that matches the unique UPN need to be verified and federated in Azure AD? Or, just verified, and NOT federated?
LikeLike
Pingback: Azure AD Hybrid Device Join Error (0x801c03f2) – Sam's Corner
What happens for users using Smartcard/Certificates for login against Azure AD (Not ADFS)? They do not get an Azure PRT generated. Is there anyway to support this type of login or does it only work with user name and password? Or is ADFS the only way to support seamless SSO with Smartcard/Certificate authentication?
LikeLike
Hi Jairo,
Great post!
I have a set up where my Devices are Azure AD joined and we have an on-prem AD FS set up. Users log in with their on-prem AD credentials and receive a PRT as shown by the command dsregcmd.exe /status . Also, when users launch portal.office.com on Chrome/IE/Edge Office365 apps don’t ask for credentials.
However, when users browse to the AD FS portal (https://sts…..) then they get a pop-up asking for username and password. Why isn’t the AD FS site making use of the same PRT and auto signing users into the AD FS portal? Please help.
LikeLike
Hello, we are noticing that if a machine that was Hybrid joined via the corporate network goes remote for around 14 days they lose access to the PRT. Even after connecting to VPN we notice the PRT never gets a status of yes. Any ideas.
LikeLike
Hello
I know this is a really old thread BUT i have been struggling to find information about the problem I am having.
To Summarise, we have a hybrid AZURE AD environment. Device and Users synched into AD. We have “shared” machines which log in as domain accounts and EDGE signs in as the user. This is so conditional access and DEVICE ID is passed through and ‘happy’, shall we say.
The problem I face is that we want OWA users to be able to use Edge to sign into Outlook and sharepoint. BUT i cannot find a way to stop SSO from happening, so EDGE automatically signs in as the windows account , even after switching user or closing the browser it still defaults back.
I have tried all sorts within Internet Options and different configuation policies but have been unsuccessful.
Would you have any idea on how we can achieve this?
LikeLike