Configuring Azure AD Password Protection and extending to on-premises Active Directory
I have recently been studying for the MS-500 exam and I think Azure AD Password Protection is quite a nifty feature which is often forgotten about when organisations enable the features included in the Enterprise Mobility + Security (EMS), Microsoft 365 E3 or Microsoft 365 Business Premium license.
So in this post we'll go through what Azure AD Password Protection actually is, how to enable it and then finally how to extend the password protection to on-premises Active Directory.
What is it?
Microsoft maintain a list of globally banned passwords in Azure AD. This is taken from analysis of telemetry from the millions of sign-ins Azure AD handles. They then use this to block commonly used weak passwords. There's some key things to note about this global banned password list:
It's not based off any external data sources such as password dumps
The list is based entirely on the ongoing results of Azure AD security telemetry and analysis.
When a password is set or changed, the current version of the global banned password list is used when validating the strength of the password.
Let's say Jane works in the Sales department of Contoso Corp. Her password is C0nt4s0!C4rp". That password meets complexity requirements but we know it's not secure.
You can add to this banned password list!
You can add specific terms to the banned password list which are specific to your organisation. You can block passwords which contain easily identifiable information, such as:
Brand names
Product names
Locations (such as your HQ)
Internal, company-specific terms
You dont even have to figure out all the variations of numbers/letters/symbols either. Just type them into the banned password list and Azure AD will automatically block those variants or combinations.
Licensing...
Some of these features require Azure AD Premium P1 or P2 as shown in the below table:
| Identity Type | Password protection with global banned password list | Password protection with custom banned password list |
|---|---|---|
| Cloud-only identities | Azure AD Free | Azure AD Premium P1 or P2 |
| Identities synchronised from on-premises Active Directory | Azure AD Premium P1 or P2 | Azure AD Premium P1 or P2 |
Enabling Azure AD Password Protection for cloud identities.
If you create your user accounts in the Azure AD portal or Microsoft 365 Admin Centre then you have cloud identities. Cloud identities means that the accounts are not synchronised from an on-premises directory service such as Active Directory running on servers within your office or datacentre. Enabling password protection with your banned password list is really easy.
Login to Azure AD (portal.azure.com or aad.portal.azure.com) with Global Administrator credentials
Select Security>Authentication Methods>Password Protection
Set the lockout threshold, lockout duration and enable custom banned password list. Then, simply enter your words/phrases which should be banned and you're done!
Extending Azure AD Password Protection to on-premises identities.
I'm not going to go into the details on how Azure AD Password Protection works under the hood because the Microsoft Docs are really good on this subject. You can find them here.
However the crux of it is that there are two components that make Azure AD Password Protection work. These are:
Azure AD Password Protection Proxy Service
Azure AD Password Protection DC Agent
The Azure AD Password Protection Proxy service communicates with Azure AD to maintain an updated list of the banned password list. It can be installed on any member server as long as it meets the pre-requisites.
The Azure AD Password Protection DC Agent intercepts password change/set requests, compares the password against the custom + global banned password list and then denies the password if it is within the banned lists.
Azure AD Password Protection Proxy Pre-requisites
Windows Server 2012 R2 or higher.
.NET 4.7 must be installed.
Outbound TLS 1.2 traffic must be allowed
Network access to the ports and URLs defined here.
In my demo environment, we have the following:
2 x Domain Controllers (Windows Server 2019)
1 x Member Server (Windows Server 2019)
1 x Client PC (Windows 10 Pro, domain-joined)
Installing the Password Protection Proxy Service
Download both the Proxy Service and DC agent from this Microsoft Download Centre link. Run the AzureADPasswordProtectionProxySetup.exe executable to install the Password Protection Service. Once installed, we need to register it.
Open up Powershell as an admin and type in Register-AzureADPasswordProtectionProxy -AccountUpn global.admin@yourdomain.com
Now on this phase it may seem like it's stuck. PowerShell will seem to hang. Do not close it. It is working and a delay is expected behaviour. Next step is to register the AD forest. Run the following command next:
Register-AzureADPasswordProtectionForest -AccountUpn global.admin@yourdomain.com
Azure AD Password Protection DC Agent Pre-requisites
All machines where the Azure AD Password Protection DC agent software will be installed must run Windows Server 2012 or later.
All machines that run the Azure AD Password Protection DC agent must have .NET 4.5 installed.
Any Active Directory domain that runs the Azure AD Password Protection DC agent service must use Distributed File System Replication (DFSR) for sysvol replication.
NOTE: Although the DC agent will install on domain controllers which are still using FRS (File Replication System - the predecessor to DFSR) however it will not work properly. This can cause you a headache down the line with operations such as files failing to replicate and sysvol restore procedures appearing to work but silently failing to replicate all files. You should move to DFSR as soon as possible and I’d highly recommend considering it as a general pre-requisite before any Azure AD Password Protection deployment is initiated.
Installing the Azure AD Password Protection DC Agent
I haven’t added any screenshots to this part of the post because it’s literally a process of running the installer and going through the wizard. There’s no options that need configuring during or after installation however a reboot is required. The DC agent should be installed on all domain controllers in the domain.
The reason for the reboot requirement is because the password filter DLL is only loaded during system start up.
What about updating the agent/proxy software?
The Proxy service automatically updates. It does this via the Azure AD Connect Agent Updater service which is installed along with the installation of the proxy service.
The DC agent however, does not automatically update. You don’t need to uninstall the existing version however, just install the newer version on top. You can use the Get-AzureADPasswordProtectionDCAgent PowerShell command to query the installed agent version across all DCs in the forest.
Enabling on-premises password protection in the Azure portal
Now we’ve got communication with the Password Protection service (via the Proxy service) and the DC agent installed on all DCs we just need to enable it in the portal. Login to the Azure portal and navigate to:
Azure Active Directory > Security > Authentication Methods > Password Protection
Now you have to make a decision; audit vs enforced.
Audit
Audit mode is effectively where the software runs in “what-if” mode. Each time a password is changed, the password is still evaluated against the policy but no action is taken. Any passwords which do not match the policy are logged in the event log on the DC which served the password change request.
Enforced
Enforced mode is intended as the final config. When a password is changed, the password is evaluated against the policy and if it does not meet the policy it rejects the password change attempt. One key thing to note though is that the end-user will see a message similar to if their password were rejected by a traditional password complexity policy.
Logs you say?
I’m not going to do a huge write up on the logging because the Microsoft Docs on the subject are top notch however the key things to be aware of are:
DC Agent Logs
\Applications and Services Logs\Microsoft\AzureADPasswordProtection\DCAgent\Admin
\Applications and Services Logs\Microsoft\AzureADPasswordProtection\DCAgent\Operational
\Applications and Services Logs\Microsoft\AzureADPasswordProtection\DCAgent\Trace
Proxy Service Logs
\Applications and Services Logs\Microsoft\AzureADPasswordProtection\ProxyService\Admin
\Applications and Services Logs\Microsoft\AzureADPasswordProtection\ProxyService\Operational
\Applications and Services Logs\Microsoft\AzureADPasswordProtection\ProxyService\Trace
Summary
Hopefully this has helped shed some light on a feature which I feel provides a lot of value for a fairly small amount of effort. It’s something which is commonly missed or not configured during an M365 deployment.
As always, leave any comments below with your thoughts!