People are often concerned regarding the risk of turning on Password Sync and Password Writeback between on premise AD and Azure AD. This post looks to describe the password sync and password writeback processes and the encryption methods used to secure the password data in transit and at rest.
1) Password Sync to Azure AD
The password Sync agent (which is part of the Azure AD Connect tool) running on the on premises Azure AD Connect server makes an RPC call to its closest on premises DC and requests via the DC replication protocol the users password hash. The DC takes the users password hash and using an MD5 key (made up from the RPC session key and a random 128 bit salt) encrypts the password hash for transport over the wire. The DC then sends the encrypted password hash plus salt to the password sync agent over the RPC session. Note this is the same way Domain Controllers replicate password hashes.
The password sync agent then decrypts the encrypted password hash using the salt and RPC session key and immediately re-hashes the password hash to a SHA256 hashed password hash using the PBKDF2 key derivation algorithm as defined in RFC 2898.
The password sync agent then passes the hashed password hash over an SSL encrypted session to Azure AD. Azure AD then encrypts the hashed password hash using AES and stores it in its database.
2) Password Writeback
When password writeback is enabled Azure AD Connect creates a tenant specific service bus relay, protects it with a strong password and attaches to the service bus relay using TLS encryption. Azure AD Connect also creates a public private key pair. The public key is placed in the tenant’s secret store in Azure AD and the private key stays on the on premise Azure AD Connect server.
When a password is reset in Azure AD, Azure AD encrypts the new password using the public key uploaded by Azure AD Connect and places the encrypted password on the service bus relay, Azure AD Connect picks up the encrypted password from the relay and decrypts it on the on premise Azure AD Connect server. The Azure AD Connect server then attempts to reset the user’s password using the Active Directory DS SetPassword API. If the password reset against the on premise AD succeeds the user is notified of the success and the resultant hashed password hash is encypted using AES and then stored in Azure AD.
If Azure AD connect is not successful in writing the password back to the on premise AD ( failing password complexity requirement for instance) or the Azure AD Connect server is down. Azure AD will not be updated and the user attempting the password reset will be notified that the reset has not succeeded.
For further reading check out the following blogs and presentations: