Starting point: “Disabled” does not mean remediated

Active Directory does not normally store domain passwords in plaintext. It retains one-way values or derived keys for NTLM and Kerberos. The “Store passwords using reversible encryption” setting breaks this model: after the next password change, AD can retain an additional representation from which the original password can be recovered. The word “encryption” sounds stronger than the resulting protection. For risk purposes, this material is a plaintext equivalent.

In mature domains, the feature is rarely an intentional strategic standard. More often, it originated with a legacy dial-in, RADIUS, VPN or web application that required classic CHAP or another path to the original password. Years later, the application has been retired and the policy value has been disabled again, while individual user options, fine-grained password policies or previously stored reversible password material remain.

This is where false assurance appears:

  • The Default Domain Password Policy is Disabled, but an effective Password Settings Object (PSO) remains Enabled.
  • A user option independently sets ADS_UF_ENCRYPTED_TEXT_PASSWORD_ALLOWED, or bit 0x80, in userAccountControl.
  • A PSO set to Disabled is treated as an exception even though it cannot override domain-wide enablement.
  • The setting was disabled, but the affected account's password was never changed afterwards.
  • An account was only marked “User must change password at next logon”; the old state remains until that logon occurs.
  • Service accounts with Password never expires were omitted from remediation.
  • System-state backups still contain the earlier directory state.

For a user account, reversible storage is effectively enabled through an OR relationship:

Default Domain Password Policy enabled
OR effective fine-grained password policy enabled
OR per-user flag 0x80 set
= reversible storage enabled at the next password change

All three paths must be closed before a new password is set. Only that sequence prevents the rotation from creating the problematic value again.

This control must not be confused with optional Windows LAPS password encryption in AD. LAPS protects a deliberately stored, random local administrator password through a separate access model. The setting discussed here affects domain passwords for user and service accounts.

Target state: three settings off, then every affected password replaced

A sustainable target combines policy, migration and evidence:

  1. The Default Domain Password Policy is disabled. The effective value is checked for each domain and managed through the defined policy process.
  2. No effective PSO enables reversible storage. The review evaluates each affected user's resultant PSO, not only AppliesTo.
  3. No user account carries the per-user flag. Exceptions are not accepted permanently; a legacy requirement is tracked as a migration problem.
  4. Classic CHAP and verified plaintext-dependent legacy paths have been removed or demonstrably replaced. A protocol name alone is not justification. In particular, neither PEAP-MS-CHAPv2 nor modern IIS Advanced Digest should automatically be treated as dependent on reversible password storage.
  5. Every potentially affected password was changed only after complete disablement. PasswordLastSet is later than a documented hardening cutoff.
  6. Technical accounts have their own rotation plan. Secrets are updated with workload owners; suitable services move to gMSA or an equivalent managed identity path.
  7. Old backups remain specially protected until retention expires. The current AD state does not clean historical backups.
  8. Changes are monitored. Domain policy, PSOs and the relevant user flag must not be silently re-enabled.

The target is not merely a green policy report. It is a defensible chain of disabled activation paths, migrated dependencies and passwords renewed afterwards.

Implementation: from inventory to defensible remediation

1) Inventory domain policy, PSOs and the user flag separately

Run the inventory from an administratively protected management host with the ActiveDirectory module. It reads no passwords and does not access internal credential attributes. The following queries return the three relevant configuration layers as objects:

