Azure AD Domain Services – A First Look

AADDS

Earlier this week Microsoft announced the preview of Azure AD Domain Services (AADDS). This new functionality allows applications that are designed to run against your On Premise Active Directory to easily run in Azure (with out having to put in place domain controllers in Azure and VPN connections back to your on premise AD).

In simple terms at the click of a button you can have a ‘managed’ domain controller fully synced up with your Azure AD appear in one of your VNet’s.  You can then domain join your Azure servers in the same way you would your On Premise servers.

There are a number of steps that have to be undertaken to enable Azure AD Domain Services but Microsoft have written a great blog that steps you through the process.  You must complete all steps before attempting to join an Azure VM to the new AADDS domain.

Couple of points to note from my testing so far.

  • Azure AD Domain Services are not yet available in all regions. If you have all your Azure infrastructure running in the Australia regions you will need to create a new VNet in either the US, Europe or Asia region to be able to enable Domain Services.
  • Azure AD Domain Services uses password write back to sync passwords with Azure AD.  As with AD Connect a password reset using http://myapps.microsoft.com is generally required to generate the hashes in AD before the account can be used to authenticate against the Azure AD Domain Service.
  • Any user account that you put in to the AAD DC Administrators group will be added to the administrators group on any machines you join to the AADDS domain.
  • As Azure AD Domain Services its a managed service you can not have Domain Administrator or Enterprise Admin privileges over the AADDS domain.
  • Currently a single user and computer group policy is supported and the domain can be managed with the same tools that are used to manage on-premise AD.

Further Blog articles to come as I rebuild my Azure test environment using Azure AD Domain Services!

Advertisements

Azure AD Password Sync and Writeback – Security and Encryption 

People are often concerned regarding the risk of turning on Password Sync and Password Writeback between on premise AD and Azure AD.   This post looks to describe the password sync and password writeback processes and the encryption methods used to secure the password data in transit and at rest.

1) Password Sync to Azure AD

The password Sync agent (which is part of the Azure AD Connect tool) running on the on premises Azure AD Connect server makes an RPC call to its closest on premises DC and requests via the DC replication protocol the users password hash. The DC takes the users password hash and using an MD5 key (made up from the RPC session key and a random 128 bit salt) encrypts the password hash for transport over the wire. The DC then sends the encrypted password hash plus salt to the password sync agent over the RPC session. Note this is the same way Domain Controllers replicate password hashes.

The password sync agent then decrypts the encrypted password hash using the salt and RPC session key and immediately re-hashes the password hash to a SHA256 hashed password hash using the PBKDF2 key derivation algorithm as defined in RFC 2898.

The password sync agent then passes the hashed password hash over an SSL encrypted session to Azure AD. Azure AD then encrypts the hashed password hash using AES and stores it in its database.

2) Password Writeback

When password writeback is enabled Azure AD Connect creates a tenant specific service bus relay, protects it with a strong password and attaches to the service bus relay using TLS encryption.  Azure AD Connect also creates a public private key pair. The public key is placed in the tenant’s secret store in Azure AD and the private key stays on the on premise Azure AD Connect server.

When a password is reset in Azure AD, Azure AD encrypts the new password using the public key uploaded by Azure AD Connect and places the encrypted password on the service bus relay, Azure AD Connect picks up the encrypted password from the relay and decrypts it on the on premise Azure AD Connect server.   The Azure AD Connect server then attempts to reset the user’s password using the Active Directory DS SetPassword API.   If the password reset against the on premise AD succeeds the user is notified of the success and the resultant hashed password hash is encypted using AES and then stored in Azure AD.

If Azure AD connect is not successful in writing the password back to the on premise AD ( failing password complexity requirement for instance) or the Azure AD Connect server is down.  Azure AD will not be updated and the user attempting the password reset will be notified that the reset has not succeeded.

For further reading check out the following blogs and presentations:

http://blogs.technet.com/b/ad/archive/2014/06/28/aad-password-sync-encryption-and-and-fips-compliance.aspx

http://channel9.msdn.com/Events/TechEd/NorthAmerica/2014/DCIM-B301

  https://msdn.microsoft.com/en-us/library/azure/dn903642.aspx