Whatever password complexity you apply through group policies, users will always find a way to use the simplest and most used password on the internet like P@$$w0rd, As Active Directory doesn’t have any native feature to protect from this user behavior, Azure AD Password protection comes to the rescue to provide the intelligence of the most used passwords used on password spray attacks so that you keep your users safe from password spray attacks. Even though passwordless is the future. it’s going to take some time to reach there as there are so many legacy dependencies in every brownfield environment.

It’s recommended to have Password Writeback enabled so that users can reset in both places either Cloud or OnPrem seamlessly. You can check the status of password write back, it shows healthy in the below screenshot (Your on-premises writeback client is up and running). As password protection works only with Azure AD Premium P1 or P2, you can enable the password to write back which comes with the same set of licenses as well through Azure AD Connect.

Let’s see how to implement them. As there is no minimum forest functional level or forest functional level for the agent or the proxy. you can implement in any environment. but what we observed is installing them on Windows Server 2012 R2 is a bit hectic as it requires .NET 4.7.2 versions to be installed. Installing them on Windows Server 2019 was seamless as the .NET was pre-installed.

There are two URLs need to be reached by Azure AD Password Protection Proxy to talk to Azure AD to gain the updates.

It’s better to allow them directly as they are standard Microsoft URLs, if you have a proxy and if you don’t want to bypass them you have to update config files which are not covered in this article.

On High Availability, you don’t have to worry as these Azure AD Password Protection Proxy going down doesn’t affect the environment. Only the new signatures (updated banned list for example) will not be updated until the Azure AD Password Protection Proxy server coming up. Unless you have a very large environment you certainly don’t have to bring multiple servers to maintain High availability for this. if you have a good backup we are good. if you have multiple sites you don’t have to bring multiple Proxy servers to each site as its updates the default SYSVOL shares of domain controllers which will be replicated throughout the forest with standard mechanisms as the domain controllers don’t have to speak to the internet directly.

You need a dedicated server on your primary site where the majority of users are in terms of resetting their passwords so that any new changes on the custom password banned list gets updated immediately for you majority of users, Even though you can bring multiple proxy servers on multiple sites to improve that, we don’t have such requirement though on this particular case.
let’s see how to download and install the proxy setup,

Download Azure AD Password Protection for Windows Server Active Directory from Official Microsoft Download Center

Open Powershell – Run as administrator – Browse to AzureADPasswordProtectionProxySetup.msi and open it so that it opens with elevated privileges.

Open Powershell to Import AzureADPasswordProtection Module to check the Proxy status

Import-Module AzureADPasswordProtection

To check the status of the proxy use the below PowerShell command.

Get-Service AzureADPasswordProtectionProxy | FL

Now let’s register the proxy with Azure AD with your Global Admin Credentials

Register-AzureADPasswordProtectionProxy -AccountUpn 'yourglobaladmin@yourdomain.com'

Once your proxy agent is healthy. let’s make sure one of the domain controllers can access the Proxy agent to get the updates to the SYSVOL shares to replicate them to the whole environment.

To Verify Health using Powershell –

Test-AzureADPasswordProtectionProxyHealth -TestAll

Run as administrator – AzureADPasswordProtectionDCAgentSetup.msi install them on all domain controllers. before installing them on Domain Controllers make sure you are running the password protection on Audit mode. (it’s on Audit mode by default). So that you don’t affect the users.

Now let’s install the AzureADPasswordProtectionDCAgentSetup.msi on all domain controllers. As the password protection mode is on audit mode it’s not going to enforce anything.

Once you install them they come online with Audit mode.

if you try to reset with a simple password “Password@1234” 10025 is generated with Audit only

Event Logs location on Domain Controllers – \Applications and Services Logs\Microsoft\AzureADPasswordProtection\DCAgent\Admin

if the password is healthy 10015 is generated.

Once you feel everything is working as expected you can enforce them.

Resetting with a simple password

You can list the installed Domain Controller agents using the below command

Get-AzureADPasswordProtectionDCAgent

Also, you can get a summary using the below PowerShell which queries the event viewer and gets you collective results.

Get-AzureADPasswordProtectionSummaryReport -DomainController DCName

Once all you users reset the password after this is enabled. you are well protected from Password Spray attacks in your environment