Overview
Password complexity rules — uppercase, lowercase, number, special character — are well-intentioned but largely ineffective in practice. A user told to pick a complex password reliably produces Winter2024! or Nakamas@1. These passwords satisfy every character class requirement and still appear near the top of every attacker’s dictionary. Length and complexity requirements do not prevent predictability; they shift the form that predictability takes.
Entra ID Password Protection addresses this by evaluating passwords against what is actually known about how humans pick bad passwords, rather than enforcing structural rules that do not correlate with real-world security.
The Global Banned Password List
Microsoft maintains a global banned password list derived from its threat intelligence team’s analysis of real-world credential breach data. When billions of compromised credentials are analysed, clear patterns emerge: the same passwords appear across millions of breached accounts. This list is updated continuously as new breach datasets are processed.
The global list is opaque by design — administrators cannot view or modify it. It is always active for every Entra ID tenant at no additional licensing cost.
Fuzzy Matching and Normalisation
The evaluation is not a simple string comparison. Before checking a candidate password against the list, it is normalised:
- Characters are converted to lowercase.
- Common substitutions are reversed:
@→a,3→e,0→o,1→i, and similar leetspeak patterns. - The password is tokenised — split into component words where common separators (digits, special characters) appear.
Each token is then evaluated independently. A password like P@ssw0rd2024 normalises to password which matches the global list — the padding and substitutions do not help the user. This is the critical distinction between fuzzy matching and complexity rules: fuzzy matching catches what humans actually do; complexity rules only prevent the literal string password.
The Custom Banned Password List
Administrators can add up to 1,000 organisation-specific terms to a custom banned password list. The same fuzzy matching and normalisation logic applies to custom entries.
The intent is to prevent passwords that are company-specific but universally guessable by anyone targeting that organisation:
- Company name and variants (
Contoso,Cont0so,ContOSO1) - Product names and brand terms
- Office locations, department abbreviations
- Project codenames
An attacker researching an organisation before an attack will build a wordlist from public sources — the company website, LinkedIn, press releases. Custom banned passwords ensure that this reconnaissance does not translate directly into valid credentials.
How the Evaluation Works
Every time a user changes or resets their Entra ID password, the candidate password passes through the evaluation pipeline:
- The password is normalised and tokenised.
- Each token is checked against the global banned list.
- Each token is checked against the custom banned list.
- If any token matches either list, the password is rejected regardless of how it is combined with other characters.
- If no tokens match, standard minimum-length requirements are applied.
The result is a system where Contoso2024! fails not because it lacks complexity but because contoso is on the custom list. The user receives a rejection message and must choose a password with no banned token in its composition.
Smart Lockout
Smart Lockout is a complementary control that operates at the authentication layer rather than the password selection layer. Where banned password lists prevent weak passwords from being set, Smart Lockout prevents attackers from testing passwords at scale.
Entra ID tracks failed authentication attempts per account using dual counters:
- Familiar location counter — Failed attempts from IP addresses in the user’s sign-in history.
- Unfamiliar location counter — Failed attempts from IP addresses not seen before for this account.
The lockout threshold defaults to 10 failed attempts. After the threshold is crossed, the account is locked for an increasing duration — the duration grows with each subsequent lockout cycle, making sustained brute-force attacks progressively less effective.
The dual-counter design matters because it prevents a legitimate user travelling from an unfamiliar location from being caught in a lockout caused by an ongoing attack from familiar infrastructure, and vice versa. Legitimate users from known locations may not hit the lockout threshold at the same point as an attacker probing from a cloud-hosted IP range.
On-Premises Password Protection
Without additional components, the cloud-side banned password lists and Smart Lockout only apply to Entra ID sign-ins. Users changing passwords directly in on-premises Active Directory — via Ctrl+Alt+Del, a domain-joined workstation, or a domain controller’s password reset interface — bypass cloud-side controls entirely.
Entra Password Protection for on-premises AD closes this gap through two components:
| Component | Role |
|---|---|
| DC Agent | Installed on each domain controller; intercepts password change operations and evaluates them locally |
| Proxy Service | Installed on one or more member servers; downloads the current banned password policy from Azure and distributes it to DC agents |
The DC agent receives the policy from the proxy service and evaluates every password change request locally against the same global and custom banned password lists that apply in the cloud. If the candidate password contains a banned token, the DC agent returns a failure to the Windows password change subsystem and the change is rejected — identically to how a cloud-side password change would be rejected.
The policy is downloaded from Azure periodically, so DC agents can continue enforcing the last-known policy even during temporary connectivity loss.
On-premises password protection requires Entra ID P1 licensing and Entra Connect is not required for this specific feature — the proxy service handles the Azure communication independently.
Why This Matters in Hybrid Environments
Hybrid environments where both Entra ID and on-premises AD coexist have two authentication paths. Without on-premises password protection, the same user might face strong password requirements in the cloud (where the banned list applies) but be able to set Summer2024 when changing their domain password directly. If those credentials are synchronised to the cloud via Password Hash Synchronization, the weak on-premises password propagates upward.
Deploying the DC agent and proxy service ensures that the banned password policy is consistent across both environments, preventing a situation where the weakest link is the domain controller handling the password change.
Summary
Entra Password Protection replaces structural complexity rules with intelligence drawn from actual breach data. The global banned list catches universally predictable passwords; the custom list catches organisation-specific predictable passwords. Fuzzy matching ensures that character substitutions and padding do not circumvent either list. Smart Lockout prevents brute-force enumeration. On-premises password protection extends the same policy to Active Directory domain controllers, closing the gap in hybrid environments where a weak domain password could otherwise propagate into the cloud. Together, these controls address password predictability at the point of creation rather than waiting for a breach to reveal it.