This weeks group policy setting of the week is about the “Remove Default Programs link from the Start menu” option that can be found under User Configuration > Policies > Administrative Templates > Start Menu and Taskbar. The start menu entry “Default Programs” was was introduced as part of the United States v. Microsoft Antitrust settlement case back in the…

If you are using the Group Policy Preferences to apply local user account be aware there is a security risk in doing this. In short the passwords are stored in the AD SYSVOL encrypted using AES however the encryption key is well known so this could only be considered obfuscated at best…. More info about this can be read at http://blogs.technet.com/grouppolicy/archive/2009/04/22/passwords-in-group-policy-preferences-updated.aspx

However using Group Policy Preferences to set passwords on local user accounts is still extremely useful and one could argue that not changing the local administrator account password is potentially more of a security issue over time. So if you still want to use this option but want to mitigate the risk in using this feature then here are a few steps that can be taken that will help.

Before you start tell as few as people as possible when you are changing the passwords. This is important as if you tell people when the password is changing they will know when to look for the password stored in the SYSVOL.

Step 1. Change default group policy refresh period to be as short as you dare (see Image 1). The default is 90 minutes but if you can safely crank it down 5 or 10 minutes that would be better. This will speed up the propagation delay of the new password once is configured in the group policy.

Image 1. Changing the default group policy refresh

Step 2. Some time during the middle of the day create a new group policy object and configured the the new local user password option (See image 2). then wait for the setting to propagate.

Image 2. Configuring the Local Account Password

Step 3. Then you need to wait… How long? The formula i would use for the time to wait is as follows:

Max Active Directory Propagation Delay + Max Group Policy Refresh Interval

Therefore if it take 16 minutes for Group Policy changes to propagate to all DC’s in the domain and you have set group policy refresh to 10 minutes the formula will look like this.

16 minutes + (10 minutes + 2 minutes) = 28 minutes

Note the 2 minutes is to take into account the 20% offset that group policy refresh interval has from the set value.

Step 4. Then one you have waited for the new password setting to rollout DELETE the group policy password setting you configured. This will purge the obfuscated version of the password from the SYSVOL. The reason also I recommend you create and delete a new group policy each time you do this is so the password file is store in a different path in the SYSVOL which is just another way to make it harder for someone to file the password file.

Step 5. You may want to repeat steps 4, 5 and 6 a couple of days apart to ensure that you have applied the setting to all the computers that were not turned on or connected to the network the first time (sounds like a great reason to deploy Direct Access).

Step 6. Finally don’t forget to wind back the default group policy refresh interval to its original value.

Now as we are all good IT Professional it would be best to tell people that the local admin password has changed and will be disseminated securely (NOT via email or IM) when needed. The key is to do it quick and then remove the policy as soon as you are done to have the smallest window of opportunity as possible for someone to grab the password file.

Of course this sound very devious and some could say you are covering your trails by deleting the policy once you are done which is not something you generally want to do as a good IT Professional… But if you are going to do this in a organisation then your are probably going to need to follow change control anyway so you should still have an official record of what you have done.

Alan Burchill

As I previously mentioned in Part 1 “use Group Policy to save “How to use BitLocker to Go” recovery keys in Active Directory – Part 1” one of the cool new features in Windows 7 is the ability to encrypt removable storage devices to help prevent the loss of data within an organisation while storing a copy of the decryption key in Active Directory. Another way to encrypt the removable storage devices and still have the ability to recover a encrypted devices if the unlock key is lost is to use a Data Recovery Agent digital certificate.

Now before you begin you first need to have deployed you a PKI infrastructure in your organisation so that you can issue the data recovery certificate to your nominated recovery agents.

So lets get started…

How to configured Group Policy to use a Data Recovery Agent with “BitLocker to Go” drives

Issuing the EFS Data Recovery Agent

First you need to create/issue at least one account with the Data Recovery Agent certificate that will be used for when encrypting all the Bitlocker to Go drives.

Step 1. Click Start, and then type certmgr.msc to open the Certificates snap-in

Step 2. In the console tree, expand Personal, and then click Certificates.

Step 2. Right click on Certificates and click on All Tasks and then Request New Certificate…

Step 3. Click Next to the first page of the Certificate Enrollment wizard and then then click on Active Directory Enrollment Policy and click Next

