Group Policy Settings

This section is divided into two important parts. The first discusses group policy in general, and the second discusses each setting separately.

General Observations

Every GPO has two main sections:

• Computer Configuration

• User Configuration

Every GPO setting is either set in the Computer Configuration section or the User Configuration section. Settings in the Computer Configuration section can only affect computers. They are applied whenever the computer logs on to the domain (or in the case of some policies, when the computer logs off the domain). User Configuration settings can only affect users. They apply whenever a user logs on to the domain (or with some policies, when the user logs off the domain). At first glance, both sections might appear to be duplicates of each other because they share a lot of the same main category names, but with the exception of Software Installs and a small selection of Administrative Template settings, the settings in one section do not match the settings in the other section. The Computer Configuration section contains more security settings. The User Configuration section contains more desktop/profile settings.

Seeing only these two top-level sections should also remind administrators that, ultimately, group policy can only affect computers or users. Although it may sometimes appear as though a GPO can be applied against a group of computers or users, this is never the case. GPOs must be applied against an OU or container object, and only the computer or user objects contained within are affected.

Main Setting Categories

There are three main setting categories (refer to Figure 14-4):

• Software Settings (for automated software installs and updates)

• Windows Settings (where most OS security settings are made)

• Administrative Templates (for managing applications and components)

Security templates can only be imported into the Computer Configuration Windows Setting\Security Settings object. Administrative templates can be imported into the Administrative Templates category under either Computer Configuration or User Configuration.

Under these three main categories, literally hundreds of choices can be made.

Software Settings

Software can be installed or updated using group policy. Microsoft calls this software publishing. Software can be made available for download and install, with the end user choosing when to install. Conversely, software can be forcibly pushed out and mandated when the computer or user logs in. Software publishing works best with programs with MS installer files (.MSI) but can be used to install other types of files. The client PC must be 2000 or later and have Windows Installer and Application Management services either actively running (Automatic startup mode) or in Manual startup mode. Group policy pushes software installs down, but the Windows Installer service installs it. The Application Management service interacts with group policy to download the software and then hands it off to Windows Installer.

Assigned versus Published

Software installs can be:

• Assigned — to users or computers

• Published — to users only

If assigned to a computer, the software installs when the PC starts up or reboots. If assigned to the user, it installs when the user logs on. These are mandated modes. The user or computer logs on and the software installs. If the software is published to the user, the user can install the software at their leisure, using the Add/Remove Programs applet (custom categories can be installed), or they can make the application install when the associated file type is double-clicked. For instance, suppose a user wants to send out Microsoft Visio diagrams, but not every user has Microsoft Visio installed. The administrator can download Microsoft's free Visio viewer applet and tell Active Directory to install it when a user without the full version of Microsoft Visio opens a Visio diagram for the first time. Administrators can choose Assign or Publish or choose the Advanced option to further customize their selection (see Figure 14-5).

Figure 14-5

Using software publishing you can install the following file types:

• MSI (Microsoft Installer Files)

• MST (Transform Files, installed with MSI files only)

• MSP (Microsoft Patch, becoming less common)

• ZAP (almost any other type of file — for example, Setup.exe)

MSI files install in the security context of the Windows Installer service, Local System. Thus, when using software publishing, programs can be installed and updated without the user being an administrator or Power User. Microsoft Transform files modify programs installed by MSI files. For instance, you can install Microsoft Office as an MSI file and then customize the security settings and menu bars.

ZAP files allow administrators to install non-MSI files. Administrators must create a special ZAP text file telling the GPO what file to install. They can only be published to users, and because the Windows Installer isn't used, the program will install with the security context of the end user (almost guaranteeing that admin permissions will be needed). ZAP files do not support rollback or install on "first use" features. For more information on Zap files, try http://support.microsoft.com/default.aspx?scid=kb;en-us;231747.

It usually takes two or three computer reboots before the software publishing GPO takes effect. It takes one reboot to apply the software publishing policy and at least one second to actually push the software install. Software publishing has more options than I can cover in this chapter, but here are the general steps.

Group Policy Software Publishing Steps

Copy the installation package file (MSI, MSP, or ZAP) and related files to a network share distribution point.

Users or computers must have correct permissions to the network share, the install files, and the GPO that will install the package. Ensure that you select all the files that are to be included in the package over a readable accessible network share and not from a local drive (i.e., C:) when creating the software publishing GPO. Network users will probably not be able to access files stored on local drives without a shared folder.

1. Right-click Software Installation and choose New ð Package ð Package.

2. Choose Assigned, Published, or Advanced.

3. Choose appropriate options on the resulting software publishing dialog boxes; for example:

   1. Auto-install this application by file extension activation allows an application to be installed when the user clicks on a particular file extension (install on demand).

   2. Uninstall this application when it falls out of the scope of management allows most applications (not ZAP installed) to be uninstalled when the user or computer is moved out of the OU to which the software install GPO applies. In order for this to work, the package must have been installed with this option selected in the first place.

   3. Do not display this package in the Add/Remove Programs control panel, if enabled, will not put the software installation package in Add/Remove Programs as is its normal behavior.

   4. Install this application at logon is an option if the package is assigned to a user.

When finished, simply close the software publishing dialog box. Figure 14-6 shows an example install.

Figure 14-6

Group Policy Software Publishing Disadvantages

Unfortunately, software publishing doesn't have a lot of true enterprise management features:

• There is no easy way to stagger installs across the enterprise.

• Bandwidth throttling is not possible.

• There is no reporting available on who did and didn't get the install.

• It requires local admin rights for non-MSI files.

• Many security patches and service packs can't be rolled back.

• It only works with W2K and later.

However, if you don't have another automated software installation tool (such as Microsoft SMS), GPO software publishing is a great way to distribute software quickly. For instance, use software publishing to push out Internet Explorer add-on updates, Sun Java VM updates, and Adobe Acrobat Reader updates. If you can't be assured that end users will consistently update their installed software applications, use GPO software publishing to regain control of your unmanaged software.

GPO Windows Settings

The Windows Settings subcategories include Scripts and Security Settings.

Scripts

Scripts allow an administrator to create shutdown and startup scripts for computers, and logon and logoff scripts for users (see Figure 14-7). It allows scripts, batch files, and command files to be executed when the computer starts up or shuts down, or when the user logs on or off. Any programming and scripting language that the client understands can be used. By default, scripts should be located on the Sysvol share.

Figure 14-7

Security Settings

Most GPO non-administrative template settings are located under Security Settings (see Figure 14-8). Security Settings include the following:

• Account Policies

• Local Polices

• Event Log Settings

• Restricted Groups

• System Services

• Registry Settings

• File System Settings

• Wireless Settings

• Public Key Policies

• Software Restriction Policies

