The Security of Identity Synchronization to Azure Active Directory
One of the biggest concerns many businesses have when it comes to expanding to the cloud is, rightfully so, security. And while there are many components to cloud security, one that gets more than its share of scrutiny is identity and password synchronization.
On the surface, the idea that you are going to take account data, including usernames and passwords that exist in Active Directory, and synchronize it with an entity for which you have no authority does seem like it might be a bad one, or at least one that would generate some questions. Who will have my passwords? Are they retrievable? Are they stored in plain text? How are they transmitted during synchronization? What happens if the entity holding them gets hacked?
Now, it would be irresponsible (and naive) to make a blanket statement that all cloud platforms are safe and that all vendors take the same measures to protect identities. But in the case of Microsoft’s Azure AD platform, businesses should feel comfortable that their identities are kept as secret and as safe as in their own on-premises Active Directory.
To determine how secure Azure AD is, we need to start at the source – your local Active Directory. Does anybody remember that huge data breach in which the company’s Active Directory was hacked and all the users’ passwords were exposed? No? That’s because it’s never happened. This is not to say that no company has ever had its NTDS.DIT file stolen. It doesn’t even mean that an NTDS.DIT file has never been hacked. The reason why an Active Directory password breach is virtually impossible is because there are no plain text passwords kept anywhere in Active Directory. This is the same reason why you cannot call your company’s help desk administrator to retrieve your password and need to have it reset instead. All passwords are stored as non-reversible hash values in Windows Server Active Directory Domain Controllers. Of course, you need to make sure that you take care to properly secure your network and your Active Directory Domain by making sure to follow security best practices, such as not storing passwords using reversible encryption.
Without getting too deep into the math, a hash is a one-way function that maps data (your password) of arbitrary size to data of fixed size (the hash value). The results of the function are repeatable (hashing the same password multiple times will yield the same hash value) but not reversible (you cannot derive the password from the hash). An additional security measure called a salt can be added to a hash to increase security. A salt adds random characters to a password before the hash function is run in order to further randomize the hash value. In the case of a salted hash, two users with identical passwords will have completely different hash values produced.
So now that we are comfortable that our on premises Active Directory is secure, let’s get our identities to the cloud.
As we have already established, your Active Directory Domain Controller does not have a plaintext version of your password at rest, so when Azure AD Connect (or previous versions such as DirSync) runs its password synchronization agent, it can only sync the password hash value. In order to get this value from the Domain Controller to the Azure AD Connect server, the synchronization agent encrypts the hash with an MD5 cryptographic key that is derived from the RPC session key and a salt. Once this encrypted envelope is received by Azure AD Connect, it is decrypted to expose the original hash. Note that the Azure AD Connect server is an on-premises server and that no information has left the network at this point.
With the hash successfully and securely transferred to the Azure AD Connect server, the password sync agent re-hashes the password hash value with an irreversible SHA256 hash before transmitting it over a secure connection to the cloud. At this point, Microsoft does not have your password and it does not have a hash of your password; it has a hash of a hash of your password.
And in case you’re wondering how irreversible this irreversible SHA256 hash is, let’s do some quick math:
The number of possible iterations of a 256-bit hash are 2256 which comes to roughly 1.15 × 1077. This not exactly the number of iterations that would be valid for the hash values (remember that hash values are all fixed length, so 0, 1, 2, 39999, etc. are not going to be valid values) but to put this number in perspective, it is bigger (WAY bigger) than the estimated mass in kilograms of the observable universe (3 × 1052). If a computer were able to attempt 1 trillion passwords per second, it would take 1.15 × 1065 seconds or 3.67 × 1057 years to try every possible value.
The day may come when quantum computing can perform these calculations orders of magnitude faster than even the fastest modern supercomputers, but today is not that day.
