Password Hash Synchronization (PHS) ensures a hash of the user’s password is copied from the directory into the Azure AD. When a user’s password is stored in AD, it is stored as a hash; that is, the password has a mathematical algorithm applied to it that effectively scrambles it. A user’s password is prevented from being readable if the underlying database is compromised.

With Azure PHS, the password that is already hashed is hashed once again—a hash of a hash—before it is then stored in the Azure AD, providing an extra level of protection, as per the example shown in the following diagram:

Figure 3.9 – Azure PHS

The result of all this is that when a user authenticates against Azure AD, it does so directly against the information stored in the Azure AD database.

An AD Connect synchronization client is required on a computer in your organization if communications to your domain are severed for whatever reason. Users can still authenticate because they are doing so against information in Azure AD.

One potential downside, however, is that this synchronization process is not immediate. Therefore, if a user updates their details, it won’t reflect in the Azure AD accounts until the sync process has taken place, which by default takes 30 minutes. However, this can be changed, or synchronizations can be forced, which is useful if a bulk update is performed, especially on disabling accounts.

Note that some premium features such as Identity Protection and Azure AD DS require PHS.

For some organizations, storing the password hash in Azure AD is simply not an option. For these scenarios, one option would be pass-through authentication (PTA).

Azure AD PTA

With PTA, when a user needs to authenticate, the request is forwarded to an agent that performs the authentication and returns the result and authentication token, as in the example shown in the following diagram:

Figure 3.10 – Azure PTA

Another reason you may wish to go for this option is if any changes to user accounts must be enforced across the enterprise immediately.

These agents must have access to your AD, including unconstrained access to your domain controllers, and they need access to the internet. You therefore need to consider the security implications of this, and the effort involved; for example, opening firewall ports. All traffic is, of course, encrypted and limited to authentication requests.

Because PTA works by handing off the process to an agent, you need to consider resilience. It is recommended you install the AD Connect agent on at least three servers to both distribute the load and provide a backup should one of the agents go offline.

If you still lose connectivity to your agents, authentication will fail. Another failsafe is to use PHS, although this, of course, requires storing password hashes in Azure AD, so you need to consider why you opted for PTA in the first place.