SOLVED

Azure AD Connect Password hash synchronization

Brass Contributor

We use password hash synchronization with Azure AD Connect sync.   Federation, SSO and pass-through authentication are all disabled.

 

When we log onto our workstation computers using a domain user name, are we authenticating at that point with Azure AD or our on-premises Active Directory? 

 

I don't know if this is relevant, but in the AAD admin portal, all our devices are flagged as 'Azure AD registered' (not Azure AD joined - not exactly sure of the difference).  

 

We have a custom Office 365 domain name.  A local server is our domain controller.

 

I am asking this because it appears that our local network 'maximum password age' default domain policy that is set in Group Policy Management is not taking effect.  It is set to 42 days, but we are never asked to enter a new password.  

 

The Microsoft Admin Center Security & Privacy setting has the password expiration set to never.  This appears to be the one that is taking precedence when we log into our domain on our workstations.

 

Is that expected behavior?  

 

Do you need more information from my end?

 

Thank you,

Betty

 

PS:  the powershell command "Get-AzureADUser" shows 'DisablePasswordExpiration' for everybody's PasswordPolicies.

3 Replies

Hello there @Betty Stolwyk thanks for your question! 

When you use Password hash sync, you actually just replicate the on-prem password to your cloud identity, so you have the same password in both places. 

So when you login to your workstation with domain\username you are authentication to your local domain controllers. 

And when you login to portal.office.com with your user@domain.com user, then you are authentication with Azure AD. 

 

When password hash sync is enabled, the password policies in your on-premises AD overrides complexity policies in the cloud. 

HOWEVER...

If a user is in the scope of password hash sync, by default the cloud account password is set to Never Expire for that user. So that your user in the cloud has password never expires is expected. 

 

You can continue to sign in to your cloud services by using a synchronized password that is expired in your on-prem AD. Your cloud password is updated the next time you change the password in the on-prem AD.

 

To sumarize 

  • When you sign in with domain\user, you authenticate with the local Domain controller(s)
  • When you sign into Office365, you authenticate with Azure AD
  • Password never expires on the cloud accounts is expected with password hash sync 
  • Password Hash sync just duplicates the on-prem password and sets that for the cloud identity 
    • If the password expires in the local AD, the user can still login to Office365 with that expired password until its changed on-prem 

I hope this answered your question!

Let me know if I can assist you further. 

 

Kind Regards
Oliwer Sjöberg

@oliwer_sundgren Thank you for your quick response!  

 

I appreciate the clarification that logging into our workstation authenticates against our local Active Directory.  That makes sense.

 

However, that information reinforces my confusion about why we never get asked for a new password on workstation login when we hit the 'maximum password age' of 42 days as defined by

our local default domain policy that is set in Group Policy Management.  (I was thinking that might have been overridden by the Azure AD password policy of never expiring, but you cleared that up that is not the case.)

 

So it looks like this is a question that is outside of this forum's subject area since it must be some problem with the on-premises password policy.

 

So unless you happen to have some insight or advice for me on that, I will consider  this answered 🙂

 

betty

best response confirmed by Betty Stolwyk (Brass Contributor)
Solution
No problem, happy to help 🙂
It does seem like youll need to double check the password GPO. You could , from a logged on worksation do the "GPRESULT" command from CMD to see all GPOs that are applied to that user and worksation.

I would appreciate if you could mark my reply as "best response" if you feel satisfied 🙂

Let me know if you have other questions , feel free to DM me !

Kind regards
Oliwer Sjöberg
1 best response

Accepted Solutions
best response confirmed by Betty Stolwyk (Brass Contributor)
Solution
No problem, happy to help 🙂
It does seem like youll need to double check the password GPO. You could , from a logged on worksation do the "GPRESULT" command from CMD to see all GPOs that are applied to that user and worksation.

I would appreciate if you could mark my reply as "best response" if you feel satisfied 🙂

Let me know if you have other questions , feel free to DM me !

Kind regards
Oliwer Sjöberg

View solution in original post