A Curious Case: Unable to login to an AutoPilot machine after AutoPilot deployment
While working with a customer on an AutoPilot deployment, I ran into an odd issue which initially had me stumped.
The Issue
The problem I experienced was that AutoPilot would complete successfully, as shown below. I’d be automatically logged into Windows and all was well however if I did anything which would log me out of Windows, such as rebooting the PC I found I was then unable to log back in. Windows simply stated ‘The username or password is incorrect.’
However, it wasn’t.
I’d proved I had the correct credentials from the successful AutoPilot deployment minutes before.
Customer Environment
Before I go into the details of the issue and the fix, I want to outline this customers environment.
Azure AD Native Join was being used in the AutoPilot deployment profile
Federated identities were in use, with ADFS 2016 as the STS.
A third party MFA provider was integrated with ADFS (Duo, in this particular case)
The Solution
Initially I thought the issue was that the customer hadn’t enabled the required WS-Trust and WS-Fed endpoints on their ADFS, outlined in this Microsoft Doc however they had.
Some of you may know that when logging into Windows on a native Azure AD joined device, Windows actually performs a web-based login in the background. This is explained in this Microsoft Doc. You can notice this in the Azure AD sign-in logs as well as shown in the below snippet
Notice that user agent string of “Windows-AzureAD-Authentication-Provider/1.0”?
Make a note of that. We’ll need it in a bit.
So after scratching my head for a bit, a thought came to me;
What if it’s trying to perform Duo MFA via ADFS and failing because it’s not a login request whereby I can see the ADFS login page and it can prompt for Duo MFA?
After speaking with the infrastructure team of the client I was working with, we agreed to exclude my account from any ADFS policies and to allow it to login with zero restrictions to test my theory.
It worked.
I was logged in. Great.
However, obviously I couldn’t suggest to the customer to simply turn off all their ADFS restrictions as they were required for compliance purposes.
After much Googling of that user string and other search terms, I found this Duo KB article which not only explained the issue but had a helpful few examples to resolve. The crux of the article is exactly what I thought it might be; the browser-based login doesn’t show the prompt for MFA and so is unable to authenticate against the IdP (ADFS), resulting in the error on the Windows client.
As stated in the Duo article, there’s two options to fix this but I’m going to list the one we ended up opting for in this scenario which is to make a specific ADFS rule that only allows Windows Azure AD joined clients to login without MFA, but require it for everything else. We ended up creating an additional authentication rule in ADFS which lets the ''x-ms-client-application” value that matches “Windows-AzureAD-Authentication-Provider” in without MFA
AdditionalAuthenticationRules : NOT EXISTS([Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/ x-ms-client-application", Value =~ "(Windows-AzureAD-Authentication-Provider)"]) => issue(Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod"", Value = "http://schemas.microsoft.com/claims/multipleauthn"");
Once that was applied, we were golden.
Why doesn’t this happen with Azure AD Conditional Access or per-user Azure MFA?
Great question.
I don’t know.
I can only suspect that Microsoft do some sort of exclusion on their side to allow this to work seamlessly without any additional configuration and that this is only a potential problem for federated clients with external authentication providers as Azure AD doesn’t handle the issuance of authentication tokens.
If anyone knows a definitive answer on this, I’d be curious to know.
Hopefully some of you found this helpful! Leave a comment if you have any questions and I’ll try get back as soon as I can.