Azure AD Connect is Microsoft’s solution to connect on-premises Windows Server Active Directory Domain Services implementations to an Azure Active Directory tenant.

With Azure AD Connect and its underlying Azure AD Sync installation, Microsoft offers four authentication implementation scenarios:

• Password Sync
• Password Sync & Federation
• Password Sync & Azure AD Domain Services (currently in preview)
• Federation

Of course, scenario 4 (Federation-only) does not involve synchronizing password hashes between an on-premises Windows Server Active Directory Domain Services implementation to an Azure Active Directory tenant, but the other three scenarios do.

On Password Sync

Password Sync with Azure AD Connect and Azure AD Sync synchronizes password hashes from one or more on-premises Windows Server Active Directory Domain Services environments to an Azure Active Directory tenant. It can be used with Password write-back and with support for Azure Self-service Password Reset.

On Password Sync and Federation

A Microsoft best practice is to use Federation with Password Sync as a fall-back mechanism for when the Active Directory Federation Services (AD FS)-implementation is unavailable. This way, an admin can change the authentication method for the affected DNS name space(s) (and their underlying subdomains) from federation to password sync (and back) using two Windows PowerShell one-liners.

On Password Sync and Azure AD Domain Services

Azure Active Directory newest feature, Azure AD Domain Services (AADDS) offers a Kerberos, NTLM and LDAP endpoint in Azure Infrastructure-as-a-Service (IaaS) (with even some basic Group Policy thrown in), so you can seamlessly shift and lift your applications and services to Azure IaaS.

The main difference between hosting (Read-only) Domain Controllers in Azure IaaS and Azure AD Domain Services, is that the latter has Azure AD as its back-end. In the first scenario you’d merely be replicating Active Directory objects.

Note:
ADaaS does not offer 100% of the functionality a Domain Controller does; it offers sufficient functionality for the purpose of running most workloads in Azure IaaS. In many organizations, ADaaS will prove to be the solution to get rid of the last on-premises applications in their pursuits of 100% cloud adoption.

Hashing the hash

As you would imagine, Microsoft took all of our security concerns as valuable feedback and provided us additional security when we’re synchronizing the password hashes for our colleagues and customers from our on-premises Windows Server Active Directory Domain Services environment(s) to Azure Active Directory. This takes care of securing these keys in transit. Additionally, Microsoft stores the double-hashed password hash for your colleagues and customers in Azure Active Directory. Consequently, the values stored in both environments never match for any colleague or customer.

But what about Password Sync in the Azure AD Domain Services scenario?

The table below shows you the different password hashing methods used per scenario:

Note:
The NTOWF hash is the result of the NT One Way Function, introduced with NT LanManager version 2 (NTLMv2). This function is based on MD4.

Note:
The OrgID Hash, or Azure AD Connect OWF is the One Way Function that is used by Azure AD Connect and Azure AD Sync to provide additional security on password hashes as synchronized between an on-premises Windows Server Active Directory Domain Services implementation to an Azure Active Directory tenant and as stored in Azure Active Directory. It is a secure PBKDF2 key derived from SHA256 hashing of the NTOWF password hash. More information is available here.

Hashing for Azure AD Domain Services

To be able to offer the functionality your on-premises Windows Server Active Directory Domain Services implementation does, Microsoft can not apply its OrgID-hashing methodology in Azure AD Connect and Azure AD Sync: the values for the stored password hashes on on-premises Active Directory Domain Controllers and from Azure AD Domain Services in Azure Infrastructure-as-a-Service need to match.

This is why, after you turn on the Azure AD Domain Services functionality in the Azure AD Tenant, Azure AD Connect and Azure AD Sync will sync up both the OrgID Hash and the NTOWF Hash.

This is why the Enable Domain Services for this directory switch has a remark reading “By enabling Azure AD Domain Services for this directory, you consent to storing credential hashes required for NTLM and Kerberos authentication in Azure AD.”

Note:
The switch to enable Azure AD Domain Services is located in Azure AD. There is no option to disable or enable this in Azure AD Connect or Azure AD Sync.

As a consequence, when you enable Azure AD Domain Services, you end up in a scenario where:

• You experience a longer synchronization time for the first synchronization cycle after enabling the feature.
• You experience considerable more password change and password reset-related network traffic flowing between the Azure AD Sync installation and Azure.
• Both OrgID hashes and NTOWF hashes are synchronized to Azure AD from your on-premises Windows Server Active Directory Domain Services implementation.

Note:
After you turn off Azure AD Domain Services, the NTOWF hash values for the synchronized objects will not be emptied. There is currently no process to empty these values.

Concluding

Microsoft has thought long and hard on security for Azure AD. Azure AD Syncs security model and the OrgID hash are examples of their execution.

For organizations wanting NTLM or Kerberos in Azure IaaS based on Azure AD, Microsoft is willing to do away with all this for the sake of your legacy.

Further reading

How Secure is DirSync with Password Synchronisation?
DirSync: Password Sync Frequently Asked Questions
How Azure Active Directory Connect Syncs Passwords
Azure AD Domain Services is now in Public Preview – Use Azure AD as a cloud domain controller!