How to Enable Azure AD Password Protection: A Step-by-Step Guide


As an IT admin, preventing your users from using simple or known-hacked passwords has become critical for the overall security of your enterprise. An excellent step to take is to plan for and deploy Azure AD Password Protection. In this article, I’ll walk you through installing the Proxy service and DC agent in your on-premises Active Directory, then register them with your Azure Active Directory (recently renamed Microsoft Entra ID) tenant.

What is Azure AD Password Protection?

More often than you want to admit, users in your organization often create passwords using common local words like a birthday, a child’s name, a school, or even a famous person. Because these passwords are easy to guess, they open up your enterprise to hackers and major security risks.

To enforce strong and complex passwords in your environment, Azure AD Password Protection provides a global and automatically downloaded banned password list. A local password change request will fail if a user attempts to use a banned password from the file.

The first steps to implement Azure AD Password Protection include installing the proxy service and domain controller (DC) agent software on a few of your on-premises servers. Then you register these with your Azure Active Directory tenant.

There are two modes that the solution runs in, Audit mode and Enforce mode:

  • Audit mode is used to monitor and log infractions from your users changing their passwords.
  • After you pilot the software for a while, you can switch to Enforce mode which will block users from changing their passwords with a banned password.

Azure AD Password Protection licensing

Is Azure AD Password Protection free? Well, that depends. The two downloads you’ll use (the proxy service and DC agent I mentioned above) are no-cost. The only potential cost is listed in the table below.

If your environment is running on hybrid mode with both Active Directory and Azure AD, you will need either Azure AD Premium P1 or P2 licenses for your users. If you happen to have ‘cloud-only’ users and only wish to use the global banned password list, then there will be no costs for your organization.

Here is a small table that details what specific features require Azure AD Premium license plans.

UsersAzure AD Password Protection with global banned password listAzure AD Password Protection with custom banned password list
Cloud-only usersAzure AD FreeAzure AD Premium P1 or P2
Users synchronized from on-premises AD DSAzure AD Premium P1 or P2Azure AD Premium P1 or P2
Licensing details of Azure AD Password Protection

How are passwords evaluated with Azure AD Password Protection?

If you look at the architectural diagram provided by Microsoft below, you get an idea of how the tool works.

  1. A user initiates a password change.
  2. The DC agent on one of your domain controllers processes the password filter DLL and sends the request to the proxy service on one of your domain member servers.
  3. The DC agent service processes them by using the current password policy and returns a result of pass or fail.
The architecture of Azure AD Password Protection
The architecture of Azure AD Password Protection (Image credit: Microsoft)

Global banned password list

Azure AD Password Protection includes a global banned password list. The content of this list isn’t publicly available, but it’s based on the ongoing results of Azure AD security telemetry and analysis of user passwords utilized in Azure AD.

When a user tries to change their password, the desired password will be checked against this list. This will happen automatically for every Azure AD customer.

Custom banned password list

To offer customers more flexibility on what passwords are allowed in your organization, Azure AD Password Protection also supports custom-banned password lists. These lists work alongside the global list mentioned above to enforce your enterprises’ specific requirements in terms of words that may resemble people, products, headquarter sites, etc.

Users will see an error like these when trying to use one of these custom-banned passwords:

  • Unfortunately, your password contains a word, phrase, or pattern that makes your password easily guessable. Please try again with a different password.
  • Unfortunately, you can’t use that password because it contains words or characters that have been blocked by your administrator. Please try again with a different password.

Password spray attacks and third-party compromised password lists

Another security threat addressed by Azure AD Password Protection is password spray attacks. The majority of password spray attacks submit only a handful of known insecure passwords against each of the accounts in an organization.

Azure AD Password Protection blocks all known weak passwords likely to be used in these password spray attacks. This is based on real-world security telemetry data from Azure AD to build the aforementioned global banned password list. Because third-party websites that contain millions of compromised passwords are geared towards brute-force methods of invasion, those techniques aren’t the best way to improve overall password strength. 

What are the requirements for Azure AD Password Protection?

Let’s take a look at the requirements for implementing Azure AD Password Protection. Then I’ll offer some guidance on how to deploy this solution, how many servers to use, how many DCs to install the agents on, and more.

Here are some general Windows Server software requirements from Microsoft to be aware of.

  • All machines, including domain controllers, that have Azure AD Password Protection components installed must have the Universal C Runtime installed.
  • You need an account that has Active Directory domain administrator privileges in the forest root domain to register the Windows Server Active Directory forest with Azure AD.
  • The Key Distribution Service must be enabled on all DCs in the domain that runs Windows Server 2012 and later versions. This service is enabled via a manual trigger start by default
  • Network connectivity must exist between at least one domain controller in each domain and at least one server that hosts the proxy service for Azure AD Password Protection. This connectivity must allow the domain controller to access RPC endpoint mapper port 135 and the RPC server port on the proxy service.
  • All machines where the Azure AD Password Protection Proxy service will be installed must have network access to for authentication requests and for Azure AD Password Protection functionality.