Step 4. Tick the EFS Recovery Agent policy and then click Enroll

Step 5. Click Finish once your account has enrolled as the EFS Recovery Agent certificate.

You should now see the File Recovery Certificate in you Personal Certificate store.

Exporting the DRA Certificate

You now need to export the DRA certification information to be used in the BitLocker Drive Encryption group policy in a future step.

Step 1. Double-click the BitLockerDRA certificate to display the certificate properties sheet.

Step 2. Click the Details tab

Step 3. Click Copy to File

Step 4. Click Next on the Welcome to the Certificate Export Wizard page

Step 5. Leave the No, do not export the private key selected and then click Next.

Step 6. On the Export File Format page, verify that DER encoded binary x.509 (.CER) is selected, and then click Next.

Step 7. On the File to Export page, click Browse to display the Save as dialog box. In File name, type BitLocker. In Save as type, verify that DER Encoded Binary X.509 (.cer) is selected, and then click Save to return to the File to Export page.

Step 8. The File name box on the wizard page should now display the path to the BitLocker.cer file in your document library. Click Next.

Step 9. On the Completing the Certificate Export Wizard page, verify that the information displayed is correct, and then click Finish.

Step 10. When the certificate has been exported, the Certificate Export Wizard dialog box will be displayed with the message The export was successful. Click Close to close the dialog and the wizard.

Configuring the Bitlocker Data Recovery Agent in Group Policy

In this section we are going to take the Data Recover Agent certificate we exported above and import it into the group policy to apply to computers that will have DRA certification for encrypting Bitlocker drives. The screenshots below are from a Windows Server 2008 R2 server with the group policy management console installed but if you are on a Windows 7 computer you will need to have install the Remote Server Admin Tools installed.

Step 1. Click Start, type gpedit.msc in the Search programs and files box, and then press ENTER.

Step 2. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Yes.

Step 3. In the console tree under Local Computer Policy\Computer Configuration\Windows Settings\Security Settings\Public Key Policies, right-click BitLocker Drive Encryption, and then click Add Data Recovery Agent to start the Add Recovery Agent Wizard.

Step 4. Click Next on the Add Recovery Agent Wizard welcome screen

Step 5. On the Select Recovery Agents page, click Browse Folder

Step 6. Browse to the location you have a copy of the BitLocker.cer file that you exported in the previous procedure select the certificate and click Open

Step 7. Click

Note: You can repeat this process as necessary to add multiple data recovery agents. After all data recovery agent certificates you want to use have been specified, click Next.

Note: The example above has USER_UNKNOWN because the DRA file was manually imported.

Step 8. On the Completing the Recovery Agent Wizard page, click Finish to add the data recovery agent

Below is the BitLocker Drive Encryption setup with a DRA installed.

Additional Group Policy Configuration

BitLocker Identification Field

You now need to configure the BitLocker Identification field on all the computers you are going to use Bitlocker on as this helps identify what removable devices belong to your organisation.

Step 1. Click Start, type gpedit.msc in the Search programs and files box, and then press ENTER.

Step 2. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Yes.

Step 3. In the console tree under Computer Configuration\Administrative Templates\Windows Components\Bitlocker Drive Encryption and then double click on Provide the unique identifiers for your organization

Step 3. Enter you specific Bitlocker identification name that you use to identify your Bitlocker encrypted devices in the BitLocker identification field

Note: You can add additional Bitlocker identifiers from other trusted organisations in the Allowed BitLocker identification field

Enable Allow Data Recovery Agent

Continuing on from above you will need to configure you computers to Allow the Data Recovery Agent option.

Step 4 (cont.). In the console tree under Computer Configuration\Administrative Templates\Windows Components\Bitlocker Drive Encryption\Removable Data Drive and then double click on Choose how Bitlocker-protected removable drives can be recovered , then you will need to click Enabled and tick Allow data recovery agent then click OK

Note: You still have the option of configuring the standard AD recovery keys in this window. The Allow Data Recovery Agent option as far as I can tell has no bearing of the other options.

You have now configured Group Policy to use a Data Recovery Agent certificate to be used to encrypt all the “Bitlocker to Go” drives in your organisation.

How to unlock a “BitLocker to Go” drive with a Data Recovery Agent

