AAD Password Sync, Encryption and FIPS compliance

[Alex Simons (AZURE)]

First published on CloudBlogs on Jun, 28 2014
Howdy folks, 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())             {                 return md5.ComputeHash(data);             }         }

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 SyncSYNCBUSSynchronization ServiceBin miiserver.exe.config. For more information here, refer to http://social.technet.microsoft.com/wiki/contents/articles/24961.password-sync-failing-in-fips-c... 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! Best Regards, Alex Simons (twitter: Alex_A_Simons ) Director of PM Active Directory Team (updated 7/3/2014 to fix a few typos and grammar issues)