A little over two weeks ago, the United State Computer Emergency Readiness Team (US-CERT) issued a bulletin calling for admins to take action on an old issue that I’ve covered extensively in the past. The issue relates to the fact that there are several areas within Group Policy Preference (GPP) that used to allow you to enter user name and password information into the preference item, to be processed by client computers. The most common example here was using GPP Local Users and Groups policy to deliver password changes to local administrator accounts on servers or workstations. This was a great feature that was hampered by a tiny little issue (I’m being facetious here). Namely, that the encryption key and algorithm type that was used by Group Policy to store the password in SYSVOL (and also cached on the client) was published openly on Microsoft’s site, available for anyone to view and use to decrypt those passwords. To make matters more challenging, any client machine (server or workstation) that processes one of these preference settings, also caches the setting’s XML (including the password entry) locally on the client, either under %programdata% (for per-computer settings) or %appdata% (for per-user settings). So you not only have to worry about the passwords stored in the GPO, but you also have to worry about the clients that have received them. Ugly…
The Recommended Steps
As explained in countless articles and in Microsoft’s own security bulletin at the time this was exposed, admins were strongly encouraged to apply the fix described in the bulletin, that would prevent the creation of new GPP settings that contained passwords. Microsoft also presented a PowerShell script alternative to this feature called Invoke-PasswordRoll that allowed you to centrally change local account passwords (note that it only managed local account passwords–it didn’t allow changes to the other areas that GPP support password management on, such as services, data sources and scheduled tasks.) Later, Microsoft announced another centralized password management solution for local accounts called the Local Administrator Password Solution (LAPS), available for free on their website. This one is a bit more advanced, leveraging AD protected attributes to store password information for a given machine, but not leveraging Group Policy. The sad reality is that a really great feature in GP is no longer a good idea. The US-CERT bulletin was underscoring this fact and strongly encouraging all you admins out there to get rid of these nasty things from your environment before someone takes advantage of it. It is good advice, despite the inconvenience. And, if you follow the steps in Microsoft’s bulletin and related articles, you are *almost*, but not quite, in good hands.
The Steps, And What’s Missing?
The information and hotfixes Microsoft provided were great–including the ability to discover where these passwords were stored in your domain. Unfortunately the remediation of this vulnerability was limited to the following 6 basic steps:
“
- In GPMC, open the preference that contains CPassword data.
- Change the action to Delete or Disable, as applicable to the preference.
- Click OK to save your changes.
- Wait for one or two Group Policy refresh cycles to allow changes to propagate to clients.
- After changes are applied on all clients, delete the preference.
- Repeat steps 1 through 5 as needed to clean your whole environment. When the detection script returns zero results, you are finished.
“
Essentially what that said was, “delete the preference, wait until it’s processed by the client and you’re good”. Unfortunately, you may actually still want to use that preference setting, but just not use the password feature! The current Microsoft security bulletin and scripts don’t provide a way of remediating those passwords while keeping the setting intact. Fortunately, we here at SDM have taken up the challenge of making it easier for you to get rid of those passwords without losing the setting itself! And, best of all, it’s a free GUI tool that makes it super easy to find and fix these bad boys!
A Long Name To Match It’s Power!
Today we are releasing the “SDM Software GP Preference Password Remediation Utility 1.0”. Yes, the name is long. Can you tell we are not a company of marketers??? But the point of the tool is to provide you with a way to get rid of those vulnerable password entries in your GP Preference settings, while still keeping the underlying settings around. The tool is really straightforward, as shown below:
Group Policy Preference Password Remediation Utility
The tool does three things:
1. Scans all GPOs in an AD domain to find non-empty password entries within GP Preference settings–lists those entries in the grid view. We put some optimizations in there to only scan GPOs that we find those 5 GPP areas that can contain password entries. So in large environments, it shouldn’t take forever to scan all your GPOs–our test environment here with about 350 GPOs took about a minute to scan. (Requires read permissions on all GPOs)
2. Allows you to right-click one or more entries and remediate those passwords within the GPO’s SYSVOL storage. Remediation entails removing the cpassword attribute completely from the XML that defines a setting and incrementing the GPO’s version number appropriately. This last bit is important. You want the client to know that *something* has changed in the GPO so it picks up the change on it’s next processing cycle. (This requires write permissions on any remediated GPOs to work successfully.)
3. Prior to remediation, the utility will perform a GPMC backup of all selected GPOs into a folder under %public%\documents\SDM Software\GPOBackups. If you need to backout the remediation, you can use GPMC’s restore feature to restore the GPO from the backup directory we create.
The utility is simple and to the point and we hope you find it useful!
Cleaning up the Clients
The last thing to note, as I alluded to above, is that you still have to worry about these passwords being cached at client. That’s one reason why we increment the GPO version number when we remove the password fields. It instructs the client during it’s next GP processing cycle, that *something* has changed. This tells the client to download the newest GP Preference setting file to the cache, which of course, will no longer include the password field!
However, if you need to “force the issue”, there are a couple of mechanisms that GPMC provides in Windows 8.x/2012 and above. First, the Group Policy PowerShell module includes the invoke-gpupdate cmdlet that let’s you script a gpupdate /force against one or more computers.
The second method is another feature that was included in GPMC in Win8/2012–the ability to force remote gpupdates from within the GUI GPMC console itself (see below)
Performing a remote Group Policy Update in GPMC
The nice part about doing this in GPMC is that you can right-click on a whole OU, and have it apply a GPUpdate against all the computers in that OU. Cool!
What Next?
So, once the tool has removed the passwords from GP Preference settings and you’ve allowed it to propagate to all clients, what next? Well, there’s at least one caveat to this tool that you need to consider. Some of these preference items may no longer make sense to use if the password has been removed. Clearly you won’t be adding new passwords to these preferences going forward, so this is a good opportunity to re-assess whether you need these settings anymore. In those cases, it may make sense to follow the original Microsoft guidance and just delete them. But in the meantime, we hope this utility will solve the immediate problem of having all these crackable passwords lying around your network, waiting to be exploited!
We look forward to hearing your feedback on this.
Darren