There are other requirements for the Azure AD Password Protection DC agent and proxy service, and you can check out the support page on Microsoft Learn for more details.

How to implement Azure AD Password Protection

Now that we have all the requirements fresh in your mind, let’s start with the installation steps. We’ll begin with the proxy service.

Deploying the Azure AD Password Protection proxy service

This first install step will typically require at least two member servers in your Active Directory domain. These servers will communicate with Azure AD to maintain a copy of the global and custom banned password lists for your Azure AD tenant.

Note: each server can only provide password policies for a single forest. The server must be joined to the domain. You will also need network connectivity between at least one DC in each domain of the forest and one password protection proxy server.

To install the proxy service, we will first download the software from the Microsoft Download Center.

Here is my Downloads folder on one of my member servers (WS22-FS02).

Downloads folder showing the two downloads for Azure AD Password Protection
Downloads folder showing the two downloads for AAD Password Protection (Image credit: Petri/Michael Reinders)

Let’s double-click on AzureADPasswordProtectionProxySetup.exe. We will check the license terms checkbox and click Install.

Installing the Azure AD Password Protection Proxy Bundle
Installing the Azure AD Password Protection Proxy Bundle (Image credit: Petri/Michael Reinders)

And we’re done!

Successful installation of the Azure AD Password Protection Proxy bundle
That was easy! Setup is complete (Image credit: Petri/Michael Reinders)

We now turn to PowerShell to finish the setup. Let’s first import the new module that was just installed with the Import-Module command. Then, we will run the Get-Service command to confirm that the service is running.

Import-Module AzureADPasswordProtection

Get-Service AzureADPasswordProtectionProxy | fl
Using PowerShell to import the modules
Using PowerShell to import the modules (Image credit: Petri/Michael Reinders)

Next, we need to register the idle proxy with our Azure AD tenant. You will need a Global Administrator account to provision your first proxy service in your tenant. Although various authentication methods are available, let’s go with the most common and do it interactively.

Register-AzureADPasswordProtectionProxy -AccountUpn '[email protected]'
Registering the Azure AD Password Protection Proxy with Azure
Registering the proxy in Azure (Image credit: Petri/Michael Reinders)

No news is definitely good news. Let’s run a test command and verify the config worked.

Test-AzureADPasswordProtectionProxyHealth -Testall
Confirming the prior command registered successfully
Confirming the prior command registered successfully (Image credit: Petri/Michael Reinders)

Yes! Looking good so far. Next, we register our on-premises AD forest with the appropriate credentials to communicate with Azure. You will need to use an account with either Global Administrator or Security Administrator rights, Enterprise Administrator AD rights, and an account with local administrator permissions. Yikes.

Register-AzureADPasswordProtectionForest -AccountUpn [email protected]
Doing final checks for all initial configurations
Doing final checks for all initial configurations (Image credit: Petri/Michael Reinders)

Again, we’re solid. Let’s move on to the DC agent!

Deploying the Azure AD Password Protection DC agent

If that seemed like a lot of steps, don’t worry. There’s literally a single step for installing the Azure AD Password Protection DC agent.

From the earlier download location, you just need to install the .MSI file and that’s it! I’ve logged into one of my DCs (WS16-DC2) and am double-clicking on the AzureADPasswordProtectionDCAgentSetup.msi file.

Installing the Azure AD Password Protection DC agent
Installing the AAD DC agent software (Image credit: Petri/Michael Reinders)

Let’s check the license agreement box and click Install.

Setup complete for the Azure AD password protection DC agent
It worked! Setup complete (Image credit: Petri/Michael Reinders)

That’s all there is to it! Oh, and a reboot.

Confirming the service is installed and running
Confirming the service is installed and running (Image credit: Petri/Michael Reinders)

Looks like we’re 5 by 5 (Aliens reference, thank you very much…).

Enabling on-premises Azure AD Password Protection (in Azure)

There is one final step. We need to enable this feature in the Azure Active Directory administrative center.

The Azure Portal website
The Azure Portal website (Image credit: Petri/Michael Reinders)

On the left navigation, first, click Security -> Authentication methods -> Password protection.

Password Protection features in Azure AD
Password Protection features in Azure AD (Image credit: Petri/Michael Reinders)

That’s interesting: Here, the Enable password protection on Windows Server Active Directory feature is already enabled and set to Yes. Plus, we are in Audit mode, meaning only banned password change events are logged. Users are NOT blocked… yet. When you switch to Enforce, users WILL be blocked when attempting to change their password from the list.

Using the Custom banned passwords list is as easy as setting that feature to Yes
Using the Custom banned passwords list is as easy as setting that feature to Yes (Image credit: Petri/Michael Reinders)

Enabling Azure AD Password Protection is worth it

This is a relatively easy-to-install solution that will help you control your users’ security. Implementing the custom banned password list will prevent your users from using common publicly known product names, headquarter sites, and even local sports team names from being used as passwords.

If you have any questions or comments, please leave them below, and thanks for reading!