☁️Entra ID🏢Active DirectoryIdentityPasswordConfig

Entra ID Password Protection: Custom Lists and the Expiration Trap

Review Entra ID Password Protection, custom banned terms, AD DS Audit versus Enforced mode, and the cloud password expiration trap.

Younes AZABARBy Younes AZABAR9 min read
Entra ID Password Protection: Custom Lists and the Expiration Trap

What Is Entra ID Password Protection?

Entra ID Password Protection evaluates new passwords against Microsoft's global banned terms and, when configured, an organization's custom list. The operational review has three separate questions: are organization-specific terms covered, are on-premises changes actually blocked, and does password expiration still force routine changes?

Microsoft documents the cloud global list as automatic and impossible to disable. A missing custom list therefore does not mean the tenant has no password protection. It means the organization has not added its own vocabulary to the baseline. Validation happens during password changes and resets. Microsoft Learn: Password Protection concepts.

Treat this as a control review alongside the broader Microsoft Entra ID security audit, which explains how to verify enforceable access controls, privileged roles, application trust, and external identities. A password policy alone cannot answer those wider questions.

How It Works: Why the Global List Is Not Enough

Microsoft builds its global list from Entra security telemetry. The custom list adds local terms such as brands, products, headquarters locations, and internal abbreviations. The two lists work together; the custom list is not a replacement for the global baseline. Microsoft Learn: custom banned passwords.

Do not assume every password containing a listed term must fail. The evaluation algorithm normalizes input, checks variants, and scores the resulting password; a sufficiently strong password can contain a banned term and still pass. Read the documented evaluation algorithm before designing validation tests.

This distinction changes what a useful custom list looks like. Review the organization's vocabulary rather than importing a huge collection of complete passwords. Ask whether current brands, acquired company names, product families, and locally meaningful abbreviations are represented. Keep test cases tied to the configured terms so that a rejection can be investigated rather than merely assumed.

The password spraying article explains the attack: a small set of guesses spread across many accounts. This guide reviews the configuration that reduces predictable password choices before those guesses arrive. It does not treat a password-policy finding as evidence that a spray occurred.

The Expiration Trap

Microsoft's password policy recommendations discourage routine expiration for cloud-only accounts and recommend passwords that do not expire. The same guidance stresses password uniqueness, MFA registration, and identity protection. Removing scheduled expiration belongs with those controls; it is not a reason to ignore a suspected compromise.

The counterintuitive finding is expiration enabled, rather than expiration disabled. Review why an age-based change requirement exists, what identity population it applies to, and whether a binding requirement prevents removing it. Keep any such exception separate from the recommended cloud baseline. Do not label a documented business constraint as remediated merely because the default recommendation differs.

Defaults are not evidence of your tenant's state

The Entra password policy page documents no expiration as the current default maximum age, but a 90-day default for tenants created before 2021. It also describes the individual user's never-expire setting separately. Tenant age and a user flag are therefore insufficient substitutes for reading the effective policy.

The Microsoft 365 expiration procedure applies to cloud-only users. It explicitly excludes hybrid users using password hash synchronization, pass-through authentication, or on-premises federation. In a hybrid review, identify the password authority before choosing the change procedure.

Measure the Configuration Before Changing It

1. Record the Password Protection portal settings

Open Entra ID > Authentication methods > Password protection. Record Enforce custom list, the list entries, Enable password protection on Windows Server Active Directory, and the on-premises Mode. These are separate observations. An enabled Windows Server switch does not tell you whether the agents have received a policy or whether every intended controller is covered.

Microsoft's on-premises operations page says Audit accepts passwords that would fail while recording the outcome; Enforced rejects insecure passwords. Setting the Windows Server option to No stops validation in deployed DC agents. These settings concern AD DS, not a switch that disables the automatic cloud global list.

2. Read the cloud user expiration exception

With Microsoft Graph PowerShell installed and connected to the intended tenant as at least a User Administrator, as required by the cited procedure, use the following command, quoted unchanged from Microsoft's expiration check procedure:

Get-MgUser -All -Property UserPrincipalName, PasswordPolicies | Select-Object UserPrincipalName, @{N="PasswordNeverExpires";E={$_.PasswordPolicies -contains "DisablePasswordExpiration"}}

-All requests all users; -Property explicitly retrieves the properties used by the expression. Read the result in the correct direction: PasswordNeverExpires=True means the disabling flag is present. False means that flag was not found; it does not by itself establish a finite domain maximum age.

Pair this inventory with Microsoft 365 admin center > Settings > Org Settings > Security and Privacy > Password expiration policy for the applicable cloud population. Record domain scope and any individual exceptions. The procedure warns that new managed domains, or domains converted from federation, need the organization policy reapplied to update all domains. Microsoft Learn: expiration policy.

