Over the last few months, I have noticed that a lot of customers have been working to configure Active Directory Federation Services (AD FS) single sign-on for Azure Virtual Desktop (AVD) to enable a more seamless login solution for their hybrid AVD solution. Throughout my time as a Microsoft customer engineer, I’ve had the opportunity to work with those customers and have found that very minor configuration mistakes can sometimes lead to rather complex troubleshooting efforts. In this blog post, I will share a recent case to help break down the AVD SSO login process and provide some examples to help isolate configuration issues. Thanks David Morillo and Michael Kullish in helping write this blog.
Okay, so you have configured Azure Virtual Desktop AD FS Single Sign On, tried to login, it doesn’t work. Let's say you are presented with numerous, somewhat obscure errors and aren’t sure where to start – for example:
So… now what?
First and foremost, it’s important to understand that there are several technologies that must all come together to provide the AVD SSO functionality. These include Active Directory Certificate Services (ADCS), ADDS, AD FS, Azure Key Vault, Azure Active Directory, and various parts of AVD (SessionHost, AVD Gateway, AVD Broker).
Normally, the first indication SSO isn’t working is by seeing the Windows Security Authentication prompt following a successful authentication to AD FS.
Take for example the following flow:
After selecting the hostpool the AD FS login prompt is displayed:
But, unexpectedly after the above you get a Windows user authentication prompt:
In this situation, you know something has gone wrong.
Where to check:
Often a great place to begin the search is within Log Analytics. A pre-requisite of course is that you have diagnostics configured for both Azure Virtual Desktop and Azure Key Vault.
First, let’s check to see if the AVD application is successfully retrieving the certificate from Key Vault. To do that we can use this query:
From the Azure portal:
Search “Log Analytics workspaces” > Select “<workspace for key vault>” > Select Logs > Paste below query into query editor
AzureDiagnostics
| where ResourceProvider == "MICROSOFT.KEYVAULT"
| where identity_claim_appid_g == "9cdead84-a844-4324-93f2-b2e6bb768d07"
| project TimeGenerated, Resource, OperationName, ResultType, ResultSignature
| sort by TimeGenerated desc
In the event of a failure, you might see the following:
In this case, you need to verify the appropriate permissions are configured in your Key Vault’s access policies. The Windows Virtual Desktop application should have Get specified for Secret Permissions:
You will know this part of the flow is working when the Log Analytics query above returns as follows:
While we are here in Key Vault, it is also worth validating the “AllowedWVDSubscriptions” tag has the GUID of the subscription where your AVD resources are created:
To check for errors on the tag use this query:
WVDErrors
| where Message contains "AllowedWVDSubscriptions value doesn't contains"
| project TimeGenerated, Message
If you don’t find any indications of an issue in the above queries, we’ll need to dig deeper into the authentication flow by reviewing the AD FS Admin and potentially the AD FS Trace event logs. Now, these logs can be unwieldy, so before diving in headfirst it’s worth being prepared with some ammo that can help us quickly find the relevant information. The ammo we need is a Correlation ID associated with our failed login attempt which we can again obtain from the AVD diagnostic logs:
WVDErrors
| where UserName == "<username>"
| sort by TimeGenerated
Message <extended>: Windows Virtual Desktop couldn’t connect to the AD FS server that provides single sign-on support. Calling https://sts.contoso.com/AD FS/ for cert logon returned status BadRequest content {"error":"invalid_client","error_description":"MSIS9622: Client authentication failed. Please verify the credential provided for client authentication is valid."}. Make sure the AD FS server is working and reachable from the service side.
Using this CorrelationId we can directly search the AD FS servers’ AD FS Admin event logs in a couple different ways. In my opinion, depending on the size of your AD FS farm, it’s best to use PowerShell so you can quickly locate which server contains the most info around the failed request:
$xPath = "*[System[Correlation[@ActivityID='{<CorrelationID>}']]]"
Get-WinEvent -LogName "AD FS/Admin" -FilterXPath $xPath
Note: If needed you can loop through all your AD FS servers in the farm by passing them into the “-ComputerName” parameter)
$xPath = "*[System[Correlation[@ActivityID='{<CorrelationID>}']]]"
$adfsServers = 'adfsServer1','adfsServer2'
$adfsServers | ForEach-Object { Get-WinEvent -ComputerName $PSItem -LogName "AD FS/Admin" -FilterXPath $xPath }
With this command we should get output of more detailed results on what the underlying error really is. In the case of this recent customer issue the error displayed as follows:
As I worked with the customer inspecting this error message we noticed an additional slash within the Audience URI, which certainly could be a root cause of their issue:
Armed with this knowledge we reviewed the configuration of their hostpool settings
with a particular interest in what the SSO ADFS Authority property was set to:
Get-AzWvdHostPool -Name "<HostpoolName>" -ResourceGroupName "<RGName>" | fl *
As we looked, we noticed there was a trailing slash at the end of the SsoadfsAuthority value, so we went ahead and made a small adjustment using the Update-AzWvdHostPool cmdlet.
Update-AzWvdHostPool -Name <HostPoolName> -ResourceGroupName <ResourceGroup> -SsoadfsAuthority “https://sts.contoso.com/ADFS”
Notice that we supplied the parameter input of SsoadfsAuthority without a trailing slash as documented on our AVD AD FS SSO docs page:
After all this the customer tested again and this time around the login was successful!
What we learned during this troubleshooting session was just how important the AVD and Key Vault diagnostic logs are in helping walk through the authentication flow to identify root causes.
Even simple configuration issues like this can sometimes be hard to spot as the culprit, but once you understand the methods to find where things may breakdown the mysteries often become much clearer and easier to solve. Happy troubleshooting!