Starting point: complexity alone accepts predictable passwords

The Active Directory setting “Password must meet complexity requirements” is useful, but its name promises more than it delivers. The built-in Windows rule checks a small number of structural conditions: it rejects certain occurrences of account or display-name tokens and requires characters from at least three of five categories. It does not estimate how predictable a password is, compare it with organization-specific terms or detect the familiar pattern of a capitalized word followed by a year and a symbol.

As a result, a short password can satisfy complexity while remaining easy to guess, and a long passphrase can fail because it does not contain enough character classes. Complexity is therefore a baseline syntax check, not a measure of password strength.

Typical AD environments add several operational weaknesses:

  • The Default Domain Password Policy still enforces eight or ten characters because a legacy application allegedly supports no more.
  • Complexity is enabled and treated as the complete password control.
  • A minimum above 14 characters has never been tested because older administration consoles, applications or support scripts are assumed to impose a hard limit.
  • Fine-grained password policies exist, but their subjects and precedence are not documented.
  • Service accounts, privileged users and ordinary users are covered by the same human-oriented policy.
  • The organization name, product names, locations and common internal abbreviations remain valid passwords.
  • Microsoft Entra Password Protection is enabled for cloud identities but has not been deployed to on-premises domain controllers.
  • Password changes through help desk resets, self-service writeback, VPNs or legacy applications have not been tested as separate paths.
  • Existing accounts are assumed to comply immediately after the policy changes, although AD evaluates the new rule only when a password is set or changed.
  • Password reports contain account names or speculative “weak password” labels without a controlled evidence model.

The correct response is not to add ever more mandatory symbols. The stronger design combines sufficient length, a targeted banned-password check, controlled account-specific policy and reduced dependence on reusable passwords.

Target state: length and rejection quality carry the policy

A sustainable target state has several layers:

  1. The effective domain policy is known. One authoritative GPO linked at the domain root controls the password policy for domain accounts; conflicting settings are removed.
  2. Length carries most of the password strength. Fourteen characters are a practical starting point for many environments. Higher values are selected by account type and enforced only after compatibility auditing across all domain controllers and password-setting paths.
  3. Built-in complexity is retained as a baseline, not presented as proof of strength. Any decision to disable the character-class rule in favor of passphrases is made only after equivalent length and banned-password controls are enforced and compliance requirements have been checked.
  4. The future length is audited before enforcement. The “Minimum password length audit” setting identifies password changes that would fall below the planned target without rejecting them.
  5. Microsoft Entra Password Protection checks new AD passwords. Its global banned-password intelligence and a maintained custom list feed normalized matches into a strength score; weak candidates are rejected without treating every occurrence inside a long password as an automatic denial.
  6. Fine-grained password policies have narrow, explicit purposes. Privileged or exceptional account classes can receive a stricter minimum through Password Settings Objects (PSOs); weaker policies do not become a permanent compatibility escape.
  7. Machine-managed identities do not depend on human composition rules. Suitable services use gMSA or another managed identity; remaining technical secrets are randomly generated and held in a vault.
  8. All password-setting paths are tested. Interactive changes, administrative resets, self-service password reset with writeback, federation, LDAP-based applications and remote-access systems produce the intended result.
  9. Existing passwords are remediated in controlled waves. The effective-date evidence distinguishes policy deployment from actual password renewal.
  10. Password use is reduced. Phishing-resistant MFA, Windows Hello for Business, privileged access workstations and separate admin identities limit the damage that one reusable password can cause.

Length is not unlimited security: users can still choose a repeated word, and a compromised endpoint can capture a valid credential regardless of length. The target therefore improves password quality while reducing the number of workflows in which users must type a password at all.

Implementation: build evidence before increasing the minimum

1) Inventory the effective policies without changing state

Run the inventory from an administratively protected management host with the ActiveDirectory module. The first block reads the default domain policy, all PSOs and the domain-controller estate. It does not request or test any password:

& {
  Set-StrictMode -Version Latest
  Import-Module ActiveDirectory -ErrorAction Stop

  $domain = Get-ADDomain -ErrorAction Stop
  $defaultPolicy = Get-ADDefaultDomainPasswordPolicy `
    -Identity $domain.DNSRoot `
    -ErrorAction Stop

  [pscustomobject]@{
    Scope                        = $domain.DNSRoot
    PolicyType                   = 'DefaultDomainPasswordPolicy'
    ComplexityEnabled           = $defaultPolicy.ComplexityEnabled
    MinPasswordLength           = $defaultPolicy.MinPasswordLength
    PasswordHistoryCount        = $defaultPolicy.PasswordHistoryCount
    MinPasswordAge              = $defaultPolicy.MinPasswordAge
    MaxPasswordAge              = $defaultPolicy.MaxPasswordAge
    LockoutThreshold            = $defaultPolicy.LockoutThreshold
    LockoutObservationWindow    = $defaultPolicy.LockoutObservationWindow
    LockoutDuration             = $defaultPolicy.LockoutDuration
    ReversibleEncryptionEnabled = $defaultPolicy.ReversibleEncryptionEnabled
  }

  $policies = @(Get-ADFineGrainedPasswordPolicy -Filter * -ErrorAction Stop)
  foreach ($policy in $policies) {
    $subjects = @(
      Get-ADFineGrainedPasswordPolicySubject `
        -Identity $policy `
        -ErrorAction Stop
    )

    [pscustomobject]@{
      PolicyType                   = 'FineGrainedPasswordPolicy'
      Name                         = $policy.Name
      Precedence                   = $policy.Precedence
      ComplexityEnabled            = $policy.ComplexityEnabled
      MinPasswordLength            = $policy.MinPasswordLength
      PasswordHistoryCount         = $policy.PasswordHistoryCount
      MinPasswordAge               = $policy.MinPasswordAge
      MaxPasswordAge               = $policy.MaxPasswordAge
      LockoutThreshold             = $policy.LockoutThreshold
      LockoutObservationWindow     = $policy.LockoutObservationWindow
      LockoutDuration              = $policy.LockoutDuration
      ReversibleEncryptionEnabled  = $policy.ReversibleEncryptionEnabled
      Subjects                     = (($subjects | ForEach-Object { $_.DistinguishedName }) -join '; ')
    }
  }

  Get-ADDomainController -Filter * -ErrorAction Stop |
    Select-Object HostName, Site, OperatingSystem, OperatingSystemVersion,
      IsReadOnly, IsGlobalCatalog
}

The effective directory values do not identify the GPO that will set them again during the next policy refresh. Review links and precedence at the domain root in Group Policy Management and retain an XML report of the authoritative GPO in the change record. A password policy linked only to a user or workstation OU does not set the domain-account password policy.

For representative accounts, determine the resultant PSO instead of inferring it from group names:

$sampleUsers = @(
  'pilot.standard'
  'pilot.privileged'
  'pilot.service'
)

foreach ($samAccountName in $sampleUsers) {
  $user = Get-ADUser -Identity $samAccountName -ErrorAction Stop
  $resultant = Get-ADUserResultantPasswordPolicy `
    -Identity $user `
    -ErrorAction Stop

  [pscustomobject]@{
    SamAccountName     = $user.SamAccountName
    ResultantPolicy    = if ($resultant) { $resultant.Name } else { 'Default domain policy' }
    MinPasswordLength  = if ($resultant) { $resultant.MinPasswordLength } else { $null }
    ComplexityEnabled = if ($resultant) { $resultant.ComplexityEnabled } else { $null }
  }
}

A missing resultant PSO means that the default domain policy applies. Direct PSO assignment to a user takes priority over group assignment; among assignments at the same level, the lowest numerical precedence wins. Group membership changes can therefore change a user's effective policy without modifying the PSO itself.

Do not attempt to verify compliance by collecting plaintext passwords or exporting hashes into an ordinary audit workflow. PasswordLastSet can prove when a password was replaced, but it cannot prove its length or predictability. Policy state, controlled canary tests and password-change telemetry provide the defensible evidence.

2) Separate human, privileged and machine-managed identities

Before choosing a number, classify the accounts and authentication paths:

  • Ordinary workforce users need a memorable long password or passphrase, a password manager for application credentials and phishing-resistant MFA where available.
  • Privileged personal accounts need separate identities, a stricter policy where justified, MFA and restricted logon paths. A longer password does not make daily admin use on an ordinary client acceptable.
  • Emergency accounts follow a dedicated, monitored procedure with long random credentials held under split or otherwise strongly controlled access.
  • Service accounts move to gMSA, virtual accounts or workload identities where possible. Remaining secrets are generated randomly and rotated with the workload owner.
  • Application test accounts are non-privileged, time-limited and never reused as production exceptions.

