Scenario: When authenticating to an Exchange On-Premises mailbox with using the interactive login presented by Hybrid Modern Authentication, you get stuck in an endless loop of interactive login attempts:
1. You successfully satisfy the interactive logon
2. The interactive login window disappears as it normally should after a successful login
3. But immediately the interactive windows pops back up for you to do it again.
Solution: In our case, we had to replace the Authentication Certificate that was being used in the MSOLServicePrincipalCredential for Exchange Online. However, lets walk through some of the troubleshooting than into the fix:
1. TEST OAUTH Connectivity
I tested OAUTH Connectivity between Exchange Online and Exchange On-Premises, running these commands:
#From Exchange Online PowerShell
test-OAuthConnectivity -Service EWS -TargetUri https://<OnPremises Exchange Namespace>/metadata/json/1 -Mailbox <ExOnline MBX UPN> -Verbose
#From Exchange On-Premises PowerShell
test-OAuthConnectivity -Service EWS -TargetUri https://outlook.office365.com/ews/exchange.asmx -Mailbox <ExOnline MBX UPN> -Verbose
Both resulted in ResultType: Error with the details of the Error being:
System.net.webexception: The remote server returned an error: (401) Unauthorized. ……. Reason=”The token has an invalid signature.”;error_category=”invalid_signature
2. Hmm, seems like our Hybrid Modern Auth is broke — Bad tokens are being generated. So its time to start digging into the Configure OAUTH authentication between Exchange and Exchange Online Organizations
Now, Hybrid Modern Authentication was already enabled and working at some point in the past in this environment– how long ago? not really sure. So I know most of these components are already there and enabled. To jump straight to the solution that fixed us, it was Step 3 and Step 4,
Step 3: Export the on-premises authorization certificate
$thumbprint = (Get-AuthConfig).CurrentCertificateThumbprint
if((test-path $env:SYSTEMDRIVE\OAuthConfig) -eq $false)
{
md $env:SYSTEMDRIVE\OAuthConfig
}
cd $env:SYSTEMDRIVE\OAuthConfig
$oAuthCert = (dir Cert:\LocalMachine\My) | where {$_.Thumbprint -match $thumbprint}
$certType = [System.Security.Cryptography.X509Certificates.X509ContentType]::Cert
$certBytes = $oAuthCert.Export($certType)
$CertFile = "$env:SYSTEMDRIVE\OAuthConfig\OAuthCert.cer"
[System.IO.File]::WriteAllBytes($CertFile, $certBytes)Step 4: Upload the on-premises authorization certificate to Azure Active Directory Access Control Service (ACS)
Connect-MsolService
$CertFile = "$env:SYSTEMDRIVE\OAuthConfig\OAuthCert.cer"
$objFSO = New-Object -ComObject Scripting.FileSystemObject
$CertFile = $objFSO.GetAbsolutePathName($CertFile)
$cer = New-Object System.Security.Cryptography.X509Certificates.X509Certificate
$cer.Import($CertFile)
$binCert = $cer.GetRawCertData()
$credValue = [System.Convert]::ToBase64String($binCert)
$ServiceName = "00000002-0000-0ff1-ce00-000000000000"
$p = Get-MsolServicePrincipal -ServicePrincipalName $ServiceName
New-MsolServicePrincipalCredential -AppPrincipalId $p.AppPrincipalId -Type asymmetric -Usage Verify -Value $credValueAfter running this command, I immediately tested with my email client and Poof — no more interactive logon loop. Test-OAUTHConnectivity was also coming back a success. One more command that I found helpful was verifying the MSOLServicePrincipalCredential:
Get-MsolServicePrincipalCredential -ServicePrincipalName “00000002-0000-0ff1-ce00-000000000000” -ReturnKeyValues $true | Select Type, KeyID, StartDate,EndDate
After I uploaded, and actually did it twice to see if there would be any negative impact (there was not), I saw the new certificate listed. You can easily identify the cert by the StartDate/EndDate of it.
Uploading the new cert fixed it!
Ex-Shell 