Password Hash Sync Chaos - why are user passwords rejected?

Question

Hi,
We've recently enabled Password Hash Sync (migrating from ADFS) and were expecting an easy seamless transition, but it's been as enjoyable being punched in the face! We've experienced a ten fold increase in service desk calls and have users complaining on login failures.

We rolled out PHS and Azure SSO by the following:

1. Enabled PHS around a month ago on AAD Connect and pushed out the AAD SSO URLs to clients at the same time (i.e. https://autologon.microsoftazuread-sso.com)
2. Configured Azure SSO with staged rollout for a small pilot group and tested for several weeks. Tests worked flawlessly.
3. On Wednesday 2nd, switched the domain to PHS (Set-MsolDomainAuthentication -Authentication Managed -DomainName contoso.com). From this point onwards, we had a lot of password reset issues!
4. On Thursday we enabled AAD SSO (Enable-AzureADSSO -ENable $true) for the domain (this was missed on the previous day and missing from the Microsoft documentation).

https://learn.microsoft.com/en-us/azure/active-directory/hybrid/migrate-from-federation-to-cloud-authentication
https://learn.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-sso-quick-start

From AADConnect (Invoke-ADSyncDiagnostics) and the Azure portal AD Connect, Password Hash Sync as a service seems to work fine. Most of our users can logon OK, but we have seen a 10x increase in calls to our service desk. Whilst some of this is user error, I do not believe most of it is.

The issues we've found are:

• A password change on premise can take up to 2 minutes to sync to AAD, so there's a brief time that the password isn't valid in O365, some users might try to repeatedly login or initiate another password reset via SSPR.
• For users that SSO doesn't work, there might be cached credentials in the browser that causes an invalid password attempt.

We have a higher number of password resets than normal being triggered since PHS implemenation, why is this? What can we do to further troubleshoot and mitigate?

Thanks

Answer 1

@TechUser2020-6505 Thanks for reaching out. If I understand your scenario correctly, your environment recently moved from ADFS to Password hash sync method and faced few user login failures.

At the configuration level, with Azure AD connect, when we change the method to password has sync, we expect the user login failures temporarily as it might take some time to change the status from federated to managed. If the issue continues even if the password has synced to azure ad, then that is something we need to fix.

2 minutes window for password hash sync is by design without any manual control over that. One more thing that comes to mind is to make sure that the user account do not have this flag set :
"Change password at next logon" Currently, Azure AD Connect does not support synchronizing temporary passwords with Azure AD. A password is considered to be temporary if the Change password at next logon option is set on the on-premises Active Directory user.

If we have to investigate further, we need to go further with per user basis and find out what happened and where exactly it is stuck. Looking at the behaviors this does not look like a password sync issue, but more of end user specific login behaviors. if you have some sample users UPN, we can try to look further. For that you will need to send us an email at azcommunity@microsoft.com with subject "Atten-Vipul" and I can get back to you to discuss further.

-----------------------------------------------------------------------------------------------------------------

Please remember to "Accept Answer" if any answer/reply helped, so that others in the community facing similar issues can easily find the solution.

Answer 2

Hi All,
Incase anyone else comes across this. We never got to the bottom of the large number of failures - Microsoft weren't very helpful. Support staff took around 5 weeks to get engaged and after 2 months I'm told there's not much they can do as the logs in Azure only go back 30 days.

If you're thinking of enabling PHS, be mindful of:

1. When you implement the switchover - mobile (phone and iPad) users seem particularly impacted, so pick a quiet time.
2. Expect to see the screen below as accounts are modified from ADFS to PHS

https://learn.microsoft.com/en-us/azure/active-directory/hybrid/migrate-from-federation-to-cloud-authentication#convert-domains-from-federated-to-managed

Answer 3

Hi vipulsparsh,
It's TrackingID#2203020050002205

Thanks

Answer 4

""Change password at next logon" Currently, Azure AD Connect does not support synchronizing temporary passwords with Azure AD."

Are you sure? I just checked the "force password change at next logon" in Active Directory and then logged into portal.office.com using the account and was prompted to immediately change my password.

I've got a case open with Microsoft about this at the moment, but so far, it's been hard work and slow progress in getting Microsoft engaged :-(

Answer 5

Just an update - this is mostly problematic with our users who do not have a dedicated PC. People who mainly access O365 services via a mobile phone have had issues with password resets.