Below are the instructions explaining how to use the Data Recovery Agent to unlock a BitLocker to Go encrypted drive

Step 1. Put the drive into the computer you want to unlock.

Step 2. Right Click on a Command Prompt, and then click Run as administrator. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Yes.

Step 3 (optional). If you want to get information on the volume before you unlock it you can run manage-bde -status E:

Step 4. Now you need to get the “CertificateThumbprint” of the drive you want to unlock type the command manage-bde –protectors –get E: where E: is the volume you are trying to unlock

Note: Take a note of the Data Recovery Agent (Certificate Based) Certificate Thumbprint (see circled in red).

Tip: You could also mark the thumbprint by using the Edit > Mark option of the command prompt.

Then select the thumbprint by clicking on the first character of the thumbprint and dragging to the last character.

Step 4. To unlock the drive, type the following command Manage-bde –unlock E: -cert –ct 88d07b2874031569e17eedf402e0a098fc0f7b81

You have now successfully unlocked the drive using a Data Recovery Agent.

Note: You will need to have the Data Recovery Agent Certificate (with the private key) installed in the Personal certificate store on the computer you are performing this task.

Step 5 (optional). Try getting running the following command again to view more information about the drives encryption manage-bde -status E:

Form more information about BitLocker drive encryption with Data Recovery Agents see the following pages:

Microsoft TechNet: Configuring the BitLocker Identification Field (Windows 7)
Microsoft TechNet: Using a Data Recovery Agent to Recover Bitlocker-Protected Drives
Microsoft TechNet: Using Data Recovery Agents with Bitlocker

One of the cool new feature in Windows 7 Ultimate and Enterprise is the ability to encrypt USB devices with a password to protect the data from falling into the wrong hands. One of the problem with this is that if a user were to ever forget the unlock key then they will need to remember where they kept the recovery file or paper print out of the 48 digit recovery key. Now for a consumer this feature this might be fine as you keep can keep the key in a fire proof safe or even a locked filing cabinet but if you are managing this in a corporate environment you might have to keep track of thousands or even ten’s of thousands of these devices to keep track of the recovery key.

Well there is where group policy can be your saviour…. of course!

In Part 1 of this “how to” I am going to show you how to setup the recovery key archiving into Active Directory. In Part 2 I will show you how to use Group Policy with Active Directory Certificate Services to enable a Data Recovery Agent so that all your devices can be recovery using a single EFS recovery agent account.

Part 1

Using group policy you can mandate that all encrypted removable device must first have the recover key stored in Active Directory before they start to encrypt. This ensures that for any USB encrypted devices in your organisation that you will always have the ability to unlock the data on the drive even in case that someone forgets the unlock password.

Now before we begin there are a few pre-requisites that we need to cover to make sure this work.

1. You Active Directory must be running the Windows Server 2003 R2 scheme extensions. But I hear you say “you said that Group Policy Preferences doesn’t need schema changes to work” well yes… this is still true it is not a group policy requirement it is a BitLocker requirement.

2. You should install the “BitLocker Drive Encryption Administration Utilities” with Windows Server 2008 R2 or with the RSAT tools for Windows 7 (see image 1.) on at least one computer in your organisation. This computer can then be used to search for and view the recovery keys if you ever need them. This is a new tool with 2008 R2/Windows 7 and makes it MUCH easier to read the recovery keys than back in the 2003 R2/Vista days.

Image 1. Installing “BitLocker Drive Encryption Administration Utilities”

How to configured Group Policy to save the Recovery Key?

Now before I go on I will assume that you are already familiar with Group Policy so all I am going to cover is the key (pardon the pun) policies you need to ensure the recovery keys are backed up to AD DS for all your removable USB storage devices in your organisation.

Step 1. Edit the group policy that you have applied to all your workstations and navigate to Computer > Policies > Administrative Templates > Windows Components > BitLocker Drive Encryption > Removable Data Drives. Here the two policies you need to enable are “Deny write access to removable drives not protected by BitLocker” and “Choose how BitLocker-protected Removable drives can be recovered” (see Image 2).

Image 2. Removable Data Drives BitLocker Drive Group Policy

Step 2. When you Enable the “Deny write access to removable drives not protected by BitLocker” also tick the “Do not allow write access to devices configured in another organization” option (see Image 3). This setting is important as it will make any non-BitLocker encrypted devices from being written to in your organisation thus bypassing the whole reason to use BitLocker.