No tenant output is shown here: the command is a documented measurement, not a claim that a particular environment passed.

Detection: Verify On-Premises Enforcement

Use the DC agent Admin channel under Applications and Services Logs > Microsoft > AzureADPasswordProtection > DCAgent > Admin. Microsoft's monitoring reference distinguishes these outcomes:

ObservationPassword changePassword set/resetInterpretation
Custom policy rejection10016 and 3000210017 and 30003The submitted password was rejected against the customer policy.
Custom policy would reject in Audit10024 and 3000810025 and 30007The password was accepted because the policy was in Audit.
No policy available3000130001Acceptance without an available Azure password policy requires investigation.

Event 30019 is a policy-state notification, not an outcome emitted for every password change or reset. It reports that the received policy disabled processing: subsequent passwords are treated as compliant without validation, and no further events are logged until the policy changes.

Associated event pairs share a CorrelationId. Review the reason event alongside the outcome, and retain controller identity and timestamp. Do not count the pair as two independent rejected requests.

For a controller-specific summary, Microsoft gives this command on a Password Protection proxy server:

Get-AzureADPasswordProtectionSummaryReport -DomainController bplrootdc2

This is Microsoft's example controller name, not an environment observed here. Substitute the controller being reviewed. The report reads agent Admin logs through remote PowerShell; missing access or missing agents limits the evidence. Do not interpret an empty report as a successful enforcement test.

These events describe password validation, not sign-in attacks. Correlate an incident through sign-in telemetry separately; a custom-list rejection alone cannot identify the person attempting a password spray.

Remediation: Custom Terms, AD DS Enforcement, and Expiration

1. Enable and validate the custom list

Follow the custom-list tutorial with at least Authentication Policy Administrator and Entra ID P1 or P2 licensing. Set Enforce custom list to Yes, enter one term per line, and save. Terms must be 4–16 characters; the list supports up to 1,000 terms. Updates can take several hours.

Use a non-administrator test account and the documented SSPR prerequisites. Test a weak variation of a configured term after propagation. Record acceptance or rejection without retaining the password. If a test unexpectedly passes, inspect enforcement, propagation, and the evaluation algorithm before declaring the list ineffective.

2. Complete the on-premises deployment

Follow Microsoft's deployment guide: install and register the proxy service and forest, deploy DC agents, and account for the restart required to load the password filter. Writable controllers are the validation points; RODCs forward password operations and do not need a DC agent.

Audit is the documented initial mode. Use that period to test password-change workflows and domain controller promotion/demotion, then move to Enforced after resolving operational issues. Confirm the Windows Server option is Yes and save the change using the operations procedure. Repeat a controlled weak-password test and inspect its correlated rejection events.

The deployment guide also explains cached-policy operation when proxies are unavailable. Verify policy freshness as well as agent presence: a running service and a portal screenshot are different pieces of evidence.

3. Remove routine cloud expiration where applicable

For cloud-only users, review the recommended never-expire option in the Microsoft 365 expiration pane. For an individual user's exception, Microsoft documents this command in Set a password to never expire:

Update-MgUser -UserId <user ID> -PasswordPolicies DisablePasswordExpiration

The placeholder is copied from the documentation; replace it with the intended user ID. Review the existing password-policy values before a targeted update. Avoid turning the example into an unreviewed tenant-wide change, and rerun the read-only inventory afterward.

For hybrid identities, resolve the AD-side policy and synchronization model separately. The cloud procedure does not certify an on-premises maximum age change. Preserve compromise-triggered password changes and the MFA and identity-risk controls recommended by Microsoft.

How EtcSec Detects This

The etc-collector detector implementations reviewed for this article evaluate three configuration signals:

Catalogue identifierImplemented conditionInterpretation limit
PASSWORD_PROTECTION_DISABLEDCollected tenant configuration has a non-null PasswordProtectionEnabled value explicitly set to false.Missing settings alone do not trigger it. Reconcile the finding with the portal; it does not establish that Microsoft's automatic cloud global list was disabled.
CUSTOM_BANNED_PASSWORDS_DISABLEDTenant configuration exists and CustomBannedPasswordListConfigured is false.The collector fetch is best-effort: false can also reflect an unsuccessful settings read. Confirm collection success and the portal configuration; this flag alone does not verify the custom enforcement switch, policy propagation, or DC coverage.
PASSWORD_EXPIRATION_ENABLEDCollected DomainInfo.MaxPasswordAge is greater than zero and less than 365 days.This implementation evaluates an AD-domain age value, not a complete inventory of cloud user expiration policies.

Use these findings to start the corresponding manual checks. Absence of a finding does not replace the portal measurements, Graph inventory, and controlled AD DS validation described above. Close each remediation with evidence from the actual password-change path being protected.

Explore the identity security pages that support this topic