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