Image 3. Deny write access to removable drives not protected by BitLocker

Step 3. Now Enable the “Choose how BitLocker-protected Removable drives can be recovered” and make sure that the “Save BitLocker recovery information to AD DS for removable data drives” and the “Do not enable BitLocker until recovery information is stored to AD DS for removable data drives” are both ticked (See image 4.). This setting ensures the computer has successfully saved recovery key into AD before encrypting a USB storage device.

Image 4. Choose how BitLocker-protected removable drives can be recovered

You may also want to consider ticking the “Omit recovery option form the BitLocker setup wizard” as this will prevent you users from saving the recovery key manually which might be desirable if you don’t trust them to store the key in a safe place.

Because of the “Do not enable BitLocker until recovery information is stored to AD DS for removable data drives” option has been ticked if the user tries to encrypt a new USB storage device when not connected to the corporate network then they will get the following error message (see image 5).

Image 5. Error saving recovery key

If the user is out of the office they will need to establishing a VPN connection or enable BitLocker on the device the next time they are in the Office. This would not be a problem if you have configured Direct Access but this is a post for another time.

Note: The loop hole to this is that if someone already had a BitLocker to Go encrypted device and plugs it into a computer they will be able to save information to the device. This does not mean the data will not be encrypted its just you wont have the recovery key if they forget the password to that particular device.

To help with this problem you can set the BitLocker identification field on all the computers in the organisation so they will reject all encrypted devices that don’t have the same identification field value. This setting is under Computer > Policies > Administrative Templates > Windows Components > BitLocker Drive Encryption called “Provide the unique identifiers for your organization” (see image 6.). This might sound like you can mandate outside memory sticks can’t be used in your organisation but if someone has set the identification field to the same value this would get around option.

Image 6. Provide the unique identifiers for your organization

How to recover the BitLocker recovery password in AD?

So you have deployed BitLocker to your organisation and you have told everyone to be careful to remember the passwords but of course your manger has come to you saying that they have forgotten the password for his USB memory stick and it has the only copy of some really important files on it that he has have for a meeting tomorrow.

What do you do?

Step 1. First we need to identify the USB devices Recovery key identifier by plugging it into a computer running Windows 7 Ultimate/Enterprise. You can then find this identifier by clicking on the “I forgot my password” option (see image 7.)

Image 7. I forgot my password

Step 2. Then write down the 8 characters of the recovery key identifier (See image 8.)

Image 8. Recovery key identifier

Step 3. Now go to the computer that you installed the “BitLocker Recovery Password Viewer” tool that I previously mentioned above launch “Active Directly Users and Computers” MMC snap-in with and account with Domain Admin privileges. Click on the domain name that will have the recovery key saved and then click “Action” and then “Find BitLocker Recovery Password…” (see image 9.).

Image 9. “Find BitLocker Recovery Password…”

Step 4. Now type the first 8 characters you wrote down in step 2. and click “Search” (See Image 10.). This will show you the Recovery Password in the Details pane that you will need to unlock the drive.

Image 10. Find BitLocker Recovery Password…”

Step 5. Now go back to the computer you have plugged the USB device into and click on “Type the recovery key” (see image 7.).

Step 6. Now type the 48 digit Recovery Password into the text box and click “Next” (see image 11.)

Image 11. Enter your recovery key

Step 7. Click OK and you will now be able to read the required file off this drive (See Image 12.).

Image 12. You cannot save file on this drive

Note: If you want to restore the drive back to normal you will need to go to the control panel and go into the “Manage BitLocker” option to “Turn off BitLocker” (see Image 13.) on the device and then go back and select the option to “Turn On BitLocker” again. This will completely reset the recovery key on the device making the one you just recovered totally invalid.

Image 13. Control Panel BitLocker Drive Encryption option

Part 2 can now be found here “How to configure Group Policy to use Data Recovery Agent to encrypt “Bitlocker to Go” drives – Part 2”

This weeks (and first for the year) Group Policy Setting of the Week is a Group Policy setting that configures Group Policy. The “Group Policy refresh interval for computers” can be found under Computer Configuration > Policies > Administrative Templates > System > Group Policy and is used to control how often the background computer refresh interval of a performed.

