Azure AD Password Auditing

Introduction

Password auditing of Active Directory is a common and well-understood practice, and a key security process that many organisations implement. However, with the shift to Azure, the existing methods can’t be used. This article is designed to give a better understanding of how passwords work inside Azure Active Directory (AD), Azure AD Directory Services (DS) and hybrid environments that make use of Azure AD Connect Sync, and how the affect the ability to carry out password audits.

Password Auditing

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

In most cases, the auditing process is not as simple as reading a database full of employee passwords as many organisations do not store them in a readable format, but it does still occasionally happen. Instead, computers use one-way cryptographic hash functions also known as “hashing” to generate an irreversible fixed-length string or “digest” value to identify if a password entered is correct. It does this by checking the hashed value of a submitted password against the stored value that it should match. Detailed steps for carrying this out in an on-prem Active Directory domain can be found in the Active Directory Password Auditing article.

Password Cracking

During the password auditing process, we try to model a particular type of attacker. Most often, an opportunistic cybercriminal that wants to steal user details and discover which passwords people reuse.

The attackers intention would be to copy the hash database of an organisation, in a Windows environment these values would be stored in the NTDS.dit file which is held on domain controllers. The attacker would then generate password guesses using a wordlist or brute force attack and calculate the relevant hash digests to compare against database entries. If a generated hash digest matches the one found in the file, then a valid password has been identified.

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

Azure

This approach to password auditing has been used for many years in traditional Active Directory environments, but with the shift to Microsoft Azure and the cloud hosted versions of Active Directory, it is not always possible.

There are three main deployment models of Active Directory in Azure, which are discussed in more detail in the following sections.

Azure AD

The first deployment type 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.

An important feature of the 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, usernames and password credentials are securely stored in Azure, which is outside of the organisations control. This makes it near impossible to audit weak passwords, so it is important to remember, there are disadvantages to cloud hosting.

Microsoft developed a solution to address these auditing concerns with its Attack Simulator in Microsoft Defender for Office 365. This is a point-and-click security solution that performs operations such as password brute-forcing and phishing campaigns. Unfortunately, it is not very granular and is only available with the more expensive licenses (currently “Microsoft Defender for Office 365 Plan 2”, which is only included in the E5 licenses).

- Azure AD and Domain Joined Azure AD

Azure AD DS

Azure cloud Active Directory Domain Services (AD DS) is a relatively recent addition to the Azure cloud suite that is intended to bridge the gap between cloud hosting and on-premise applications.

Put plainly, it is a private network managed by two domain controllers. The idea is that if you are an organisation that has on-site applications and you wish to host them in the cloud, you can.

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

It is important to remember that Azure AD is the “cloud” active directory service while 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 two ways:

• Spawn a virtual machine 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 point to note when configuring Azure AD DS is that it doesn’t initially work with Azure AD accounts. That is because the AD service does not store passwords in clear text, or as NTLM digests which are required in the on-premise environment.

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

It appeared that this may provide a method to use the traditional Active Directory password auditing techniques by dumping the NTDS.dit file from one of the domain controllers. For example, if an organisation uses Azure AD DS, and it would be possible to setup a Kali VM within the internal network, then it might also be possible to replicate the domain controller settings to the Kali machine.

Unfortunately, Microsoft has done an excellent job of securing the AD DS environment. It does not appear 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 and not the domain admins group. It means you cannot replicate any changes, or perform typical attacks against the domain controllers.

- Azure AD DS with VMs and a VPN Endpoint

Azure AD Connect Sync

The third Azure AD deployment model is the hybrid-cloud variant. This deployment is used when an organisation has a physical AD environment and manages part of it via the cloud.

The concept of this method is to keep the on-premise portion synchronised with Azure AD. This responsibility falls to the Azure AD Connect Sync service whose job is to periodically update the cloud environment from the physical forest.

Note this is “to the cloud, not from it”. That is 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, On Premise AD and AD Connect Sync

Conclusion

It was not possible to 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 which would likely come at an additional cost if at all.

Password auditing of the Azure AD is possible but only with the correct Office 365 subscription. It uses the Attack Simulator contained within the Defender for Office 365 suite.

For quick reference the findings on this topic are listed below:

Deployment Type	Description
Azure Active Directory (AD)	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)	The Microsoft solution to cloud hosting legacy applications that use NTLM and Kerberos Authentication. It is 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 hash digests 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	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.