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.



About the Author: steve bowman

Three Minutes For A More Secure & Efficient Infrastructure

Short and to the point, Steve’s Email Blasts give you endpoint management tips, tricks, and news in three minutes or less email read-time, guaranteed.

Model says no to spam. Privacy Policy

Model Technology Solutions

Model Technology Solutions is a small but mighty band of infrastructure experts. We’ve helped companies in diverse industries to modernize and automate their infrastructures through effectively managing their Microsoft endpoint suite.

With us on your team, you’ll watch your security and compliance go up and your IT team’s costs (and headaches) go down. You’ll relax in knowing that your endpoints will be secure and online when your users need them most. And you’ll finally get back to your most-important tasks.

Model Technology Solutions
12125 Woodcrest Executive Drive, Ste. 204 Creve Coeur, MO 63141

Phone: (314) 254-4138
General Inquiries: model@model-technology.com
Sales and Quotes: sales@model-technology.com