• IPSec Policies

Figure 14-8

Importing Security Templates

Security templates can only be imported by right-clicking Security Settings and choosing Import Policy. You can import several templates, one after another, if you want. If any settings conflict between different templates, the last one imported wins.

Security Settings - Account Policies - Password Policy

This setting controls domain or local password settings. As covered in Chapter 4, setting a secure password policy is among the most significant security defenses. Password policy settings can only be set at the local and domain level. Well, they can be set elsewhere, but the settings won't take effect. If password policy is set at an OU level, it will only impact the local accounts on the computers within that OU, but not the domain accounts. Rumor has it that Windows versions after W2K3 SP1 will change this requirement.

Enforce password history

Determines how many passwords Windows will remember and not let the user re-use. This should be enabled and set to a reasonable value. Most administrators set the value to 20, which is also the default value if this feature is enabled.

Maximum password age

Indicates how many days users can use a password before they must change it (password expiration period). It can be 0 to 999 days; 0 means there is no password expiration interval. This should be set to a reasonable period of time. Environments requiring strong security should set this value to 90 days or less. Setting it too short (e.g., 15 days) is likely to frustrate users and lead to a more insecure password environment (e.g., users writing their passwords down).

Minimum password age

Specifies how long a password must be used before a user can change it. It is used to prevent users from changing their password a whole bunch of times quickly to defeat the Enforce password history setting. It can be 0 to 998 days; 0 means the password can be changed immediately. This value should be set to anything above 0.

Minimum password length

Specifies the minimum password length that will be accepted by Windows or the domain controller. Can be set from 0 to 14. Should be set to 14 in environments requiring strong security, and 8 or above for other environments. Password length is less worrisome if other password defenses have been enabled (e.g., Account Lockout, Auditing, LM password hashes disabled, etc.).

Password must meet complexity requirement

Complexity requirements were covered in Chapter 4. Enabled by default on W2K3 servers. Initial install and a new DCPromo are two times when the password is not forced to be complex even with complexity set.

Store password using reversible encryption for all users in the domain

Can be set on individual accounts in Active Directory Users and Computers. Storing passwords using reversible encryption is essentially the same as storing plaintext versions of the passwords. Disabled by default, this policy should never be enabled unless application requirements outweigh the need to protect password information. This policy is required when using Challenge-Handshake Authentication Protocol (CHAP) authentication through RRAS or Internet Authentication Services (IAS). It is also required when using Digest Authentication in Internet Information Services (IIS).

Security Settings - Account Policies - Account Lockout Policy

Controls account lockout settings. Like password policy, it can only be effectively set at the local and domain level. Recommended settings are covered in Chapter 4.

Account Lockout Duration

Specifies how many minutes an account remains locked out after the Account Lockout Threshold is reached. If set to 0, the account must be unlocked by an administrator. It should be enabled and set to at least 1 minute.

Account Lockout Threshold

Specifies how many invalid logons (without a valid logon) are needed to cause an account to be locked out. Should be set between 3 and 5.

Reset account lockout counter after

Specifies how many minutes invalid logons are tracked in the same threshold counter before resetting the counter to zero. This should be enabled and set to any value.

Security Settings - Account Policies - Kerberos Policy

This controls five Kerberos settings, and can only be set at the domain level. Kerberos Policy does not normally need to be adjusted.

Enforce user logon restrictions

Determines whether the Kerberos server validates every session ticket request only if the user has the Log on locally user right (if the requested Kerberos service is running locally) or the Access this computer from the network user right (if the requested Kerberos service is running remotely). Although enabled, it may slow network access to services. My recommendation is to leave it enabled.

Maximum lifetime for service ticket

Determines the maximum amount of time (in minutes) that a granted session ticket can be used to access a particular Kerberos service. The setting must be greater than 10 minutes, but less than or equal to the setting for Maximum lifetime for user ticket. A decreased time interval will strengthen security. The default is 600 minutes (i.e., 10 hours) and should be left alone unless the administrator has a specific reason to change it.

Maximum lifetime for user ticket

Determines the maximum amount of time (in hours) that a user's ticket-granting ticket (TGT) may be used to request access to Kerberos services without having to re-authenticate and generate another TGT. A decreased time interval will strengthen security. The default setting is 10 hours and should be left as is unless the administrator has a specific reason to change it.

Maximum lifetime for user ticket renewal

Determines the period of time (in days) during which a user's ticket-granting ticket (TGT) may be renewed. A decreased time interval will strengthen security. The default setting is 7 days and should be left as is unless the administrator has a specific reason to change it.

Maximum tolerance for computer clock synchronization

Determines the maximum time difference (in minutes) that Windows Kerberos servers allow between the client's system time and participating Kerberos servers. A decreased time interval will strengthen security. The default setting is 5 minutes and should be left as is unless an administrator has a specific reason to change it.

Security Settings - Local Policies - Audit Policy

These control audit log settings. With few exceptions, they will apply wherever GPO applies.

Audit Account Logon Events

If enabled, all domain logons/authentication events are recorded on the nearest domain controller. This setting has no effect on non-domain controllers.

Audit Account Management

If enabled, this setting tracks creation and manipulation of user and group accounts, including password resets or changes.

Audit Directory Access

If enabled, this setting monitors AD requests on domain controllers only. It can be set per user.

Audit Logon Events

If enabled, logon events are recorded where logon or resource access occurs (i.e., where an object is accessed).

Audit Object Access

If enabled, this will monitor attempted object use (e.g., file, folder, printer, registry entry). It requires that audit permissions be set on the object to be audited. It can be set to monitor particular users or groups.

Audit Policy Change

If enabled, this setting tracks changes to User Rights, Audit policies, or Trust Policies.

Audit Privilege Use

If enabled, this setting tracks usage of User Rights Assignment privileges. It does not track a few privileges (e.g., Backup and Restore privileges) unless the associated User Rights Assignment option is also selected (see below).

Audit Process Tracking

If enabled, this setting audits application processes: starts, stops, and pauses. Turn this on if you are a programmer troubleshooting a program or if you're tracking hackers. Consider enabling on stand-alone domain controllers, which should not be having a lot of process changes.

Audit System Events

If enabled, this setting tracks systemwide events.

The Microsoft Windows Server 2003 Security Guide recommends the audit settings in Table 14-1.

Table 14-1

Computer Environment
Audit Category	Legacy	Enterprise	High Security
Account logon events	Success, Failure	Success, Failure	Success, Failure
Account management	Success, Failure	Success, Failure	Success, Failure
Directory service access	Success, Failure	Success, Failure	Success, Failure
Logon events	Success, Failure	Success, Failure	Success, Failure
Object access	Success, Failure	Success, Failure	Success, Failure
Policy change	Success	Success	Success
Privilege use	No Auditing	Failure	Success, Failure
Process tracking	No Auditing	No Auditing	No Auditing
System events	Success	Success	Success