By default the refresh will happen every 90 minutes however it has a 30 minute random offset so it could potentially take between 1 to 2 hours for a policy refresh to occur. Keep in mind however that if configured the policy refresh to a shorter interval it will potentially not take affect to all your computers until the longest refresh interval of the last refresh interval setting. Normally this setting it set to a short interval before a major change to group policy setting is made to an SOE so that any rollback of the change can be implemented faster (example see How to use Group Policy Preferences to set change Passwords).

Today on Group Policy Setting of the Week we are going to be taking a look at “Exclude directories in roaming profile” which can be found in the deepest darkest regions of User Configuration > Policies > Administrative Templates > System > User Profiles. This setting is useful in organisations that have Roaming Profiles configured but want to make sure that the roaming profile size does not blow out thus slow doing the users logon and log off or the computer. This option can be used to exclude specific folders of poorly written application from the roaming profile if they write large amounts of data (e.g. caches) to incorrect locations.

A classic example of this was when Google Earth was first released it saved cache files to the users roaming profile folder which meant their profile size quickly swelled to over 1gb. User then quickly started to complain that it took a a long time to logon and logoff their computer (go figure). Enabling this option allowed the specific cached folders to be excluded from their roaming profile and therefore a much smaller roaming profile was copied to and from the server making their login’s and logoffs much quicker. The side affect of this is that the setting saved to the folders you exclude will no longer roam with the user when they logon a new computer.

Very handy if you want to keep roaming profiles to a small size which in turn will speed up the users logon and logoff processes.

This setting will work with Windows 2000 or greater and multiple paths can be appended with a ; as a delimiter between the entries.

This weeks simple Group Policy Setting of the Week (GPSW) is called “Add Logoff to the Start Menu” which can be found under User Configuration > Policies > Administrative Templates > Start Menu and Taskbar. This option adds the “Log Off ” to the users start menu and is normally configured to be enabled on Terminal Servers where you don’t want them accidently shutdown the server.

Now hopefully your normal users don’t have admin access to your Terminal Servers however if you are a Server Administrator then you could have admin access and as such having the shutdown button on a desktop that looks a LOT like you local computer could be very dangerous. So this is one of the few group policy settings that should be configured to loopback that should be applied to the server administrator via a Loopback merge setting (we will talk about Loopback setting another day).

But how do I shutdown the server then I hear you ask? No prob you can either run the “shutdown.exe” command line (tshutdn.exe on Windows 2003) or by CTRL-ALT-END and then shutdown from the secure desktop.

I have selected for this weeks Group Policy Setting of the Week (GPSW) the group policy preferences that is used to configure Power Plans. While configuring power plans for your environment may be nothing new if you have deployed third party tools, you can now avoid the added expense and complexity of doing this as this functionality is now provided out of the box.

This option can be found under User Configuration > Preferences > Control Panel Settings > Power Options and is used to control the individual power plan for your computers. Strangely I have found that this option only works under the User Configuration setting which I presume is the case because it is normally a user configured setting even though the option is under the computer configuration section as well. This power plan option also work with Windows XP however you do need to explicitly select the correct OS power plan as the XP plan will not work on Vista+ and vice versa.

Windows Vista and later Power Plan

Windows XP Power Plan

As you can see this can be used to configured almost all the power plan setting that your version of windows has to offer. One notable omission is the CPU System Cooling Policy setting that was introduced with Windows 7 which is not available to be configured in the Vista (or later) power plan.

Left (Windows 7 System cooling policy) Right (Windows Vista and Later plan without the System cool policy option)

If you are interested in more advanced targeting option with Group Policy Preferences and want to learn how to apply different power plans to computers based on the time of the day check out my previous blog article at http://abskb.spaces.live.com/blog/cns!8834054641A09100!1133.entry

If you have not already got Group Policy Preferences deployed in your organisation then this is definitely the excuse you need to get it deployed. Go to any manager today and say you can start reducing the power consumption of you computer fleet using software they are already licensed and almost always the reaction will be to have it done yesterday.

Notes:

This setting will work on Windows XP or greater if you have the Group Policy Client side extensions installed.
You need to be running the Group Policy Management consol on Windows Vista (Windows 7 recommended) to manage these settings