Azure AD Connect is a Microsoft utility that will sync your Active Directory records to Azure AD/Office 365. An introduction to this is available here.

One of the benefits of Azure AD is being able to use it as your point of authentication for users over the internet, without having to poke holes in your on-premises firewall. I was considering this for a 3rd party solution – but I had a concern.

How Do Passwords Work in Azure?

Azure AD/Office 365 stores passwords for users created ‘On Cloud’ – i.e. the primary record for them exists in Azure AD/Office365. For the ‘On Cloud’ users, password resets are instant, because the same system that hosts the user, manages their password.

Azure AD/Office 365 does not store passwords for your on-premises users. Instead, it uses a password hash. To learn more about this, read Mircosoft’s article on Understanding Office 365 identity and Azure Active Directory. This only functions if you’ve actually enabled password sync, which is a tickbox configurable from the Azure AD Connect side of things.

This means an on-premises user still authenticates against Azure AD/Office 365, but details are synced using Azure AD Connect on a scheduled basis. Someone’s phone number changes? That’ll be pushed to the cloud on the next sync. By default, that sync is every 3 hours. Personally I prefer every hour, but this is going to be dependent on the size of your AD environment if that makes sense.

What about Password changes?

Password hashes are different though. They occur every few minutes – sometimes within seconds. Event logs on the server that hosts Azure AD Connect will show three different events occuring.

The first is the ‘Password Change Request’ Event ID 656. From this you’ll see which user it is, as well as when the password change was actually made according to AD.

Second is the batch count, Event ID 651. This shows that it’s finished collecting details of password changes.

Finally, the Password Change Result record, Event ID 657. This should show the user affected again, and the result of the password change (which is hopefully Success):

I was hoping passwords would almost be instant (within a few seconds) and my original testing showed that, but after more testing I found mixed results. More often it would take a minute or two.

Real World Impact

This means that if you have any application that authenticates against Azure AD, there is a chance of up to a roughly 3 minute delay before Azure AD knows of the new password, and won’t create a great experience for end users depending what applications they use, even first party.

Consider if you had Sharepoint Online for something staff accessed, and someone logs onto their domain connected PC. Their password has expired, so they change it and continue logging in. First thing they do is try and get to the SharePoint Online website, and get prompted for credentials. They try their new password, and it doesn’t work! So they try their old password… but in between these two attempts, their password in Azure AD has now updated. The old password doesn’t work either! From an end user perspective, that’s incredibly confusing.

Solution

The real solution to all of the above is to not use Azure AD Connect, and instead use ADFS. Instead of syncing passwords, password requests come from Azure AD back to your on-premises ADFS environment to authenticate a user. This will be immediately aware of a password change, and authenticate the user with the right credentials. You get the added benefit of pass-through authentication to Azure/Office 365 resources, which means users don’t need to keep authenticating to online resources (such as my SharePoint Online example above).

Any questions/comments/disputes on the above? Comment below!

Thanks to @Froosh for confirming my tests on this.