I recently encountered a frustrating authentication issue where users on Citrix servers were unable to log into Office 365 services, instead of the expected login form, they were greeted with completely blank login boxes. This affected both Microsoft Edge and Google Chrome, making it a system-wide problem rather than a browser-specific issue, the login box which should "know who you are" but it did not seem to "know"
Executive summary
The cause of this problem is the Citrix environment we are running with the user of short-lived Citrix FAS certificates that then cause issues with the Azure Primary Refresh Token (PRT), however on a lock and unlock Entra falls back to the correct authentication and then provides a token, this problem does not occur on non-citrix devices. this is a common problem and is made worse by FAS is using "internally signed" certificates that are not trusted by Entra.
You also get very interesting ways to fix this because the problem goes away when you lock your workstation on Citrix and unlock it - which on a Citrix platform would be quite a common activity - it really only affects you if you login do not lock your workstation for extended periods of time - This is quite uncommon because Citrix is not a particularly stable platform - yes, you guessed it - not a fan of Citrix.
If you wish to look at my working out and the process I went on please continue to read, then you can see how deep the rabbit hole goes….
The Problem Statement
Users accessing Office 365 services (portal.azure.com, login.microsoftonline.com, SharePoint Online) from virtual deskop servers were experiencing blank login dialogs. The authentication pages would load, but the username and password fields remained completely empty and unresponsive.
Key symptoms:
- Blank login boxes on all Office 365 sites
- Affected both Edge and Chrome browsers
- Issue only occurred on Citrix servers (Windows Server 2022)
- Same users could authenticate successfully from non-Citrix servers
- Network connectivity to Office 365 endpoints was working correctly
Initial Investigation: The ADFS Phantoms
This was for my account that did use Azure for authentication, so my first instinct was to check the device registration status using
dsregcmd /status. The output revealed some concerning information:SSO State
AzureAdPrt : NO
Previous Prt Attempt : 2025-06-13 15:01:54.999 UTC
Attempt Status : 0xc000006d
Server Error Code : invalid_client
Server Error Description : AADSTS50017: Validation of given certificate for certificate
based authentication failed.
This led me down a rabbit hole of investigating Azure AD Primary Refresh Token (PRT) issues, ADFS configuration problems, and hybrid identity setup. I spent considerable time examining:
- Azure AD Connect configuration
- Seamless SSO settings
- Certificate validation issues
- Device registration problems
However, I soon realized this was a phantom problem was not the issue. The working server also showed AzureAdPrt : NO in some cases, yet Office 365 authentication worked perfectly, meaning that "dsregcmd" can sometimes lead you down rabbit holes.
The ADFS phantom messages
If you are using ADFS as your authentication source I noticed that some of the requests were also giving a 503 error (which is Service not Available) which is not a great item to see in the "dnsregcmd" status command but again seemed to be a phantom issue.
Attempt Status : 0xc00cee4f
User Identity : bear.user@bythepowerofgreyskull.com
Credential Type : Password
Correlation ID : 8292effa-124f-4f8f-869e-8ec95934194c
Endpoint URI : https://adfs.bythepowerofgreyskull.com/adfs/services/trust/13/usernamemixed
HTTP Method : POST
HTTP Error : 0xc00cee4f
HTTP status : 503Indeed upon visiting that URL I did get the "Internal server error" notification so I thought I would checkout that infrastructure to rule it out and for ADFS you have a federation and a WAP (Web Application Proxy) first I started with the web application proxy servers, if you look at the "Web Application Proxy” log under the Windows event log you will notice that the key here for the "token signing certificate" should match your live token certificate - which in this case it did.
There were no errors in this event log meaning the proxy was doing its job, next we have the federation servers these are domain joined and are usually full of entries of people getting their passwords wrong - which is normal.
If on those servers you find the the Event Log : AD FS/Admin these events are quite normal:
Exception details:
Microsoft.IdentityServer.AuthenticationFailedException:
lee@bythepowerofgreyskull.com-The user name or password is incorrect --->
System.IdentityModel.Tokens.SecurityTokenValidationException: lee@bythepowerofgreyskull.com
---> System.ComponentModel.Win32Exception: The user name or password is incorrect
Exception details:
Microsoft.IdentityServer.AuthenticationFailedException: lee@bythepowerofgreyskull.com --->
System.IdentityModel.Tokens.SecurityTokenValidationException: lee@bythepowerofgreyskull.com
at Microsoft.IdentityServer.Service.Tokens.MSISWindowsUserNameSecurityTokenHandler.
ValidateToken(SecurityToken token)
at Microsoft.IdentityServer.Web.WSTrust.SecurityTokenServiceManager.
GetEffectivePrincipal(SecurityTokenElement securityTokenElement, SecurityTokenHandler
Collection securityTokenHandlerCollection)
at Microsoft.IdentityServer.Web.WSTrust.SecurityTokenServiceManager.Issue
(RequestSecurityToken request, IList`1& identityClaimSet)
at Microsoft.IdentityServer.Web.Protocols.PassiveProtocolHandler.SubmitRequest
(MSISRequestSecurityToken request, IList`1& identityClaimCollection)
https://adfs.bythepowerofgreyskull.com/adfs/services/trust/13/usernamemixed
This would then give up a 404 which is correct for a direct visit as this call requires additional parameters I was not providing, aka malformed URL, but a 404 from a 503 is a good step in the correct direction.
This however turned out not to be a problem with ADFS after all and this was another phantom problem that was well worth looking into, let’s move on.
Network and Proxy Investigation
Since many organization use I proxy, I thought it would be prudent to investigate whether network infrastructure was causing the issue. I examined:
- SSL inspection policies
- Trusted site configurations
- Browser policy settings
- Proxy configuration differences
https://enterpriseregistration.windows.netadfs.bythepowwrofgreyskull.comWhen I checked the certificates being presented by these websites many of them were indeed NOT going through HTTPS inspection.
Edge/Chrome Flags - could disabling flags make a difference?
Well, this was another option on the table so lets take a quick look:
edge://flagsThis will then give you a list of options that can be enabled or disabled if you enter te command above and then search for Security you will see an interesting option called "Strict-Origin-Isolation" as below:
While is this is not the same as CSP policies it does govern isolation so if that worth an enable just to see what happens, well why not, so you can change this to Disabled and then restart Edge:
While I did thought this fixed the problem, I was using the wrong site and it ended up not making any difference as this policy does not override public CSP policies that is impossible as I later found out.
Could it be Group Policy ?
This is applied to servers so could it be a group policy that is cause the issue, well group policy is very extensive and different servers will be have different group policies installed on them based on the OU they reside in.
This means we need to look at all the group policy objects and find the ones that could be relevant so for this we need a resulting set of policies (RSOP) and for that full report we can use this command:
GPRESULT /H GPReport.html This will then mean you need to go though that report and look for all the policy objects applying anything linked to browser, security or iframe which depending on the amount of objects could take a while, instead use this Powershell that can be run as a user:
# Get full policy details including registry locationsGet-WmiObject -Namespace "root\RSOP\Computer" -Class "RSOP_RegistryPolicySetting" |
Where-Object {
$_.valueName -match "Browser|Security|Frame"
} |
Select-Object @{Name="RegistryKey";Expression={$_.registryKey}},
@{Name="KeyName";Expression={$_.keyName}},
valueName,
@{Name="Value";Expression={
if($_.value -is [byte[]]) {
if($_.value.Length -eq 4) {
[BitConverter]::ToInt32($_.value, 0)
} else {
[System.Text.Encoding]::Unicode.GetString($_.value).TrimEnd("`0")
}
} else { $_.value }
}},
@{Name="GPO";Expression={
$gpoId = $_.GPOID
(Get-WmiObject -Namespace "root\RSOP\Computer" -Class "RSOP_GPO" |
Where-Object {$_.id -eq $gpoId}).name
}}
This will then return the name of the GPO object and the setting applied if you have any applied to your server, saving your hours of spooling though html files.
Comparing Working vs Non-Working Environments
Running the diagnostic script on both environments revealed interesting differences:
Citrix Desktop Server (Non-Working):
AzureAdJoined : YES
DomainJoined : YES
AzureAdPrt : NO
RDP Session: Yes
microsoftonline.com: Local Intranet
RDP Working Server:
AzureAdJoined : YES
DomainJoined : YES
AzureAdPrt : YES
RDP Session: Yes
microsoftonline.com: Not configured (defaults to Internet zone)
While the PRT differences were notable, they didn't explain why the login forms were completely blank rather than prompting for credentials.
The Browser Security Zone Investigation
I initially suspected that the security zone configuration was causing the issue. The RDP servers had microsoftonline.com configured in the Local Intranet zone, which could potentially cause integrated authentication attempts.
I tested various configurations:
- Moving sites from Local Intranet to Trusted Sites
- Changing authentication settings for different zones
- Configuring browser policies for Edge and Chrome
However, none of these changes resolved the blank login boxes, and the issue persisted across both Edge and Chrome despite their different security models.
Developer Tools Analysis : CSP Blocking Traffic
The breakthrough came when I opened the browser's Developer Tools (F12) and examined the Console tab while attempting to access https://portal.azure.com. The error message was clear and definitive:
Refused to frame 'https://portal.azure.com/' because an ancestor violates
the following Content Security Policy directive: "frame-ancestors 'self'".
This Content Security Policy (CSP) violation seemed to be the root cause of the blank login boxes, this was also replicated in Chrome as well:
Understanding Content Security Policy Violations
Content Security Policy is a security feature that helps prevent cross-site scripting (XSS) and data injection attacks. The frame-ancestors directive specifically controls which sources can embed a page in a frame or iframe.
The error indicated that:
- The Office 365 login page was being loaded within a frame context
- The page's CSP header only allowed framing by the same origin (
'self') - Something in the Citrix environment was creating an unauthorized frame context
If you look at that report you will notice the policy causing us problems in shown in the red box below, so this is being enforced by the remote web server as it should be:
This means we are then violating that policy which is causing the authentication issue, lets dig deeper.
Disabling Content Security Policy (cannot be done)
Firstly you cannot disable a CSP policy that is on a remote website, but this rabbit hole required investigation (without going to deep) so you can tell your browser to disable Content Security Policy which can be done with the registry values below:
For Microsoft Edge:Or via Registry:
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Edge]
"ContentSecurityPolicyChecksEnabled"=dword:00000000
For Google Chrome:
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome]
"DisableContentSecurityPolicy"=dword:00000001
When you add these keys it does nothing as its not enforced locally its enforced remotely, another rabbit hole that has been tried that did not fix the issue, moving right along
What Creates the Frame Context?I still had a question remaining: What was creating the frame context that triggered the CSP violation?
Since the proxy infrastructure wasn't modifying traffic, the framing had to be occurring locally on the Citrix servers. Potential culprits included:
- Citrix App browser integration
- Group Policy settings forcing browser sandboxing
- Windows Defender Application Guard
- Third-party security software creating browser containers
- Citrix-specific browser launching mechanisms
Security Considerations
Disabling Content Security Policy reduces browser security by removing protection against certain types of attacks. In a production environment, I would recommend:
- Identify the specific component creating the frame context
- Configure that component to properly handle CSP headers
- Implement CSP bypass only for necessary Office 365 domains
- Monitor for any security implications
While investigation is taking place you can configure CSP overrides for specific domains:
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Edge]
"ContentSecurityPolicyOverride"="frame-ancestors *; script-src 'self' 'unsafe-inline';"
This regsitry key also did not fix the problem as the CSP policy is being applied remotely and Windows 2019 and later are more strict on CSP processing.Locating the iFrame problem
The problem with iFrame Seems to be observed in the console tab on the DevTools Option in your browser, which is F12.
Identifying the Frame Context
The first breakthrough came from running diagnostic JavaScript in the browser console. This helped me understand exactly what was creating the problematic frame context.
// This will show what's creating the frame context
console.log("Current frame hierarchy:");
console.log("window.parent === window:", window.parent === window);
console.log("window.top === window:", window.top === window);
console.log("Frames count:", window.frames.length);
console.log("Document domain:", document.domain);
console.log("Window location:", window.location.href);
console.log("Parent location:", window.parent.location.href);
Key Findings from Console Output:
-
window.parent === window: true- This page is NOT in a frame -
window.top === window: true- This page is at the top level -
Frames count: 1- But there's 1 frame inside this page - We're on
login.microsoftonline.com- The authentication page itself
The CSP error says it's refusing to frame portal.azure.com, but we're currently on login.microsoftonline.com. This revealed the authentication flow sequence:
- User visits
portal.azure.com portal.azure.comredirects tologin.microsoftonline.com- After authentication,
login.microsoftonline.comshould redirect back toportal.azure.com - Step 3 is where it fails with the CSP error
Checking User Agent and IE Mode
I suspected Internet Explorer Integration might be forcing sites into IE mode, causing frame contexts and CSP violation, but was another rabbit hole not linked to the problem, to check that from the console run this:
navigator.userAgent
The results was:
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko)
Chrome/136.0.0.0 Safari/537.36 Edg/136.0.0.0 OS/10.0.20348
This confirmed we're using modern Edge, not IE mode, so that wasn't the issue either.
Deeper Look : Finding the Problematic iFrame
The breakthrough came from deeper console investigation:
// Check if we're in a frame
console.log("In frame:", window !== window.top);
console.log("Frame count:", window.frames.length);
console.log("Current URL:", window.location.href);
// Look for any iframes on the page
console.log("iframes on page:", document.querySelectorAll('iframe'));
Console output revealed the following:
<iframe height="0" width="0" src="https://portal.azure.com/cobrand/" style="display: none;">
</iframe>
Working vs. Broken Server Comparison
Broken Server (2019/2022):
- Frame count: 1
- Had the problematic cobrand iframe:
<iframe src="https://portal.azure.com/cobrand/">
Working Server (2016):
- Frame count: 0
- No iframes at all
Even Deeper : Investigating the Cobrand Trigger
To understand what triggers the cobrand iframe, we ran additional diagnostics:
// Check what's triggering the cobrand
console.log("Referrer:", document.referrer);
console.log("User agent:", navigator.userAgent);
console.log("Platform:", navigator.platform);
CoBrand Trigger Results:
- Referrer:
https://portal.azure.com/ - OS/10.0.20348 (Windows Server 2022 build number)
This revealed an Authentication Loop:
- You visit
portal.azure.com - Portal redirects you to
login.microsoftonline.com - Because you came FROM
portal.azure.com, Microsoft's login page loads the cobrand iframe - Cobrand iframe tries to load
portal.azure.com/cobrand/ - CSP violation occurs
On Server 2016, you go directly to login with no referrer, so no cobrand iframe loads. On Server 2019/2022, something automatically redirects you to portal.azure.com first, triggering the problematic referrer.
Analyzing the Cobrand Parameters
Let's examine what's in that iframe more closely:
document.querySelectorAll('iframe').forEach((iframe, index) => {
console.log(`Iframe ${index}:`, {
src: iframe.src,
style: iframe.style.cssText,
id: iframe.id,
className: iframe.className
});
});
Key findings from the URL parameters:
client_id=c44b4083-3bb0-49c1-b47d-974e53cbdf3c- Azure Portal application IDsite_id=501430- Partner/organization branding identifier
The site_id=501430 parameter is what triggers the cobrand iframe! This tells Microsoft's login page to load custom branding via the cobrand iframe.
Back to Basics with Facts
The current path of investigation has been very detailed but lets go back to basics and get some information from the type of servers and the status of those servers, so this is the summary.
- Domain: bear.local
- Affected systems: srv-app01 (Server 2019), srv-web02 (Server 2022), srv-db03 (Server 2022)
- Working system: srv-legacy01 (Server 2016)
- User account: admin.user@bear.local
The strangest part? The same user account would work fine on Server 2016 but fail consistently on newer server versions.
The Cobrand and iframe could be coming from the failed PRT token?
Yes, it might be that the iframe issue could with this evidence tied to the to Azure AD Primary Refresh Token (PRT) status, not Group Policy settings, the pattern seems to be flowing like this:
When AzureAdPrt : NO:
- Azure Portal serves stricter CSP headers for authentication flows
- Organizational branding gets loaded with
frame-ancestors 'self'blocking iframes - This is a security feature - systems without valid PRT get more restrictive policies
When AzureAdPrt : YES:
- Azure Portal trusts the device authentication context
- More permissive CSP headers allow iframe embedding with cobranding
- The device has established trust with Azure AD
The Authentication Pattern Emerges
The shifts back to the device registration status once again as this seems to be common thread here, but we need to look into this with a little more detail and look at all the data provided by the output.
When I compared all the results of dsregcmd /status, I discovered a critical pattern:
Working Server (srv-legacy01 - Server 2016):
User State:
AzureAdPrt : YES
Affected Servers (Server 2019/2022):
SSO State:
AzureAdPrt : NO
Credential Type : Certificate
Server Error Code : invalid_client
Server Error Description : AADSTS50017: Validation of given certificate for
certificate based authentication failed, Trace ID: 1b5e5b2a-e083-4849-b3fd-81c243b21a00
Correlation ID: a71263a2-941f-45d5-ad2e-a4398e97b0c6 Timestamp: 2025-06-20 10:01:51ZAADSTS50017: Certificate validation failed Which then mean this is the process:
- Your user account is trying to authenticate with a certificate-based method
- That certificate is invalid, expired, or not trusted by Azure AD - or in my case did not exist
- This prevents proper Azure AD authentication, which impacts PRT acquisition
Which then connects to iframe/CSP Issues:
- Certificate fails → Authentication context is "untrusted"
- Untrusted authentication context → Azure serves stricter CSP headers
- Stricter CSP → iframe embedding with cobranding gets blocked
What explains the working v non-working servers then ?
Working servers: Users authenticate successfully without certificate errors → AzureAdPrt : YES → Permissive CSP headers
Failing servers: Certificate authentication fails → Fallback to less trusted auth → AzureAdPrt : NO → Restrictive CSP headers that block iframes
AAD Event Viewer
You can also check the AAD event log in the location Microsoft-Windows-AAD/Operational
<add looking for only AadCloudAPPlugin Operation only and go into examples>
CBA (Certificated Based Authentication) - could that be involved?
The confusing part was that:
- Certificate-based authentication was disabled at the tenant level
- No certificates were assigned to the user account
- No Conditional Access policies required certificates
- The user had no certificates visible in their authentication methods
Yet Windows Server 2019+ was still attempting certificate authentication, why I wonder why, however the cause is this will be something covered before in this article.
Passkey : Creation and Removal causing issues?
I did at one point I did create a passkey from the Authentication application, when you do this Entra enables passkey authentication for your account. Deleting the physical or platform passkey from your device does not automatically remove or disable that authentication method in Entra. As a result, Azure continues to attempt passkey-based authentication, which fails because the credential no longer exists. This leads to an incomplete or untrusted authentication state, however I am in the policy that allows Passkey creation.
This means the broken passkey flow causes Entra to treat the session as untrusted, prompting the Azure Portal to enforce a restrictive Content Security Policy, which blocks iframes - in theory then?
Yes, I also had a FIDO2 security key (called "Stick of Doom"), which is living up to its name, and when you remove a FIDO2 key there is a chance that Entra does not fully clean up the associated authentication artifacts, well that depends on where you look.
Cannot check Entra due to "certificate failture"
When attempting to query Entra to see what authentication methods were actually configured, I encountered a classic catch-22, after installing Azure CLI you should be able to run these commands:
az loginaz rest --method GET --url https://graph.microsoft.com/v1.0/me/authentication/methods"The commands above should show me exactly what authentication methods Entra has registered for your account, including any hidden FIDO2/passkey artifacts that might be causing the certificate authentication attempts, unfortunately it failed with certificate authentication errors - the same issue I was trying to fix thought this whole post, see below:
271136
The command failed with an unexpected error. Here is the traceback:
ErrorTag: 540656077, ErrorCode: 0, ErrorContext: Caught exception, ErrorStatus: Response_Status.Status_Unexpected
Traceback (most recent call last):
File "D:\a\_work\1\s\build_scripts\windows\artifacts\cli\Lib\site-packages\knack/cli.py", line 233, in invoke
File "D:\a\_work\1\s\build_scripts\windows\artifacts\cli\Lib\site-packages\azure/cli/core/commands/init.py", line 666, in execute
File "D:\a\_work\1\s\build_scripts\windows\artifacts\cli\Lib\site-packages\azure/cli/core/commands/init.py", line 734, in runjobs_serially
RuntimeError: ErrorTag: 540656077, ErrorCode: 0, ErrorContext: Caught exception, ErrorStatus: Response_Status.Status_Unexpected
Checking my "user" driven security portal
You can get to that from this URL : https://myaccount.microsoft.com/
When you get there choose the Security option as below:
You will then see your current security information as below, notice the default method is Authenticator in the user portal:
I though these settings were the "live" setting for the myself, but it would appear they are not read on.
Checking the "Entra" authentication methods
This is where it gets little weird, if you try to check them as your user you cannot, not as yourself anyway it refers you back to the "user" driven authentication page we were just on, which is no help.
If however you have another account or you ask someone else to check you will then see the settings you cannot manage yourself for your account, and for me this looked like this:
Interesting so this via has OAUTH TOTP as primary and I also have a load of "Windows Hello for Business" that I do not use anymore that are not visible on the user driven version of this information so you cannot remove them, this means when I have been asked to sign into a laptop this has been created as part of the enrollment process.
I have not removed these "rogue" devices for this profile and have set the default here back to Authenticator as this is methods I am not using anymore.
System Failing : HTTPS Inspection the re-visit
I thought I would write a script to check the critical authentication URL's to see if proxy inspection is indeed enabled on those websites, which would in turn be breaking authentication depending on the resource being requested, the the script returns the fact that yes, we are inspecting these URLS:
When you inspect https://login.microsoftonline.com, you're breaking the certificate chain that Azure PRT (Primary Refresh Token) authentication relies on. The dsregcmd /status showing AzureAdPrt issues is a strong indicator of this.
Azure PRT authentication uses certificate-based flows that require end-to-end TLS trust. When your inspection proxy intercepts this traffic, it:
- Breaks certificate pinning that Microsoft uses for security
- Invalidates the cryptographic chain needed for device certificate validation
- Interferes with token exchange flows that happen during authentication
- Disrupts the client certificate presentation that Windows Hello for Business relies on
Microsoft explicitly advises against inspecting login.microsoftonline.com precisely because of these authentication mechanisms. The URL handles:
- Device registration and certificate exchange
- Primary Refresh Token flows
- Certificate-based authentication workflows
- Windows Hello for Business authentication
Is this HTTPS inspection linked to the "ceritifcate errors"
The inspection proxy is creating a false certificate authentication scenario by breaking the TLS chain.
When the inspection proxy intercepts login.microsoftonline.com, it:
- Terminates the original TLS connection from your client
- Presents its own certificate to complete the connection to Microsoft
- Breaks the end-to-end certificate chain that Azure expects
Why dsregcmd "thinks" You're Using Certificate Authentication:
The broken TLS chain creates artifacts that look like certificate-based authentication to both systems:
- Microsoft's side sees certificate fragments or validation failures and assumes you're attempting certificate-based authentication
- Your client side may be sending certificate-related headers or tokens that are now malformed due to the interrupted TLS flow
- The authentication flow gets confused and tries to process what looks like a partial or corrupted certificate authentication attempt
How does this link to Azure PRT:
Azure PRT (Primary Refresh Token) relies on device certificates for its authentication flow. When the inspection proxy breaks the TLS chain:
- The device certificate that should be transparently handled gets corrupted or misinterpreted
- The system thinks you're actively trying to use certificate authentication instead of it being a background device trust mechanism
dsregcmdshows authentication issues because the device can't properly present its certificates through the broken TLS chain
The inspection proxy isn't just breaking authentication - it's actively misrepresenting the authentication method being used, which then reports as CBA like errors.
AzurePrt is "NO" with HTTPS Inspection enabled
This is an example from a script of the URL we were examining as you can see below:
+----------------------------------------------------------------------+
This shows that the AzureADPrt is not configured using this inspection but if I change by proxy (to a proxy without https inspection) and then lock and unlock my workstation you will notice that the AzureADPrt is now working as it should be:
AzureAdPrtExpiryTime : 2025-08-20 10:40:16.000 UTC
AzureAdPrtAuthority : https://login.microsoftonline.com/<tenantid>
When this is set to "Yes" then the authentication one again works and all the decryption problems vanish and the logins work, however I jumped to conclusions with HTTPS inspection being the issue, and it technically not the issue.
HTTPS Inspection - not the cause, lets move on?
I tried another test and noticed that if using the proxy where HTTPS inspection was enabled only for valid URL's (as above) then the initial login would fail with no AzureADPrt, then if you locked your workstation and then unlocked your workstation without changing your proxy this would then work, as you can see below:
When the AzureADPrt was present everything started working, what I noticed was in the logs there was a short-lived certificates in those logs being used for authentication which was not present in my personal certificate store, which may be cause problems with PRT token acquisition, this is why when you lock your device and unlock it you then get a valid authentication method and AzureADPrt then registers.
dsregtool for Diagnostics
We now need to use the dsregtool to get more detailed logs as you need logs to fix the problem (yes we have been though logs but more are required) this is the process:
- Running as a local admin - I used a different session complete step 2-5
- Download the script extract it to a folder like c:\temp,
- Elevated Powershell prompt navigate to c:\temp
- Run the utility and choose Option 7 (Collect the logs)
- Wait for the utility to ask you to re-produce the steps of the issue
- Running as the local user (in a different session or switch users)
- Run the test 3 (Troubleshoot Microsoft Entra hybrid join)
- Wait for conclusion
- Stop Option 7 from running when completed (take a while to complete)
This will give you some diagnostics log files that will give you some handy information, but for this problem we need to go deep in the logs than this, if you cannot read those speak to Microsoft about analysis.
AuthScript - Verbose details required!
I required to use the deeper scripts to understand what is going on, this should only be required for the failed AzureADPrt in my situsation
- Using a RDP as with an admin account
- Download the zip "authlogs" from the link: here
- Unzip to a folder like "C:\temp"
- Powershell as an administrator required (elevated)
- .\Start-Auth.ps1 -vauth -accepteula
- Wait for repro message before you continue
- Login as the user with the issue (after its logging so Step 6 is complete)
- Wait for 10/15 seconds after the logon.
- Using your RDP session stop the trace with .\stop-auth.ps1
When we look in
This clearly is talking about a certificate being used, but not one I can see as this certificate is being generated by the Citrix Federated Authentication Service (FAS) we also have the only other Entra certificate solution called Certificate Based Authentication (CBA) disabled as we covered earlier.
Lets look at the FAS server and we can see that indeed it is using certificates, here you can see the setup linked to template and a CA as below:
If we look at the template being used we can see the template name:
Citrix FAS does not present the user with the certificate, it does this in the background and its invisible to to the user store which means this is the problem with the PRT acquisition.
PRTs are only issued when one of these are true:
- You authenticate via Azure AD directly (e.g., with password, Windows Hello for Business)
You have a federated login using ADFS or hybrid join with Kerberos Cloud Trust or Certificate Trust
- Username + password (cloud or federated)
- Windows Hello for Business (key or cert-based)
- Device-joined (AADJ or HAADJ) logon where device identity is registered and attested
- Is short-lived
- Is issued by an internal CA
- Is not presented through a supported Azure AD login path
Microsoft Doesn’t Trust Enterprise CAs for Identity Tokens
-
Internal CAs (like those used for FAS) are not trusted by Azure AD or Microsoft Entra ID for issuing authentication credentials.
The FAS certificate being issued by an internal CA and used in a non-standard auth flow is not trusted by Microsoft for PRT purposes.The issue isn't just the certificate lifetime, but that the auth method is fundamentally outside Microsoft's supported PRT issuance paths.
This also is confirmed with users reporting issues like this:
Even with hybrid‑joined VDA’s and CBA enabled, PRT will sometimes not work… dsregcmd /status reports credential type certificate and HTTP error 0x80090027.
Why does locking and unlocking my workstation fix the problem
Glad you asked
1. Unlocking Makes Windows Try Again — Differently
When you unlock your Citrix session (or any Windows device), Windows runs the login process again in the background.
- This time, it might use a different method to verify who you are — such as your cached password or another method Azure trusts.
- That can result in a PRT (Primary Refresh Token) being issued, even though it didn’t happen during the original login.
2. FAS Login Doesn’t Go Through Azure Properly
When you first log in through Citrix FAS:
- You’re logging in with a certificate from your internal system, not directly through Azure AD.
- Azure AD doesn’t trust this on its own, so it doesn’t issue a PRT.
But when you unlock later:
- Windows might try again using your cached credentials or another method that does talk to Azure properly.
- That can succeed in getting a PRT at that point.
Network or Policy May Not Be Ready at First Login
Especially on non-persistent Citrix machines:
- At the exact moment of login, things like Group Policy, network connection, or Azure AD trust may not be ready yet.
- So even if everything else is set up right, the PRT request silently fails.
Later — after everything has caught up — unlocking the session gives Windows another chance, and this time it works.
4. Apps or Windows Can Prompt Azure to Try Again
Modern apps (like Teams or Outlook) might trigger Windows to try again to get a token (PRT) when you unlock.
- Windows uses a system called the Web Account Manager (WAM) to manage tokens.
- On unlock, WAM might say, "Hey, we need a token now," and request one from Azure — and that request is valid and trusted.
Trusting Certificate Authority in Entra
If that CA is not configured and trusted in Entra, then Entra doesn’t recognize or accept the certificate, so you need to upload your certificates to Entra to get this accepted as a certificate, lets get this in a table as an overview, you can do one or all of these if you need to fix this problem.
| Step | Condition | Outcome |
|---|---|---|
| Internal CA not uploaded to Entra | Cert trust missing | Certificate authentication fails, no PRT |
| CA chain uploaded, Entra CBA enabled, proper UPN mapping | Entra trusts certificates | PRT can be issued inside session |
| VDA hybrid join + CBA enabled | Trusted environment | Best chance for consistent PRT issuance |
Note : If you wish to get a walkthrough on that I will cover that in another post - this post is long enough already, but that journey has been fun to say the least.