(Don’t) Set or Save Passwords Using Group Policy Preferences
Group Policy Preferences provides immensely powerful ways to manage PCs and users and their settings. However, a dangerous situation exists with the manner in which Group Policy Preferences stores passwords that you save in GPOs.
It’s really important that you read this post if you are:
- Setting local user passwords via Group Policy
- Have configured a group policy setting that performs an action as a specific user (eg, map network drive as a specific user account)
Some backstory
Group Policy Preferences, while totally awesome, was not originally built into Windows. It started life as an extension (3rd party) to Group Policy to provide greater flexibility.
By acquiring the technology and incorporating it into the platform, we were able to get many customers to trust and adopt it as a viable replacement for logon scripts and other configuration systems/products. So, a good thing!
However, there are some nuances about it’s operation that remain as a remnant of history, these include some quirky UI elements and, this issue.
What is cPassword?
cPassword is the name of the attribute that stores passwords in a Group Policy Preference item. Whenever a preference item requires a password to be saved (typically the two scenarios at the top of this post) then the password itself it stored within this attribute. The attribute is actually just a value in the relevant XML in the Group Policy Template, stored in the SYSVOL folder on Domain Controllers.
The contents of the attribute itself is encrypted – here’s an example from an environment that set’s the local Administrator account password using GPP:
So you might think – OK, so what’s the problem?
The issue is that the password is not stored securely enough and can be easily decrypted by any authenticated user in the domain. As a result, if you are storing passwords in GPP you are at a high level of risk.
You don’t have to be subject to a sophisticated, targeted attack for this to bite you, badly. Anyone with some basic understanding of cryptography could discover these passwords by only investing a few minutes of time.
OK, so what is Microsoft doing about this?
The only real alternative here is to use something else to store passwords. It’s fairly straightforward to make your own script to perform this action, but will depend based on your needs.
In order to drive customers to an alternative, we’ve done a few things. Firstly, we’ve had a warning in Windows whenever you set a cPassword attribute via Preferences:
More recently, we issued MS14-025: Vulnerability in Group Policy Preferences could allow elevation of privilege: May 13, 2014 to raise awareness and provide some other options.
In addition, we changed the following in Windows with an update:
- Password fields in all affected preferences are disabled. Administrators cannot create new preferences by using these password fields.
- The username field is disabled in some preferences.
- Existing preferences that contain a password cannot be updated. They can only be deleted or disabled, as appropriate for the specific preference.
- The behavior for Delete and Disable actions have not changed for the preferences.
- When an administrator opens any preference that contains the CPassword attribute, the administrator receives the following warning dialog box to inform him or her of the recent deprecation. Attempts to save changes to new or existing preferences that require the CPassword attribute will trigger the same dialog box. Only Delete and Disable actions will not trigger warning dialog boxes.
Hmmm, OK – what can I do?
I thought you’d never ask!
Check out KB962486 – and specifically have a look at the following things you can do right now:
- Use the script we provide to scan your SYSVOL folder for any GPOs that contain cPassword attributes. After removing all the unneeded GPOs (there may be some affected GPOs that are unlinked or not required any more) focus on the ones that you’ll need to keep and why they need to save a password.
- Use the roll password script as a replacement for setting your local admin passwords via GPP. Just remember that you may have additional or different requirements the script doesn’t cover, so be sure to think before you go on a mad GPP removal and password setting rampage.
Happy cPassword hunting!
Ash
Comments
- Anonymous
March 18, 2015
The comment has been removed