As stated above, Process tracking should be enabled on stand-alone domain controllers. Also, settings configured under Audit Policy will not affect audit settings configured using Per-User Selective Auditing (new in XP Pro SP2 and Windows Server 2003 SP1).

Security Settings - Local Policies - User Rights Assignment

User Rights Assignments are also known as User Privileges or User Special Privileges. Basically, they allow security principals (users, groups, and computers) to do things they would not otherwise be able to do with NTFS permissions alone. Often, these rights are really meant to be given to service accounts (or less often, computer accounts), and not user accounts.

Every version of Windows comes with default User Rights Assignments given to various users and groups. You can modify membership here. Only security principals defined here can do the particular special privilege. Be careful: If you forget to include existing accounts, System, or Administrator, it is very possible to mess up Windows and/or lock yourself out of functionality of one type or another. This section will discuss the right, give the defaults, and make recommendations. If no recommendation is made, leave the defaults unless you have a specific reason for changing them.

Access this computer from the network

Determines which users and groups are allowed to connect to the computer over the network. This user right is required by a number of network protocols, including server message block (SMB)-based protocols, network basic input/output system (NetBIOS), Common Internet File System (CIFS), Hypertext Transfer Protocol (HTTP), and Component Object Model Plus (COM+). Should be set to Authenticated Users and Administrators, not Everyone, in most environments. Must allow Enterprise Domain Controllers group on Domain Controllers; and add Backup Operators, Everyone, and Pre-Win 2K-compatible groups if they are used. Early versions of OWA required that remote users have this right.

Act as part of the operating system

Allows a process to assume the identity of any user (called impersonation) without additional authentication and thus gain access to local resources that the user is authorized to access. The process can therefore gain access to the same local resources as that user. In Windows, a user never accesses a resource directly. A service (e.g., Windows Explorer) does it on behalf of the user by impersonating them. Impersonation is normal. It is also why the LocalSystem account is often the service account for most Windows services — so it can do things on behalf of all authenticated users.

Processes that require this privilege should use the LocalSystem account, which already includes this privilege. It shouldn't be assigned to any additional account, unless needed. If in a W2K or NT domain, you may need to assign this right to processes that need to exchange authentication passwords in clear text. In W2K3, delegation can be constrained by service, but not in W2K. When this right is given to a process, it is given to the process' service account. Only give this right to very trusted accounts.

Add Workstations to the Domain

Allows members to add/join 10 computers (the number is configurable by a registry setting on the domain controller) to the domain. Only valid if set on a domain controller. By default, all Authenticated Users have this right, which you should only consider granting to the Administrators group. If you want a user to be able to add more than 10 computers, you can do a registry edit to increase the number or allow unlimited additions by giving the user the Create Computer Objects right (in the AD Delegation Wizard).

Computers added to the domain using Add Workstations to the Domain (vs. the Create Computer Objects delegated right) have the Domain Administrators as their owner. W2K has this setting, but by default it does not have any members. NT 4 required that administrators add computer accounts, by default.

Adjust memory quotas for process

Allows a user/programmer to change the memory allocated to a particular program. Normally, you don't need to change this setting unless playing with performance issues. By default, it is granted to Administrators, LocalService, NetworkService, and the IWAM IIS service account. Adjust memory quotas for a process called Increase quotas in W2K.

Allow log on locally

User right that determines which users or groups have the right to log on interactively to a particular computer. On a domain controller, only Administrators and various operator accounts have this right. Make sure the Administrators group always has this right. If you modify the Allow log on locally right, make sure you add the Administrators group so administrators are not locked out.

By default, the following accounts have the Allow log on locally right: On workstations and servers: Administrators, Backup Operators, Power Users, Users, and Guest. On domain controllers: Account Operators, Administrators, Backup Operators, Print Operators, and Server Operators. Allow log on locally is known as Log on locally in some versions of Windows. W2K Terminal Server users must have this right, but W2K3 users don't (they have a separate group).

Allow log on through Terminal Services

Determines which users or groups have the right to log on from a Terminal Services client. Remote Desktop users and Administrators should have this right. By default the following groups have the Allow log on through Terminal Services right: On workstation and servers: Administrators, Remote Desktop Users. On domain controllers: Administrators. Windows 2000 computers must be SP2 or later. If Deny log on through Terminal Services is also selected at the same Active Directory level, the deny right will override.

Back up files and directories

This right is needed and used when an application attempts to access a file or directory using the NTFS file system (NTFS) backup application programming interface (API), as most backup software does. The Back up files and directories right grants the following permissions: Traverse Folder/Execute File, List Folder/Read Data, Read Attributes, Read Extended Attributes, and Read Permissions. This right is needed to install Windows updates that use Update.exe.

Accounts with this right can circumvent normal file and directory permissions to access unauthorized files. It should only be given to Administrators, Backup Operators, and backup service accounts. Use or attempted use of the Back up files and directories right is not automatically tracked if you enable Audit Privileged User under Audit Policy.

Bypass traverse checking

Allows access to files or folders (if the user has correct permissions) regardless of permission restrictions on the parent folder. It's the way Windows works! This privilege does not allow the user to list the contents of a directory, only to traverse the directory tree. Bypass traverse checking default memberships on workstations and servers are Administrators, Backup Operators, Power Users, Users , and Everyone. On domain controllers the default members are Administrators and Authenticated Users. If you remove this right, you "break" Windows in most cases.

Change System Time

Allows Windows' system time to be changed. This right is restricted because a user could accidentally mess up the correct time, which is necessary for Kerberos authentication and might allow malicious intruders to hide their tracks (by placing their current activities "in the past." Default users are Administrators and Server Operators (and Power Users on workstations). Does not allow Time Zone to be changed, which is something many mobile users need when traveling. You can allow non-admin users to change the time zone using a registry edit (see http://support.microsoft.com/default.aspx?scid=kb;en-us;300022).

Create a Pagefile

Allows a security principle to create a virtual memory pagefile or change its size. Normally given to Administrators, it is not normally needed by anyone else.

Create a Token Object

Determines which accounts can be used by processes to create a token that can then be used to get access to any local resources when the process uses an internal API. This user right is used internally by the operating system. Unless it is necessary, do not assign this user right to a user, group, or process other than LocalSystem. You should not assign this to any account that you would not want to take over complete control of the OS.

Create Global Objects

Allows "global objects" (vs. per-user or per-session objects) to be created in Terminal Sessions. Normally given to Administrators and Service. Terminal Services users can still create session-specific objects.

Create permanent shared objects

