Store Passwords Using Reversible Encryption: How to Find and Fix It in Active Directory

Reversible Passwords means Active Directory is allowed to keep some passwords in a form that can be decrypted back to plaintext, either through the per-account userAccountControl flag 128 or the “Store passwords using reversible encryption” policy. To fix it, clear the flag, disable the policy in every GPO and fine-grained password policy, then reset the affected passwords.

The last step is the one teams skip: Microsoft states that existing passwords stay stored with reversible encryption until they are changed.

What the scanner is actually detecting

The setting can live in three places, and a clean result needs all three:

• Per account. The ENCRYPTED_TEXT_PWD_ALLOWED bit (hex 0x0080, decimal 128) in userAccountControl. In Active Directory Users and Computers it is the “Store password using reversible encryption” check box under Account options. In PowerShell it is the AllowReversiblePasswordEncryption property.
• Domain password policy. “Store passwords using reversible encryption” in the GPO linked to the domain root, normally the Default Domain Policy. It covers every account the domain policy applies to without setting any per-account flag, so an account query alone will not reveal it.
• Fine-grained password policies (PSOs). The msDS-PasswordReversibleEncryptionEnabled attribute, shown in PowerShell as ReversibleEncryptionEnabled.

Do not confuse this with Tenable’s separate Reversible Passwords in GPO indicator. That one is about passwords saved in Group Policy Preferences files (the MS14-025 problem), not about this policy setting.

Real-world risk

This is not a remote exploit, and Tenable rates it Medium. Reading the stored value requires domain replication rights (a DCSync) or an offline copy of the directory database, such as a domain controller backup. PingCastle’s technical explanation is direct: the password is effectively kept in clear text in the account’s supplementalCredentials attribute and can be retrieved with DCSync.

Anyone with that access can already take NT hashes, so what does plaintext add? It works where only a real password is accepted, such as VPN portals, web applications and non-Windows systems that reuse it, and it reveals the person’s password pattern, which helps guess the next one after a reset.

There is also an attacker-driven version. MITRE ATT&CK T1556.005 describes intruders enabling reversible encryption so that passwords set afterwards can be recovered in plaintext. A flag nobody can explain is a possible sign of compromise, not just a hygiene issue.

How to confirm it

These commands are read-only. Run them from an admin workstation with the RSAT ActiveDirectory and GroupPolicy modules, using an account that can read the Password Settings Container.

# User accounts with the flag (ENCRYPTED_TEXT_PWD_ALLOWED, 128)
Get-ADUser -LDAPFilter '(userAccountControl:1.2.840.113556.1.4.803:=128)' -Properties PasswordLastSet |
    Select-Object SamAccountName, Enabled, PasswordLastSet

# Same check through the module's property name
Get-ADUser -Filter 'AllowReversiblePasswordEncryption -eq $true'

# Computer accounts (PingCastle S-C-Reversible)
Get-ADComputer -LDAPFilter '(userAccountControl:1.2.840.113556.1.4.803:=128)'

Then check the policies:

# Domain-wide policy
Get-ADDefaultDomainPasswordPolicy | Select-Object ReversibleEncryptionEnabled

# Fine-grained password policies and who they apply to
Get-ADFineGrainedPasswordPolicy -Filter * |
    Select-Object Name, Precedence, ReversibleEncryptionEnabled, AppliesTo

# GPOs that define the setting (enabled or disabled; open each to see the value)
Get-GPO -All | Where-Object {
    (Get-GPOReport -Guid $_.Id -ReportType Html) -match 'Store passwords using reversible encryption'
} | Select-Object DisplayName, Id

For a flag you cannot explain, find out when userAccountControl last changed and on which domain controller, then look on that DC for event 4738, which Microsoft documents with the text ‘Encrypted Text Password Allowed’ – Enabled (it requires the Audit User Account Management subcategory):

Get-ADReplicationAttributeMetadata -Object (Get-ADUser svc-legacy).DistinguishedName -Server DC01 -Properties userAccountControl |
    Select-Object AttributeName, LastOriginatingChangeTime, LastOriginatingChangeDirectoryServerIdentity

How to fix it

Step 1: identify real dependencies

Microsoft’s policy reference names two cases that need reversible encryption: CHAP through remote access or IAS (now NPS), and Digest Authentication in IIS. Ask the owner of each flagged account whether one of these applies. Tenable’s guidance is that such accounts are typically legacy service accounts you should consider deleting. Export the current list first, because you will need it for verification and rollback:

Get-ADUser -LDAPFilter '(userAccountControl:1.2.840.113556.1.4.803:=128)' -Properties PasswordLastSet |
    Select-Object SamAccountName, DistinguishedName, PasswordLastSet |
    Export-Csv .reversible-before.csv -NoTypeInformation

Step 2: clear the per-account flag

# One account
Set-ADUser -Identity svc-legacy -AllowReversiblePasswordEncryption $false

# Every flagged user
Get-ADUser -LDAPFilter '(userAccountControl:1.2.840.113556.1.4.803:=128)' |
    Set-ADUser -AllowReversiblePasswordEncryption $false

# Computer accounts
Get-ADComputer -LDAPFilter '(userAccountControl:1.2.840.113556.1.4.803:=128)' |
    Set-ADAccountControl -AllowReversiblePasswordEncryption $false

In the GUI, open the account in Active Directory Users and Computers, go to the Account tab and clear Store password using reversible encryption.

Step 3: disable the domain policy

In the Group Policy Management Console, edit the GPO linked at the domain root that defines the setting (normally the Default Domain Policy) and set:

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