This classification prevents an old appliance from dictating a weak domain-wide minimum. If one system cannot accept the target length, establish the exact input limit, owner, authentication path and retirement date. Isolate the exception to a dedicated non-privileged account only when migration cannot be completed first.

Password age and history remain separate design decisions. Password history helps prevent immediate reuse, and a non-zero minimum age can deter rapid cycling through history. Arbitrary frequent expiration can increase predictable choices and support load, so it should not be used to compensate for a short minimum. Forced changes remain appropriate after suspected compromise, exposure, weak-policy remediation or a defined risk event.

Reducing MaxPasswordAge can expire accounts immediately when pwdLastSet plus the new maximum already lies in the past. Model the affected population and plan communication, exceptions and reset capacity before changing that value.

3) Audit the domain-wide GPO baseline above 14 before enforcing it

The historical 14-character ceiling came from older policy tooling and compatibility assumptions, not from a desirable AD security target. The length audit is available on appropriately patched Windows Server 2016 and 2019 domain controllers; Microsoft's documented enforcement for a 15-or-more-character default-domain GPO minimum starts with Windows Server, version 2004, and later server generations when “Relax minimum password length limits” is enabled. The rollout still requires a compatibility project, particularly in forests with old domain controllers or long-lived third-party integrations.

First patch every domain controller and the systems used to administer Group Policy. Record operating-system builds, update status and pending reboots. An operating-system name from the AD inventory is not proof that the required security updates and policy behavior are present.

Then set “Minimum password length audit” to the planned future value, for example 15 or 16, while leaving the enforced minimum unchanged. Collect Directory-Services-SAM events 16977, 16978 and 16979 centrally. Event 16978 identifies a set or change below the audit value; 16979 identifies a configuration in which only 14 is effectively enforced. Audit does not reject the candidate and says nothing about passwords that remain unchanged.

Exercise every supported path deliberately with dedicated test identities:

  • sign-in screen and Ctrl+Alt+Delete password changes,
  • help-desk and identity-administration resets,
  • Microsoft Entra self-service password reset with writeback,
  • VPN, Wi-Fi, NPS/RADIUS and federation workflows,
  • LDAP applications and identity-management connectors,
  • Unix, NAS, ERP and other non-Windows integrations,
  • remote desktop and published application portals,
  • scheduled tasks, Windows services and application pools where human-managed service accounts remain,
  • password-manager generation and paste behavior,
  • Unicode, spaces and the longest planned passphrase, where these forms are part of the approved standard.

Test rejection as well as success: too-short input, an organization-specific banned term and a valid long candidate must all produce understandable behavior. Never put the test passwords in a ticket, script, screenshot or event export.

Legacy applications may truncate a value silently, apply a shorter UI limit, normalize characters differently or validate only in one workflow. A successful web-form reset does not prove that the subsequent bind, service start or mobile sign-in uses the same value. Complete an end-to-end authentication test and a rollback for each dependency.

Microsoft recommends observing the length audit for three to six months so that infrequent maintenance and rotation paths are represented. Enable the relaxed-length setting and raise the domain-wide minimum only when every domain controller, including read-only domain controllers, supports enforcement and event 16979 is absent.

FGPP stores its minimum in a separate Password Settings Object and can define values above 14 for a selected cohort. This avoids changing the default-domain GPO for every account, but it does not remove the same application, reset and provisioning compatibility tests.

4) Change the authoritative domain policy as one controlled unit

After compatibility evidence is complete, enable support for a longer minimum and set the approved value in the authoritative root-linked password-policy GPO. Keep complexity enabled if it remains part of the approved baseline, set reversible encryption to disabled and preserve the separately approved age, history and lockout settings. Avoid mixing unrelated lockout or Kerberos changes into the same deployment.

The following command safely previews the intended directory target and values:

$domain = Get-ADDomain -ErrorAction Stop