Allows Active Directory objects to be created. Normally, this right is only needed by programs adding objects or extending the Active Directory schema. LocalSystem has the right be default; it's normally not needed by any other account.

Create Global Objects

Introduced in W2K SP4, a global object can sometimes be something as normal as a graphics file attempting to be inserted into a Word document. This setting should not be modified unless necessary. It is required by some malicious code programs and some remote management programs (e.g., software push programs).

Debug programs

Determines which users can attach a debugger to any process or to the kernel. A very security-sensitive setting to have, it is set to Administrators by default. It's needed for some current and future Microsoft patching (e.g., Update.exe) mechanisms. If removed, it may disable forthcoming hot patching, a new "in-memory" patching technique used by W2K3 that will require less reboots. For information about why debug programs might be needed for patching, see http://support.microsoft.com/default.aspx?scid=kb;en-us;888791.

Deny access to this computer from network

Overrides Access this computer from the network. Usually only the default Support account is listed. Modify as required to secure your environment.

Deny log on as a batch job

Overrides the Log on as batch job right.

Deny log on as a service

Overrides the Log on as a service right.

Deny log on locally

Overrides Allow Log on locally. Normally, it contains the Support account and maybe the SQLDebugger account on SQL servers. Normally, non-admin users cannot log on locally to a domain controller.

Deny log on through Terminal Services

Overrides Allow log on through Terminal Services.

Enable computer and user accounts to be trusted for delegation

Determines which users can set the Trusted for Delegation setting on a user or computer object. A server process running on a computer (or under a user context) that is trusted for delegation can access remote resources on another computer using delegated credentials of a client. Normally, this right is only given to Administrators. This right was created because some trojans and worms (NT Remote Explorer) are programmed to "steal" another user's credentials to access remote resources.

Note 

More information on the NT Remote Explorer malware program can be found at http://securityresponse.symantec.com/avcenter/venc/data/w32.remoteexplore.html.

The user or object that is granted this privilege must have write permissions to the user account or the computer object used in the delegation. All computer accounts, except Domain Controllers, have a Do not trust this computer for delegation flag that is set by default. Domain Controllers have Trust this computer for delegation to any service (Kerberos only) flag that is set by default.

A server process running on a computer (or under a user context) that is trusted for delegation can access remote resources on another computer using delegated credentials of a client, as long as the client account does not have the Account is sensitive and cannot be delegated flag set (which can be set in the Account tab in Active Directory Users and Computers).

Force shutdown from a remote system

Allows users to shut down computers running from a remote location on the network. This is set to Administrators and Server Operators by default.

Generate Security Audits

Determines which accounts can be used by a process to add entries to the security log. Normally given to LocalSystem, LocalService, and NetworkService.

Impersonate a client after authentication

Allows programs that run on behalf of the user to impersonate the user. Normally given to Administrator, Administrators, IIS_WPG, and any service. Added with W2K SP4. When you assign the Impersonate a client after authentication user right to a user, you permit programs that run on behalf of that user to impersonate a client. This security setting helps to prevent unauthorized servers from impersonating clients that connect to it through methods such as remote procedure calls (RPC) or named pipes.

Increase scheduling priority

Determines which users can change a process' scheduling priority of programs and processes in Task Manager. It contains the Administrators group by default.

Load and unload device drivers

Determines which users can load and unload non-Plug-and-Play device drivers. It contains Administrators and Print Operators by default.

Lock pages in memory

Determines who can force programs to remain in physical memory versus being swapped out to a virtual memory page file. Normally only used by knowledgeable developers. No default members.

Log on as batch job

Determines which accounts can log on as a batch job (versus. interactive). When users create a job in Task Scheduler, Windows will give this right to the user account used when scheduling the task. It normally contains LocalService, IIS accounts, the Support account, and maybe SQLDebuggr. Deny log on as batch job will override this right.

Log on as service

Determines which accounts can log on as a service. All "service accounts" must have this right and are assigned it automatically if the account is used on the Service's Logon tab. It allows accounts to be logged on (by the SCM) and be authenticated so the service can start without a user having to log on. It normally contains NetworkService and Administrator. The Deny log on as service right will override this right.

Manage auditing and security log

Allows a user to view and clear the security log and enable object access auditing on individual objects. The right is given to Administrators by default. Non-admin users can view the System and Application logs but not the Security log. This is a separate setting under Security Options, which can be enabled to allow the Guest account to view the Security log.

Modify firmware environment values

Allows a user to modify the Last Known Good setting. It's normally given to Administrators by default. Needed to install or upgrade Windows OS. On Itanium-based computers, boot information is stored in nonvolatile RAM. Users must be assigned the Modify firmware environment values right to run Bootcfg.exe and to change the Default Operating System setting on Startup and Recovery in System Properties. The Modify firmware environment values right is needed for Windows updates that use Update.exe.

Perform volume maintenance tasks

Allows user to use applications that access disk volumes, including the Disk Management, volume shadow copies, and defrag. Normally, only Administrators have this right. Users with the Perform volume maintenance tasks right can explore disks and extend files into memory that contains other data. When the extended files are opened, the user might be able to read and modify the acquired data.

Profile a single process

Determines which users can use Performance Monitor to profile non-system processes. Given to Administrators, Power Users, and LocalSystem.

Profile system performance

Determines which users can use Performance Monitor to profile system processes. Usually given to Administrators and LocalSystem.

Remove computer from docking station

Determines whether a user can undock a portable computer from its docking station without logging on and still have the laptop automatically go into its undocked profile. Administrators normally have this right. Badly described in help files as a physical security measure.

Replace a process level token

Determines which user (really usually a service) accounts can start another (i.e., call) process. Used by Task Scheduler. Given to LocalService, NetworkService, and IWAM accounts.

Restore files and directories

Determines which users can restore backed up objects to which they would otherwise not have permissions. Given to Administrators, Backup Operators, and Server Operators. Does not automatically allow users to access tape logs stored in user profiles (if needed during a restore). The Restore files and directories user right is similar to granting the following permissions to the user or group in question on all files and folders on the system: Traverse Folder/Execute File and Write.

On workstations, the Restore files and directories right is given by default to Administrators, Backup Operators, Power Users, and Users. On servers, it is given to Administrators, Backup Operators, and Power Users. On domain controllers, it is given to Account Operators, Administrators, Backup Operators, Server Operators, and Print Operators. Restore files and directories and Shut down the system rights are needed to install Windows updates that use Update.exe.

Shut down the system

Determines which users logged on locally can use the Shutdown menu option to shut down Windows. Normally given to Administrators, Server Operators, and Print Operators.

Synchronize directory service data

Determines which users have the authority to synchronize all directory service data. The default is none.

Take ownership of files or other objects

Allows members to take ownership of an NFTS-secured object. Normally, only Administrators should have this right. It is needed to install Windows patches using Update.exe.

