Group Policy preferences are a new feature set available since Windows Server 2008, which shouldn’t be confused with the well known Group Policy objects (GPOs) dating back to Windows NT. The main idea behind the creation of Group Policy preferences is the ability to push so-called “unmanaged” settings. Compared to “managed” GPOs, group policy preferences can be altered by the end user and aren’t enforced on a regular basis.

Before the release of the Group Policy feature, administrators could already set user preferences via scripts or .reg files. This lead to complex login scripts potentially containing sensitive information. Using Group Policy features, you can now manage this kind of settings centrally and in a convenient way.

While this addition was released with Windows 2008 Server, you can install the client-side extensions on client computers running on Vista, Windows XP SP2 or Windows 2003 SP1 for backward compatibility with all your workstations.

Let’s see an example on how we can define a local user on some workstations. It starts with the creation and edition of a group policy object:

In the Group Policy Management Editor, we still see our well-known Policies folder, but also a new hierarchy for these unmanaged preferences. Creating a local administrator on the machines targeted by the GPO “GPO_local_accounts” is only a matter of clicks:

Where is this setting stored and how secure is it? Group Policy Preferences are stored, as all other GPOs, within the SYSVOL folder on the domain controllers (%LOGONSERVER%\SYSVOL) but within xml files.

The above created policy gets translated into the following groups.xml file:

<?xml version="1.0" encoding="utf-8"?>
  <Groups clsid="{3125E937-EB16-4b4c-9934-544FC6D24D26}">
    <User clsid="{DF5F1855-51E5-4d24-8B1A-D9BDE98BA1D1}"
     name="ladmin_gpo" image="0" changed="2012-02-03 07:10:48"
     uid="{FE47E73C-7525-46CD-B2E0-F68D3022EDCE}">
      <Properties action="C" fullName="Local admin created by GPO"
       description=""
       cpassword="9QHhFTUdm6rDgu30J7ShZfqt07T6vOUGkyAFG3G7M+5AotJjkOva7E9KSAcamdrruTgly0O/uVTB/UUdLNU4775b5381hyuUzkd4lJW+llcNNNrQlYu7zqH3/i+8jfjhUq9lqPn8VjCtb9iaEqWbKQ"
       changeLogon="0" noChange="0" neverExpires="0"
       acctDisabled="0" userName="ladmin_gpo"/>
    </User>
    <Group clsid="{6D4A79E4-529C-4481-ABD0-F5BD7EA93BA7}"
     name="Administrators (built-in)" image="2"
     changed="2012-02-06 10:45:50"
     uid="{4D0CE71D-D2E4-42B1-9BF3-147C910A15F1}">
      <Properties action="U" newName="" description=""
       deleteAllUsers="0" userAction="ADD" deleteAllGroups="0"
       removeAccounts="0" groupSid="S-1-5-32-544"
       groupName="Administrators (built-in)">
        <Members>
          <Member name="ladmin_gpo" action="ADD" sid=""/>
        </Members>
      </Properties>
    </Group>
  </Groups>

So how secure is my password, stored within the cpassword attribute? According to the documentation, it’s using AES-256 – so pretty secure, isn’t it?

Well, not exactly, as the key is public and documented in the MSDN. All you need to do is open CrypTool, add some padding to the value to be base64 compliant, and perform a base64 decoding:

Choose then the AES decryption option (Analysis – Symmetric Encryption (modern) – Rijndael (AES) and paste the public key:

That’s it, the password is decrypted without any brute-force attack:

As conclusion, while Group Policy preferences are a great tool to distribute unmanaged settings, it should not be used to push down features containing credentials such as:

  • User preferences
  • Database connections strings
  • Scheduled tasks
  • Mapped drives settings
  • Service preferences

References