For those of you following this issue, which I blogged about previously, you’ll know that several areas within Group Policy Preferences allowed for defining of passwords that were stored with the GPO settings storage in SYSVOL. These passwords were stored using an encryption method that was published publically by Microsoft (and had been for several years). In addition, the fact that the encryption used a static key, and the actual value of the key, was also published with this data. As a result, this password information, which was often used within the “Local Users and Groups” Preferences areas to rotate local administrator passwords on Windows systems, was deemed weak and a security risk (not surprising there).

The “Fix”

Last week, as I posted on various social media outlets (Twitter: @grouppolicyguy, Facebook: facebook.com/sdmsoftware), Microsoft published an article and accompanying hotfixes to address this password storage weakness. I’ve been of two minds on this issue. Namely, while it’s certainly not a great idea to provide a password rotation mechanism and distribution mechanism and then publish the encryption key used for it, I know for a fact that lots of admins rely heavily on this capability. So the question became, how do you address this issue adequately? Well Microsoft responded to that question with the above-referenced article and hotfixes. To recap, the following GP Preferences areas are affected by this article:

• Drive Maps
• Local Users and Groups
• Scheduled Tasks
• Services
• Data Sources

Here’s what the article does, in a nutshell:

1. Provides a hotfix (nominally, this is Hotfix # 2928120 or 2961899, depending upon whether you already have update 2919355– a Windows 8.x specific patch– installed) to the Remote Server Administration Tools (RSAT) that prevents new Preferences created in one of these above areas from defining a username and/or password (depending upon the Preferences area and the Preference Action state (e.g. Create, Update, Replace & Delete)). It does this by graying out the fields in the GP Editor UI for these properties. This hotfix applies to all OS’ after Windows Vista (both server and client). The only time this graying out is not in effect is if the “Action” field on the Preference is set to Delete or the Preference item itself has been disabled. In this case, for obvious reasons, the state of the password is irrelevant, since it’s about to be removed.

2. Provides the text of a PowerShell script function called Invoke-PasswordRoll (and an accompanying function called ConvertTo-CleartextPassword). The purpose of these script functions is to provide administrators with an alternative mechanism for securely delivering password updates to machines. The way this script works, is that you feed it a list of computer names and a list of user accounts, and it randomly generates a password, connects to the remote machine using WMI and ADSI and changes the accounts specified to have the random password. It then stores the random password it just created for that account in a TSV file on the machine where the script is running, and then optionally encrypts the TSV file with an encryption key you specify. Obviously this mechanism may or may not work for you, depending upon your requirements. Frankly, there are probably better solutions out there–commercial solutions as well as free ones, for handling password management. If you are in the position of having to scramble to address this issue, this might be a good time to evaluate some of those alternatives.

3. The final thing this article provides, is a PowerShell script function, called Get-SettingsWithCPassword, that allows you to enumerate GPOs that contain GP Preferences passwords. This is similar to the script that I provided in my article on this topic, referenced above. The Microsoft article also provides specific guidance on what changes within each of the 5 Preference areas listed above, with the hotfix. I encourage folks that are looking at this issue, to read the whole article thoroughly.

Getting The Downloads

The article is a bit convoluted and you may be asking, where the heck is the link to download the hotfix? Let me just save you some time and point you here: https://technet.microsoft.com/library/security/ms14-025, which has all the links for the actual downloads.

Fixing What You Have

Finally, the one big piece missing within this article, is what to do with your existing GP Preferences passwords. The article suggests going into each preference item that contains a password in your environment, setting the action to either Disable or Delete, wait a few GP processing cycles for this to propagate, and then delete the Preference item altogether from the GPO.  You might ask, “Why do I need to go through the step of setting the Preference to disable or delete first?”. Great question! Here’s why (and you won’t like it). The password is not only held in SYSVOL as part of the GPO. A little known feature of GP Preferences is that data is cached in a set of history files at the client that processes those Preferences, so that rollbacks of Preference settings, when needed, can be done. Passwords are no exception to this. Thus, every client that has processed a GP Preference containing a password, has a local copy of the password’s hash within c:\programdata\Microsoft\Group Policy\History. The only way that cached copy will go away is if you a) delete it yourself or b) set the preference to Delete or Disable to get rid of it during the next processing cycle. Neat!

Thanks for reading.

Darren