Sometimes an error is telling you everything you need to know, but not giving you sufficient context to understand it. In retrospect the solution may seem obvious, but at the time it’s just frustrating. I recently ran into an issue with Autodiscover and Office 365 in a hybrid configuration that I had never seen before, and oddly enough neither had Microsoft. It is a gripping story of trust, betrayal, and bad password policies. If you’re getting a 401 Unauthorized Response error from Exchange Remote Connectivity Analyzer, this post might be for you. More past the break…
The setup was relatively straightforward. Two Exchange 2010 SP3 CASHT servers and two Exchange 2010 SP3 MBX servers on-premise with a hybrid configuration to Office 365. DirSync was configured and enabled with hybrid and password synchronization turned on. Autodiscover for the domain was pointing at the two CASHT servers, which were also the hybrid setup endpoints. I tested autodiscover using a two test accounts I had created, one with a mailbox on-premise and one on Exchange Online. Everything checked out with ExRCA, so I passed it along to the customer. They move one user to Exchange Online and autodiscover does not work for him. I create a new test account and autodiscover does not work for me either. In the ExRCA logs it is reporting a 401 Unauthorized error. If I move the account back to on-premise, then autodiscover tests out fine. So now I have a situation where autodiscover on-premise works, but not in Office 365, except when it does… weird.
It’s important to understand how autodiscover actually works in a hybrid setup. The A record for autodiscover.domain.com points to the hybrid servers. When a user tries to query autodiscover, they pass along their credentials and autodiscover checks if they are a mail-enabled user. If the account is mail-enabled, Exchange checks if the account has a local mailbox, and if it does then autodiscover returns the information from Exchange. If the account does not have a local mailbox, Exchange checks the targetEmailAddress property against the Organization Relationships in Exchange and checks if the domain is in the relationship. If it’s found in the relationship, then the autodiscover request is sent to the entry listed in the TargetAutodiscoverEpr property using a 302 redirect.
So I was running the test, and the redirect was occurring, and then getting a 401 error with account credentials I knew where right. Microsoft and I worked together on this one, and the tech had me change the test user password to “Office365@123”. Suddenly, the autodiscover request worked! The tech thought that I must have just been mistyping the password this whole time, but I knew that wasn’t the case. I reset the user password to what it had been before, “BlueFish14”, and the autodiscover failed again. That’s when it finally clicked. The password was not meeting the complexity rules for the Office 365 directory. What was strange is that this test user account could log into Office 365 and OWA with the original password, it just seemed that autodiscover didn’t like the password complexity level!
The password complexity settings for the on-premise Active Directory were lower than the default in Office 365. DirSync was synchronizing passwords from on-premise to the Office 365 accounts, which in theory should only be the password hash. I don’t know how autodiscover even knows that the complexity rules aren’t met, or why it cares, but that was definitely the issue. So if you are getting the following error:
An HTTP 401 Unauthorized response was received from the remote Unknown server. This is usually the result of an incorrect username or password. If you are attempting to log onto an Office 365 service, ensure you are using your full User Principal Name (UPN).
The issue could very well be your complexity rules on-premise. The solution? Change the complexity rules for your local Active Directory password policy, which honestly probably should be updated anyway if they aren’t meeting the relatively basic requirements on Office 365. For your reference that is 8 characters with the following: upper case, lower case, special characters, and numbers.
Director, Cloud Solutions and Microsoft MVP: Cloud (Azure/Azure Stack) & DC Mgmt