Set-ADDefaultDomainPasswordPolicy `
  -Identity $domain.DNSRoot `
  -ComplexityEnabled $true `
  -MinPasswordLength 14 `
  -PasswordHistoryCount 24 `
  -MinPasswordAge ([timespan]::FromDays(1)) `
  -ReversibleEncryptionEnabled $false `
  -WhatIf

-WhatIf makes no change. It also does not validate application compatibility, enable the relaxed-length prerequisite or author the GPO. Set-ADDefaultDomainPasswordPolicy writes the effective directory policy directly and a later Group Policy refresh can overwrite it. Use the command as a target and scope check; make the durable change through the controlled GPO process unless a documented emergency runbook explicitly requires a direct change.

Deploy through rings where the policy source allows it to be tested safely, but remember that the domain password policy is not a normal per-OU client setting. Once effective, any domain controller processing a password operation can enforce it. A separate test domain or forest gives cleaner pre-production evidence than attempting to make one production user OU receive a different default policy.

After the change, verify the effective value against multiple domain controllers, wait for AD and SYSVOL replication convergence, and repeat all canary flows. Existing passwords are not re-evaluated automatically. Plan renewal waves based on risk and support capacity instead of expiring every account simultaneously.

5) Use fine-grained policies for stricter cohorts, not hidden exceptions

Fine-grained password policies can apply different password and lockout settings to users and global security groups. They do not attach directly to organizational units. A PSO is appropriate when a defined account class needs a stricter minimum or a distinct, approved age model; it is not a substitute for a coherent domain baseline. For the current Microsoft administration workflow, plan for at least Windows Server 2012 domain functional level and current RSAT tools.

Before changing a PSO, preview the action:

Set-ADFineGrainedPasswordPolicy `
  -Identity 'Privileged-Human-Accounts' `
  -ComplexityEnabled $true `
  -MinPasswordLength 16 `
  -PasswordHistoryCount 24 `
  -ReversibleEncryptionEnabled $false `
  -WhatIf

Add-ADFineGrainedPasswordPolicySubject `
  -Identity 'Privileged-Human-Accounts' `
  -Subjects 'GG-Password-Privileged-Humans' `
  -WhatIf

Replace the sample names with approved objects from the change record. After review, run the change without -WhatIf, recalculate the resultant policy for every subject and test one non-privileged canary account that temporarily follows the same group path. Password age and lockout remain unchanged in this example; simulate and approve any change to them separately.

Each PSO needs an owner, rationale, subject group, precedence, review date and removal condition. Keep the number small. A lower numerical precedence unexpectedly winning through nested group membership is a common source of both outages and weak exceptions.

Entra Password Protection is not configured per PSO. Its on-premises policy provides a common banned-password decision for the registered environment. Cohort-specific differences therefore belong in AD length and lifecycle controls, not in imagined separate banned lists.

6) Deploy Entra Password Protection with complete domain-controller coverage

The built-in complexity rule cannot maintain a global dictionary of predictable passwords or understand organization-specific language. Microsoft Entra Password Protection adds two useful layers when deployed for Windows Server Active Directory:

  • a Microsoft-maintained global banned-password capability, and
  • a tenant-managed custom list for organization names, brands, products, locations and internal abbreviations that are likely to appear in user choices.

The evaluation is not merely an exact string comparison. Normalization and scoring make common character substitutions and closely related variants less useful as bypasses. A matching term contributes to the score; it is not automatically denied in every sufficiently long surrounding value. The custom list should therefore contain high-value organization-specific terms, not an attempted copy of every leaked password. Give the list an accountable owner and review it after company, product and location changes. Do not add employee personal data or rejected plaintext passwords to it.

For on-premises protection, the proxy service is mandatory; for resilience, Microsoft recommends at least two current signed proxies on separate hardened, domain-joined member servers. Permit only the required outbound connectivity to Microsoft Entra and do not make the proxy internet-facing. Confirm Microsoft Entra ID P1 or P2 licensing for protected users before committing the control. Register the proxy services and forest through the controlled Entra administration process, then deploy the DC agent to every writable domain controller in each protected domain. Password set and change operations received by an RODC are forwarded to a writable DC, so the DC agent is neither required nor installed on RODCs. Include new, rebuilt and disaster-recovery writable domain controllers in the build standard.

