Entra Password Protection: banned lists, smart lockout and on-premises AD
Even on the road to passwordless, passwords remain in most environments for years. Entra Password Protection blocks the most predictable choices, both in the cloud and in on-premises Active Directory. That only works if it has been extended on-premises and switched to enforced mode.
Global list and custom list
Microsoft maintains a global banned password list, fed by what it observes in password spray attacks. It applies automatically to all cloud users and cannot be viewed or edited.
The custom list, which requires Entra ID P1, lets you add terms specific to your organisation: company name, products, city, the local football club. A few dozen well-chosen terms are enough; there is no need to add variants, the evaluation takes care of that.
How evaluation works
The proposed password is first normalised: converted to lower case, with common substitutions reversed ("0" for "o", "@" for "a", and so on). It is then compared with the lists using fuzzy matching. Finally, a scoring system decides whether it is accepted: each banned term found counts as one point, each remaining character also counts, and a minimum score is required. So "Company2026!" will be rejected if "company" is on the custom list.
Smart lockout
Smart lockout temporarily blocks authentication attempts after a number of failures, distinguishing sign-ins from familiar locations from those of an attacker. The threshold and duration can be customised with a P1 licence. In hybrid environments, make sure the Entra threshold is lower than the AD account lockout threshold, so the cloud blocks the attacker before on-premises accounts get locked out.
Extending protection to on-premises AD
The same policy can apply when passwords are changed or reset in Active Directory. Two components are required:
- the DC agent, installed on every domain controller, which validates passwords locally;
- the proxy service, installed on member servers, which retrieves the policy from Entra ID. Domain controllers do not need direct internet access.
Deployment starts in audit mode: non-compliant passwords are logged but not rejected. That mode should only be temporary.
Get-AzureADPasswordProtectionDCAgent Get-AzureADPasswordProtectionProxy Get-AzureADPasswordProtectionSummaryReport
Key limitation. Protection only applies when a password is set or changed. Weak passwords already in place remain valid until their next change, so they need to be identified through a dedicated audit.
What an audit checks
- Whether a custom list exists and is relevant.
- Whether on-premises protection is enabled, and in which mode (audit or enforced).
- That the agent is present on every domain controller, including recently promoted ones.
- Consistent lockout thresholds between Entra ID and AD.