Microsoft notes that each domain has only one account policy, taken from GPOs linked at the domain root. The same setting in an OU-linked GPO affects only local accounts on computers in that OU. Fix those GPOs as well, because PingCastle’s A-ReversiblePwd flags any GPO that enables it. If you are not sure which root-linked GPO wins, see how GPO precedence decides which setting applies.

Set-ADDefaultDomainPasswordPolicy -ReversibleEncryptionEnabled $false exists, but domain controllers read account policy from the default domain policy GPO, so a GPO still set to Enabled will win. Change the GPO.

Step 4: fix fine-grained password policies

Get-ADFineGrainedPasswordPolicy -Filter * | Where-Object ReversibleEncryptionEnabled |
    Set-ADFineGrainedPasswordPolicy -ReversibleEncryptionEnabled $false

Step 5: change the passwords

PingCastle agrees with Microsoft: the cleartext goes away at the next password change.

# Interactive users: force a change at next sign-in
Set-ADUser -Identity jdoe -ChangePasswordAtLogon $true

# Service accounts: reset, then update every service, task and config that uses it
Set-ADAccountPassword -Identity svc-legacy -Reset -NewPassword (Read-Host -AsSecureString 'New password')

If the domain policy or a PSO was enabled, every covered account whose password was set while it was on holds a reversible copy. Unless you know exactly when it was enabled, treat every account whose password predates the fix as affected, and start with privileged and service accounts:

$fixDate = Get-Date '2026-09-26'   # the day you disabled the setting
Get-ADUser -Filter 'Enabled -eq $true' -Properties PasswordLastSet |
    Where-Object { $_.PasswordLastSet -lt $fixDate } |
    Select-Object SamAccountName, PasswordLastSet

For a PSO, limit the list to members of its AppliesTo groups. Disabled accounts still hold their stored copy, so reset or delete them too. This setting belongs in any domain baseline; our Windows Server hardening checklist covers the rest of the password policy.

How to verify the fix and rescan

1. Run gpupdate /force on the domain controllers (or wait for the next refresh), then rerun the confirmation commands. The flag queries should return nothing, and every ReversibleEncryptionEnabled value should be False.
2. Check which policy a given user actually gets with Get-ADUserResultantPasswordPolicy -Identity jdoe. It returns the PSO in effect, or nothing when the domain policy applies.
3. Compare PasswordLastSet against your reversible-before.csv export. Every account on that list should now show a date after the fix.
4. Rescan. Tenable Identity Exposure re-evaluates on its own as it sees the directory change. PingCastle needs a new healthcheck run. Defender for Identity updates the exposed entities list within minutes, but Microsoft says the status can take up to 24 hours.

A check that reads only the flag can go green before the passwords change, so close the ticket only after the resets.

What can break and how to roll back

• CHAP on NPS or RRAS. Users authenticating with CHAP fail once their password changes, because no reversible copy exists any more.
• IIS Digest Authentication. Microsoft’s policy page lists it as requiring the setting, so test any site that uses it.
• Service accounts. A reset that is not pushed to every service, scheduled task and config file causes outages. Never set “change password at next logon” on a service account.

If a genuine dependency surfaces, re-enable the flag on that single account rather than domain-wide, then reset its password, since only a password set while the flag is on is stored reversibly:

Set-ADUser -Identity svc-legacy -AllowReversiblePasswordEncryption $true
Set-ADAccountPassword -Identity svc-legacy -Reset -NewPassword (Read-Host -AsSecureString 'New password')

Record it as an accepted exception with an owner and a review date, and alert on event 4738 so any new instance of the flag is noticed.

Common false positive reasons

• Wrong indicator. Tenable’s Reversible Passwords in GPO concerns Group Policy Preferences passwords, and clearing account flags will not close it.
• Stale data. The scan ran before the change replicated or before the next assessment cycle.
• OU-linked GPO. PingCastle’s A-ReversiblePwd fires even when the GPO is linked below the domain root. That is a real finding, but it affects only local accounts on computers in that OU.
• Disabled accounts. Not a false positive: the stored copy is still there. Lower priority, but reset or delete them.
• Documented exception. A CHAP account you deliberately kept is accepted risk, not a scanner error.

FAQ

Does clearing the check box remove the stored password?

No. Microsoft states that existing passwords stay stored with reversible encryption until they are changed. Reset or change the password after clearing the flag.

Can an attacker use this remotely?

Not on its own. They need replication rights or an offline copy of the directory database; the setting makes that access pay out plaintext instead of hashes.

Which applications really need reversible encryption?

Microsoft names CHAP through remote access or IAS, and Digest Authentication in IIS. If neither is in use, nothing should need it.

Why does the account query miss the domain policy?

The domain policy does not set the per-account flag. Check Get-ADDefaultDomainPasswordPolicy and the PSOs separately.

Tracking this finding across many hosts

This finding lives in the directory rather than on one host, but the same account often shows up in reports from more than one tool. SITEY, a self-hosted vulnerability management platform, imports findings from 16 scanners and merges duplicates per scanner, not across scanners, so expect one entry per tool. Its AI triage can suggest false positives with evidence, and a human makes the final call.

Sources

• Microsoft Learn: Store passwords using reversible encryption
• Microsoft Learn: UserAccountControl property flags
• Microsoft Learn: Defender for Identity accounts security posture assessments
• Tenable: Reversible Passwords indicator of exposure
• PingCastle: rule descriptions (S-Reversible, S-C-Reversible, A-ReversiblePwd)