The DC agent introduces a password filter into a security-sensitive process and requires a planned restart. Treat package source, signature validation, version control, proxy firewall rules and rollback as production infrastructure changes.

The on-premises policy covers all users in a protected domain. It cannot be limited to a pilot user group or selected PSO subjects; pilot scope comes from DC deployment and Audit mode, not user targeting.

Partial writable-DC coverage is not an acceptable steady state. Password operations can be handled or forwarded through different writable domain controllers, so an uncovered path creates inconsistent enforcement. Confirm the supported platform, runtime and DFSR-based SYSVOL prerequisites before installation. Domain controllers do not need direct internet access, and the cleartext password candidate never leaves the DC. A DC agent uses its last successfully downloaded policy; if it has never received a valid policy, it accepts the candidate and logs the condition. Current PasswordPolicyDateUTC on every writable DC is therefore an enforcement gate. Inventory agent and proxy versions through the endpoint-management platform, and use the local event channels as a second source. This read-only command shows the available logs without assuming a particular package version:

Get-WinEvent -ListLog '*PasswordProtection*' -ErrorAction SilentlyContinue |
  Select-Object LogName, IsEnabled, RecordCount, LastWriteTime

The agents use locally available policy data to keep validation functional during temporary cloud or proxy disruption. That resilience does not remove the need to alert on failed policy downloads, stale policy, proxy unavailability or an unregistered DC. On a proxy with the installed module, the following read-only checks in 64-bit PowerShell show proxy, DC-agent and validation-summary state:

Import-Module AzureADPasswordProtection -ErrorAction Stop

Get-AzureADPasswordProtectionProxy -Forest
Get-AzureADPasswordProtectionDCAgent -Forest |
  Select-Object ServerFQDN, Domain, PasswordPolicyDateUTC, HeartbeatUTC
Get-AzureADPasswordProtectionSummaryReport -Forest

The summary report remotely queries DC-agent logs and can create load in a large environment. HeartbeatUTC and PasswordPolicyDateUTC update roughly hourly and also reflect AD replication latency; stale values are an agent- or policy-health signal. Use centrally forwarded events for continuous monitoring. Correlate audit-only failures 10024/10025, events 10016/10017, technical errors 10012/10013, and associated 300xx details by CorrelationId and active mode. 10016/10017 alone do not prove an enforced rejection. Test the failure mode rather than assuming that an installed service equals current protection.

7) Move Entra Password Protection from audit to enforcement

Start the on-premises deployment in Audit mode. In this state, a password that the Entra policy would reject is recorded but remains accepted if the underlying AD policy permits it. Audit mode provides three things before user impact:

  1. evidence that every writable domain controller and password-change path reaches the agent,
  2. an estimate of affected resets and likely help-desk volume, and
  3. a chance to correct an overbroad custom term list.

Collect DC-agent and proxy events centrally with the domain controller, account identifier, policy result, agent version and timestamp. Do not collect the submitted password. Restrict access because account names and password-change patterns are still security-relevant information.

Run audit for a representative business and support cycle, but do not wait passively for every user to change a password. Execute the canary matrix on each site and password-setting path. Resolve missing logs, outdated agents, proxy errors and help-desk tooling before enforcement.

Move to Enforced only when:

  • all intended writable DCs report the current agent and policy,
  • at least two healthy proxies are registered and monitored,
  • every supported reset path returns a usable rejection message,
  • the custom list has an owner and reviewed terms,
  • service desk guidance explains length and banned terms without revealing the list as a guessing aid,
  • emergency accounts and application dependencies have passed controlled tests,
  • rollback and break-glass procedures have been exercised.

Enforcement affects new password set and change operations. It does not scan or invalidate existing passwords. Use risk-based renewal waves after the complete policy stack is active, with earlier handling for privileged accounts and known weak-policy cohorts.

8) Align reset, recovery and service-desk processes

A technically strong policy can still create unsafe operational workarounds. Help-desk staff must not choose a permanent password for the user, reuse a common temporary value or ask the user to disclose a rejected candidate. Use an identity-verified reset process, a unique temporary credential where required, and a forced user-controlled change through a protected channel.

