Group Policy Central

Microsoft has just released Security Compliance Manager v2.5 beta https://connect.microsoft.com/site715/program2682 along with a heap of new security baseline for you to use to compare against your environment. In case you are not familiar with SCM then it is a great product from Microsoft that consolidates all the best practice for their software with in-depth explanation for each setting.

Notably this new version has security baselines for Exchange Server 2010 and 2007. These baseline are also customised for the specific role of the server. Also interesting is the baseline settings not only include group policy computer settings but also Powershell command to configured aspects of the product that are not as simply to make as a registry key change.

As you can see from the image below the PowerShell script to perform the required configuration is listed in the detail pain…

As yet I can only assume you need to copy the PS command and make you own script for you to run again your exchange server. Still better than nothing… and the software is still beta so we are likely to see more improvements soon… 

Speakers: Tom Cloward and Jeff Sigman

Source http://channel9.msdn.com/Events/TechEd/NorthAmerica/2011/WSV325

If  you were waiting to get your hand on the CTP of Microsoft Security Compliance Manager v2 after I wet your appetite in my previous blog post.  I am happy to report that it is now avaialbe for download and the instructions to download i can be found at http://blogs.technet.com/b/secguide/archive/2011/03/10/scm-v2-ctp-available-to-download.aspx

In case you did miss my previous post about the CTP of MCS v2 two major new features are:

1. Import GPO – Which allows you to import existing GPO Backups in to the SCM v2 tool for analysis.
2. Existing instance of SQL during install – They by not forcing you to install SQL Express to use the tool

For more information see my previous post at http://www.grouppolicy.biz/2011/03/introducing-microsoft-security-compliance-manager-v2/

Back in the days of Windows XP IT administrators could disable the local administrator account on domain joined computers but still be able to use the account if they rebooted the computer into safe mode (see How to access the computer after you disable the administrator account ).

To log on to Windows by using the disabled local Administrator account, start Windows in Safe mode.

However this behaviour has change since Windows Vista (and 7) and now you are no longer able to logon to a computers local administrator account if it is disabled (see Built-in Administrator Account Disabled ).

On domain joined computers, the disabled built-in administrator account cannot logon in safe mode

This presents some challenges as IT administrator as sometime you still need to ability to logon to a computer using the local administrator. The most common scenario you need to do this is when you need to troubleshoot domain account issues (e.g. re-join the computer to the domain) when the AD computer account has been reset or deleted or the password has become out of sync and you get a workstation trust relationship issue (see below).

The problem is that the local administrator account is now disabled and due to the new behaviour of the account you can no longer log with it using safe mode.

The built-in administrator account is disabled by default in Windows Vista on new installations.

This of course makes it almost impossible to configure the computer into a workgroup so that it can then be re-added to the domain to fix the problem. Its even more difficult if you have BitLocker encryption enabled on your local hard drive.

It is possible that you could logon with a user with local administrator access using cached credentials however this is limited to the last 10 people that logged on (increasable to 50 if you change the CachedLogonsCount below registry key).

But even so, this would also mean you have to know the username and password of the account at the time they last logged onto the computer. This may be a bit hard to do as they may have changed their password a number of times since they logged on to that computer.

Unfortunately, it is also much more unlikely now that the normal local user of the computer has not been given local admin due to all the improvement with Windows 7 (e.g. UAC) that allows users to work with standard user permissions.

Now you might think the really obvious solution is to just enable the local administrator account and set a password in advanced using Group Policy Preferences (see below) so that you can use it when you need to however doing this has a few security issues.

However enabling the local administrator account means it can be used by anyone who knows the credentials and they could then use the account to remotely access any workstation on the network (not good). It also mean a normal user that knows the local admin credentials ( we would like to think they don’t but somehow they find out) could us them whenever they are presented with a specify credentials UAC prompt. So it’s pretty much a back door that anyone can use to get around the fact you spent all this time setting up their computers for them to not require local administrator access…

So to get around this issues you could just set the password on a regular basis using Group Policy Preference (see above image) however this also has a few problems as well… While setting the local administrator password is easy to do however it is stored in the SYSVOL as an encrypted string that is fairly easy to crack (see Passwords in Group Policy Preferences ).

