Hi Jairo,Thanks for the very exact article. One thing I can’t bear in mind is the PRT validity time. The initial PRT is acquired during Add Work or School Account method. 2.
It’s valid for full 90 days provided that I access an AzureAD covered useful resource during the first 14 days. One AzureAD covered aid will be enough. 3. New PRT will only be obtained if the initial expired which mean after 90 days or 14 days. On instruments that are registered Azure AD for domain joined or Azure AD joined. 1.
The preliminary PRT is obtained during first Sign on/Unlock if the outdated one has not expired. 2. It’s valid for full 90 days, however the end user doesn’t are looking to access an AzureAD covered useful resource in the course of the first 14 days to have full life time of 90 day. The reason being is that it’s all handle silently and immediately by Windows every 4 hours. Question.
Regarding 3 in the private registered devices via Add Work or School Account. What will the tip user event be if I’m signed in to my computing device and try to access AzureAD covered resource with a PRT that just got expired?Question. From an Admin Point view what do I ought to do to revoke the Credentials. Will it suffice to disable the User Account In Azure AD?Is there something more that needs to be done on the device side?What occurs to an interactive windows 10 login if the domain is federated to 1/3 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 0,33 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 could be great if it were federated besides, but I suspect that’s not likely built out…Pls. advise. A critical point during this scenario is resetting the user password. Normally, this is done with atmosphere 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 assistance about the flag and the AAD request is not successful. Logon with Hello or cached credentials client offline, old password works. If the user doesn’t know PIN and password, you need to reset the password without setting the Flag “user must CHGPWD at next logon”. Is there an opportunity to alter the password of federated users at client logon ?Another tricky thing are cached credentials.
As I mean, logons with Hello won’t ever 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 continually always done with Hello PIN. After one or more pwd changes, the user is not capable of logon together with his actual password in that case the customer is offline and the user cannot bear in mind the PIN. This scenario cames up if you happen to use Intune / NDES to connect the client to LAN in accordance with certificates or the user is in a hotel with WLAN captive portal. I except the one way to get the user logged on with the brand new password is getting the customer 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 ought to do a password logon on the client. Thank you on your blog, it’s very instructive for me. I have one query : When the user or device dependent on the case certificates issued by MS Organisation Access is used ?You explained in yet another post how this one is issued but I can’t find wherein step it is used. I’m also trying to consider when WS Trust, and which WS Trust endpoint usernamemixed or windowstransport for either user or equipment. So, my assumption is here 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 completed: – For W7, a consumer certificate is issued for the user, adding device id – For W10, a consumer certificate is issed for the gadget, including device idRegarding authentication:You said “Azure AD will authenticate the user with the credentials acquired non federated or with verifying the SAML token received from AD FS federated. After authentication Azure AD will build a PRT with both user and device claims and could return it to Windows. ”In my case federated, I guess it’s truly 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’ve got a SAML user token, not easy device authentication on Azure TLS endpoint eviceAuthTls/ ?, inquiring for for a client certificates signed by MS Organisation Access Certificate Authority. For W7, I guess here’s done in WEB SSO mode, that means only from a browser done in a user context, so using the user certificates when logging to Azure services. For W10… no idea what it’s in fact done, I wonder whether SYSTEM thus using the machine certificate is doing it while the user is logging in W10. 1. Registration of Win10 uses the windowstransport end point indeed for authentication just before 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 here’s the adfs/ls end point. 2. You are right concerning the certificates issued to the user context Win7 and to the laptop context Win10. The certificates thumbprint is what is stored in the device object in Azure AD and what’s 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 a part of the discipline of the certificate. 1. In Win10, during user auth to Windows WinLogon, we send user credentials to the usernamemixed end point only we don’t rely upon the windowstransport get the SAML token and send it to Azure AD together with the device certificates via an OAuth auth request. This is not a passive flow so the device TLS end point is not concerned. Once this completes Windows gets the PRT and afterwards it is the PRT which contains both user and device claims it’s used as I explained at the top of my reaction.
2. Win7 doesn’t do authentication to Azure AD during user check in to Windows WinLogon. Built in SSO is only accessible 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. Jairo, I have a WPJ device and I cannot see the PRT cached for the user in the course of the “dsregcmd. exe /status”, still SSO is operating, was there any conduct change?When I prompt my Office ProPlus subscription it is going to perform a WPJ of the device and SSO will begin to happen, on a scenario where we’ve got shared instruments, the SSO will always happen, regardless the user authenticated on the device, with the first individual that WPJ the device, how should we continue in such scenario?Is there an ideal way to disable/keep away from WPJ contraptions?Besides the “User may sign in their gadgets.
” in AAD?Hi Sean, upon device registration, along with the certificate issued for the device identification, an extra asymmetric key is generated Kstk or storage key. The public component of the key pair is stored in the device object in Azure AD. This key is the one which protects the consultation keys generated upon authentication. So when a new consultation key is generated for example when the PRT is issued, it is shipped to Windows encrypted with the Kstk which then Windows stores in the TPM using the Kstk . Session keys are derived from old ones using random salts upon subsequent authentications e. g.
getting an access token from the PRT. ” Upon re authentication the PRT is shipped over to Azure AD signed using a derived version of the previously imported consultation key stored in the TPM which Azure AD can verify” – So it means, in the course of the subsequent re authentication or request for access tokens, the authenticatorre using the Kerberos term here which the customer sends to Azure AD must also contain something like below: Keysession + Kstk, where stands for being encrypted/signed by. Thus Azure AD itself doesn’t want to store the session key somewhere. Is my figuring out correct?Hi Michael, here is a known issue that we are fixing in a better update of Windows. In another login ID atmosphere, check in to Azure AD upon Windows logon fails the PRT is not acquired hence failing access to elements included with device based conditional access policies. If you’re curious why, this is as a result of we are currently counting on the local UPN suffix to do user realm discovery at WinLogon time in finding where to send the credentials for authentication in the federated case, understanding the AD FS/on prem STS to go first.
We are solving this example by introducing a policy registry key for you to set in the organization to override the domain suffix for discovery. Once we find the proper IdP Identity Provider remainder will work. Hi Jairo, I now had a chance to check W10 1803 device registration which seems to work now with Alternate UPN situation. Looks like the AD SCP is now used for building the “[email protected]” lookup that allows you to determine the correct STS was formerly done using logged in user’s UPN. I still have one issue: One of our domain names is federated with a special ADFS server than any 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 MichaelHi Jairo,I have a tough question that I’m looking to be aware the WHY. My Azure AD is federated with on an onprem AD FS 2016. I’m operating Domain Joined Windows 10 Enterprise 10 1709 and they’re 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 computer systems.
Now comes the WHY…If open Edge Browser on anyone of the Windows 10 gadgets and check out 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 acquire an Access Token. Why does it bounce me back to AD FS?Shouldn’t the WAM intercept this authentication request and supply the PRT to Azure AD?I’m completely very well with AD FS needs to be contacted during Initial PRT retrieval as a result of I’m federated which occurs during the preliminary Desktop Logon/Unlock to Windows.
It is not likely that the computer gets unregistered upon user resetting their password. What does happen is that the PRT expires and a new one must be received 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 could be triggered for MFA at the time of access. You can use dsregcmd. exe /status which will come up with 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 be certain that the user successfully authenticate to Azure AD upon WinLogon. James, it is not clear to me what’s it which you are experiencing. I am not sure what do you mean with losing its MDM in the Intune portal. If you’ve got hybrid Azure AD joined devices you could 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’re doing make sure you be capable of use the policy “require device to be marked as compliant”. If that’s the case and it isn’t operating it may be rather an authentication issue. You can see the output of dsregcmd. exe /status on the device that’s failing per my outdated response and see if you see the expected outputs. Hello Jairo,One question concerning Azure PRT.
In 3 you clarify that PRT retrieval is based upon Username/Password or Windows Hello Credentials. How about Smart Card authentication?In our latest 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 rely upon PRT which in turn in the beginning relies on password known to the user. Is this accurate?So no smart card aid for WH4B and for Conditional Access which depends on PRT with out at the beginning understanding the password?Thanks, MichaelP.
S. : Any chance to see a more bendy workaround for the Alternate Login situation. Currently it’s restricted to a forest wide SCP surroundings. We’d like to see a more flexible approach GPO/RegKey/… as we have got consumers of the same forest using Alternate Login with alternative tenants. Here are the flaws we were having. All of our units are Win10 1809, and are both showing up in AAD as Hybrid, and their items are showing up in registered contraptions.
But since implementing this we’ve got some users who get peculiar certificates pop ups in Chrome with the Windows Accounts Extension enabled when looking to access ADFS federated on premise internet sites. 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 aren’t getting the cert pop up, but rather get prompted for credentials. The only way I were able to solve this was deleting their entire user profile from the device, or re imaging it. I have tried dsregcmd leave as defined by s4erka in that blog.
MS help says re image. But there is more I think going on.