Azure AD Passwords

Fingerprint Icon Written by Chris Powell

Azure Cloud

This post details my voyage into understanding how passwords work inside of Azure Active Directory (AD), Azure AD Directory Services (DS) and hybrid environments that make use of Azure AD Connect Sync.

Password Auditing

For people that have not heard of password auditing before, it is something security people like me do regularly. The idea is to review passwords within an organisation to see how resistant they are to hash cracking and brute force attacks.

Most of the time, the auditing process isn't as simple as reading a database full of peoples passwords — not many organisations store them in a readable format anymore — but it can happen. Instead, computers use one-way cryptographic hash functions — a.k.a hashing — to generate a deterministic value from passwords.

Password Cracking

During a password audit, we try to model a particular type of attacker. Most often, an opportunist cybercriminal that wants to steal details and access passwords people reuse.

The basic idea is to copy an organisations hash database — in Windows environments, they are kept on domain controllers in a file called NTDS.dit. Next, we generate password guesses and calculate the relevant hash digests to compare against database entries. If a generated digest matches the one found in the file, then we have identified a password.

The process helps provide an insight into the susceptibility of an organisation to password cracking and brute force attacks.

Azure AD

The first cloud product we encounter is Azure AD. It is an authentication and authorisation endpoint, hosted by Microsoft which allows users to connect to a variety of cloud applications. Most typically, the Office 365 suite.

What's nice about Azure AD is that it uses a strong and robust model built on top of OpenID and OAuth. It also allows organisations to domain join their IT infrastructure, which can be managed entirely in the cloud.

In either case, your secure username and password credentials are stored in Azure, which is outside of your control. This makes it near impossible to audit weak usernames and passwords, so remember, there are disadvantages to cloud hosting.

Microsoft decided to address these auditing concerns with its Advanced Threat Protection (ATP) Attack Simulation feature. It's a point-and-click security solution that performs things like password brute-forcing and phishing campaigns. Unfortunately, it's not very granular and comes with a hefty price tag.

Azure AD
- Azure AD and Domain Joined Azure AD

Azure AD DS

The next stop on our Azure cloud tour is AD DS — Active Directory Domain Services. It's a relatively recent addition to the Azure cloud suite that's meant to bridge the gap between cloud hosting and on-premise applications.

In simple terms, it's a private network managed by two domain controllers. The idea is that if you're an organisation that has on-site applications and you wish to host them in the cloud, then you can.

It doesn't matter if they use NTLM authentication or Kerberos, you can still use Azure. The AD DS domain controllers also synchronise with your original Azure AD service.

Remember, Azure AD is the “cloud” active directory service — Azure AD DS is a private network with standard domain controllers hosted in the cloud.

You can connect to Azure AD DS in one of twos ways:

Spawn a Windows, Ubuntu, Kali box etc. in the Azure environment and place it in the private network, or Create a VPN endpoint with access to the hosted AD DS network.

An interesting thing to note when configuring Azure AD DS is that it doesn't initially work with Azure AD accounts. That's because the AD service doesn't store passwords in the clear, or as NTLM hashes which are required in the on-premise environment.

What this means is that your users and services accounts created in Azure AD cannot authenticate via AD DS until you reset the password, in turn, generating the appropriate NTLM digests as required.

During my research, I thought this may present an entry point for password auditing. If an organisation uses Azure AD DS, and I can stand-up a Kali box within the internal network, then I might be able to replicate the domain controller settings to my machine.

Unfortunately, Microsoft has done an excellent job locking down the AD DS environment. I don't believe there is any way to compromise the environment within the realms of the End User License Agreement (EULA).

Cloud accounts created via the web-interface are placed into an AD DS administrators group, not the domain admins group. It means you cannot replicate any changes, or perform typical attacks against the domain controllers.

Azure AD
- Azure AD DS with VMs and a VPN Endpoint

Azure AD Connect Sync

Finally, we arrive at the hybrid-cloud model. In simplest terms, this is where an organisation has a physical AD environment and manages part of it via the cloud.

The idea is to keep the on-premise bit synchronised with Azure AD. This responsibility falls onto the Azure AD Connect Sync service who's job is to periodically update the cloud environment from the physical forest.

Note that I said to the cloud, not from it. That's because credential data only flows one way — from on-premise to the cloud — not in the reverse direction. However, there are some unique exceptions.

One example is the Self Service Password Reset (SSPR) feature that allows users to reset their own passwords. But only accounts created through the on-premise environment will be synchronised out of Azure AD.

Azure AD
- Azure AD, On Premise AD and AD Connect Sync

Conclusion

To conclude, I cannot find a simple, repeatable way to perform password audits on Azure AD — even when using the Azure AD DS and the Connect Sync service.

Unfortunately, this is something that must be sacrificed when moving to cloud environments, that is unless service providers include additional provisions for password auditing. But I don't think that's likely.

Remember that password auditing is possible with the correct Azure AD license. It uses the Attack Simulator contained within the Office 365 Advanced Threat Protection (ATP) suite.

For a quick reference, I have included my findings below:

  • Azure Active Directory (AD) is a cloud-hosted service provided by Microsoft that provides Single Sign-On (SSO) for applications like Office 365. It also permits domain joining machines to allow device management within organisations. It uses OpenID and OAuth for its authentication and authorisation needs.
  • Azure AD Domain Services (DS) is Microsoft's answer to cloud hosting legacy applications that use NTLM and Kerberos Authentication. It's a private network with two domain controllers that plug directly into the Azure cloud and can be accessed via a VPN endpoint or a hosted server. NTLM hashes are not generated in Azure AD by default, so if Azure AD DS is activated, then account passwords must be reset before they are accessible on the network segment.
  • Azure AD Connect Sync is the AD service that synchronises accounts between physical AD forests and the Azure AD cloud environment. Data almost exclusively flows on-way to the cloud unless the SSPR license is active to allow password resets. Then it only synchronises with accounts that have specifically been created in the on-premise forest, never the cloud.