& {
  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'
    ReversibleEncryptionEnabled  = $defaultPolicy.ReversibleEncryptionEnabled
  }

  Get-ADFineGrainedPasswordPolicy -Filter * -ErrorAction Stop |
    Select-Object Name, Precedence, ReversibleEncryptionEnabled, AppliesTo

  Get-ADUser `
    -LDAPFilter '(&(objectCategory=person)(objectClass=user)(userAccountControl:1.2.840.113556.1.4.803:=128))' `
    -Properties Enabled, PasswordLastSet, PasswordNeverExpires, userAccountControl `
    -ErrorAction Stop |
    Select-Object SamAccountName, Enabled, PasswordLastSet, PasswordNeverExpires,
      @{Name='PerUserReversibleEncryption';Expression={($_.userAccountControl -band 0x80) -ne 0}}
}

The output contains security-relevant account names and therefore does not belong in an open ticket or unprotected share. It also shows only the current configuration. It cannot reliably establish whether an account received a reversible representation in the past.

Where several PSOs apply directly or through groups, only the resultant PSO counts. Direct assignments to the user take precedence over group-based assignments; at the same assignment level, the lowest Precedence wins. Check the effective value for representative and potentially affected accounts:

Get-ADUserResultantPasswordPolicy -Identity 'pilot.user' -ErrorAction Stop |
  Select-Object Name, Precedence, ReversibleEncryptionEnabled

If the command returns no PSO, the Default Domain Password Policy applies to that account. In large domains, evaluate this in controlled batches rather than issuing unlimited parallel requests against a domain controller.

2) Determine the historical scope conservatively

A current Disabled value does not prove when the setting was disabled. Combine several records to determine the rotation scope:

  • GPO backups, change tickets and Policy Analyzer exports,
  • modification timestamps and versions of Password Settings Objects,
  • changes to user flag 0x80 for as long as audit history is available,
  • PasswordLastSet, account age and known service migrations,
  • system and application owners of former legacy authentication paths.

If the enablement period is unknown, the safe assumption is broader than the visible findings. Every account whose password may have changed under an enabling domain policy, an enabling PSO or a set per-user flag 0x80 during the possible period belongs in the rotation plan. An LDAP query for today's user flag is not sufficient.

Disabled accounts are not ignored automatically. Accounts that must be retained receive a new random password after policy remediation. Accounts no longer required are removed or made permanently unusable through the established retirement process. Built-in identities, trust accounts and krbtgt do not belong in generic bulk rotation; they require their respective runbooks.

3) Replace classic CHAP and verified legacy dependencies first

Before any change, establish which workload genuinely requires the original password. Typical review points include:

  • NPS, RAS, VPN and wireless policies using classic CHAP,
  • IIS sites and applications using Digest Authentication, with version and actual credential use assessed separately,
  • older appliances, middleware or business applications with proprietary password verification,
  • technical accounts that carry the per-user flag only because of a historical vendor requirement.

A product name or old architecture diagram is not sufficient evidence. What matters is the effective authentication method, a reproducible test and an accountable owner. IIS also requires a specific distinction: older Digest implementations could require a recoverable password, whereas modern Advanced Digest uses precomputed digest credentials. Digest remains a separate legacy path to modernize, but its presence alone does not prove reversible password storage. Depending on the application, target paths can include certificate-based EAP, Kerberos/Negotiate, a modern authentication proxy or an updated product version.

If a dependency cannot be replaced immediately, confine the exception to one dedicated, non-privileged account. Give it only the required logon rights and network paths, a long unique password, monitoring, a named owner and an expiry date. One legacy application is not a reason to enable the domain-wide setting again.

4) Close the activation paths in the right order

Manage the default-domain setting authoritatively through the controlled domain-level Group Policy process:

Computer Configuration > Policies > Windows Settings > Security Settings > Account Policies > Password Policy > Store passwords using reversible encryption = Disabled

A copy linked to a workstation or user OU does not change the domain password policy. Update the authoritative highest-precedence GPO at the domain root first and check for conflicts. Set-ADDefaultDomainPasswordPolicy changes the effective directory value but does not author a GPO; a conflicting GPO can set the value again. Use the cmdlet only as a controlled immediate step within the same runbook, and inspect it with -WhatIf first:

$domain = Get-ADDomain -ErrorAction Stop

Set-ADDefaultDomainPasswordPolicy `
  -Identity $domain.DNSRoot `
  -ReversibleEncryptionEnabled $false `
  -WhatIf

Change enabling PSOs individually after the dependency migration has been approved. Again, use -WhatIf first to confirm scope:

Set-ADFineGrainedPasswordPolicy `
  -Identity 'Legacy-CHAP-Users' `
  -ReversibleEncryptionEnabled $false `
  -WhatIf

Do not overwrite userAccountControl as a complete numeric value; doing so can remove unrelated account flags. The targeted cmdlet parameter changes only the intended option:

Set-ADAccountControl `
  -Identity 'legacy.service' `
  -AllowReversiblePasswordEncryption $false `
  -WhatIf

After approval, run the same changes without -WhatIf. Treat domain policy, PSOs and user-flag changes as separate changes so that cause and effect remain traceable. Verify AD replication and effective values against multiple domain controllers before beginning the first password rotation.

5) Rotate passwords only after complete disablement

Disablement applies only to future password changes. Existing reversible representations remain until the corresponding password is actually changed. Rotation is therefore the step that actually removes the exposure.

Separate the sequence by risk and operating model:

  1. privileged personal accounts and administrative break-glass accounts under their dedicated procedure,
  2. normal users in supported waves with clear help-desk communication,
  3. service accounts together with the application, secret store, scheduled tasks, services and dependencies,
  4. disabled accounts that must be retained, using a random new secret,
  5. special identities only through product-specific runbooks.

“User must change password at next logon” is unsuitable for service accounts. Generate the secret under the controlled process, store it in the approved vault, update the workload and then run a functional test. Where supported, migration to gMSA reduces future manual rotation effort.

A legacy test immediately after the policy change can be misleading: while the old reversible material is still present, the previous authentication path may continue to work. A canary test becomes meaningful only after a new password has been set.

6) Prove completion with a cutoff and subsequent rotation

For each domain, document a hardening cutoff at which all three activation paths were demonstrably disabled after replication convergence. Every account in scope must then meet this condition:

PasswordLastSet > hardening cutoff

The evidence set includes at least:

  • effective Default Domain Password Policy for every domain,
  • all PSOs with precedence, assignment and current reversible-encryption value,
  • the complete result set for per-user flag 0x80, ideally empty,
  • rotation state, owner and functional test by account class,
  • documented residual exceptions with expiry and compensating controls,
  • replication and GPO state after the change,
  • monitoring for subsequent changes.

