SaaS applications are different, they are not installed on a local machine and don’t have the access to local Active Directory domain controller that’s why SaaS application often use disjoint identity providers and user have to maintain separate username and passwords multiple cloud-based applications. Single Sign-On (SSO) is the common answer to resolving this. SSO is defined as the ability for two disjoint identity provider to trust one another so that as a user can log in IDP and then when trying to access resources secured by the second IDP and not need to log in again. That trust called federation trust.
Office 365 is the one of the popular SaaS application, which has the three identity models for Office 365, and we have to determine the successful Office 365 onboarding is start with the simple identity model that meet organizational needs. Once you finalize the identity model then you have to think another part of the Office 365. Let’s take a look at each one in a brief detail:
Cloud identity: In this model user is created and managed in Office 365 and store in Azure Active Directory and the password is verified by Azure Active Directory. There are no equivalent user account on-premises.
Synchronized Identity: In this model, the user identity is managed in On-Premises server and the accounts and password hashes are synchronized to the cloud. The user can enter the same password on-premises and in the cloud also, the password is verified by Azure Active Directory. In this model, we need to use sync tool such as AAD, DirSync.
Federated identity: This model requires a synchronized identity but one changes, the user password is verified by the on-premises identity provider. No need to password hash synchronized to Azure Active Directory. We can use Active Directory Federation Services or any third party federation provider.
In this article I will try to explain the Synchronized Identity (Password Hash Sync), let’s start:
What is Password Hash Sync
We have involved from plain text password storage to hashing a password, to appending salts etc. When a password has been hashed it means it has been turned into a scrambled representation of itself. Password hashing is one of the most basic security considerations that must be made when designing any application that accepts passwords from users, without hashing any password that is stored in your application's database can be stolen if the database is compromised.
Hashing is a type of algorithm which takes size of data and turns it into a fixed-length of data. This is often used to ease the retrieval of data as you can shorten large amounts of the data to a shorter string.
Now a question is what is the difference between hashing and encryption, simple is hash is not reversible.
You cannot directly turn a hashed value into the password, but you can work out what the password is if you continually generate hashes from passwords until you find one that matches a so-called brute-force attack or similar methods.
Following if the workflow for account registration and authentication in a hash-based account system:
- The user creates an account.
- Users password is hashed and stored in the database.
- When a user tries to log in, the hash of the password they entered is checked against the hash of their real password (retrieve from the Database).
- If the hashes match, the user is granted access, if the not user will get the message “Invalid login credentials”.
When the username or password they got wrong, always give a generic message “Invalid username or password” this will prevent attackers from enumerating valid username without knowing their passwords.
Modern Hashing Algorithms
MD-5, SHA-1, SHA-2, SHA-3
When & Why use the Password Hash Sync
We are using password hash sync because to implement simple then federation service, Microsoft always want to integrate on-premises AD to Azure AD and password hash sync does this without the need for some multiple servers. Password hash sync provides a smooth path for these organizations to move to the cloud. Also, the advantage of password sync is that, unlike a federation, it does not depend upon an external federation service to process authentications. There is only one configuration option to add password hash sync to Directory Sync tool this is done during the configuration wizard and is a small checkbox where we can choose password hashes in addition to the users’ profile attributes. If enabled password hash sync applies to all synchronized users. While a Federation deployments take some efforts due to additional servers and network implementation, on-premises servers also required internet access through any corporate firewalls in a secure way, and they also have to be highly available since logins are not possible if internet connectivity is offline. Password Hash Sync is the feature of directory synchronization it only required a single server with outgoing access to the Internet in order to connect to Azure AD there is no requirement for inbound connections, custom firewall openings or highly available configurations.
Photo courtesy of Microsoft
How Password Synchronization works
- Every two minute the password sync agent on the DC connect server request stored password hashes from DC with help of the replication protocol (MS-DRSR) to sync the data between the DCs.
- DC encrypts the MD5 hash from DC4 password hash before sending of the RPC session key and a salt. The DC also passes the salt to the synchronization agent by using the DC replication protocol so that agent will decrypt the envelope.
- MD5crryptoServiceProvider and salt to generate a key to decrypt the received data back to its original MD4 format, password synchronization agent does not have the access to the clear text password.
- The Password synchronization agent’s use the MD5 for replication protocol compatibility with the DC and only use on-premises between the DC and the password synchronization agent.
- Password sync agent expands the 16-byte binary password hash to 64 bytes by first converting the hash to a 32-byte hexadecimal string, then converting this string back into binary with UTF-16 encoding.
- Password sync agent adds a salt, consisting of a 10-byte length salt, to the 64-byte binary to further protect the original hash. Then combines the MD4 hash plus salt and input into the PBKDF2 function.
- Password sync agent takes the resulting 32-byte hash, concatenates both the salt and the number of SHA256 iterations to transmits the string from Azure AD Connect to Azure AD over SSL.
- Now when the user tries to sign in to Azure AD and give the password, the password is run through the same MD4+Salt+PBKDF2+HMAC-SHA256 process, if the hash matches the hash stored in Azure AD, the user has entered the connect password and is authenticated.
Photo courtesy of Microsoft