Share via

Azure SSO problems (AzureAdPRT=NO) on AAD hybrid-joined non-persistent VDI

J Hanson TMK 126 Reputation points
2021-11-10T09:35:47.773+00:00

Hi all, we have been dogged by this problem for a few months now. We are using Citrix PVS to provision windows 10 desktops and we have conditional access in place. Somewhere around 5%-10% of users will log into a non-persistent windows 10 20H2 desktop which has been AAD hybrid-joined, they will be able to use Office and Teams desktop apps, but they are lacking the Primary Refresh Token (azureADPRT= NO in dsregcmd /status). When they try and visit a site configured with Azure SSO they get the dreaded “you can’t get there from here” failure message for conditional access, because this PRT is missing. Logging out and picking up a new desktop sometimes fixes it but often it will take them several logoffs to fix.

 

We have a ticket open with Microsoft and we believe we are doing all the right things according to their documentation and have got some trusted third parties to validate our practices as well:

 

-We do a dsregcmd /LEAVE on the gold image before sealing it

 

-Desktops have the SYSTEM account configured with our proxy details and perform a dsregcmd /join on startup, which is apparently successful

 

-we have added a longer “settlementperiodbeforeuse” on the delivery groups in question to make sure everything has time to run/work

 

-We use FSlogix profile containers and exclude all of %localappdata%\Packages and %localappdata%\TokenBroker

 

-We delete the following reg entries at logoff to ensure they are not roamed in the user profile

HKEY_CURRENT_USER\SOFTWARE\Microsoft\IdentityCRL

HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\AAD

HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows NT\CurrentVersion\WorkplaceJoin

 

-we use Zscaler “one click” configuration for Microsoft 365, but…

 

-Important URLs are explicitly added to our proxy bypass list anyway

https://enterpriseregistration.windows.net

https://login.microsoftonline.com

https://device.login.microsoftonline.com

https://autologon.microsoftazuread-sso.com

 

-We have AAD Connect syncing the OUs with these machines

 

-We are federated with ADFS on-prem, we have never used device authentication in ADFS  so we see a few errors in the AAD event log about this but 90%+ of users are working so it seems like a red herring.

 

-We have tried tinkering with the timing of the dsregcmd /join and are confident all network connectivity is available by the time it runs.

 

Has anyone had any experience of getting this to work reliably?

 

All opinions welcome!!

 

Microsoft Security | Microsoft Entra | Microsoft Entra ID
0 comments
Accepted answer
  1. J Hanson TMK 126 Reputation points
    2021-12-07T11:31:43.297+00:00

    Update - found the solution, I am adding it here in case anyone else finds this.

    We were triggering our own "dsregcmd /join" command at startup when the network is available, we have been doing this for a couple of years to make sure all desktops are successfully AAD hybrid joined and can use Microsoft 365 and conditional access.

    There is also a Microsoft scheduled task "\Microsoft\Windows\Workplace Join\Automatic-Device-Join" which is meant to do this job. We found that in some cases this was running at the same time as our own dsregcmd /join, when they went through at the same time they were both recognised by AAD and some kind of duplicate IDs or thumbprints were registered in Azure for the desktop. This would break the process of the device authenticating and acquiring the Primary Refresh Token, and SSO would then fail.

    We changed our own join step to call this scheduled task instead, and the internal task scheduler logic makes sure only one instance can run at once.

    6 people found this answer helpful.
    0 comments

0 additional answers

Sort by: Most helpful
Most helpful Newest Oldest

Your answer

Answers can be marked as Accepted Answers by the question author, which helps users to know the answer solved the author's problem.