Rejection messages should state the rule category without exposing the custom banned list. “Choose a longer password that does not contain common or organization-specific terms” is useful; displaying the exact matched term can disclose unnecessary policy detail. Support scripts and ticket templates must never log password parameters.

Self-service password reset and password writeback need the same end-to-end tests as an administrator reset. A cloud policy success followed by an on-premises rejection must be presented clearly to the user and recorded for operations. Conversely, cloud-only password protection does not prove that a password changed directly in AD passed the Entra banned-password control; the on-premises agents provide that decision.

Password managers should be permitted and supported for non-AD application credentials and emergency workflows. Users should not be encouraged to create one “complex” pattern and vary the final characters across systems. For AD user passwords, long memorable values, banned-term enforcement and reduced typing through Windows Hello for Business provide a more sustainable model.

9) Prove the result and monitor drift

Retain an evidence package for each domain and forest:

  • authoritative GPO report and link precedence,
  • effective default policy before and after the change,
  • every PSO, its subjects, precedence and resultant-policy samples,
  • domain-controller operating-system, patch, agent and reboot status,
  • proxy inventory, registration and health,
  • audit findings and the decision to enforce,
  • canary results for every password-setting and authentication path,
  • exception owners, scope and expiry,
  • the policy effective timestamp and subsequent account-renewal status.

Monitor changes to the domain password policy, PSOs, PSO subject groups, Entra Password Protection mode and custom list, proxy registration and DC-agent health. A newly promoted domain controller without the agent is a control failure even when every existing DC is healthy.

For account remediation, record only whether PasswordLastSet is later than the approved enforcement cutoff. Do not claim that this timestamp proves strength by itself; it becomes meaningful only when all DCs enforced the intended AD and Entra controls at that time.

Benefits: stronger choices with measurable enforcement

  • Short compliant patterns are reduced. A minimum above 14 removes a large class of historically accepted choices that satisfied only the character-class rule.
  • Predictable terms are penalized. Global and organization-specific banned-password controls make weak normalized variants fail a strength score that complexity cannot provide.
  • The policy can be evidenced. Effective AD values, resultant PSOs, audit events, agent coverage and renewal timestamps form a testable control chain.
  • Exceptions become visible. Compatibility problems are attached to a named application, account, owner and expiry rather than lowering the whole domain.
  • Privileged cohorts can be stricter. FGPP supports a higher minimum without creating a second domain.
  • User guidance becomes simpler. “Use a long, unique value without common or company terms” is more useful than teaching a sequence of mandatory substitutions.
  • Hybrid reset paths converge. Entra Password Protection can apply the same banned-password decision to on-premises changes when the agent architecture is complete.
  • Managed identities receive proper treatment. Service accounts can move away from human password composition and manual rotation.

Drawbacks and limits: compatibility and operations decide the pace

  • Longer minimums can expose legacy limits. Applications may reject, truncate or normalize long input differently, causing authentication failures only after the change.
  • Domain-controller work is required. Entra Password Protection needs proxy infrastructure, DC agents, restarts, monitoring and lifecycle ownership.
  • Licensing and cloud dependency must be planned. On-premises Entra Password Protection requires the appropriate tenant capability and outbound service connectivity, even though locally cached policy supports temporary disruption.
  • Existing passwords remain valid. Neither a higher minimum nor banned-password enforcement retroactively assesses the current credential set.
  • Built-in complexity can reduce passphrase usability. A long value can still fail the three-category rule, encouraging predictable capital-letter and symbol placement.
  • Banned lists are never exhaustive. They reduce known predictable choices but do not measure uniqueness across unrelated services or guarantee high entropy.
  • One custom list cannot express every cohort. Entra banned-password policy is broad; PSOs provide account-specific length and age settings, not separate organization dictionaries.
  • User support initially increases. Audit data, clear rejection behavior and service-desk preparation are needed before enforcement.
  • Passwords remain phishable and replayable in applicable protocols. MFA, passwordless authentication, endpoint security and restricted admin paths remain necessary.
  • Policy evidence is indirect. AD does not disclose the current password's quality. Completion must be derived from enforced controls plus a subsequent legitimate password change.