A password in a preference item is stored in SYSVOL ….. it is not stored as clear text in the XML source code of the preference item. However, the password is not secured.

To help mitigate this I have also written an article that explain a way to more securely apply the new password to all the computers (see How to use Group Policy Preferences to change account Passwords ) but even if you did this on a regular basis you would still need to tell all the IT support staff what the new password is when you change the password and thus people quickly learn the local admin account credentials all over again…

Note: That all being said it is still a really good idea to set a password for the local administrator account as the default password is configured as blank.

The other solution you might think of is to boot the computer using a third-party tool that can reset and enable the local admin account (see http://www.bing.com/search?q=sethc.exe+%22windows+7%22+administrator+password&form=QBRE&qs=n&sk= ) however these tools don’t work if your local drive is encrypted with BitLocker nor are they supported from Microsoft (see Microsoft policy about lost or forgotten passwords ).

If you want help to break or to reset a password, you can locate and contact a third-party company for this help. You use such third-party products and services at your own risk.

So lets assume you have a computer that is no longer properly connected to the domain with a disabled local administrator account. The computers local system drive is BitLocker encrypted and and you don’t know the credentials of any other accounts that have previously logged on with local administrator permissions… What do you do?

So below I will show you how to enable the local administrator account so that you can at least still logon with the local administrator even if the account has been disabled…

How to enable a disabled local administrator account on a Windows 7 computer with BitLocker enabled

Before you begin you are going to at a minimum know the following information:

• The account name and password of the local administrator account.
• The BitLocker recovery key for the local system drive. (see instruction on how to get the key from here How to use Group Policy to save “BitLocker to Go” recovery keys in Active Directory – Part 1 )

Step 1. Boot the computer using the Windows 7 Installation media

Step 2. When prompted to “Install now” click the “Repair your computer” option at the bottom left.

Step 3 (optional). If your local computer hard drive is BitLocker is encrypted you will now be prompted to type in the recovery key (see below) and just follow the next couple of step that is appropriate for your situation.

Note: You may need to use the Recovery Key Identifier (e.g. A5103515) to find the correct encryption recovery key from Active Directory.

Note2: This step is only required if your local hard drive is encrypted using BitLocker drive encryption.

Step 4. After you have entered the correct recovery and unlocked the drive select the appropriate installation of Windows 7 that you wish to gain access to (You will probably only have one option to select).

Note: Remember the drive letter in the location column as you will need to use this later (Almost definitely going to be “(D:) Local Disk” ).

Step 5. From the System Recovery Options click on “Command Prompt”

Step 6. Now run “regedit” from the command prompt.

Step 7. Click on HKEY_USERS and then click on File > Load Hive

Step 8. Navigate to D:\Windows\System32\Config folder and select the SAM file then click Open

Note: The drive letter you use in the path above is the same as the the drive letter in the Location column in Step 4.

Step 9. Now type “SAM_TEMP” (or any value) in the Key Name text field and click OK

Step 10. Expand SAM_TEMP\SAM\Domains\Account\Users\000001F4 and double click on the “F” key.

Step 11. Change the value “11” in the first column, row 0038 to “10” and click OK

Before	After

Step 12. Click back on “SAM_TEMP” and then from the File > Unload Hive and Yes to confirm.

Step 13. Exit Regedit and close the Command Prompt and click Restart from the System Recovery Option menu

Done…

Summary

You will now be able to logon as the local administrator account by using the account name “.\administrator” and the password of the account (which you should already know). This will enable you to configure the computer into a workgroup and then re-join the computer account back into the domain but without having to resort to enabling a back door administrator account on the all the computers in your environment…

Now you might now be wondering what is the point of security is on Windows 7 (i.e. BitLocker and disabled local admin) if it is so easy to circumvent however you need to remember that for this process to work you still need to know the local administrator password and more importantly you will need to know the unique BitLocker recovery key… Obviously this makes it very important to have BitLocker drive encryption deployed otherwise it will make it very easy to break into pretty much any computer if you have physical access.

the best network software security measures can be rendered useless if you fail to physically protect your systems

I know this is not strictly a Group Policy topic however it is very closely related topic and one I feel that this is still well worth knowing for any IT administrator so you can configured a more secure environment…

Other References

How to configure Group Policy to use Data Recovery Agents with “Bitlocker to Go” drives – Part 2
How to use Group Policy to save “BitLocker to Go” recovery keys in Active Directory – Part 1

Windows Seven Forums: How to Enable the Built-in Administrator Account from WinRE

Update: Microsoft have now released the patch to the .lnk vulnerability MS10-046: Vulnerability in Windows Shell could allow remote code execution . If you have previously deployed the workaround using this article then it is now time to reverse the change you made by simple jumping to Removing the KB2286198 Workaround via Group Policy section and following the instructions. Needless to say this is a particular bad security issue and that you should be deploying this patch to all the computers in your environment ASAP. You have been Warned!!!

There is currently a Microsoft Security Advisory KB2286198 out that affects all copies of Windows about a security issues with displaying icons on shortcuts via non-local drives (e.g. Removable, Network and WebDav folders). The security advisory lists the workaround to the issues that effectively disables displaying all shortcuts. While this is not exactly a prettiest workaround (see image below) it does prevent you from being vulnerable to the security exploit.

There is a Microsoft Fix It for the issues if you just want to apply this workaround to a handful of computers but below I will show how you can apply the same workaround to all your domain computers using Group Policy.

KB2286198 Workaround via Group Policy Instructions

First we are going to create a policy that we can use at a later stage to restore the icon handler. The value that we are

Step 1. Edit a Group Policy Object that applies to all the computers you want to apply the workaround

Step 2. Navigate to Computer Configuration > Preferences > Windows Settings > Registry and in the menu click on Action > New > Registry Item

Step 4. Change the Hive to “HKEY_CLASSES_ROOT” then type “lnkfile\shellex\IconHandler” in the Key Path then tick Default and type “{00021401-0000-0000-C000-000000000046}” in the “Value Data” field and then click OK

We now want to disable this entry as we are going to use to to restore the Icon Handler once you the patch for this issue is out.

Step 5. Click on the IconHandler item in the right hand column and then click  “Disable this item” (Red Circle) in the toolbar.

Now we create the entry that disables the Icon Handler…

Step 6. Right click on the IconHandler registry item you just created and click “Copy”

Step 7. Right click somewhere in the blank in the right column and click “Paste”

Step 8. Click Yes

Step 9. Click on the second IconHandler registry item and click “Enable this item” (Green Circle) in the toolbar.

Step 10. Double click on the second IconHandler registry item and clear the “Value Data” field then click Ok.

Step 11. Now select and copy both IconHandler 1 & 2 and paste them again into a blank area (see step 6,7 & 8).

Step 12. Double click on IconHandler 3 & 4 and change the “lnkfile” in the Key Path to “piffile” (should now look like below image).

Now we are going to disable the WebClient Service that is the second part of this workaround…

Step 13. In the same GPO navigate to Computer Configuration > Preferences > Control Panel Settings > Services and in the menu Action > New > Service

Step 14. Change the Startup value to “Disabled” and type “WebClient” in the Service Name text field then change the Service Action to “Stop Service” and click OK.

Done…

The workaround will now push out to all you workstations and become affective on the next reboot (see image below).

Removing the KB2286198 Workaround via Group Policy

Step 1. In the GPO you set this up in navigate back to Computer Configuration > Preferences > Windows Settings > Registry and delete enabled registry entries (probably the second and fourth) and then click on the remaining two registry entries and click on Enable this item in the toolbar (see image below).

Step 2. In the same GPO navigate to Computer Configuration > Preferences > Control Panel Settings > Services and double click on the WebClient service item and change the Startup to “Manual" and the Service Action to “No change” then click OK.

Hopefully this will keep you secure until Microsoft release a patch for this security issue. As always implement these fixes at your own risk and I make no guarantees that these workaround will necessarily work in your environment.

Further References

• http://securitygarden.blogspot.com/2010/07/fix-it-released-for-security-advisory.html
• http://securitygarden.blogspot.com/2010/08/critical-out-of-band-update-released.html
• http://support.microsoft.com/kb/2286198
• http://www.microsoft.com/technet/security/advisory/2286198.mspx
• http://www.microsoft.com/technet/security/bulletin/ms10-046.mspx