Authentication Issues with Azure AD Connect with On-Prem ADFS 3.0
By Steve Bowman
Published September 11, 2015
Estimated Reading Time: 2 minutes

I recently had an engagement where a standard O365 redirect to on-premise ADFS 3.0 authentication was required. I ran into an odd configuration issue that redirected users to a blank Microsoft online login page. I thought at first the authentication on premise was not working and the redirect was due to a bad token/response from ADFS. I enabled verbose security logging and found that the authentication request was properly working and returning through the claims provider to O365. I then connected to the tenant via powershell and ran the following:

 

Get-MsolFederationProperty -DomainName <DomainNameHere>

 

The specific value I was looking for was the Thumbprint of the signing certificate. At first, the thumbprint did not match the on-premise certificate. I then ran the following to update the federation property:

 

Update-MsolFederatedDomain -DomainName <DomainNameHere>

 

Note: Normally with an empty root domain setup on premise, you must use the following switch to support multiple domains: -SupportMultiDomain

This was not the case for my environment, as I had a single forest domain configuration.

I then was able to rerun the Get-MsolFederationProperty command to verify the thumbprints now matched. However, users still experienced the blank Microsoft login page after a successful authentication on-premise.

As a last resort, I converted the online federated domain back to standard with the following:

 

Convert-MsolDomainToStandard -DomainName <DomainNameHere> -SkipUserConversion $True
Note: In an scenario where you have not enabled password hash synchronization, I would recommend not skipping the user conversion step as this will not allow users that rely on adfs to login to online services in the time it takes to remediate on-premise authentication. I would run the following to provision individual passwords to provide to users during the outage if you expect it to be long enough to effect production’s ability to work:

 

Convert-MsolDomainToStandard -DomainName <DomainNameHere> -SkipUserConversion $False -PasswordFile <Path to TXT File for Password List>

 

Running the command above will convert all existing federated users to standard cloud users with their respective passwords being written to a text file specified in the –PasswordFile switch. Note: This is very time consuming based on the number of users that exist in Azure AD/O365.
After the domain finished converting to standard, I refederated the domain with the following command:

 

Convert-MsolDomainToFederated -DomainName <DomainNameHere>

 

Note: Once again, depending on your hierarchy on premise…you may need to specify the –SupportMultipleDomains switch.

After converting the domain back to federated, Users were able to authenticate to O365 without issue.

Hopefully this saves some time for anyone experiencing this type of authentication issue, as the symptoms lead me around in circles before remediating the root cause.

 

Dp

Post Tags:
Article By Steve Bowman
Steve Bowman is a Partner at Model Technology as well as their Vice President of Sales and Marketing. Steve is a father, husband, Franciscan, and lover of technology. He's bilingual in business and technology and have over 30 years of experience in selling enterprise technology solutions in a variety of industries.

Related Posts

Paying high cyber-insurance premiums?

Prove you’re cyber-ready and reduce your premiums through our NIST-based cybersecurity assessment. Then make the most of your assessment results through monthly consulting sessions with our vCISO Director of Cybersecurity.

Learn More