Events 4738 and 4739 can record changes to users and domain policy respectively. With suitable Directory Service Change auditing and SACLs, event 5136 adds visibility into changes to relevant AD objects. The objective is not one specific event ID, but central coverage of changes to the user flag, domain-policy properties and PSOs, with each change mapped to an authorized record.

Historical system-state and domain-controller backups cannot be cleaned retroactively by changing the live directory. They remain highly sensitive until retention ends, require tightly restricted access and need a tested restore process. After restoring an old state, re-check the hardening controls and rotate affected passwords again.

Benefits: less recoverable password material and stronger evidence

  • Recoverable password representations are removed. After subsequent rotation, the current AD state no longer contains a plaintext equivalent created by this feature for affected accounts.
  • The change is technically measurable. Three configuration paths and a rotation cutoff produce defensible evidence.
  • Legacy dependencies become visible. Obsolete CHAP and verified plaintext-dependent paths receive an owner, migration plan and expiry instead of an invisible domain exception.
  • The impact of AD or backup exposure is reduced. A recoverable password is especially serious if it was reused outside the domain against policy.
  • Operations become simpler. A domain-wide special configuration disappears; exceptions are limited to concrete workloads and accounts.

Drawbacks and limits: rotation is the real effort

  • Legacy authentication can fail. Classic CHAP and other confirmed plaintext-dependent paths must be migrated or specifically isolated before password rotation; IIS Digest requires a version- and configuration-specific compatibility test independently.
  • Service accounts require coordination. An unplanned reset can interrupt services, jobs, appliances or integrations.
  • Current policy does not prove historical remediation. Without reliable history, a conservative rotation scope is required.
  • Backups retain former secrets. The measure does not change old system-state backups or exported directory states.
  • NT hashes and Kerberos keys remain part of AD. This control does not replace domain-controller hardening, protection of replication rights, strong passwords, privileged administration paths or MFA at suitable access points.
  • Hybrid identities require separate analysis. An AD DS change does not automatically alter password material or authentication paths in cloud-only systems.
  • The result cannot be proven directly through LDAP. Normal inventory queries show activation paths but cannot reliably prove the historical contents of internal credential structures. Policy state plus rotation after the cutoff therefore forms the defensible operational evidence.

Common pitfalls

  • Checking only the Default Domain Password Policy and missing enabling PSOs or the per-user flag.
  • Assuming a PSO set to Disabled overrides domain-wide enablement.
  • Inferring PSO application from AppliesTo without checking the user's resultant policy.
  • Disabling policy without changing passwords afterwards.
  • Counting “User must change password at next logon” as a completed rotation.
  • Testing immediately after the policy change and mistaking the old password material for a successful migration.
  • Replacing userAccountControl numerically and damaging unrelated account properties.
  • Rotating service accounts without an owner, dependency matrix, vault update and rollback.
  • Treating PEAP-MS-CHAPv2 as proof of reversible storage solely because of its name.
  • Treating IIS Digest as plaintext-dependent without checking its version and credential path.
  • Re-enabling the domain value for one legacy application.
  • Removing disabled accounts and Password never expires accounts from scope.
  • Checking the current DC while ignoring replication convergence, other domains and old backups.
  • Confusing LAPS password encryption with the domain-password option discussed here.

Project checklist

  • [ ] Record the effective Default Domain Password Policy for every domain.
  • [ ] Export every fine-grained password policy with state, precedence and assignments.
  • [ ] Determine the resultant PSO for potentially affected and representative users.
  • [ ] Inventory all user accounts with userAccountControl bit 0x80.
  • [ ] Reconstruct the historical enablement period from GPO backups, changes and audit data.
  • [ ] Include a broader set of potentially affected accounts when historical scope is uncertain.
  • [ ] Verify classic CHAP and other plaintext-dependent third-party paths technically.
  • [ ] Assess IIS Digest separately by version, configuration and credential path.
  • [ ] Assign each dependency an owner, target protocol, test case and retirement date.
  • [ ] Prepare canary accounts and functional tests for every authentication path.
  • [ ] Disable the setting in the authoritative effective domain-root GPO and verify the effective directory value.
  • [ ] Disable enabling PSOs and per-user flags through controlled changes.
  • [ ] Verify effective state and replication against multiple domain controllers.
  • [ ] Record the hardening cutoff only after full convergence.
  • [ ] Rotate privileged accounts under their dedicated runbooks.
  • [ ] Bring normal users through actual password changes in supported waves.
  • [ ] Rotate service accounts with workload owner, vault update, functional test and rollback.
  • [ ] Move suitable service accounts to gMSA or another managed identity path.
  • [ ] Handle disabled accounts that must be retained securely.
  • [ ] Prove PasswordLastSet is later than the hardening cutoff for every account.
  • [ ] Run legacy canary tests only after the password change.
  • [ ] Monitor changes to domain policy, PSOs and the user flag centrally.
  • [ ] Keep old system-state backups under tightly restricted access until retention expires.
  • [ ] Document residual exceptions with owner, scope, compensating controls and expiry.
  • [ ] Establish recurring compliance checks for all three activation paths.