Working with a customer and we decided to enable Pass-Through Authentication with SSO instead of Password Hash Synchronization. One of the several benefits of using Pass-Through Authentication instead of Password Hash Synchronization is increased security of not having your password hashes synchronized to a third party service. This is a key benefit as documented here along with other benefits. With Pass-Through Authentication, there are some limitations that you must be aware of. These are documented here.
At the time of writing this article, Free/Busy is not one of them. Free/Busy worked from On-Premises to Exchange Online, but did not work from Exchange Online to On-Premises.
Pass-Through Authentication Client Support
In this link here, it specifically states, “User sign-ins to legacy Office client applications: Office 2010, and Office 2013 without modern authentication. Organizations are encouraged to switch to modern authentication, if possible. Modern authentication allows for Pass-through Authentication support.” This tells us, if we decide to use Pass-Through Authentication, all of our clients must use Modern Authentication.
This link here provides a table on what clients support Modern Authentication. One thing to note, is for Mac OS X
This link here discusses the registry key needed for Office 2013 to utilize Modern Authentication. This link also mentions that for Office 2016, no registry key is needed.
This link here discusses browser support and mentions that for Mac OS X using Safari, Mac OS X must be Active Directory Joined.
Free/Busy Problems
All clients were Office 2016 including MAC OS X. MAC OS X was also domain joined. So no need to enable any registry keys. When a user was migrated to Exchange Online, everybody still On-Premises could still access the user’s Exchange Online user’s Free/Busy. The problem was that any users migrated to Exchange Online could no longer open On-Premises calendars and see On-Premises free/busy.
We would get the following error:
Going through the Free/Busy Troubleshooter available here, everything looked configured correctly.
We went through the following steps to troubleshoot:
- Ensured the Reverse Proxy was not doing any Pre-Authentication for /EWS/* and /Autodiscover/*
- Ensured the DomainName values were set correctly in Get-OrganizationRelationship both On-Premises and Online
- Looked at IIS Logs and saw /autodiscover and /EWS passing through to Exchange
- Ensured WebServicesVirtualDirectory had an ExternalURL defined
- Ran a Get-AutodiscoverVirtualDirectory | Set-AutoDiscoverVirtualDirectory -WSSecurityAuthentication $true
- Ran a Get-WebServicesVirtualDirectory | Set-WebServicesVirtualDirectory -WSSecurityAuthentication $true
- Ensured the Hybrid Server had svc-Integrated handler mappings
- In Exchange Online Powershell, ran a Get-OrganizationRelationship -Identity “Exchange Online to On Premises Organization Relationship” | FL and verified all the details looked correct.
- In Exchange Management Shell, ran a Get-OrganizationReationship -Identity “On Premises to Exchange Online Organization Relationship” and verified all the details looked correct
- Verified Sharing Policies to make sure they were configured to allow the sharing of Free/Busy
- In Exchange Online Powershell, did a Set-OrganizationRelationship -Identity “Exchange Online to On Premises Organization Relationship” -TargetSharingEpr “https://webmail.domain.com/EWS/Exchange.asmx/WSSecurity” to hard code the EWS URL to ensure Free/Busy wasn’t failing due to an Autodiscover Issue.
Nothing worked. So I decided to do the following command in Exchange Online PowerShell:
Test-OrganizationRelation -Identity “Exchange Online to On Premises Organization Relationship” -UserIdentity “On-Premises User E-mail Address”
As can be seen, we are getting the error, “FailureToGetDelegationToken” which is getting a FailedAuthentication telling us the password has to be changed. Of course, I decided to search online for this error and got back one hit that was very recent. The hit was a Technet Forum post here. The individual posting mentioned that he was using Pass-Through Authentication and his error was 100% identical. He fixed this by going into AAD Connect and enabling Password Hash Synchronization as an Optional Feature to Pass-Through Authentication. This means, you’ll still be using Pass-Through Authentication for Authentication but Password Hashes will still be synchronized to Azure AD.
More on this is documented in the Pass-Through Authentication Current Limitations article here. In the Important section, it means that as a workaround for unsupported scenarios only, you can enable password has synchronization on the Optional Features page in the Azure AD Connect Wizard. But again, Free/Busy not working from Exchange Online to Exchange On-Premises is not listed as a current limitation or an Unsupported Scenario.
So we decided to go ahead and enable Password Hash Synchronization as an optional feature in the Azure AD Connect Wizard. We then confirmed that Password Hashes were synchronizing to Azure AD by doing the following:
- On the Azure AD Connect synchronization server, we ran the following and it returned $true which told us the Azure AD Connect synchronization server was successfully enabled to synchronize Password Hashes.
Import-Module adsync
$adConnector = (Get-ADSyncConnector | ? {$_.Type -eq “AD”}).Name
Get-ADSyncAADPasswordSyncConfiguration -SourceConnector $adConnector
- Opened PowerShell on our Azure AD Connect synchronization server and did a Connect-MSOLService and authenticated. Ran the following command which returned $true which told us that the Azure AD environment is set up to accept Password Hash Synchronization.
(Get-MsolCompanyInformation).PasswordSynchronizationEnabled
- On the Azure AD Connect synchronization server, opened Event Viewer and looked at the application logs filtering on 656/657 which will confirm that password hashes are successfully synchronizing.
We ran another test using the following command in Exchange Online Powershell:
Test-OrganizationRelation -Identity “Exchange Online to On Premises Organization Relationship” -UserIdentity “On-Premises User E-mail Address”
And the results we got back were much better!
And sure enough, going into Outlook 2016 and testing Free/Busy to an On-Premises Mailbox as well as opening calendars for On-Premises Mailboxes were working!
It definitely seems as if there’s a bug with Exchange Online Organization Relationships/Federation where if using Pass-Through Authentication will cause Free/Busy failures to On-Premises Mailboxes unless you also synchronize Password Hashes.
Update 12/06/2017
Microsoft took the bug I submitted and created a KB on it: https://support.microsoft.com/en-gb/help/4056251/free-busy-lookup-fails-from-exchange-on-premises-to-exchange-online
It appears that you can run the following command to alleviate the issue which is a per-user command:
Set-MsolUserPassword -UserPrincipalName [email protected] -ForceChangePassword $false
I don’t have a chance to test it anymore but at least there is a KB on it now and if it doesn’t work, you have your other option which is to enable Password Hash Synchronization as an Optional Feature to Pass Through Authentication.
Leave a Reply