9.3 Microsoft Entra Password Protection
Key Takeaways
- Entra Password Protection applies a Microsoft-maintained global banned password list automatically to every Entra tenant
- Administrators add an org-specific custom banned password list for terms like company, sport, and team names
- The Password Protection DC agent extends banned-password enforcement and smart lockout to on-premises AD in hybrid scenarios
- Smart lockout distinguishes bad actors from genuine users and locks out the attacker while the real user can still sign in
- Password Protection is distinct from SSPR (self-service reset) and from Conditional Access (access control)
Quick Answer: Entra Password Protection hardens passwords using a Microsoft-maintained global banned password list applied to every tenant, an optional custom banned password list for your org's terms, and smart lockout that locks out attackers while letting real users sign in. In hybrid environments, a DC agent extends the same protections to on-premises AD.
Global Banned Password List
Microsoft maintains a global banned password list of weak, commonly-used passwords (think "Password1", "Summer2024", "qwerty"). The list is updated continuously based on Microsoft's threat intelligence and password telemetry, and it is applied automatically to every Entra tenant — no configuration needed. When a user tries to set or change a password, Entra checks it against the global list using fuzzy matching and character-substitution awareness (so "P@ssw0rd" is still caught).
Custom Banned Password List
Administrators add an org-specific custom banned password list for terms the global list cannot know: company name, product names, sport teams, local landmarks, internal acronyms. The custom list is configured in the Entra admin center under Protection → Authentication methods → Password protection. Both lists are evaluated together — a password is rejected if it matches either.
Configuration options on that blade:
- Enforce custom banned password list on-premises (for hybrid with DC agent)
- Password protection for Windows Server Active Directory (enable for the tenant)
- Mode: Audit (log only, do not block) or Enforced (block weak passwords). Audit mode is the rollout best practice — review the logs, then flip to Enforced.
The DC Agent for Hybrid Environments
For organizations with on-premises AD, the Password Protection DC agent extends the global and custom banned password lists and smart lockout to on-prem password changes. Deployment has two parts:
- Entra Password Protection Proxy service — installed on a domain-joined server (often the Connect server) that proxies banned-list downloads from Entra to the forest.
- DC agent — installed on every domain controller; it enforces the banned password list during on-prem password set/change operations and applies smart lockout to on-prem sign-ins.
The proxy fetches the updated banned password list from Entra periodically and the DC agents pull it from the proxy. Forest-level registration is performed once with Register-AzureADPasswordProtectionForest, a cmdlet from the AzureADPasswordProtection module that the proxy installer places on the proxy server. Despite the name, this is not the retired AzureAD directory module — it is the on-premises Password Protection tooling and it remains current.
Smart Lockout
Traditional AD lockout locks an account after N bad passwords regardless of source. An attacker spraying passwords from a botnet can lock out a genuine user, creating a denial-of-service. Smart lockout in Entra ID uses signals (device, location, IP, behavior) to distinguish the bad actor from the real user:
- The attacker is locked out — subsequent bad attempts from that source are rejected.
- The genuine user can still sign in with the correct password, even while the attacker is being locked out, because Entra tracks the lockout per-actor rather than per-account.
On-premises smart lockout is available through the DC agent and is configured in the same Password protection blade (lockout threshold, lockout duration).
Distinguishing the Three Password-Adjacent Features
A frequent MS-102 trap is conflating three distinct features:
| Feature | Purpose | Where Configured |
|---|---|---|
| Password Protection | Block weak passwords (banned lists) + smart lockout | Protection → Authentication methods → Password protection |
| SSPR | Users reset their own forgotten passwords | Protection → Password reset |
| Conditional Access | Control who can access what, under what conditions (MFA, compliant device, location) | Protection → Conditional Access |
Password Protection is about preventing bad passwords from being set. SSPR is about letting users recover from a forgotten password. Conditional Access is about governing access at sign-in time. They are complementary, not interchangeable.
Mode and Reporting
While in Audit mode, the DC agent evaluates every password against the active policy and logs the outcome without blocking it. The DC agent writes to Applications and Services Logs\Microsoft\AzureADPasswordProtection\DCAgent\Admin, where event ID 10024 records "password accepted due to policy in audit only mode" (its policy-validation counterpart is 30008). Summarise across all DCs with Get-AzureADPasswordProtectionSummaryReport rather than reading each log by hand. This lets you gauge user impact before enforcing. After a review period, switch to Enforced mode. The Entra admin center reports the count of passwords rejected and the banned terms that triggered rejections.
Licensing
The global banned password list and cloud smart lockout are included with every Entra tenant at no extra license — they protect cloud-only users out of the box. The custom banned password list, on-premises enforcement through the DC agent, and on-prem smart lockout require Microsoft Entra ID P1 or P2 (included in Microsoft 365 Business Premium and in most M365 E3/E5 identity and compliance SKUs). Plan licensing before deploying the DC agent forest-wide: the proxy and DC agent install without a license, but the custom list and enforced on-prem mode are gated behind P1/P2.
How the Evaluation Works
When a password is submitted, Entra normalizes it (lower-casing and collapsing repeated characters) and then tokenizes it against the banned lists using fuzzy matching that accounts for character substitution and keyboard adjacency — so P@ssw0rd!, pA55w0rd, and password all resolve to the same weak root. A password is rejected only when a matching banned token appears in the submitted password; unrelated strong passwords that merely contain a short banned substring are not rejected. This keeps false positives low while still catching the patterns attackers actually spray.
An administrator adds "Contoso" and "Blue Jays" to the custom banned password list and leaves the policy in Audit mode. What happens when a user sets their password to "Contoso2026!"?
Which Microsoft Entra feature is responsible for blocking an attacker spraying passwords while the genuine account owner can still sign in?