A couple weeks back, Taylor Higley asked a question on Twitter about Azure AD Password Sync, MD5 and FIPS compliance:
My reply was a bit cryptic and prompted replies from Eric Kool-Brown and Brian Arkills that pointed out that one-way hashes can't be decrypted (at least not without some brute forcing):
This blog post is a follow up to that conversation with more details now that I can take advantage of the luxury of having a more than 140 characters to use.
So, why does Password Sync fail to run on a Federal Information Processing Standard (FIPS) compliant machine and what is going on under the covers? This is because FIPS compliant systems bar the use of MD5 hash algorithms, so they block Password Sync when the tool tries to access MD5 functions.
Does Password Sync use MD5 functions for encryption? The answer is No. Here's what is actually going on under the covers.
User passwords are stored as a non-reversible hash in Windows Server Active Directory Domain Controllers (DCs). When our password sync agent attempts to synchronize the password hash from a DC over a secure RPC interface, the DC encrypts that password hash using an MD5 key. The MD5 key that the DC uses is derived from the RPC session key and a salt. Once this happens, the password hash is now wrapped in an MD5 encryption envelope. The password sync agent gets this encrypted password hash from the domain controller over the secure RPC interface.
The following is a code snippet how the MD5 hash key is generated.
byte ComputeMd5(byte sessionKey, byte salt)
byte data = new byte[sessionKey.Length + salt.Length];
Buffer.BlockCopy(sessionKey, 0, data, 0, sessionKey.Length);
Buffer.BlockCopy(salt, 0, data, sessionKey.Length, salt.Length);
using (MD5 md5 = new MD5CryptoServiceProvider())
Once the Password sync agent has the encrypted password hash it uses MD5CryptoServiceProvider to generate a hash key used for decrypting the envelope containing the password hash. At no point in time does the password sync agent have access to the clear text password. The password sync agent then secures the password hash by re-hashing it using a stronger SHA256 hash per RFC 2898 before uploading it to the cloud.
So when MD5CryptoServiceProvider is used in a FIPS compliant environment, it throws a System.InvalidOperation exception. This is because the MD5 hash is considered a weak hash and not recommended for use in a FIPs environment. However since it is not being used to do encryption, we believe this is a non-issue.
Password Sync can be enabled in a FIPS compliant system by locally disabling FIPS for the Directory Sync process. This can be done by adding <enforceFIPSPolicy enabled="false" /> in the miiserver.exe.config file. The miiserver.exe.config can be found at % ProgramFiles \Windows Azure Active Directory Sync\SYNCBUS\Synchronization Service\Bin\ miiserver.exe.config.
For more information here, refer to http://social.technet.microsoft.com/wiki/contents/articles/24961.password-sync-failing-in-fips-compliant-systems.aspx
I hope this is helpful and provides clarity for everyone interested in this issue.
As always, would love to get any feedback or suggestions you have!
Alex Simons (twitter: Alex_A_Simons)
Director of PM
Active Directory Team
(updated 7/3/2014 to fix a few typos and grammar issues)
This totally makes no ense. MD5 Encryption Envelop?
And no, there is no excuse for using MD5 as one-way for password hashing, it is still weak (easy to bruteforce and most likely even easier than that to collide)
This is a great post! Thank you for sharing your ideas. I always love learning new things because they widen my knowledge regarding certain things. Thanks and more power.
Is what is stored by Azure a verifier, or a hash of an NT hash which is not salted?
I am concerned with salting.
Neither the NT hash nor the LM hash is salted. Salting is a process that combines the password with a random numeric value (the salt) before computing the one-way function. Windows has never stored hashes in human-readable form, so there has never been a need
to salt them.
Windows also stores a password verifier on domain members when a domain user logs on to that domain member. This verifier can be used to authenticate a domain user if the computer is not able to access the domain controller. The password verifier is also commonly
called a cached credential. It is computed by taking the NT hash, concatenating the user name to it, and then hashing the result by using the MD4 hash function.
Like Bernd says, there is no such thing as an MD5 encryption envelope. As you note, AD does not store clear text passwords. The Windows client converts the initial user-entered plain-text password into a hash using the One-Way-Function (OWF) and that is
what is stored on the user object. Then when the user subsequently logs in, the Windows client runs the password through the OWF and sends the encrypted hash to the DC where it is decrypted and compared to the stored password OWF hash. Consequently DirSync
never has to mess with clear text passwords. Sure, you'd want to encrypt the password OWF hash when it is on the wire to AAD, but you'd use an encryption algorithm like RSA not a hash algorithm like MD5. Perhaps AAD is applying another round of hashing to
the password because the OWF is known to be weak, but why use MD5 at all, just use SHA256 directly.
BTW, my description is simplified for the sake of brevity. There are lots of good write-ups on the LM and NTLM OWFs including an excellent one by Jesper Johansson