Security Settings - Local Policies - Security Options

Security Options contains specific security settings that can be enabled locally. It contains more than 60 settings in Windows XP and later, and more are added with every patch and service pack. In XP and later, Security options are preceded by a category setting (e.g., Accounts, Interactive Logon, etc.). There are some minor changes in setting names between XP and W2K3. There were no category names in W2K. The security options shown below are the most relevant options present in W2K3. Unless otherwise noted, leave them at the defaults. Also, be aware of double-negatives (i.e., disabling the disable of an option).

Administrator account status

Allows the local Administrator account to be disabled in XP Pro and later. This option is disabled by default. If the Administrator account is disabled accidentally, it can be re-enabled by logging on in Safe mode.

Guest account status

This option can be enabled but is disabled by default.

Limit local account user of blank passwords to console logon only

Enabled by default. Disables network users from having or using blank passwords. Local users are still allowed to have blank passwords.

Rename administrator account

Disabled by default. Allows the Administrator account to be renamed. As covered in several previous chapters, this should be enabled and the Administrator account renamed to something inconspicuous.

Rename guest account

Disabled by default. Allows the guest account to be renamed. As covered in several previous chapters, this should be enabled and the guest account renamed to something inconspicuous.

Audit the access of global system objects

If Audit the access of global system objects is enabled, it causes system objects, such as mutexes (mutual exclusive), events, semaphores (locking mechanisms used inside resource managers or resource dispensers), and DOS devices to be created with auditing turned on. The access of global system objects is normal, and would generate large security log files if this setting were enabled. It should be disabled or left undefined.

Audit the use of Backup and Restore privilege

Disabled by default. If enabled, it would generate large security log files during a typical backup and restore jobs initiated by normal backup software. This option should be disabled or left undefined.

Shutdown system immediately if unable to log security audit events

Should be left disabled in most environments. If enabled, when the security log reaches its maximum size, it forces the affected system to immediately shut down. No one is allowed to access the system until the administrator logs on locally, clears the security log, and resets a registry entry. This should be enabled in high-security environments where security logs are monitored daily.

Allow undock without having to log on

If enabled, as is its default, it will allow a laptop to go into its Undocked profile without the user having to log on. If Allow undock without having to log on is enabled, logon is not required and an external hard-ware eject button can be used to undock the computer. If disabled, a user must log on and have the Remove computer from docking station privilege to undock the computer.

Allowed to format and eject removable media

Defines who can format and eject NTFS removable media, such as tapes and zip disks.

Prevent users from installing printer drivers

If enabled, non-admin users cannot install network print drivers. Enabled by default on servers and disabled on workstations.

Security Options - Devices

Restrict CD-ROM access to locally logged-on user only

Disabled by default. When enabled, it disallows any user from accessing the CD-ROM drive remotely. On the Restrict options, if a local user is accessing the CD-ROM, remote network access is temporarily disabled for the duration of the local access, regardless of settings.

Restrict floppy access to locally logged-on user only

Disabled by default. When enabled, it disallows any user from accessing the floppy drive and its media remotely. On the Restrict options, if a local user is accessing the floppy drive, remote network access is temporarily disabled for the duration of the local access, regardless of settings.

Unsigned driver installation behavior

Determines how drivers not tested and signed by Microsoft as compatible are handled. By default, it's set to Warn but allow installation prior to Windows Vista. Can also be set to Do not allow installation or Silently succeed. Unfortunately, many valid drivers are not signed by Microsoft. However, a very high percentage of system crashes are caused by unsigned drivers. Starting with Windows Vista (and already in Datacenter editions of W2K3), unsigned drivers are not allowed by default.

Allow server operators to schedule tasks

