Last Update: Jul 17, 2023 | Published: May 31, 2023
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.
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:
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.
Users | Azure AD Password Protection with global banned password list | Azure AD Password Protection with custom banned password list |
---|---|---|
Cloud-only users | Azure AD Free | Azure AD Premium P1 or P2 |
Users synchronized from on-premises AD DS | Azure AD Premium P1 or P2 | Azure AD Premium P1 or P2 |
If you look at the architectural diagram provided by Microsoft below, you get an idea of how the tool works.
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.
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:
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.
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.
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.
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.
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).
Let’s double-click on AzureADPasswordProtectionProxySetup.exe. We will check the license terms checkbox and click Install.
And we’re done!
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
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]'
No news is definitely good news. Let’s run a test command and verify the config worked.
Test-AzureADPasswordProtectionProxyHealth -Testall
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]
Again, we’re solid. Let’s move on to the 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.
Let’s check the license agreement box and click Install.
That’s all there is to it! Oh, and a reboot.
Looks like we’re 5 by 5 (Aliens reference, thank you very much…).
There is one final step. We need to enable this feature in the Azure Active Directory administrative center.
On the left navigation, first, click Security -> Authentication methods -> Password protection.
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.
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!