Group Policy Extensions in Windows Vista and Windows Server 2008, Part 2

If you would like to read the other articles in this series please go to:

• Group Policy Extensions in Windows Vista and Windows Server 2008, Part 1
• Group Policy Extensions in Windows Vista and Windows Server 2008, Part 3
• Group Policy Extensions in Windows Vista and Windows Server 2008, Part 4
• Group Policy Extensions in Windows Vista and Windows Server 2008, Part 5
• Group Policy Extensions in Windows Vista and Windows Server 2008, Part 6
• Group Policy Extensions in Windows Vista and Windows Server 2008, Part 7

In the first part of this article series, I explained that Windows Vista and Windows Server 2008 offer hundreds of additional group policy settings beyond those offered in Windows Server 2003 and Windows XP. In this article, I want to continue the discussion by talking about the group policy settings that are used to control user accounts and hardware devices.

The group policy settings that I will be discussing are all located at Computer Configuration / Windows Settings / Security Settings / Local Policies / Security Options. As you can see in Figure A, there are far too many group policy settings in the Security Options container for me to discuss them all. Therefore, I will limit my discussion to the policy settings that are the most useful or most interesting.

Figure A:
Account related group policy settings are located at Computer Configuration / Windows Settings / Security Settings / Local Policies / Security Options

Administrator Account Status

One of the major security weaknesses of previous Windows operating systems has always been the existence of a local administrator account on workstations. While Windows Vista does make use of a local Administrator account, the Accounts: Administrator Account Status policy setting can be used to disable it.

By default, the administrator account is enabled, but disabling it is simple. All you have to do is set this policy setting to Disabled. Before you start disabling local administrator accounts though, there are some consequences that you need to be aware of. If you have disabled the administrator account, you will not be able to re-enable it again unless the local administrator account’s password meets the minimum password length and complexity requirements. Another administrator can reset the account’s password assuming that such an account exists.

If you find yourself locked out of a machine, and there is no other administrative account that can reset the password, all is not lost. The local Administrator account is always enabled when the machine is running in safe mode. Therefore, you can boot the machine into safe mode, log in as the local administrator, and then reset the password. You should then be able to re-enable the local administrator account.

Limiting the Use of Blank Passwords

Normally, there is no reason why anyone in your organization should ever have a blank password. As a precaution though, the Accounts: Limit Local Account Use of Blank Passwords to Console Logon Only policy setting limits how accounts with blank passwords can be used.

This policy setting, which is enabled by default, makes it so that any user accounts that do not have passwords are only allowed to log in locally. This means that someone could use such an account to log in directly to a PC using a keyboard, but the account could not be used to log in through another mechanism such as Remote Desktop.

Renaming the Administrator Account

For well over a decade, Microsoft has been telling us to rename the Administrator account for security reasons. The problem with doing so is that every workstation has its own administrator account, which has to be manually renamed.

Vista and Server 2008 now offer us a group policy setting which can be used to rename the local administrator account automatically. The name of the policy setting is Accounts: Rename Administrator Account. To use this policy setting, all you have to do is to enter a new name for the administrator account, and the change will be propagated to all of the machines for which the group policy applies.

Auditing Backup and Restore Operations

One of the more interesting group policy settings is the Audit: Audit the Use of Backup and Restore Privilege setting. The basic idea behind this policy setting is that if you choose to enable it (the policy setting is disabled by default) then backup and restore operations are audited.

The reason why I say that this is one of the more interesting policy settings is because it has both its good points and its bad points. This policy is good in that it allows you to verify that the person responsible for backing up the system really is performing backups according to company policy. It also allows you to be aware of any restore operations that have occurred. The bad point of using this policy setting is that it produces a log entry for every file that is backed up. This means that your audit logs could potentially become flooded with log entries related to the backup. Of course some small amount of disk and CPU resources are also used when a log entry is written. By itself, the effects of writing a log entry are nominal. If you are writing hundreds of thousands of log entries at a time though, the log entries could severely impact performance.

Removable Media

In many companies, the use of removable media is simply not allowed. Removable media such as CDs and DVDs allows users to bring unauthorized data or applications into the organizations or to make copies of sensitive data and remove that data from the organization. Since the use of removable media is often discouraged, Microsoft created the Devices: Allowed to Format and Eject Removable Media policy setting. As the name implies, this policy setting can be used to prevent users from formatting or ejecting removable media.

Printer Drivers

Windows is designed in a way that if a user wants to print to a network printer, they do not typically need a CD containing the printer driver, nor do they need to download a driver from the Internet. When a user uses a universal naming convention (UNC) to attach to a printer that is being shared by a Windows machine, the host checks the user’s workstation to see if it has an appropriate driver. If no driver exists, then the printer’s host sends a copy of the printer driver to the machine that just attached to the share.

In most cases, this is probably a desirable behavior, because it allows users to do their jobs without having to contact the help desk every time they need to print to a different printer. In higher security environments though, it might be considered risky to allow users to print to printers that have not been specifically designated to them. One way of preventing users from printing to unauthorized printers is to prevent users from installing print drivers.

You can stop users from installing printer drivers by enabling the Devices: Prevent Users from Installing Printer Drivers policy setting. This policy setting is disabled by default on workstations, but it is enabled by default on servers.

There are a couple of things that you need to keep in mind if you are thinking of enabling this policy setting. First, this policy setting does not prevent users from adding local printers, it only stops users from installing drivers for network printers. Another thing to keep in mind is that enabling this policy will not stop a user from printing to a network printer for which the user already has a driver. Finally, enabling this setting has no effect on administrators.

Conclusion

In this article, I have shown you several group policy settings related to controlling user accounts and hardware devices. In Part 3 I will continue the discussion by showing you more group policy settings that are unique to Windoes Server 2008 and Windows Vista.