Common pitfalls

  • Treating “complexity enabled” as equivalent to a strong password policy.
  • Raising the number of required character classes while leaving the minimum length short.
  • Enforcing more than 14 characters before patching DCs and testing every reset and authentication path.
  • Assuming the old 14-character administration limit is still an AD security maximum.
  • Setting the default domain value directly and forgetting that the authoritative GPO will overwrite it.
  • Linking a password GPO to a user OU and expecting it to control domain-account passwords.
  • Inferring PSO scope from an OU or group name instead of checking resultant policy.
  • Allowing a low-precedence-number PSO to win unexpectedly through nested group membership.
  • Creating a weaker PSO for every incompatible application and never retiring it.
  • Deploying Entra Password Protection to only some writable DCs and accepting inconsistent behavior.
  • Moving to Enforced mode before proxy, agent and rejection-message telemetry is complete.
  • Copying a public breach dictionary into the custom list instead of maintaining organization-specific terms.
  • Adding employee names or rejected plaintext values to the custom list or audit record.
  • Assuming cloud password protection automatically covers passwords changed directly in AD.
  • Assuming a new policy scans or invalidates existing passwords.
  • Expiring all users simultaneously and overwhelming service desk and dependent applications.
  • Applying human complexity rules to service accounts instead of using gMSA or generated vault-held secrets.
  • Revealing the exact banned term in help-desk tickets or user-facing error text.
  • Ignoring a newly promoted or recovered DC that lacks the password-protection agent.
  • Using password length as a substitute for MFA, tiered administration and endpoint hardening.

Project checklist

  • [ ] Export the effective default domain password policy for every domain.
  • [ ] Identify the authoritative root-linked password-policy GPO and remove conflicting ownership.
  • [ ] Export every PSO with precedence, subjects and current settings.
  • [ ] Calculate resultant policy for representative standard, privileged and service accounts.
  • [ ] Classify human, privileged, emergency, service and application test identities.
  • [ ] Move suitable services to gMSA or another managed identity.
  • [ ] Document every application that sets, resets, stores or validates an AD password.
  • [ ] Patch all domain controllers and Group Policy administration systems.
  • [ ] Verify support for relaxed minimum-password-length limits across the DC estate.
  • [ ] Set the minimum-password-length audit threshold to the proposed value above 14.
  • [ ] Collect and protect audit events from every domain controller.
  • [ ] Test interactive, help-desk, SSPR writeback, VPN, LDAP and third-party paths.
  • [ ] Test the longest approved value, Unicode and spaces where supported by the standard.
  • [ ] Check for silent truncation, UI limits and inconsistent normalization.
  • [ ] Assign each incompatible application an owner, isolation plan and retirement date.
  • [ ] Approve the domain minimum, complexity, history and age settings separately.
  • [ ] Preview directory changes with -WhatIf and implement the durable setting through GPO.
  • [ ] Verify AD and SYSVOL replication before accepting the effective timestamp.
  • [ ] Keep PSOs narrow, documented and stricter than the domain baseline where possible.
  • [ ] Recalculate resultant PSOs after every subject or precedence change.
  • [ ] Confirm Microsoft Entra licensing and required outbound connectivity.
  • [ ] Deploy at least two hardened Password Protection proxy servers.
  • [ ] Register the forest and include registration health in monitoring.
  • [ ] Deploy the current DC agent to every writable domain controller in protected domains and plan restarts.
  • [ ] Add the agent to DC promotion, rebuild and disaster-recovery standards.
  • [ ] Build and approve a concise organization-specific custom banned-password list.
  • [ ] Run Entra Password Protection in Audit mode through a representative support cycle.
  • [ ] Resolve every uncovered DC, stale policy, proxy error and missing reset path.
  • [ ] Train service desk without exposing rejected passwords or exact banned terms.
  • [ ] Exercise rollback and emergency-account procedures.
  • [ ] Move to Enforced mode only after complete coverage and canary success.
  • [ ] Renew privileged and known weak-policy accounts first in controlled waves.
  • [ ] Record account renewal only after the full policy stack is effective.
  • [ ] Monitor GPO, PSO, subject-group, Entra policy, proxy and DC-agent changes.
  • [ ] Review exceptions, custom terms, application dependencies and PSOs on a fixed schedule.
  • [ ] Continue phishing-resistant MFA, Windows Hello for Business and privileged-path improvements.