Azure Active Directory (AD) Password Protection is an integral feature of Azure AD that safeguards users from selecting weak, easily guessable, or compromised passwords. Microsoft maintains a “global banned passwords” list that comprises passwords deemed too common. While this list remains unpublished, you can utilize Azure AD Password Protection to validate password changes against it for both cloud and on-premises users.
Additionally, you can create a custom banned password list with up to 1,000 entries to include organization-specific information which could be easily guessed.
When processing a password change, the service normalizes the password (i.e., converting it to lowercase and replacing common substitutions like W3lC0m301 -> welcome01) and compares the result against the banned password lists. If there’s a match, the user receives an error message and is prompted to choose a more secure password.
One drawback of the current implementation is its all-or-nothing approach. It would be beneficial if organizations could implement different password policies for different user groups. Hopefully, future updates will address this limitation.
Before diving into the setup process, let’s briefly discuss licensing! License requirements vary depending on whether you are protecting cloud or AD-synced users and if you want to use the custom banned password list.
Azure AD Password Protection is automatically enabled for cloud users using the global password list, and it cannot be disabled. However, you can configure lockout thresholds and establish the custom password list by navigating to Azure Portal > Azure AD > Security > Authentication methods > Password protection blade or in the new Microsoft Entra Admin Center > Azure AD > Protect & Secure > Authentication Methods > Password protection.
The custom password list permits up to 1,000 entries, with each item having a minimum of 4 and a maximum of 16 characters. Given the system’s password normalization process, it’s advisable to include only keywords, such as “Welcome” or “Monday,” instead of variations like “M0Nd@y!”
Under Azure AD Password Protection settings, you will find an option for Mode, which can be set to “Enforced” or “Audit.” Note that this setting applies only to Windows Server Active Directory, and it does not affect the cloud user password protection status (i.e., it cannot be toggled on or off).
To protect on-premises users who authenticate via a traditional Windows Server Active Directory account (and those users whose accounts are synced using Azure AD Connect), you need to install a proxy service on a member server and an agent and password filter DLLs on the domain controllers. The proxy service enables your domain controllers to access the Azure AD Password Policy service.
You can find the required installers at the download center. There are two installers: the Proxy Setup (EXE) and the DC Agent (MSI). Install the Proxy service on a member server and the DC agent on your domain controllers. Note that updating the password filter DLLs will necessitate a reboot of the domain controllers. Additionally, you will need domain admin rights to the forest root domain, as the forest is registered with Azure AD Password Protection rather than individual domains.
After installation, you must register the proxy and the forest with Azure AD. The process installs a PowerShell module, so open PowerShell and execute the following commands:
Register-AzureADPasswordProtectionProxy -AccountUpn yourglobaladmin@yourtenant.onmicrosoft.com’
Register-AzureADPasswordProtectionForest -AccountUpn ‘yourglobaladmin@yourtenant.onmicrosoft.com’
The -AuthenticateUsingDeviceCode switch is optional, but if omitted, you must either disable Internet Explorer Enhanced Security mode or have a compatible browser installed on the server for the login prompt to function. Utilizing this switch provides a code to enter into a browser on your desktop machine. If you’re installing on Server Core, this switch is necessary since there’s no browser available to display the login prompt.
Once the proxy and forest are registered, there’s no further configuration needed on the domain controllers. To enable the feature, go to Azure Portal > Azure AD > Security > Authentication methods > Password protection blade or in the new Microsoft Entra Admin Center > Azure AD > Protect & Secure > Authentication Methods > Password protection.
In Audit mode, password changes proceed as usual, but the event log on domain controllers will record whether the password would have been rejected. You can find the log under Applications and Services Logs > Microsoft > AzureAD > PasswordProtection > DCAgent > Admin.
Audit mode is valuable for assessing the volume of weak passwords in use before informing users about stricter password policies. It won’t reveal attempted passwords but can help identify which users are the biggest offenders.
A comprehensive list of event log entries associated with Azure AD Password Protection is available in the Microsoft Docs.
When the policy is set to Enforce, attempting to set a password that doesn’t comply with Azure AD Password Protection will yield a generic “Password does not meet the password policy requirements” error.
