Status of reversible encryption password

Question

Is there an easy way to check Windows 2008R2 DC user accounts for a flag or keying material that shows that an account currently has a reversible password stored?

I'm aware of DSInternals but I'm not looking to decrypt the passwords. I've looked through AD attributes through AD Explorer but didn't see any obvious flags (even bitwise like ENCRYPTED_TEXT_PWD_ALLOWED in UserAccountControl doesn't change when the right is set at the group or domain level).

This could be useful to verify this data is deleted or to verify users that still have to use encryption methods like Digest or CHAP that require access to the password.

Thanks.

Solution 1

2008R2 stores the password in a hidden supplementalCredentials attribute. This attribute is generally not readable or writable. There are methods of reading it, such as setting up a bogus replication peer by using Get-ADReplAccount in the DSInternals module or parsing the ntds.dit database file offline (e.g., with Get-ADDBAccount). LDAP-based tools, such as Revdump no longer work.

Solution 2

First off, digest authentication and reversible encryption should never ever be used. There are tools available to easily extract plain text passwords for accounts using these. Attackers commonly use this method to extract plain text passwords of your accounts so they can learn how passwords are generated and easily guess the next one if they ever lose persistence.

The best way to determine if this is being used is by checking if it is enabled in Group Policy, Fine-Grained Password Policies, or on the Active Directory user account. Once the setting is enabled, the users plain text password will be available after the next password reset.

1) Group Policy (Default Domain Policy):

Computer Configuration\Windows Settings\Security Settings\Account Policies\Password Policy -> "Store password using reversible encryption"

From TechNet: "The intent of this policy is to provide support for applications which use protocols that require knowledge of the user password for authentication purposes. Storing passwords using reversible encryption is essentially the same as storing clear-text versions of the passwords. For this reason, this policy should never be enabled unless application requirements outweigh the need to protect password information."

2) Fine-Grained Password Policies:

Check here for how to view a Resultant PSO for a User or a Global Security Group.

From TechNet: "You can use fine-grained password policies to specify multiple password policies within a single domain. You can use fine-grained password policies to apply different restrictions for password and account lockout policies to different sets of users in a domain."

3) On the domain user object account options:

"Store password using reversible encryption"

Use this PowerShell query to find users in your domain that are configured with the "Store password using reversible encryption" check box checked: Get-ADObject -LDAPFilter '(&(objectClass=user)(objectCategory=user)(userAccountControl:1.2.840.113556.1.4.803:=128))'

Here is another PowerShell method to identify domain accounts with reversible encryption enabled:

Get-ADUser -Filter 'AllowReversiblePasswordEncryption -eq "True"'

Comments

[melds]

For those marking this as a poorly written question, what additional information would you like to see? Even if one wouldn't want to turn on reversible encryption, it would still be useful to know if any of your user accounts still have G$RADIUSCHAP and G$RADIUSCHAPKEY set.

[EEAA]

It is completely irresponsible to use reversible password encryption. This was the case years ago, let alone today. This is why you are getting downvoted.

[melds]

But the question isn't weather to use reversible encryption or not but if there is a way to see if a reversible key pair is currently saved in an account. It's useful to know to audit for insecure keys, it's useful in a test environment, and it's useful when storing an insecure password is the better choice when the other option is sending it insecurely.

[melds]

First, thank you for your response. Unfortunately it doesn't answer my question; it only shows clients that have the flag set on their account, not if they have a password (i.e., G$RADIUSCHAP and G$RADIUSCHAPKEY). Sometimes security is a tradeoff. With the choice of sending passwords in the clear over the wire (for proxy-authenticate basic) or having reversible passwords in the domain (in order to use proxy-authenticate digest), it's easier to secure the DC than all of the client connections. Clients don't directly hit the DC in this case and it's in an isolated network.

[twconnell]

I only included the command to show users that have reversible encryption enabled so people could use it to detect which accounts need to be fixed. Do not for a second believe that by securing your DC you are somehow more protected. You must also secure every endpoint on your domain or someone is going to get in from one of those unsecured endpoints and move laterally through your network until they eventually elevate their access. If you allow even one of those endpoints access to the internet, your network is not "isolated".

[melds]

When there are no nodes on the DC and it's only used for backend authentication, there are no endpoint to steal cache entries from. Your PowerShell doesn't work if reversible encryption is turned on domain-wide or via the OU. In fact it's an effective backdoor to enable at a higher level since it is not set on userAccountControl so searches like yours give the impression reversible encryption is disabled when it's not.

[twconnell]

You're right, and that's why the policy for enabling reversible encryption is disabled by default and is a major finding in any domain security audit. The domain should also be monitored to ensure it isn't enabled at the user level. According to Microsoft, the supplementalCredentials attribute is a structured binary value that contains additional cryptographic forms of the cleartext password (and optionally the cleartext password itself) that are stored as property-value pairs. So having this attribute populated does not necessarily mean the user has the reversibly encrypted password stored.