Determines whether server operators can use the legacy At.exe command to schedule batch jobs. Not defined (i.e., doesn't allow) by default.

LDAP server signing requirements

Describes whether the client must have signed LDAP requests to interact with the server (LDAP signing requires W2K servers with SP4 or later). There are two options:

• None — Not required, but if the client wants to, the server can

• Required — The LDAP client must use signed LDAP requests

On the face of it, requiring authenticated LDAP to interact with the server is a good thing; unfortunately, unless all participating clients and domain controllers have this setting enabled, proceed with caution.

Refuse machine account password changes

Disabled by default. If enabled, computers trying to change their computer account password (normally done every 30 days without end user involvement) will be prevented by the domain controller from doing so. There are few reasons to enable, but it might be required if a PC has a dual-booting system with NT on one partition and W2K or later on another. See Microsoft KB article #154501 for more details on why you might not want automatic machine password changes to occur.

Domain member: Digitally encrypt or sign secure channel data (always)

Domain member: Digitally encrypt secure channel data (when possible)

Domain member: Digitally sign secure channel data (when possible)

Determines whether all secure channel traffic initiated by the domain member computer must be signed or encrypted. If enabled, computers will not be able to join NT 4 domains. When a computer joins a domain, a computer account and computer account password are created. After that, whenever the system starts, it uses the computer account and password to create a secure channel with a domain controller for its domain. The secure channel is used to perform operations such as service or user logon authentication, NTLM pass-through authentication, LSA SID\Name Lookup, etc. If a system is set to always encrypt or sign secure channel data, it cannot establish a secure channel with a domain controller that is not capable of signing or encrypting all secure channel traffic (i.e., NT), because all secure channel data is signed and encrypted.

Disable machine account password changes

If enabled, prevents computers from even attempting to make computer account password changes. Disabled by default.

Maximum machine account password age

Windows will change the machine account password, which is long and complex already, every 30 days by default.

Require strong (Windows 2000 or later) session key

Disabled by default. If enabled, member computers and domain controllers require strong (128-bit) cryptographic keys to establish a secure channel, versus weaker 64-bit keys used in NT. If enabled, NT and earlier clients will not be able to authenticate to the domain controller.

Do not display last user name

If enabled, the last user account name that logged on to the computer is not displayed in the Windows logon screen. Disabled by default. Should be enabled in high-security or shared computer environments.

Do not require CTRL+ALT+DEL

If enabled, users still have to log on, but they do not have to press the Ctrl+Alt+Del keys to initiate the logon sequence. Disabled by default.

Message text for users attempting to logon

Warning text message for interactive users attempting to log on. Disabled by default. Should be enabled with a legally approved message warning unauthorized users against access, or warning authorized users against unauthorized actions. If enabled, also defeats most automated brute-force password-cracking tools.

Windows XP and the Windows Server 2003 family add support for configuring logon banners that can exceed 512 characters in length and that can contain carriage-return line-feed sequences. However, Windows 2000 clients cannot interpret and display message text that is created by computers running Windows XP or the Windows Server 2003 family. You must use a Windows 2000 computer to create a logon message policy that applies to Windows 2000 computers.

Message title for users attempting to logon

Related to the previous setting. Creates dialog box title bar text surrounding logon message text. Disabled by default, but should be enabled as discussed in the previous setting.

Number of previous logons to cache (in case domain controller is not available)

Determines whether a user using a domain user account can log on to the domain using cached account information when a domain controller is not available. The number value refers to how many separate user profiles can be cached at one time, not how many times an individual user will be allowed to log on. If enabled, allowed users can log on an indefinite number of times without having to contact a domain controller. Often used for roaming laptop users. The default is 10. Set to 0 to disable logon caching.

Users must have made at least one successful logon involving a domain controller in their home domain after the setting was enabled for it to take effect. When enabled, even when a user logs on normally and the domain controller is reachable, the cached credentials are used first to speed up network logons. If enabled, it could cause GPO and security permission problems because cached credentials are used first. There are password-cracking tools that can extract cached credentials from logon caches (if they have local admin access). Recommended setting is 0 for local users and 2–3 for roaming laptop users (i.e., Administrator plus one or two other profiles).

Prompt user to change password before expiration

Determines how far in advance (in days) users are warned that their password is about to expire. The default is 14 days.

Require Domain Controller authentication to unlock workstation

Determines whether or not a domain controller is required to unlock a locked workstation, or whether cached credentials will work. Default is disabled. Should be enabled to prevent timing issues and other types of hacks involving locked screen savers.

Require a smart card

Determines whether or not a smart card is required for an interactive logon. Requires use of a smart card and PKI infrastructure. Can be set per user in Active Directory Users and Computers. Should be enabled on administrator accounts in high-risk environments.

Smart card removal behavior

Determines what happens when the smart card for a logged on user is removed from the smart card reader. Setting this option to Lock Workstation locks the workstation when the smart card is removed. Setting this option to Force Logoff automatically logs the user off when the smart card is removed. Supported in W2K and later, although this setting cannot be viewed locally on W2K machines.

Security Options - Microsoft Network Client

Windows NT 4.0 SP3 and later (and fully patched Win 9x) computers can digitally sign SMB traffic. Other than the offsetting decrease in performance (up to 15% in some networks), signed SMB traffic is a good thing. It prevents NetBIOS man-in-the-middle attacks. Windows 2000 and 2003 domain controllers require it, dropping all non-signed SMB traffic. However, SMB signing is optional (although often enabled) on all current Windows computers. By default they can participate in SMB signing, but are not required unless connecting to a domain controller.

In most cases, workstations and member servers are configured to digitally sign SMB traffic if the other partner agrees. Because most Windows OSs have this setting enabled, they will communicate with each other using signed traffic by default. Mark Minasi (www.minasi.com) has the best discussion on this topic in his April 2005 Newsletter #46. The default options configured by Microsoft are usually adequate. Essentially, this means older Windows clients will not be able to establish NetBIOS connections to Windows 2000 and 2003 domain controllers.

Note 

When reviewing the following settings, "server" does not mean a server-based edition of the operating system. It means the computer acting as a server, hosting shared resources that other remote computers want to access.

Digitally sign communications (always)

Disabled by default on non-domain controllers. If enabled, it requires signed SMB communications to the server.

Digitally sign communications (if server agrees)

Negotiates with the server to see if SMB signing should be enabled. Enabled by default. If the Digitally sign communications (always) setting is enabled, the Microsoft network client will not communicate with a Microsoft network server unless that server agrees to perform SMB packet signing. If this policy is disabled, SMB packet signing is negotiated between the client and server.

Digitally sign communications (always)

If enabled, requires signed SMB communications from all clients. Enabled by default for DCs, disabled for member servers. If enabled, participating computers cannot join an NT 4 domain.

Digitally sign communications (if client agrees)

Negotiates with the server to see if SMB signing should be enabled. Enabled by default on DCs.

Because the second option is also selected by default, clients do not have to digitally sign SMB communications if they don't want to. The second option overrides the first. NT 4.0 machines will need SP3 and later; Win95 clients needed the Directory Services client. If enabled, copying files and mapping drives between computers takes longer.

Send unencrypted password to third-party SMB servers

Prevents man-in-the-middle (MitM) attacks that modify SMB packets in transit; the SMB protocol supports the digital signing of SMB packets. If this setting is enabled, it instructs Windows to send plaintext passwords to Samba and other third-party SMB services. This policy setting determines whether SMB packet signing must be negotiated before further communication with an SMB server is permitted.

Amount of idle time required before suspending session

Determines how long an idle SMB connection can be idle before being suspended. Set to 15 minutes for servers, not enabled for workstations. When a connection becomes active again, service usually just re-authenticates transparently to the user.

Disconnect clients when logon hours expire

By default, when clients exceed allowed logon hours (as dictated in their User Account tab), they are still allowed to remain connected.

Allow anonymous SID/Name translation

Determines whether or not an anonymous connection can enumerate a user account for its SID. Enabled and required for DCs, disabled for other W2K3 and XP machines. Leave at the defaults.

Do not allow anonymous enumeration of SAM accounts

Determines if an anonymous connection can retrieve the list of local (or domain if stored on an NT domain controller) user and computer accounts. Disabled on servers, enabled on workstations. Leave at the defaults. If the Do not allow anonymous enumeration of SAM accounts setting is enabled, it will be impossible to establish down-level trusts to NT 4.0 domains.

Do not allow anonymous enumeration of SAM accounts and Shares

Determines whether anonymous connections can enumerate SAM accounts or shares. Disabled by default. Authenticated users can always do these things. If anonymous SID translation is disabled, many NT 4.0 services will fail. Anonymous enumeration of SAM settings has no effect on DCs.

Security Options - Network Access

Do not allow storage of credentials or .NET Passports for network authentication

Determines whether XP's new Stored User Names and Passwords application will save passwords, credentials, or Microsoft .NET Passports for later use after gaining domain authentication or other participating applications. This setting is disabled by default. Stored User Names and Passwords is not used by many applications. If a hacker has local admin access, they can recover the names and passwords stored in this application. This setting should be enabled in most environments.

Let Everyone permissions apply to anonymous users

Allows anonymous connections to get the same security permissions and rights as the Everyone group (as was allowed prior to W2K3). This was a huge security hole, now closed by default unless you enable this setting. Note: If you disable Let Everyone permissions apply to anonymous users, domains with this setting will be unable to establish or maintain trusts with Windows NT 4.0 domains.

Named Pipes that can be accessed anonymously

Remotely accessible registry paths

Remotely accessible registry paths and sub-paths

Restrict anonymous access to Named Pipes and Shares

Shares that can be accessed anonymously

Defines what Named Pipes (an authentication type) and registry paths are accessible to all users (regard-less of ACLs) or anonymous connections. Most Windows versions have default entries in these locations.

Leave at the defaults unless you need a highly secured machine. Removing default entries can break some remote management agents (e.g., patch management software, etc.). These settings are named slightly differently in various Windows versions.

Sharing and security model for local accounts

This option has two settings:

• Classic — local users authenticate with the logon accounts

• Guest only — local users always authenticate as guest

If all users authenticate as guest, their profiles are never saved. Guest only means that all permissions to a resource are either Read only or Modify. XP Home only has Guest model. XP Pro switches from Guest to Classic mode when it is connected to a domain. Should be set to Classic mode. This policy will have no impact on computers running Windows 2000.

Do not store LAN Manager hash value on next password change

LM hashes are very weak and subject to easy attack. By default, all Windows computers store account passwords in LM hash form. The default setting is disabled, but you should enable this setting and make all passwords expire so that users are forced to change their password. You can also instruct users to use passwords longer than 15 characters to manually disable LM hash storage.

Force logoff when logon hours expire

Forces graceful logoff when logon hours expire (versus abrupt disconnection). Disabled by default, but can be enabled when desired.

LAN Manager authentication level

Can be set to allow or reject the following: LM, NTLM, NTLM2 requests or responses. LM and NTLM are legacy authentication protocols, vulnerable to cracking. Whenever possible, you want to refuse to respond to or send LM and NTLM authentication. Test thoroughly first. NT 4.0 must be SP 4 or later. Windows 9x clients must have the Directory Services client installed.

LDAP Signing Requirements

Defines wither the client is required to sign LDAP requests before sending to DC. Settings are None, Negotiate, or Require. The default is Negotiate. W2K3 requires LDAP signing if the client is using Windows Server 2003 Administrative Pack tools.

Network security: Minimum session security for NTLM SSP based (including secure RPC) clients

Network security: Minimum session security for NTLM SSP based (including secure RPC) servers

You can pick and choose requirements, if any. Options include the following:

• Require message integrity

• Require message confidentiality

• Require NTLMv2 session security

• Require 128-bit encryption

• None

None is set by default.

Security Options - Recovery Console

Allow automatic administrative logon

If enabled, no password is required for use of the Recovery console program. Disabled by default in XP and W2K3; enabled in early versions of W2K.

Allow floppy copy and access to all drivers and folders

Determines whether a Recovery console logon session can access all Windows system drivers and folders. Disabled by default.

Security Options - Shutdown

Allow system to be shut down without having to log on

Enabled on workstations; disabled on servers. Users must have Shutdown the system right also to be able to shut down a system without logging on.

Clear virtual memory pagefile

If enabled (default is disabled), Windows will erase the page file when shutting down. Significantly decreases performance during shutdown. Will zero out the Hibernation file (hyperfil.sys) when hibernation is disabled, too.

Security Options - System Cryptography

Force strong key protection for user keys stored on the computer

This security setting determines if users' private keys require a password to be used. Can be prompted when using a personal digital certificate. The options are as follows:

• User input is not required when new keys are stored and used

• User is prompted when the key is first used (user is only allowed to click on OK warning box)

• User must enter a password each time they use a key

Use FIPS compliant algorithms for encryption, hashing, and signing

This was discussed in Chapter 13 in more detail. To recap, when enabled, it supports the Transport Layer Security (TLS) protocol as a client and as a server (if applicable) instead of SSL on web servers. Uses only the Triple DES encryption algorithm for the TLS traffic encryption. Uses only the RSA public key algorithm for the TLS key exchange and authentication. Uses only SHA-1 for the TLS hashing requirements. Uses only 3DES for EFS, instead of AES. Uses only 3DES for Terminal Server encryption. FIPS-compliant software is often a requirement of government users.

Security Options - System Objects

Default owner for objects created by members of the Administrators group

By default, when a member of the Administrators group creates an object, ownership is given to the Administrators group, not the individual administrator. This prevents ownership problems if the individual user account is deleted. This option can be enabled and changed to the account that actually created the object, instead.

Require insensitivity for non-Windows subsystems

Determines whether case insensitivity is enforced for all subsystems. Windows supports many different subsystems (e.g., Win32, Posix, etc.). The Win32 subsystem is case insensitive. However, the kernel supports case sensitivity for other subsystems, such as POSIX.

Strengthen default permissions of internal system objects (e.g., Symbolic Links)

If this policy is enabled, as is the default, users who are not administrators can read shared objects but cannot modify shared objects that they did not create.

Security Options - System Settings

Optional subsystems

Windows supports many different subsystems (e.g., Win32, POSIX, OS/2, etc.). You can specify Posix. OS/2 is no longer available as a default option.

Use Certificate Rules on Windows Executables for Software Restriction Policies

Must be enabled for Certificate rules in Software Restriction Policies to work.

Event Log Settings

Configures Event Log settings, such as maximum size and retention method (see Figure 14-9).

Figure 14-9

Restricted Group Settings

These will enforce group membership, adding and removing users to meet what is set in the Restricted Group setting. This is an excellent GPO setting. You should add any highly privileged administrative group (see Figure 14-10). Then, using the browsing feature (see Figure 14-11), manually select all the users who should belong to a particular group. If anyone adds or deletes a user into those groups outside of the Restricted Group setting, the original members will be restored shortly. This feature is great for preventing "admin creep" whereby various users are accidentally added as administrators during troubleshooting events and then forgotten about. It can also be used to keep highly unprivileged users in restricted permissions groups (as discovered in Chapters 3 and 5).

Figure 14-10

Figure 14-11

Note 

You should always browse to select groups or members in the Restricted Groups feature. This causes the SID of the object to be stored, versus the user's name (which could change).

System Services Settings

Another awesome feature of group policy, administrators can define what services are allowed to run on managed machines. The service's Startup mode (i.e., Automatic, Manual, or Disabled) can be defined, along with who has what permissions (see Figure 14-12). This feature was covered in Chapter 7 in more detail. In order to see a particular service to edit in a GPO, the service must be installed and running on the machine on which GPO is being edited. It prevents high-risk services from running on authorized machines. For example, prevent the World Wide Web service from running on computers that don't need IIS. Prevent the Windows Messenger from running on computers not needing its services.

Figure 14-12

Registry Settings

An administrator can define the permissions on existing registry keys (see Figure 14-13). This feature was also covered in Chapter 6. Default GPO settings only allow you to set or change registry permissions, but do not allow registry entries to be modified. A customized Security or Administrative template must be created to modify a custom registry entry value. In order to see a particular registry key permission to edit in a GPO, the registry key must be installed and running on the machine on which the GPO is being edited. Prevent non-admin users from being able to edit or modify high-risk registry keys, as covered in Chapter 6.

Figure 14-13

File System Settings

An administrator can define the NTFS permissions on existing files and folders (see Figure 14-14). This feature was also covered in Chapter 5. Default GPO settings only allow you to set or change NTFS file or folder permissions, but do not allow files or folders to be created or deleted. A customized Security or Administrative template must be created to modify permissions on a non-existent file or folder. In order to see a particular file or folder permission to edit in a GPO, the file or folder must be on the machine on which the GPO is being edited. Prevent non-admin users from being able to execute high-risk files, as covered in Chapter 5.

Figure 14-14

Software Restriction Policies

Administrators can set or modify software restriction policies. This feature was covered in detail in Chapter 9.

IP Security Policies

Administrators can set or modify IPSec policies. This feature was covered in detail in Chapter 8.

Administrative Templates

The Administrative Templates area of GPOs allows managed software to be configured and controlled. Administrative templates expose and manipulate registry settings. Each version of Windows comes with hundreds of Administrative template settings, and each service pack adds more. XP SP2 and W2K3 come with over 1,300 template settings. The default adm files shipped with Windows are located in %Windir%\Inf. Most deal with configuring Windows default applications, and many other Microsoft products come with Administrative templates.

Default Windows Administrative Templates

Default Windows Administrative Templates are as follows:

• System.adm — Configures OS

• Inetres.adm — Configures IE

• Wuau.adm — Configures Windows Update

• Wmplayer.adm — Windows Media Player

• Conf.adm — Configures NetMeeting

These five default templates are shipped with Windows 2000 SP2 and XP SP1 and later. Wuau (Windows Update) wasn't introduced until those particular versions of 2000 and XP. Wmplayer.adm was called wmp.adm in Windows 2000 and 2000 SP1. System.adm contains the most settings. XP SP2 significantly upgraded the System.adm, Inetres.adm, and Wuau.adm templates.

Note 

The various Administrative templates, their default settings, and this book's recommendations can be found at www.wrox.com.

Other Built-in Windows Administrative Templates

Other Built-in Windows Administrative templates (not always installed by default) are as follows:

• Common.adm — Common settings for Win9x/NT

• Windows.adm — Settings specific for Win 9x

• Inetcorp.adm — Configures miscellaneous IE settings

• Inetset.adm — Configures other miscellaneous IE settings

• Inetesc.adm — Configures W2K3's IE Enhanced Security Configuration feature. Enabled on W2K3 domain controllers by default.

Common.adm and Windows.adm are policy files meant to be used in NT or 9x systems using System Policy Editor (poledit.exe), because those systems don't understand GPOs.

Loading Administrative Templates into GPOs

New Administrative templates can be imported into both Computer and User-based GPOs, and into Local Computer Policy. Templates must be added to each GPO you want them to be accessible in. When added to a GPO, the template and its settings are uploaded to the GPO on the DC's Sysvol. New Administrative templates can be loaded into a GPO by using the following steps:

1. Open the Group Policy Object Editor or GPMC.

2. Under either Computer Configuration or User Configuration, right-click Administrative Templates, and then click Add/Remove Templates.

3. In the Add/Remove Templates dialog box, click Add.

4. Navigate to the folder containing the .adm file that you would like to add. Select the template, and then click Open.

Microsoft Office 2003 Admin Templates

Microsoft releases custom Admin templates with many of its products, including Microsoft Office. Here is a list of the Microsoft Office 2003 Administrative templates:

• Access11.adm — Access 2003

• Excel11.adm — Excel 2003

• Fp11.adm — FrontPage 2003

• Gal11.adm — Microsoft Clip Organizer

• Inf11.adm — Microsoft InfoPath 2003

• Instalr11.adm — Microsoft Windows Installer

• Office11.adm — Office 2003 common settings

• Outlk11.adm — Outlook 2003

• Ppt11.adm — PowerPoint 2003

• Pub11.adm — Publisher 2003

• Word11.adm — Word 2003

These Office templates contain hundreds of configurable settings that control Microsoft Office settings. You can download these templates from the Office 2003 Resource Kit (http://office.microsoft.com/en-us/FX011417911033.aspx).

Custom Administrative Templates

Any third-party vendor or administrator can create custom Administrative templates to manage their product. Although the default Administrative or Security templates have dozens to hundreds of settings, sometimes they don't have exactly what you need. In those cases, you can "roll your own."

Creating a Custom Administrative Template

Custom Administrative templates can be created one of three ways:

• Modify an existing template

• Use an existing template as a starting point

• Create a new template

Administrative templates are Unicode text files, with their own proprietary format, and they require special formatting and syntax. If at all possible, find an existing template that is close to what you want to achieve and modify it to meet your new needs. Don't modify default Administrative templates shipped by Microsoft, as they may be modified or overwritten by future updates. Use these steps:

1. Understand the registry, and the problems you can create for yourself if something goes wrong.

2. Document the registry settings needed for the template.

3. Create the admin template.

4. Save to %windir%\Inf.

5. Import into a test GPO.

6. Test, test, test.

7. Release to production.

Here are some links for Administrative template creation and troubleshooting:

• http://support.microsoft.com/kb/887303

• http://support.microsoft.com/kb/221833

• http://support.microsoft.com/kb/216358

• http://support.microsoft.com/kb/250842

• www.gpanswers.com

• www.gpoguy.com/FAQs/troublefaq.htm

GPO Notes/Recommendations

Here are some GPO and Administrative template notes and recommendations:

• Start small and test before deploying.

• Don't create a policy for every setting and application in your environment.

• Focus on the most critical settings first.

• In the GPO or template name, use a verb that reflects the policy's overall setting (e.g., Allow, Permit, Turn on, Force, Deny, Prohibit, Disable, Turn off, etc.).

• In the GPO or template name, use a version number (e.g., Force Corporate Screensaver_1.1) to help keep track of what versions are installed where.

• Never modify default templates; copy to a new name, and then modify.

• Create smaller, more granular policy settings instead of one larger policy.

• Make custom templates on computers with installed software or services.

• Create and/or deploy custom templates on the same administrative workstations.

• Removing an Admin template does not remove the admin template registry settings!

• If you plan to remove an admin template:

  • Modify the settings to be what you want the registry values to be after you remove the template.

  • Let new changes replicate.

  • Remove the admin template.

• Remember: admin templates are stored locally on the computer that edits or modifies them; then they are copied up to the DC's Sysvol.

• If you modify templates from several different computers, this can potentially cause unwanted "co-mingling" of old and new templates.

• Just because you modify an application or setting doesn't mean the related application will prevent users from making changes, or report the current correct setting.

• Normally, there is no harm in applying an admin template or GPO setting to a computer that it "doesn't belong on" (i.e., Office templates to a computer without Microsoft Office installed).