Local Policy Settings

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

Local Policies

In this section

• Audit Policy

• User Rights Assignment

• Security Options

These policy settings apply to a computer and contain these subsets:

• Audit policy. Determines whether security events are written to the security log in Event Viewer on the computer. Also determines whether to log successful attempts, failed attempts, or both.

• User rights assignment. Determines which users or groups have logon rights or privileges on the computer.

• Security options. Enables or disables security policy settings for the computer, such as digital signing of data, Administrator and Guest account names, floppy disk drive and CD drive access, driver installation, and logon prompts.

Because a computer can have more than one policy setting applied to it, security policy settings can conflict with each other. The order of precedence from highest to lowest is: OU, domain, and local computer.

Audit Policy

An audit log records an entry whenever users perform certain actions that you specify. For example, the modification of a file or policy setting can trigger an audit entry. The audit entry shows the action performed, the associated user account, and the date and time of the action. You can audit both successful and failed attempts at actions.

The state of the operating system and applications on a computer is dynamic. For example, an administrator might need to change security levels temporarily to resolve an administrative or network issue, but all too often, such changes are forgotten about and never undone. In a case like this, the computer might no longer meet the requirements for enterprise security.

Regular analysis enables an administrator to track and ensure an adequate level of security on each computer as part of an enterprise risk-management program. Analysis focuses on highly specific information about all system aspects related to security. This enables an administrator to tune the security levels and—most importantly—detect any security flaws that might occur in the system over time.

Security auditing is extremely important for any enterprise system, because audit logs sometimes give the only indication that a security breach has occurred. If the breach is discovered some other way, proper audit policy settings generate an audit log that contains important information about the breach.

Often, failure logs are much more informative than success logs, because failures typically indicate an error. For example, if a user successfully logs on to the system, this is considered normal. However, if a user unsuccessfully tries to log on to the system multiple times, it can indicate that someone is trying to break into the system by using someone else's user ID.

All computers in your organization should have sensible auditing policy settings so that legitimate users can be held accountable for their actions and unauthorized activity can be detected and tracked. If no auditing is configured, or if the auditing is set too low on the computers in your organization, you will not have sufficient evidence to analyze after security incidents take place. On the other hand, if too much auditing is enabled, the security log will fill up with meaningless entries. The Audit Policy settings can be configured in the following location in Group Policy Object Editor:

Computer Configuration\Windows Settings\Security Settings\Local Policies\Audit Policy

Audit account logon events

The Audit account logon events policy setting determines whether to audit each instance of a user logging on to or logging off from another computer, in which the computer recording the audit event is used to validate the account. If you configure this policy setting, you can specify whether to audit successful logons, audit failed logons, or not audit logon events at all.

The possible values for this Group Policy setting are:

• Success.

• Failure.

• No auditing.

Discussion

If Audit account logon events is set to Success, an audit entry is recorded in the security log whenever an account logon attempt succeeds. This can be useful information for accounting purposes and for post-incident forensics when you want to determine who successfully logged on to which computer. If Audit account logon events is set to Failure, an audit entry is recorded whenever an account logon attempt fails. This can be useful for intrusion detection, but this setting can also leave your enterprise vulnerable to a denial-of-service condition, because a malicious user could generate millions of logon failures and fill your security log.

If the value of this policy setting on a domain controller is Success, an entry is recorded for each user who is validated against that domain controller, even though the user is actually logging on to a workstation that is joined to the domain.

Location

GPO_name\Computer Configuration\Windows Settings\Security Settings\Local Policies\Audit Policy\

Default Values

Server Type or GPO	Default Value
Default Domain Policy	Not defined
Default Domain Controller Policy	Success
Stand-Alone Server Default Settings	Success
DC Effective Default Settings	Success
Member Server Effective Default Settings	Success

Audit account management

The Audit account management policy setting determines whether to audit each event of account management on a computer.

The possible values for this Group Policy setting are:

• Success.

• Failure.

• No auditing.

Discussion

Examples of account management events include the following:

• A user account or group is created, changed, or deleted.

• A user account is renamed, disabled, or enabled.

• A password is set or changed.

If you configure this policy setting, you can specify whether to audit successes, audit failures, or not audit account management events at all. When you set the value of Audit account management to Success, an audit entry is generated when any account management event succeeds. It is advisable to set the value to Success on all computers in your enterprise. To respond to security incidents, it is critical that organizations be able to track who created, changed, or deleted an account. When the value is set to Failure, an audit entry is generated when any account management event fails.

Location

GPO_name\Computer Configuration\Windows Settings\Security Settings\Local Policies\Audit Policy\

Default Values

Server Type or GPO	Default Value
Default Domain Policy	Not defined
Default Domain Controller Policy	Success
Stand-Alone Server Default Settings	No auditing
DC Effective Default Settings	Success
Member Server Effective Default Settings	No auditing

Audit directory service access

The Audit directory service access policy setting determines whether to audit the event of a user accessing an Active Directory object that has specified its own system access control list (SACL). An SACL is a list of users and groups for which actions on an object are to be audited on a Windows 2000–based network. If you configure this policy setting, you can specify whether to audit successes, audit failures, or not audit directory service access at all. Success audits generate an audit entry when a user successfully accesses an Active Directory object that has an SACL specified. Failure audits generate an audit entry when a user unsuccessfully attempts to access an Active Directory object that has a SACL specified.

The possible values for this Group Policy setting are:

• Success.

• Failure.

• No auditing.

Discussion

Auditing directory service access and configuring SACLs on directory objects can generate a large volume of entries in the security logs on domain controllers. You should only configure these policy settings if you actually intend to use the information.

Note that you can set an SACL on an object in Active Directory by using the Security tab in that object's properties. This is analogous to the Audit object access policy setting, except that it applies only to Active Directory objects and not to file system and registry objects.

Location

GPO_name\Computer Configuration\Windows Settings\Security Settings\Local Policies\Audit Policy\

Default Values

Server Type or GPO	Default Value
Default Domain Policy	Not defined
Default Domain Controller Policy	Success
Stand-Alone Server Default Settings	No auditing
DC Effective Default Settings	Success
Member Server Effective Default Settings	No auditing

Audit logon events

The Audit logon events policy setting determines whether to audit each instance of a user logging on to, logging off from, or making a network connection to the computer that is recording the audit event.

The possible values for this Group Policy setting are:

• Success.

• Failure.

• No auditing.

Discussion

If you are logging successful account logon audit events on a domain controller, workstation logon attempts do not generate logon audits. Only interactive and network logon attempts to the domain controller itself generate logon events. In short, account logon events are generated where the account is located; logon events are generated where the logon attempt occurs.

If you configure this policy setting, you can specify whether to audit successes, audit failures, or not audit the logon events at all. Success audits generate an audit entry when a logon attempt succeeds, which is useful information for accounting purposes and for post-incident forensics so that you can determine who successfully logged on to which computer. Failure audits generate an audit entry when a logon attempt fails, which is useful for intrusion detection, but this setting also creates a potential denial-of-service condition because a malicious user could generate millions of logon failures and fill your security event log.

Location

GPO_name\Computer Configuration\Windows Settings\Security Settings\Local Policies\Audit Policy\

Default Values

Server Type or GPO	Default Value
Default Domain Policy	Not defined
Default Domain Controller Policy	Success
Stand-Alone Server Default Settings	Success
DC Effective Default Settings	Success
Member Server Effective Default Settings	Success

Audit object access

The Audit object access policy setting determines whether to audit the event of a user accessing an object—for example, a file, folder, registry key, or printer—that has specified its own SACL.

The possible values for this Group Policy setting are:

• Success.

• Failure.

• No auditing.

Discussion

If you define this policy setting, you can specify whether to audit successes, audit failures, or not audit object access at all. Success audits generate an audit entry when a user successfully accesses an object that has specified an SACL. Failure audits generate an audit entry when a user unsuccessfully attempts to access an object that has specified an SACL; some failure events are to be expected in the course of normal system operations. For example, many applications, such as Microsoft Word, always attempt to open files with both read and write user rights; if they are unable to do so, they try to open them with read-only user rights. When this happens, a failure event will be recorded if you have enabled both failure auditing and the appropriate SACL on that file.

Enabling auditing of object access and configuring SACLs on objects can generate a large volume of entries in the security logs on systems in your enterprise; therefore, you should only enable these policy settings if you actually intend to use the information.

Enabling the capability to audit an object—such as a file, folder, printer, or registry key—is a two-step process in Windows Server 2003. After enabling the Audit object access policy setting, you must determine the objects to which you want to monitor access, and then modify their SACLs accordingly. For example, if you want to audit any attempts by users to open a particular file, you can use Group Policy or Windows Explorer to set a Success or Failure attribute directly on the file that you want to monitor for that particular event.

Location

GPO_name\Computer Configuration\Windows Settings\Security Settings\Local Policies\Audit Policy\

Default Values

Server Type or GPO	Default Value
Default Domain Policy	Not defined
Default Domain Controller Policy	No auditing
Stand-Alone Server Default Settings	No auditing
DC Effective Default Settings	No auditing
Member Server Effective Default Settings	No auditing

Audit policy change

The Audit policy change policy setting determines whether to audit every incidence of a change to user rights assignment policy settings, audit policy settings, or trust policy settings.

The possible values for this Group Policy setting are:

• Success.

• Failure.

• No auditing.

Discussion

If you configure this policy setting, you can specify whether to audit successes, audit failures, or not audit the policy settings changes at all. Success audits generate an audit entry when a change to user rights assignment, audit, or trust policy settings is successful, which is useful information for accounting purposes and for post-incident forensics so that you can determine who successfully modified policy settings in the domain or on individual computers. Failure audits generate an audit entry when a change to user rights assignment, audit, or trust policy settings fails.

Location

GPO_name\Computer Configuration\Windows Settings\Security Settings\Local Policies\Audit Policy\

Default Values

Server Type or GPO	Default Value
Default Domain Policy	Not defined
Default Domain Controller Policy	Success
Stand-Alone Server Default Settings	No auditing
DC Effective Default Settings	Success
Member Server Effective Default Settings	No auditing

Audit privilege use

The Audit privilege use policy setting determines whether to audit each instance of a user exercising a user right.

The possible values for this Group Policy setting are:

• Success.

• Failure.

• No auditing.

Discussion

If you configure this policy setting, you can specify whether to audit successes, audit failures, or not audit privilege use at all. Success audits generate an audit entry when the exercise of a user right succeeds. Failure audits generate an audit entry when the exercise of a user right fails. The volume of events generated by enabling these policy settings is very high and difficult to sort through. You should only enable these policy settings if you have a plan for how you will use the information that is generated.

By default, audit events are not generated for use of the following user rights, even if success audits or failure audits are specified for Audit privilege use:

• Bypass traverse checking

• Debug programs

• Create a token object

• Replace process level token

• Generate security audits

• Backup files and directories

• Restore files and directories

Location

GPO_name\Computer Configuration\Windows Settings\Security Settings\Local Policies\Audit Policy\

Default Values

Server Type or GPO	Default Value
Default Domain Policy	Not defined
Default Domain Controller Policy	No auditing
Stand-Alone Server Default Settings	No auditing
DC Effective Default Settings	No auditing
Member Server Effective Default Settings	No auditing

Audit process tracking

The Audit process tracking policy setting determines whether to audit detailed tracking information for events such as program activation, process exit, handle duplication, and indirect object access.

The possible values for this Group Policy setting are:

• Success.

• Failure.

• No auditing.

Discussion

If you configure this policy setting, you can specify whether to audit successes, audit failures, or not audit process tracking at all. Success audits generate an audit entry when the process being tracked succeeds. Failure audits generate an audit entry when the process being tracked fails.

Setting the value of Audit process tracking to Success or Failure will generate a large number of events, so typically it is set to No auditing. However, process tracking can be helpful in post-incident forensics because it provides a detailed log of which processes were started and the time they were started.

Location

GPO_name\Computer Configuration\Windows Settings\Security Settings\Local Policies\Audit Policy\

Default Values

Server Type or GPO	Default Value
Default Domain Policy	Not defined
Default Domain Controller Policy	No auditing
Stand-Alone Server Default Settings	No auditing
DC Effective Default Settings	No auditing
Member Server Effective Default Settings	No auditing

Audit system events

The Audit system events policy setting determines whether to audit when a user restarts or shuts down their computer, or when an event occurs that affects either system security or the security log.

The possible values for this Group Policy setting are:

• Success.

• Failure.

• No auditing.

Discussion

If you configure this policy setting, you can specify whether to audit successes, audit failures, or not audit the system events at all. Success audits generate an audit entry when a system event is executed successfully. Failure audits generate an audit entry when a system event is attempted unsuccessfully. Because only a few additional events will be recorded by setting Audit system events to both Failure and Success, and all of those events will be very significant, it is recommended that you set these values on all computers in your organization.

Location

GPO_name\Computer Configuration\Windows Settings\Security Settings\Local Policies\Audit Policy\

Default Values

Server Type or GPO	Default Value
Default Domain Policy	Not defined
Default Domain Controller Policy	Success
Stand-Alone Server Default Settings	No auditing
DC Effective Default Settings	Success
Member Server Effective Default Settings	No auditing

User Rights Assignment

User rights are tasks that a user is permitted to perform on a computer system or domain. There are two types of user rights: logon rights and privileges. Logon rights control who is authorized to log on to a computer and how they can log on. Privileges control access to system-wide resources on a computer and can override permissions set on specific objects. An example of a logon right is the right to log on to a computer locally. An example of a privilege is the right to shut down the system. Both types of user rights are assigned by administrators to individual users or groups as part of the security policy settings for the computer.

The User Rights Assignment policy settings can be configured in the following location in Group Policy Object Editor:

Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment

Access this computer from the network

The Access this computer from the network policy setting allows a user to connect to the computer from the network. This user right is required by a number of network protocols, including server message block (SMB)–based protocols, network BIOS (NetBIOS), Common Internet File System (CIFS), and Component Object Model Plus (COM+).

Note

• Misuse of this policy setting is a common error that can cause data loss or problems with data access or security.

The possible values for this Group Policy setting are:

• A user-defined list of accounts.

• Not defined.

Discussion

Users who can connect from their computer to the network can access resources on those computers for which they have permission. For example, this right is required for a user to connect to shared printers and folders. If this right is assigned to the Everyone group, and some shared folders have both share and NTFS file system permissions configured so that the Everyone group has read access, anyone will be able to view files in those shared folders. This is an unlikely situation for fresh installations of Windows Server 2003, because the default share and NTFS permissions in Windows Server 2003 do not include the Everyone group. For systems upgraded from Windows NT 4.0 or Windows 2000, this policy setting can have a higher level of risk because the default permissions for these operating systems are not as restrictive as the default permissions in Windows Server 2003.

It is advisable to assign the Access this computer from the network user right only to those users who require access to the server. For example, assigning this to the Administrators and Users groups will allow a user who logged on to the domain to access servers in the domain.

Removing this user right on domain controllers from all users will prevent anyone from logging on to the domain or using network resources. Removing this right on member servers will prevent users from connecting to those servers by way of the network. For these reasons, it is important to verify that authorized users have this right for the computers they need to access on the network.

Location

GPO_name\Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment

Default Values

Server Type or GPO	Default Value
Default Domain Policy	Not defined
Default Domain Controller Policy	Everyone, Administrators, Authenticated Users, ENTERPRISE DOMAIN CONTROLLERS, Pre-Windows 2000 Compatible Access
Stand-Alone Server Default Settings	Everyone, Administrators, Users, Power Users, Backup Operators
DC Effective Default Settings	Everyone, Administrators, Authenticated Users, ENTERPRISE DOMAIN CONTROLLERS, Pre-Windows 2000 Compatible Access
Member Server Effective Default Settings	Backup Operators, Power Users, Users, Administrators, Everyone

Act as part of the operating system

The Act as part of the operating system user right allows a process to assume the identity of any user and thus gain access to the resources that the user is authorized to access. Typically, only low-level authentication services require this user right. Note that potential access is not limited to what is associated with the user by default; the calling process might request that arbitrary additional user rights be added to the access token. The calling process might also build an access token that does not provide a primary identity for events recorded in the security log.

The possible values for this Group Policy setting are:

• A user-defined list of accounts.

• Not defined.

Discussion

This user right is extremely powerful; anyone with this right can take complete control of the computer and erase virtually any evidence of their activities.

Limit the Act as part of the operating system user right to as few accounts as possible—it should not even be assigned to the Administrators group under normal circumstances. When a service requires this user right, configure the service to log on by using the local System account, which has this user right inherently. Do not create a separate account and assign this user right to it.

This user right is rarely needed by any accounts other than the local System account.

Location

GPO_name\Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment

Default Values

Server Type or GPO	Default Value
Default Domain Policy	Not defined
Default Domain Controller Policy	No one
Stand-Alone Server Default Settings	Not defined
DC Effective Default Settings	No one
Member Server Effective Default Settings	Not defined

Add workstations to domain

The Add workstations to domain user right allows the user to add a computer to a specific domain. For the user right to take effect, it must be assigned to the user as part of the Default Domain Controllers Policy for the domain. A user who has this user right can add up to 10 workstations to the domain. Users can also join a computer to a domain if they have been assigned the Create Computer Objects permission for an OU or for the Computers container in Active Directory. Users who have the Create Computer Objects permission can add an unlimited number of computers to the domain regardless of whether they have been assigned the Add workstations to domain user right.

The possible values for this Group Policy setting are:

• A user-defined list of accounts.

• Not defined.

Discussion

This user right has a moderate risk. Users with this right can add a computer to the domain that has been configured in a way that violates corporate security policies. For example, even if your organization does not want its users to have administrative user rights on their computer, a user could install Windows on their computer and then add the computer to the domain. They would know the password for the local Administrator account, and they could log on by using that account and then add their domain account to the local Administrators group.

Configure the Add workstations to domain user right so that only authorized members of the IT team are allowed to add computers to the domain. For organizations that have never allowed users to set up their own systems or add them to the domain, this countermeasure will have no impact. For those that have allowed some or all users to configure their own computers, this countermeasure will force the organization to establish a formal process for these procedures.

Location

GPO_name\Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment

Default Values

Server Type or GPO	Default Value
Default Domain Policy	Not defined
Default Domain Controller Policy	Authenticated Users
Stand-Alone Server Default Settings	Not defined
DC Effective Default Settings	Authenticated Users
Member Server Effective Default Settings	Not defined

Adjust memory quotas for a process

The Adjust memory quotas for a process user right allows a user to adjust the maximum memory available to a process. This user right is useful for system tuning, but it can be abused. In the wrong hands, it could be used to start a denial-of-service attack.

The possible values for this Group Policy setting are:

• A user-defined list of accounts.

• Not defined.

Discussion

A user with this right can reduce the amount of memory available to any process. This could cause business-critical network applications to slow down or even to fail.

Restrict the Adjust memory quotas for a process user right to users who require it to perform their job, such as application administrators who are responsible for maintaining database management systems or domain administrators responsible for managing the corporate directory and its supporting infrastructure.

Only organizations that have been lax with regard to restricting users to roles with limited user rights will find imposing this countermeasure difficult. For most organizations, implementing this restriction should have no impact.

Location

GPO_name\Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment

Default Values

Server Type or GPO	Default Value
Default Domain Policy	Not defined
Default Domain Controller Policy	LOCAL SERVICE, NETWORK SERVICE, Administrators
Stand-Alone Server Default Settings	LOCAL SERVICE, NETWORK SERVICE, Administrators
DC Effective Default Settings	LOCAL SERVICE, NETWORK SERVICE, Administrators
Member Server Effective Default Settings	Administrators, NETWORK SERVICE, LOCAL SERVICE

Allow log on locally

Note

• Misuse of this policy setting is a common error that can cause data loss or problems with data access or security.

The Allow log on locally user right allows a user to start an interactive session on the computer. Users who do not have this right can still start a remote interactive session on the computer if they have the Allow log on through Terminal Services user right.

The possible values for this Group Policy setting are:

• A user-defined list of accounts.

• Not defined.

Discussion

Any account with the right to log on locally can be used to log on to the console of the computer. Not restricting this user right to legitimate users who need to be able to log on to the console of the system could result in unauthorized users downloading and executing malicious code to elevate their user rights.

For domain controllers, only assign the Allow log on locally user right to the Administrators group. For servers that fill other roles, add Backup Operators and Power Users. For end-user computers, assign this right to the Users group also.

Alternatively, you can add groups such as Account Operators, Server Operators, and Guests to the Deny log on locally user right. Denying access to these groups could limit the abilities of users assigned to specific administrative roles in your environment. Confirm that delegated activities will not be adversely affected.

Location

GPO_name\Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment

Default Values

Server Type or GPO	Default Value
Default Domain Policy	Not defined
Default Domain Controller Policy	Administrators, Backup Operators, Account Operators, Server Operators, Print Operators
Stand-Alone Server Default Settings	Administrators, Users, Power Users, Backup Operators
DC Effective Default Settings	Administrators, Backup Operators, Account Operators, Server Operators, Print Operators
Member Server Effective Default Settings	Backup Operators, Power Users, Users, Administrators

Allow log on through Terminal Services

The Allow log on through Terminal Services user right allows a user to log on to the computer by using a Remote Desktop connection. You should not assign this right to individual users or groups. Instead, it is a best practice to control who can open a Remote Desktop connection to the computer by adding users to or removing them from the Remote Desktop Users group.

The possible values for this Group Policy setting are:

• A user-defined list of accounts.

• Not defined.

Discussion

Any account with the right to log on via Terminal Services can be used to log on to the remote console of the computer. Not restricting this user right to legitimate users who need to log on to the console of the system might allow unauthorized users to download and execute malicious code to elevate their user rights.

For domain controllers, only assign the Allow log on through Terminal Services user right to the Administrators group. For servers that fill other roles and end-user computers, add the Remote Desktop Users group. For all server roles other than Terminal Servers, ensure that only authorized members of the IT team who need to be able to manage the systems remotely belong to either of these groups.

For Terminal Servers, ensure that only users who require access to the server have accounts that belong to the Remote Desktop Users group, because this built-in group by default has this logon right.

Alternatively, you can assign the Deny log on through Terminal Services user right to groups such as Account Operators, Server Operators, and Guests. However, be careful when implementing this method because you might block access to legitimate administrators who also happen to belong to a group that has the Deny log on through Terminal Services logon right.

Changing membership in these default groups, or removing this user right from other groups, can limit the abilities of users assigned to specific administrative roles in your environment. Confirm that delegated activities will not be adversely affected.

Location

GPO_name\Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment

Default Values

Server Type or GPO	Default Value
Default Domain Policy	Not defined
Default Domain Controller Policy	Not defined
Stand-Alone Server Default Settings	Administrators, Remote Desktop Users
DC Effective Default Settings	Administrators
Member Server Effective Default Settings	Remote Desktop Users, Administrators

Back up files and directories

The Back up files and directories user right allows the user to circumvent file and directory permissions to back up the system. This user right is selected only when an application attempts access via the NTFS backup application programming interface (API) by using, for example, Ntbackup.exe. Otherwise, normal file and directory permissions apply.

The possible values for this Group Policy setting are:

• A user-defined list of accounts.

• Not defined.

Discussion

Users who are able to back up data from a computer might take the backup media to a computer that does not belong to the domain where they have administrative user rights and restore the data. They could then take ownership of the files and view anything contained within the backup set.

Limit the Back up files and directories user right to members of the IT team who need to be able to back up corporate data as part of their day-to-day responsibilities.

Changing membership of the groups that have this user right might limit the abilities of users assigned to specific administrative roles in your environment. Confirm that authorized backup administrators are still able to perform backup operations.

Location

GPO_name\Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment

Default Values

Server Type or GPO	Default Value
Default Domain Policy	Not defined
Default Domain Controller Policy	Administrators, Backup Operators, Server Operators
Stand-Alone Server Default Settings	Administrators, Backup Operators
DC Effective Default Settings	Administrators, Backup Operators, Server Operators
Member Server Effective Default Settings	Backup Operators, Administrators

Bypass traverse checking

Note

• Misuse of this policy setting is a common error that can cause data loss or problems with data access or security.

The Bypass traverse checking user right allows a user who is navigating an object path in NTFS or the registry to pass through folders without checking for the special access permission Traverse Folder. This user right does not allow the user to list the contents of a folder, it only allows the user to traverse the folder's directories.

The possible values for this Group Policy setting are:

• A user-defined list of accounts.

• Not defined.

Discussion

The default setting for this user right is to allow anyone to bypass traverse checking. For experienced Windows system administrators, this is the expected behavior, and they configure file-system access control lists (SACLs) accordingly. The only scenario where the default configuration might lead to a mishap is if the administrator who is configuring permissions expects that users who are unable to access a folder will be unable to access the contents of any child folders. This is an unlikely situation, and therefore the risk is very low.

Organizations that are extremely concerned about security might want to remove the Everyone group, or perhaps even the Users group, from the list of groups that have the Bypass traverse checking user right.

Windows and many applications have been designed with the expectation that anyone who can legitimately access the computer will have this user right. Therefore, removing the Everyone group from the list of users who have this user right by default might lead to operating-system instability or application failure. It is recommended that you leave this policy setting at its default.

Location

GPO_name\Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment

Default Values

Server Type or GPO	Default Value
Default Domain Policy	Not defined
Default Domain Controller Policy	Everyone, Administrators, Authenticated Users, Pre-Windows 2000 Compatible Access
Stand-Alone Server Default Settings	Everyone, Administrators, Users, Power Users, Backup Operators
DC Effective Default Settings	Everyone, Administrators, Authenticated Users, Pre-Windows 2000 Compatible Access
Member Server Effective Default Settings	Backup Operators, Power Users, Users, Administrators, Everyone

Change the system time

The Change the system time user right allows the user to adjust the time on the computer's internal clock. This user right is not required to change the time zone or other display characteristics of the system time.

The possible values for this Group Policy setting are:

• A user-defined list of accounts.

• Not defined.

Discussion

Users who are able to set a computer to the wrong time can cause several problems: Time stamps on event log entries will no longer be accurate; time stamps that indicate when files and folders are created or modified will not be correct; and, if the computer belongs to a domain, it might be unable to authenticate itself or users who try to log on to the domain from it. The risk of this happening is mitigated on most domain controllers, member servers, and end-user computers because the Windows Time service automatically synchronizes time with domain controllers in the following ways:

• All client desktop computers nominate the authenticating domain controller as their inbound time partner.

• All member servers follow the same process that client desktop computers follow.

• All domain controllers in a domain nominate the primary domain controller (PDC) operations master as their inbound time partner.

• All PDC operations masters follow the hierarchy of domains in the selection of their inbound time partner.

• The PDC operations master at the root of the domain is authoritative for the organization; therefore, it is recommended that you synchronize it with a reliable external time server.

This issue becomes much more serious if a malicious user is able to change the system time and then stop the Windows Time service, or reconfigure it to be synchronized with a time server that is not accurate.

Limit the Change the system time user right to users who have a legitimate need to change the system time, such as members of the IT team.

There should be no impact for most organizations because time synchronization will be fully automated for all computers that belong to the domain. Computers that do not belong to the domain should be synchronized with an external source.

Location

GPO_name\Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment

Default Values

Server Type or GPO	Default Value
Default Domain Policy	Not defined
Default Domain Controller Policy	Administrators, Server Operators
Stand-Alone Server Default Settings	Administrators, Power Users
DC Effective Default Settings	Administrators, Server Operators
Member Server Effective Default Settings	Power Users, Administrators

Create a page file

The Create a page file user right allows the user to create and change the size of a paging file. This is done by clicking Performance on the Advanced tab of the System Properties property sheet and specifying a paging file size for a particular drive in the Performance Options dialog box.

The possible values for this Group Policy setting are:

• A user-defined list of accounts.

• Not defined.

Discussion

Users who can change the paging file size can make it extremely small or move the file to a highly fragmented storage volume, which might lead to reduced system performance.

You should only assign the Create a page file user right to members of the Administrators group.

Location

GPO_name\Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment

Default Values

Server Type or GPO	Default Value
Default Domain Policy	Not defined
Default Domain Controller Policy	Administrators
Stand-Alone Server Default Settings	Administrators
DC Effective Default Settings	Administrators
Member Server Effective Default Settings	Administrators

Create a token object

The Create a token object user right allows a process to create a token. If the process uses NtCreateToken() or another token-creation API, it can use the token to access any local resources. It is advisable not to assign this user right to any users.

The possible values for this Group Policy setting are:

• A user-defined list of accounts.

• Not defined.

Discussion

The operating system determines the level of a user's privileges by examining the user's access token. Access tokens are built when users log on to the local computer or connect to a remote computer over a network. When you revoke a user right, the change is immediately recorded in the registry, but the change is not reflected in the user's access token until the next time the user logs on or connects. A user with the ability to create or modify tokens can change the level of access for any currently logged-on account. Such a user can escalate their own user rights or create a denial-of-service condition.

Do not assign the Create a token object right to any users. Processes that require this user right should use the local System account, which already includes this user right.

Location

GPO_name\Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment

Default Values

Server Type or GPO	Default Value
Default Domain Policy	Not defined
Default Domain Controller Policy	No one
Stand-Alone Server Default Settings	Not defined
DC Effective Default Settings	No one
Member Server Effective Default Settings	Not defined

Create global objects

The Create global objects user right is required for a user account to create global objects that are available to all sessions. Users can still create objects specific to their own session without being assigned this user right.

The possible values for this Group Policy setting are:

• A user-defined list of accounts.

• Not defined.

Discussion

Users who can create global objects can affect processes that run under other users' sessions. This could lead to a variety of problems, such as application failure or data corruption.

Only assign the Create global objects user right to members of the local Administrators and Service groups.

Location

GPO_name\Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment

Default Values

Server Type or GPO	Default Value
Default Domain Policy	Not defined
Default Domain Controller Policy	Not defined
Stand-Alone Server Default Settings	Administrators, SERVICE
DC Effective Default Settings	Administrators, SERVICE
Member Server Effective Default Settings	Administrators, SERVICE

Create permanent shared objects

The Create permanent shared objects user right allows a user to create a directory object in the object manager. This means that users with this user right can create shared folders, printers, and other objects. This user right is useful for kernel-mode components that extend the object namespace. Components that run in kernel mode have this user right inherently; therefore, it is normally not necessary to specifically assign this user right.

The possible values for this Group Policy setting are:

• A user-defined list of accounts.

• Not defined.

Discussion

Users with this user right can expose sensitive data to the network by creating a new shared object.

Do not assign the Create permanent shared objects right to any users. Processes that require this user right should use the local System account, which already includes this user right. Users who belong to the local Administrators group will still be able to create, modify, and delete shared folders and printers.

Location

GPO_name\Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment

Default Values

Server Type or GPO	Default Value
Default Domain Policy	Not defined
Default Domain Controller Policy	No one
Stand-Alone Server Default Settings	Not defined
DC Effective Default Settings	No one
Member Server Effective Default Settings	Not defined

Debug programs

The Debug programs user right allows the user to attach a debugger to any process. This user right provides access to sensitive and critical operating system components.

The possible values for this Group Policy setting are:

• A user-defined list of accounts.

• Not defined.

Discussion

The Debug programs user right can be exploited to capture sensitive system information from system memory. Some attack tools exploit the debug program's user right to extract hashed passwords and other private security information. The risk of attackers' being able to exploit this user right is mitigated by the fact that the debug program's user right is by default assigned only to administrators.

Revoke the Debug programs user right from all users and groups. Revoking this user right will mean that no one except administrators will be able to debug programs. However, under normal circumstances, debugging is rarely necessary on production systems. If a problem arises that requires debugging an application on a production server temporarily, move the server to a different OU and assign the Debug programs user right to the appropriate account.

Location

GPO_name\Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment

Default Values

Server Type or GPO	Default Value
Default Domain Policy	Not defined
Default Domain Controller Policy	Administrators
Stand-Alone Server Default Settings	Administrators
DC Effective Default Settings	Administrators
Member Server Effective Default Settings	Administrators

Deny access to this computer from the network

The Deny access to this computer from the network user right prohibits a user from connecting to the computer from the network.

The possible values for this Group Policy setting are:

• A user-defined list of accounts.

• Not defined.

Discussion

Users who can log onto the computer over the network can enumerate lists of account names, group names, and shared resources. Users with permission to access shared folders and files can connect over the network and possibly view or modify data. Explicitly denying this logon right to high-risk accounts, such as the local Guest account and other accounts that have no business reason for accessing the computer over the network, provides an additional layer of protection.

Assign the Deny access to this computer from the network user right to the following accounts:

• ANONYMOUS LOGON

• The built-in local Administrator account

• The local Guest account

• The built-in Support account (the Support_388945a0 account is the logon account for Remote Assistance)

• All service accounts

  There is an important exception to this list: do not assign the logon right to any service accounts that are used to start services that need to connect to the computer over the network. For example, if you have configured a shared folder for Web servers to access, and you present content within that folder through a Web site, you might need to allow the account under which IIS is running to log on to the server with the shared folder via the network.

Configuring this logon right for other groups might limit the abilities of users assigned to specific administrative roles in your environment. Verify that delegated tasks will not be negatively affected.

Location

GPO_name\Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment

Default Values

Server Type or GPO	Default Value
Default Domain Policy	Not defined
Default Domain Controller Policy	SUPPORT_388945a0
Stand-Alone Server Default Settings	SUPPORT_388945a0
DC Effective Default Settings	SUPPORT_388945a0
Member Server Effective Default Settings	SUPPORT_388945a0

Deny log on as a batch job

The Deny log on as a batch job user right prohibits a user from logging on by using a batch-queue facility. Batch-queue in Windows Server 2003 is used for scheduling jobs that will be automatically started one or more times in the future. This user right is needed for any accounts that are used for scheduling jobs via the Task Scheduler service.

The possible values for this Group Policy setting are:

• A user-defined list of accounts.

• Not defined.

Discussion

Accounts with this logon right might be used to schedule jobs that consume excessive system resources, leading to a denial-of-service condition.

Assign the Deny log on as a batch job user right to the built-in Support account — the Support_388945a0 account is the logon account for Remote Assistance — and the local Guest account. Configuring this logon right for other accounts might prevent users who are assigned to specific administrative roles from performing their required job activities. Confirm that delegated tasks will not be affected adversely.

Location

GPO_name\Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment

Default Values

Server Type or GPO	Default Value
Default Domain Policy	Not defined
Default Domain Controller Policy	No one
Stand-Alone Server Default Settings	Not defined
DC Effective Default Settings	No one
Member Server Effective Default Settings	Not defined

Deny log on as a service

The Deny log on as a service logon right prohibits a user from logging on as a service.

The possible values for this Group Policy setting are:

• A user-defined list of accounts.

• Not defined.

Discussion

Accounts that can log on as a service might be used to configure and start new unauthorized services such as a Trojan horse or backdoor (a backdoor is a hidden entrance to an operating system that can be used to download system information). The benefit of configuring this countermeasure is somewhat mitigated by the fact that only users with administrative user rights can install and configure services, and a malicious user who has already attained that level of access can configure the service to run under the local System account.

It is advisable to keep this user right in its default state; that is, do not assign the Deny log on as a service logon right to any accounts. Organizations that are extremely concerned about security might want to assign this logon right to groups and accounts that they are certain will never need to log on as a service. Assigning this user right to specific accounts can prevent services from being started, which might lead to a denial-of-service condition.

Location

GPO_name\Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment

Default Values

Server Type or GPO	Default Value
Default Domain Policy	Not defined
Default Domain Controller Policy	No one
Stand-Alone Server Default Settings	Not defined
DC Effective Default Settings	No one
Member Server Effective Default Settings	Not defined

Deny log on locally

The Deny log on locally logon right prohibits a user from logging on directly at the computer's keyboard.

The possible values for this Group Policy setting are:

• A user-defined list of accounts.

• Not defined.

Discussion

Any account with the right to log on locally can be used to log on at the console of the computer. If this user right is not restricted to legitimate users who need to log on to the console of the system, unauthorized users can download and execute malicious code that elevates their user rights.

Assign the Deny log on locally logon right to the built-in Support account. The Support_388945a0 account is the logon account for Remote Assistance.

The Support_388945a0 account enables Help and Support Center interoperability with signed scripts. This account is primarily used to control access to signed scripts that are accessible from within Help and Support Center. Administrators can use this account to delegate the ability for an ordinary user, who does not have administrative access to a computer, to run signed scripts from links embedded within Help and Support Center. These scripts can be programmed to use the Support_388945a0 account credentials instead of the user's credentials to perform specific administrative operations on the local computer, operations that otherwise would not be supported by the ordinary user's account. When the delegated user clicks a link in Help and Support Center, the script runs under the security context of the Support_388945a0 account. This account has limited access to the computer and is disabled by default.

Assigning this logon right to additional accounts might limit the abilities of users assigned to specific administrative roles in your environment. Confirm that delegated activities will not be adversely affected.

Location

GPO_name\Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment

Default Values

Server Type or GPO	Default Value
Default Domain Policy	Not defined
Default Domain Controller Policy	SUPPORT_388945a0
Stand-Alone Server Default Settings	SUPPORT_388945a0
DC Effective Default Settings	SUPPORT_388945a0
Member Server Effective Default Settings	SUPPORT_388945a0

Deny log on through Terminal Services

The Deny log on through Terminal Services logon right prohibits a user from logging on to the computer by using a Remote Desktop connection.

The possible values for this Group Policy setting are:

• A user-defined list of accounts.

• Not defined.

Discussion

Any account with the right to log on using Terminal Services can be used to log on to the remote console of the computer. If this user right is not restricted to legitimate users who need to log on to the console of the system, unauthorized users might download and execute malicious code that elevates their user rights.

Assign the Deny log on through Terminal Services logon right to the built-in local Administrator account and all service accounts. Assigning this logon right to other groups might limit the abilities of users assigned to specific administrative roles in your environment. Confirm that delegated tasks will not be negatively affected.

Location

GPO_name\Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment

Default Values

Server Type or GPO	Default Value
Default Domain Policy	Not defined
Default Domain Controller Policy	Not defined
Stand-Alone Server Default Settings	Not defined
DC Effective Default Settings	Not defined
Member Server Effective Default Settings	Not defined

Enable computer and user accounts to be trusted for delegation

The Enable computer and user accounts to be trusted for delegation user right allows the user to change the Trusted for Delegation policy setting on a user or computer object in Active Directory. The user or computer that is assigned this user right must also have write access to the account control flags on the object.

Note

• Misuse of this policy setting is a common error that can cause data loss or problems with data access or security.

The possible values for this Group Policy setting are:

• A user-defined list of accounts.

• Not defined.

Discussion

Delegation of authentication is used by multitier client/server applications. It allows a front-end service to use the credentials of a client while authenticating to a back-end service. For this to be possible, both client and server must be running under accounts that are trusted for delegation.

Misuse of this user right can lead to unauthorized users' impersonating other users' on the network. A malicious user can exploit this user right to gain access to network resources while appearing to be a different user, which could make post–security incident forensics more difficult.

It is advisable to assign the Enable computer and user accounts to be trusted for delegation user right only to the Administrators group on domain controllers. There is no reason to assign it to anyone on member servers or workstations that belong to a domain, because it has no meaning in those contexts; this user right is only relevant to domain controllers and stand-alone systems.

Location

GPO_name\Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment

Default Values

Server Type or GPO	Default Value
Default Domain Policy	Not defined
Default Domain Controller Policy	Administrators
Stand-Alone Server Default Settings	Not defined
DC Effective Default Settings	Administrators
Member Server Effective Default Settings	Not defined

Force shutdown from a remote system

The Force shutdown from a remote system user right allows a user to shut down a computer from a remote location on the network.

The possible values for this Group Policy setting are:

• A user-defined list of accounts.

• Not defined.

Discussion

Any user who can shut down a computer can cause a denial-of-service condition; therefore, this user right should be tightly restricted.

Only assign the Force shutdown from a remote system user right to members of the Administrators group. Removing the Server Operators group might limit the abilities of users assigned to specific administrative roles in your environment. Confirm that delegated activities will not be adversely affected.

Location

GPO_name\Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment

Default Values

Server Type or GPO	Default Value
Default Domain Policy	Not defined
Default Domain Controller Policy	Administrators, Server Operators
Stand-Alone Server Default Settings	Administrators
DC Effective Default Settings	Administrators, Server Operators
Member Server Effective Default Settings	Administrators

Generate security audits

The Generate security audits user right allows a process to generate audit records in the security log. The security log can be used to trace unauthorized system access.

The possible values for this Group Policy setting are:

• A user-defined list of accounts.

• Not defined.

Discussion

Accounts that are able to write to the security log can be used by a malicious user to fill that log with meaningless events. If the computer is configured to overwrite event logs as they fill up, the attacker can use this method to remove evidence of their unauthorized activities. If the computer is configured to shut down when it is unable to write to the security log, this method can be used to create a denial-of-service condition.

Ensure that only the Local Service and Network Service groups have the Generate security audits user right assigned to them.

Location

GPO_name\Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment

Default Values

Server Type or GPO	Default Value
Default Domain Policy	Not defined
Default Domain Controller Policy	LOCAL SERVICE, NETWORK SERVICE
Stand-Alone Server Default Settings	LOCAL SERVICE, NETWORK SERVICE
DC Effective Default Settings	LOCAL SERVICE, NETWORK SERVICE
Member Server Effective Default Settings	LOCAL SERVICE, NETWORK SERVICE

Impersonate a client after authentication

The Impersonate a client after authentication user right allows programs running on behalf of a user to impersonate a client. Requiring this user right for this kind of impersonation prevents an unauthorized user from convincing a client to connect — for example, by remote procedure call (RPC) or named pipes — to a service that they have created and then impersonating that client, which can elevate the unauthorized user's credentials to administrative or system levels.

Services that are started by the Service Control Manager have the built-in Service group added by default to their access tokens. COM servers started by the COM infrastructure that are configured to run under a specific account also have the Service group added to their access tokens. As a result, these services get this user right when they are started.

In addition, a user can also impersonate an access token if any of the following conditions exist.

• The access token that is being impersonated is for this user.

• The user, in this logon session, created the access token by logging on to the network with explicit credentials.

• The requested level is less than Impersonate, such as Anonymous or Identify.

Because of these factors, users do not usually need this user right.

The possible values for this Group Policy setting are:

• A user-defined list of accounts.

• Not defined.

Discussion

A user with this user right can trick a client into connecting to a service that they have created and then impersonating that client. The user can then elevate their level of access to that of the other client.

Ensure that only the Administrators and Service groups have the Impersonate a client after authentication user right assigned to them.

Location

GPO_name\Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment

Default Values

Server Type or GPO	Default Value
Default Domain Policy	Not defined
Default Domain Controller Policy	Not defined
Stand-Alone Server Default Settings	Administrators, SERVICE
DC Effective Default Settings	Administrators, SERVICE
Member Server Effective Default Settings	Administrators, SERVICE

Increase scheduling priority

The Increase scheduling priority user right allows a user to increase the base priority class of a process. Increasing relative priority within a priority class is not a privileged operation. This user right is not required by administrative tools supplied with the operating system, but might be required by software development tools.

The possible values for this Group Policy setting are:

• A user-defined list of accounts.

• Not defined.

Discussion

A user with this user right can increase the scheduling priority of a process to Real-Time. This might leave little processing time for all other processes, which could lead to a denial-of-service condition.

Only Administrators should have the Increase scheduling priority user right assigned to them.

Location

GPO_name\Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment

Default Values

Server Type or GPO	Default Value
Default Domain Policy	Not defined
Default Domain Controller Policy	Administrators
Stand-Alone Server Default Settings	Administrators
DC Effective Default Settings	Administrators
Member Server Effective Default Settings	Administrators

Load and unload device drivers

The Load and unload device drivers user right determines which users can dynamically load and unload device drivers. This user right is not required if a signed driver for the new hardware already exists in the Driver.cab file on the computer.

The possible values for this Group Policy setting are:

• A user-defined list of accounts.

• Not defined.

Discussion

Device drivers run as highly privileged code. A user who has the Load and unload device drivers user right might unintentionally install malicious code that masquerades as a device driver. It is assumed that administrators will exercise greater care and only install drivers with verified digital signatures.

You must have this user right, and also be a member of either Administrators or Power Users, to install a new driver for a local printer or manage a local printer by setting defaults for options such as duplex printing. This requirement — to have the user right and also be a member of the Administrators or Power Users group — is new in the Windows XP and Windows Server 2003 operating systems.

Do not assign the Load and unload device drivers user right to any user or group other than Administrators. Removing this user right from the Print Operators group or other accounts might limit the abilities of users assigned to specific administrative roles in your environment. Ensure that delegated tasks will not be negatively affected.

Location

GPO_name\Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment

Default Values

Server Type or GPO	Default Value
Default Domain Policy	Not defined
Default Domain Controller Policy	Administrators, Print Operators
Stand-Alone Server Default Settings	Administrators
DC Effective Default Settings	Administrators, Print Operators
Member Server Effective Default Settings	Administrators

Lock pages in memory

The Lock pages in memory user right allows a process to keep data in physical memory, which prevents the system from paging the data to virtual memory on disk. Assigning this user right can result in significant degradation of system performance.

The possible values for this Group Policy setting are:

• A user-defined list of accounts.

• Not defined.

Discussion

Users with this user right can assign physical memory to several processes, leaving little or no RAM for other processes. This could lead to a denial-of-service condition.

Do not assign the Lock pages in memory user right to any accounts.

Location

GPO_name\Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment

Default Values

Server Type or GPO	Default Value
Default Domain Policy	Not defined
Default Domain Controller Policy	No one
Stand-Alone Server Default Settings	Not defined
DC Effective Default Settings	No one
Member Server Effective Default Settings	Not defined

Log on as a batch job

The Log on as a batch job user right allows a user to log on by using a batch-queue facility such as the Task Scheduler service. When an administrator uses the Add Scheduled Task wizard to schedule a task to run under a particular user name and password, that user automatically receives the Log on as a batch job user right. When the scheduled time arrives, the Task Scheduler service logs the user on as a batch job rather than as an interactive user, and the task runs in the user's security context.

The possible values for this Group Policy setting are:

• A user-defined list of accounts.

• Not defined.

Discussion

For most organizations, the default values are sufficient. Allow the system to manage this user right automatically if you want to allow tasks to be scheduled to run for specific user accounts. If you do not want to use the Task Scheduler in this manner, configure the Log on as a batch job user right for only the Local Service group and the local support account (Support_388945a0). For Internet Information Services (IIS) servers, configure this policy locally, rather than through domain-based Group Policy, so you can ensure that the local IUSR_computername and IWAM_computername accounts have this logon right.

If you specify this policy setting through domain-based Group Policy, the system will not be able to assign this user right to accounts used for scheduled jobs in the Task Scheduler, and the IUSR_computername and IWAM_computername accounts will not have this logon right. This will cause IIS to be unable to run some COM objects that are necessary for proper functioning.

Location

GPO_name\Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment

Default Values

Server Type or GPO	Default Value
Default Domain Policy	Not defined
Default Domain Controller Policy	LOCAL SERVICE, SUPPORT_388945a0
Stand-Alone Server Default Settings	LOCAL SERVICE, SUPPORT_388945a0
DC Effective Default Settings	LOCAL SERVICE, SUPPORT_388945a0
Member Server Effective Default Settings	LOCAL SERVICE, SUPPORT_388945a0

Log on as a service

The Log on as a service logon right allows a security principal to log on as a service. Services can be configured to run under the Local System, Local Service, or Network Service accounts, which have a built-in right to log on as a service. Any service that runs under a separate user account must be assigned this right.

The possible values for this Group Policy setting are:

• A user-defined list of accounts.

• Not defined.

Discussion

This is a powerful logon right that allows accounts to start network services. The risk is mitigated by the fact that only users with administrative user rights can install and configure services. A malicious user who has already attained that level of access can configure the service to run under the local System account.

The default security principal with the Log on as a service logon right is Network Service, a built-in local group. Service accounts should be added to this local group, and you should monitor membership for this group and this user right to ensure that unexpected changes are not being made.

Location

GPO_name\Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment

Default Values

Server Type or GPO	Default Value
Default Domain Policy	Not defined
Default Domain Controller Policy	NETWORK SERVICE
Stand-Alone Server Default Settings	NETWORK SERVICE
DC Effective Default Settings	NETWORK SERVICE
Member Server Effective Default Settings	NETWORK SERVICE

Manage auditing and security log

The Manage auditing and security log user right allows a user to specify object access auditing options for individual resources such as files, Active Directory objects, and registry entries. Object access auditing is not performed unless you enable it by using Group Policy Object Editor and configuring Audit Policy in the following location:

Computer Configuration\Windows Settings\Security Settings\Local Policies\Audit Policy

A user who has this user right can also view and clear the security log from Event Viewer.

The possible values for this Group Policy setting are:

• A user-defined list of accounts.

• Not defined.

Discussion

The right to manage the security event log is a powerful user right, and it should be closely guarded. Anyone with this user right can clear the security log, possibly erasing important evidence of unauthorized activity.

Ensure that only the local Administrators group has the Manage auditing and security log user right.

Location

GPO_name\Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment

Default Values

Server Type or GPO	Default Value
Default Domain Policy	Not defined
Default Domain Controller Policy	Administrators
Stand-Alone Server Default Settings	Administrators
DC Effective Default Settings	Administrators
Member Server Effective Default Settings	Administrators

Modify firmware environment values

The Modify firmware environment values user right allows system environment variables to be modified, either by a process through an application programming interface (API) or by a user through System Properties.

The possible values for this Group Policy setting are:

• A user-defined list of accounts.

• Not defined.

Discussion

Anyone with this user right can configure the settings of a hardware component in such a way that it fails. This can lead to data corruption or a denial-of-service condition.

Ensure that only the local Administratorsgroup has the Modify firmware environment values user right.

Location

GPO_name\Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment

Default Values

Server Type or GPO	Default Value
Default Domain Policy	Not defined
Default Domain Controller Policy	Administrators
Stand-Alone Server Default Settings	Administrators
DC Effective Default Settings	Administrators
Member Server Effective Default Settings	Administrators

Perform volume maintenance tasks

The Perform volume maintenance tasks user right allows a non- administrative or remote user to manage volumes or disks. Windows Server 2003 checks for the user right in a user's access token when a process running in the user's security context calls SetFileValidData().

The possible values for this Group Policy setting are:

• A user-defined list of accounts.

• Not defined.

Discussion

A user with this user right can delete a volume, leading to the loss of data or a denial-of-service condition.

Ensure that only the local Administrators group has the Perform volume maintenance tasks user right.

Location

GPO_name\Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment

Default Values

Server Type or GPO	Default Value
Default Domain Policy	Not defined
Default Domain Controller Policy	Not defined
Stand-Alone Server Default Settings	Administrators
DC Effective Default Settings	Administrators
Member Server Effective Default Settings	Administrators

Profile single process

The Profile single process user right allows a user to sample the performance of an application process. Ordinarily, you do not need this user right to use the Performance snap-in; however, you do need the user right if System Monitor is configured to collect data by using Windows Management Instrumentation (WMI).

The possible values for this Group Policy setting are:

• A user-defined list of accounts.

• Not defined.

Discussion

A malicious user with this user right can monitor a computer's performance to help identify critical processes that they might want to attack directly. The attacker can also determine what processes are running on the system and identify countermeasures that they should avoid — such as antivirus software or an intrusion-detection system — or identify which other users are logged on to the system.

Ensure that only the local Administrators group has the Profile single process user right. Removing this user right from the Power Users group or other accounts might limit the abilities of users who are assigned to specific administrative roles in your environment. Ensure that delegated tasks will not be negatively affected.

Location

GPO_name\Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment

Default Values

Server Type or GPO	Default Value
Default Domain Policy	Not defined
Default Domain Controller Policy	Administrators
Stand-Alone Server Default Settings	Administrators, Power Users
DC Effective Default Settings	Administrators
Member Server Effective Default Settings	Administrators, Power Users

Profile system performance

The Profile system performance user right allows a user to sample the performance of system processes. Ordinarily, you do not need this user right to use the Performance snap-in; however, you do need the user right if System Monitor is configured to collect data by using WMI.

The possible values for this Group Policy setting are:

• A user-defined list of accounts.

• Not defined.

Discussion

This is a moderate risk. A malicious user with this user right can monitor a computer's performance to help identify critical processes that they might want to attack directly. The attacker might also be able to determine what processes are running on the system so they can identify countermeasures that they might need to avoid, such as antivirus software or an intrusion-detection system.

Ensure that only the local Administrators group has the Profile system performance user right.

Location

GPO_name\Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment

Default Values

Server Type or GPO	Default Value
Default Domain Policy	Not defined
Default Domain Controller Policy	Administrators
Stand-Alone Server Default Settings	Administrators
DC Effective Default Settings	Administrators
Member Server Effective Default Settings	Administrators

Remove computer from docking station

The Remove computer from docking station user right allows the user of a portable computer to undock the computer by clicking Eject PC on the Start menu.

The possible values for this Group Policy setting are:

• A user-defined list of accounts.

• Not defined.

Discussion

Anyone who has this user right can remove a portable computer that has been started from its docking station. The value of employing this countermeasure is reduced by several factors: If a malicious user can restart the computer, they can remove it from the docking station after the BIOS has started but before the operating system has started; or a malicious user might steal the computer and the docking station together. This setting will not affect servers, because they are not typically installed in a docking station

Ensure that only the local Administrators and Power Users groups have the Remove computer from docking station user right.

This is the default configuration, so it should have little impact; however, if your organization's end users are not members of the Power Users or Administrators groups, they will be unable to remove their own portable computers from their docking stations without shutting down the system. Therefore, on portable computers, you might want to assign this user right to the local Users group.

Location

GPO_name\Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment

Default Values

Server Type or GPO	Default Value
Default Domain Policy	Not defined
Default Domain Controller Policy	Administrators
Stand-Alone Server Default Settings	Administrators, Power Users
DC Effective Default Settings	Administrators
Member Server Effective Default Settings	Administrators, Power Users

Replace a process level token

The Replace a process level token user right allows a parent process to replace the access token that is associated with a child process.

The possible values for this Group Policy setting are:

• A user-defined list of accounts.

• Not defined.

Discussion

If a user has this right and the Adjust memory quotas for a process user right, they can start processes as other users. They could use this method to hide the fact that they are performing unauthorized actions on the computer.

Ensure that only the Local Service and Network Service groups have the Replace a process level token user right.

Location

GPO_name\Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment

Default Values

Server Type or GPO	Default Value
Default Domain Policy	Not defined
Default Domain Controller Policy	LOCAL SERVICE, NETWORK SERVICE
Stand-Alone Server Default Settings	LOCAL SERVICE, NETWORK SERVICE
DC Effective Default Settings	LOCAL SERVICE, NETWORK SERVICE
Member Server Effective Default Settings	LOCAL SERVICE, NETWORK SERVICE

Restore files and directories

The Restore files and directories user right allows a user to circumvent file and directory permissions when restoring backed-up files and directories, and to set any valid security principal as the owner of an object.

The possible values for this Group Policy setting are:

• A user-defined list of accounts.

• Not defined.

Discussion

A malicious user with this user right can restore sensitive corporate data to a system, overwriting data that is more recent. This could lead to loss of important data, data corruption, or a denial-of-service condition.

This countermeasure will not prevent a malicious user from restoring data to an unmanaged system, so it is critical that organizations carefully protect the media they use for backing up data.

Ensure that only the local Administrators group has the Restore files and directories user right. Removing this user right from the Backup Operators group and other accounts might limit the abilities of users assigned to specific administrative roles in your environment. Ensure that delegated tasks will not be negatively affected.

Location

GPO_name\Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment

Default Values

Server Type or GPO	Default Value
Default Domain Policy	Not defined
Default Domain Controller Policy	Administrators, Backup Operators, Server Operators
Stand-Alone Server Default Settings	Administrators, Backup Operators
DC Effective Default Settings	Administrators, Backup Operators, Server Operators
Member Server Effective Default Settings	Administrators, Backup Operators

Shut down the system

The Shut down the system user right allows a user to shut down the local computer.

The possible values for this Group Policy setting are:

• A user-defined list of accounts.

• Not defined.

Discussion

The ability to shut down domain controllers should be limited to a very small number of trusted administrators. Even though a system shutdown requires the ability to log on to the server, you should be very careful about the accounts and groups that you allow to shut down a domain controller.

Shutting down domain controllers makes them unavailable to perform such functions as processing logons, serving Group Policy, and answering Lightweight Directory Access Protocol (LDAP) queries. Shutting down domain controllers that have been assigned operations master roles (also known as flexible single master operations or FSMO) roles can disable key domain functionality, such as processing logons for new passwords, which is performed by the PDC emulator operations master.

Ensure that only Administrators and Backup Operators have the Shut down the system user right on member servers, and that only Administrators have the user right on domain controllers. Removing these default groups might limit the abilities of users assigned to specific administrative roles in your environment. Ensure that delegated tasks will not be negatively affected.

Location

GPO_name\Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment

Default Values

Server Type or GPO	Default Value
Default Domain Policy	Not defined
Default Domain Controller Policy	Administrators, Backup Operators, Server Operators, Print Operators
Stand-Alone Server Default Settings	Administrators, Power Users, Backup Operators, Users
DC Effective Default Settings	Administrators, Backup Operators, Server Operators, Print Operators
Member Server Effective Default Settings	Administrators, Power Users, Backup Operators, Users

Synchronize directory service data

The Synchronize directory service data user right allows a process to read all objects and properties in the directory, regardless of the protection on the objects and properties. This user right is required in order to use LDAP directory synchronization (Dirsync) services.

The possible values for this Group Policy setting are:

• A user-defined list of accounts.

• Not defined.

Discussion

This user right affects domain controllers; only domain controllers should be able to synchronize directory service data. They have this right inherently because the synchronization process runs in the context of the System account on domain controllers. A malicious user who has this user right can view all information stored within the directory. They can then use some of that information to facilitate additional attacks or expose sensitive corporate data, such as direct telephone numbers or physical addresses.

Ensure that no accounts have the Synchronize directory service data user right.

Location

GPO_name\Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment

Default Values

Server Type or GPO	Default Value
Default Domain Policy	Not defined
Default Domain Controller Policy	No one
Stand-Alone Server Default Settings	Not defined
DC Effective Default Settings	No one
Member Server Effective Default Settings	Not defined

Take ownership of files or other objects

The Take ownership of files or other objects user right allows a user to take ownership of any securable object in the system, including Active Directory objects, NTFS files and folders, printers, registry keys, services, processes, and threads.

The possible values for this Group Policy setting are:

• A user-defined list of accounts.

• Not defined.

Discussion

Any user with this ability can take control of any object regardless of the permissions on that object and then make any changes they want to that object. This can result in exposure of data, corruption of data, or a denial-of-service condition.

Ensure that only the local Administrators group has the Take ownership of files or other objects user right.

Location

GPO_name\Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment

Default Values

Server Type or GPO	Default Value
Default Domain Policy	Not defined
Default Domain Controller Policy	Administrators
Stand-Alone Server Default Settings	Administrators
DC Effective Default Settings	Administrators
Member Server Effective Default Settings	Administrators

Security Options

The Security Options section of Group Policy enables or disables computer security policy settings, such as digital data signing, Administrator and Guest account names, access to floppy disk and CD drives, driver installation behavior, and logon prompts. The Security Options policy settings can be configured in the following location in Group Policy Object Editor:

Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options

Accounts: Administrator account status

The Accounts: Administrator account status policy setting enables or disables the Administrator account under normal operation. When a computer is booted in Safe Mode, the Administrator account is always enabled, regardless of this policy setting.

The possible values for this Group Policy setting are:

• Enabled.

• Disabled.

• Not defined.

Discussion

For some organizations, periodically changing the password for local accounts can be a daunting management challenge, therefore they might want to disable the built-in Administrator account. Another reason to consider disabling this built-in account is that by default it cannot be locked out, no matter how many failed logons it accrues. This makes it a prime target for brute-force password-guessing attacks. Additionally, this account has a well-known security identifier (SID); some non-Microsoft tools allow you to authenticate over the network by specifying the SID rather than the account name. This means that even if you have renamed the Administrator account, a malicious user could start a brute-force attack by using the SID.

Disabling the Administrator account can become a maintenance issue under certain circumstances. For example, in a domain environment, if the secure channel that constitutes your connection fails for any reason, and there is no other local Administrator account, you must restart the computer in Safe Mode to fix the problem that broke your connection status.

If the current Administrator password does not meet the password requirements, you will not be able to enable the Administrator account again after it has been disabled. In this case, another member of the Administrators group must set the password on the Administrator account by using the Local Users and Groups tool.

Location

GPO_name\Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options

Default Values

Server Type or GPO	Default Value
Default Domain Policy	Not defined
Default Domain Controller Policy	Not defined
Stand-Alone Server Default Settings	Enabled
DC Effective Default Settings	Enabled
Member Server Effective Default Settings	Enabled

Accounts: Guest account status

The Accounts: Guest account status policy setting determines whether the Guest account is enabled or disabled.

The possible values for this Group Policy setting are:

• Enabled.

• Disabled.

• Not defined.

Discussion

This account allows unauthenticated network users to gain access to the system by logging in as Guest with no password. Unauthorized users can access any resources that are accessible to the Guest account over the network. This means that any network shares with permissions allowing access to the Guest account, the Guests group, or the Everyone group will be accessible over the network. This can lead to the exposure or corruption of data.

Set Accounts: Guest account status to Disabled so that the built-in Guest account is no longer usable. All network users will have to authenticate before they can access shared resources on the system. If the Guest account is disabled and Network access: Sharing and security model for local accounts is set to Guest only, network logons—such as those performed by the SMB Service—will fail. This should have little impact on most organizations because it is the default value for this policy setting in Windows 2000, Windows XP, and Windows Server 2003.

Location

GPO_name\Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options

Default Values

Server Type or GPO	Default Value
Default Domain Policy	Not defined
Default Domain Controller Policy	Not defined
Stand-Alone Server Default Settings	Disabled
DC Effective Default Settings	Disabled
Member Server Effective Default Settings	Disabled

Accounts: Limit local account use of blank passwords to console logon only

The Accounts: Limit local account use of blank passwords to console logon only policy setting determines whether remote interactive logons by network services such as Terminal Services, Telnet, and File Transfer Protocol (FTP) are allowed for local accounts that have blank passwords. If this policy setting is enabled, a local account must have a nonblank password to be used to perform an interactive or network logon from a remote client.

The possible values for this Group Policy setting are:

• Enabled.

• Disabled.

• Not defined.

Discussion

This policy setting does not affect interactive logons that are performed physically at the console, or logons that use domain accounts. It is possible for non-Microsoft applications that use remote interactive logons to bypass this policy setting.

Blank passwords are a serious threat to computer security and they should be forbidden through both corporate policy and suitable technical measures. In fact, the default policy settings for Windows Server 2003 Active Directory domains require complex passwords of at least seven characters. Nevertheless, if a user with the ability to create new accounts creates one that has bypassed your domain-based password policy settings, that account might have a blank password. For example, a user could build a stand-alone system, create one or more accounts with blank passwords, and then join the computer to the domain. The local accounts with blank passwords would still function. Anyone who knows the account name can then use accounts with blank passwords to log on to systems.

It is advisable to set Accounts: Limit local account use of blank passwords to console logon only to Enabled.

Location

GPO_name\Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options

Default Values

Server Type or GPO	Default Value
Default Domain Policy	Not defined
Default Domain Controller Policy	Not defined
Stand-Alone Server Default Settings	Enabled
DC Effective Default Settings	Enabled
Member Server Effective Default Settings	Enabled

Accounts: Rename administrator account

The Accounts: Rename administrator account policy setting determines whether a different account name is associated with the SID for the Administrator account.

The possible values for this Group Policy setting are:

• User-defined text.

• Not defined.

Discussion

Because the Administrator account exists on all Windows 2000, Windows Server 2003, and Windows XP Professional computers, renaming the account makes it slightly more difficult for attackers to guess this user name and password combination. By default, the built-in Administrator account cannot be locked out no matter how many times a malicious user might use a bad password. This makes the Administrator account a popular target for brute-force password-guessing attacks. The value of this countermeasure is lessened because this account has a well-known SID and there are non-Microsoft tools that allow you to initiate a brute-force attack over the network by specifying the SID rather than the account name. This means that even if you have renamed the Administrator account, a malicious user could start a brute-force attacking by using the SID.

Rename the Administrator account by specifying a value for the Accounts: Rename administrator account policy setting.

This policy setting is not configured in the security templates, nor is a new user name for the account suggested here. This is so that numerous organizations reading this guide will not implement the same new user name in their environments.

Be sure to inform users who are authorized to use this account of the new account name.

Location

GPO_name\Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options

Default Values

Server Type or GPO	Default Value
Default Domain Policy	Not defined
Default Domain Controller Policy	Not defined
Stand-Alone Server Default Settings	Administrator
DC Effective Default Settings	Administrator
Member Server Effective Default Settings	Administrator

Accounts: Rename guest account

The Accounts: Rename guest account policy setting determines whether a different account name is associated with the SID for the Guest account.

The possible values for this Group Policy setting are:

• User-defined text.

• Not defined.

Discussion

Because the Guest account exists on all Windows 2000, Windows Server 2003, and Windows XP Professional computers, renaming the Guest account makes it slightly more difficult for unauthorized persons to guess this privileged user name and password combination.

Rename the Guest account by specifying a value for the Accounts: Rename guest account policy setting.

This policy setting is not configured in the security templates.

The Guest account is disabled by default in Windows 2000, Windows XP, and Windows Server 2003.

Location

GPO_name\Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options

Default Values

Server Type or GPO	Default Value
Default Domain Policy	Not defined
Default Domain Controller Policy	Not defined
Stand-Alone Server Default Settings	Guest
DC Effective Default Settings	Guest
Member Server Effective Default Settings	Guest

Audit: Audit the access of global system objects

Enabling the Audit: Audit the access of global system objects policy setting creates system objects—such as mutexes, events, semaphores, and MS-DOS devices—with a default SACL. If the Audit object access policy setting is also enabled, access to these system objects is audited.

Global system objects, also known as base system objects or base named objects, are ephemeral kernel objects that have had names assigned to them by the application or system component that created them. These objects are most commonly used to synchronize multiple applications or multiple parts of a complex application. By virtue of having a name, these objects are global in scope, and therefore visible to all processes on the system. These objects all have a security descriptor, but typically have a NULL SACL. Enabling this policy setting at boot time causes the kernel to assign an SACL to these objects when they are created.

The possible values for this Group Policy setting are:

• Enabled.

• Disabled.

• Not defined.

Discussion

The threat is that a globally visible named object, if incorrectly secured, might be acted on by a malicious program that knows the name of the object. For instance, if a synchronization object such as a mutex has a poorly chosen discretionary access control list (DACL), a malicious program can access that mutex by name and cause the program that created it to malfunction; however, the risk of this occurring is very low.

Enabling this policy setting can generate a large number of security events, especially on busy domain controllers and application servers. This might cause servers to respond slowly and force the security log to record numerous events of little significance. Auditing for access to global system objects is an all-or-nothing affair; there is no way to filter which events get recorded and which do not. Even if an organization has the resources to analyze events generated when this policy setting is enabled, it is unlikely to have the source code or a description of what each named object is used for; therefore, it is unlikely that many organizations could benefit from enabling this policy setting.

Location

GPO_name\Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options

Default Values

Server Type or GPO	Default Value
Default Domain Policy	Not defined
Default Domain Controller Policy	Not defined
Stand-Alone Server Default Settings	Disabled
DC Effective Default Settings	Disabled
Member Server Effective Default Settings	Disabled

Audit: Audit the use of Backup and Restore privilege

The Audit: Audit the use of Backup and Restore privilege policy setting determines whether to audit the use of all user rights, including Backup and Restore, when the Audit privilege use policy setting is configured. Enabling both policy settings generates an audit event for every file that is backed up or restored.

Enabling this policy setting in conjunction with the Audit privilege use policy setting records any instance of user rights being exercised in the security log. If Audit privilege use is enabled but Audit: Audit the use of Backup and Restore privilege is disabled, when users use Backup or Restore user rights, those events will not be audited.

The possible values for this Group Policy setting are:

• Enabled.

• Disabled.

• Not defined.

Discussion

Enabling this policy setting when the Audit privilege use policy setting is also enabled generates an audit event for every file that is backed up or restored. This can help you to track down an administrator who is accidentally or maliciously restoring data in an unauthorized manner.

It is advisable to set Audit use of Backup and Restore privilege to Disabled. Enabling this policy setting can generate a large number of security events, which might cause servers to respond slowly and force the security log to record numerous events of little significance.

Location

GPO_name\Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options

Default Values

Server Type or GPO	Default Value
Default Domain Policy	Not defined
Default Domain Controller Policy	Not defined
Stand-Alone Server Default Settings	Disabled
DC Effective Default Settings	Disabled
Member Server Effective Default Settings	Disabled

Audit: Shut down system immediately if unable to log security audits

Note

• Misuse of this policy setting is a common error that can cause data loss or problems with data access or security.

The Audit: Shut down system immediately if unable to log security audits policy setting determines whether the system shuts down if it is unable to log security events. This policy setting is a requirement for Trusted Computer System Evaluation Criteria (TCSEC)-C2 and Common Criteria certification to prevent auditable events from occurring if the audit system is unable to log those events. Microsoft has chosen to meet this requirement by halting the system and displaying a Stop message in the case of a failure of the auditing system. Enabling this policy setting stops the system if a security audit cannot be logged for any reason. Typically, an event fails to be logged when the security audit log is full and the value of Retention method for security log is either Do not overwrite events (clear log manually) or Overwrite events by days.

With Audit: Shut down system immediately if unable to log security audits set to Enabled, if the security log is full and an existing entry cannot be overwritten, the following Stop message appears:

STOP: C0000244 {Audit Failed}

An attempt to generate a security audit failed.

To recover, an administrator must log on, archive the log (optional), clear the log, and reset this option as desired.

The possible values for this Group Policy setting are:

• Enabled.

• Disabled.

• Not defined.

Discussion

If the computer is unable to record events to the security log, critical evidence or important troubleshooting information might not be available for review after a security incident.

The administrative burden of enabling this policy setting can be very high, especially if you also set the Retention methodfor security log to Do not overwrite events (clear log manually). This setting turns a repudiation threat (a backup operator could deny that they backed up or restored data) into a denial-of-service threat, because a server can be forced to shut down if it is overwhelmed with logon events and other security events that are written to the security log. Additionally, because the shutdown is not graceful, it is possible that irreparable damage to the operating system, applications, or data could result. Although NTFS will guarantee that the file system's integrity will be maintained during a sudden system shutdown, it cannot guarantee that every data file for every application will still be in a usable form when the system is restarted.

Location

GPO_name\Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options

Default Values

Server Type or GPO	Default Value
Default Domain Policy	Not defined
Default Domain Controller Policy	Not defined
Stand-Alone Server Default Settings	Disabled
DC Effective Default Settings	Disabled
Member Server Effective Default Settings	Disabled

Devices: Allow undock without having to log on

The Devices: Allow undock without having to log on policy setting determines whether a user must log on to request permission to remove a portable computer from a docking station. Enabling this policy setting allows a user to undock a computer by pressing the portable computer's physical eject button. Disabling this policy setting requires that the user log on to get undocking permission. Only users who have the Remove computer from docking station user right can be assigned this permission.

The possible values for this Group Policy setting are:

• Enabled.

• Disabled.

• Not defined.

Discussion

This policy setting should only be disabled for portable computers that cannot be mechanically undocked. Otherwise, enabling the policy setting allows a user to physically remove the computer when they cannot log in and the eject button does not work.

Enabling this policy setting means that anyone with physical access to a computer that has been placed in its docking station can remove the computer and possibly tamper with it. For computers that do not have docking stations, this policy setting has no impact. However, for users with a mobile computer that is normally docked while they are in the office, this policy setting will help lower the risk of equipment theft or a malicious user gaining physical access to these computers.

It is advisable to disable the Devices: Allow undock without having to log on policy setting. Users who have docked their computers will have to log on to the local console before they can undock their systems.

Location

GPO_name\Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options

Default Values

Server Type or GPO	Default Value
Default Domain Policy	Not defined
Default Domain Controller Policy	Not defined
Stand-Alone Server Default Settings	Enabled
DC Effective Default Settings	Enabled
Member Server Effective Default Settings	Enabled

Devices: Allowed to format and eject removable media

The Devices: Allowed to format and eject removable media policy setting determines who is allowed to format and eject removable media.

The possible values for this Group Policy setting are:

• Administrators.

• Administrators and Power Users.

• Administrators and Interactive Users.

• Not defined.

Discussion

Users can move removable disks to a different computer where they have administrative user rights and then take ownership of any file, assign themselves full control, and view or modify any file. The advantage of configuring this policy setting is diminished by the fact that most removable storage devices will eject media with the press of a button.

It is advisable to set Allowed to format and eject removable media to Administrators. Only administrators will be able to eject NTFS-formatted removable media.

Location

GPO_name\Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options

Default Values

Server Type or GPO	Default Value
Default Domain Policy	Not defined
Default Domain Controller Policy	Not defined
Stand-Alone Server Default Settings	Administrators
DC Effective Default Settings	Administrators
Member Server Effective Default Settings	Administrators

Devices: Prevent users from installing printer drivers

For a computer to print to a network printer, the driver for that network printer must be installed on the local computer. The Devices: Prevent users from installing printer drivers policy setting determines who can install a printer driver as part of adding a network printer. When you set the value to Enabled, only Administrators and Power Users can install a printer driver as part of adding a network printer. Setting the value to Disabled allows any user to install a printer driver as part of adding a network printer. This setting prevents unprivileged users from downloading and installing an untrusted printer driver.

This setting has no impact if an administrator has configured a trusted path for downloading drivers. When using trusted paths, the print subsystem attempts to use the trusted path to download the driver. If the trusted path download succeeds, the driver is installed on behalf of any user. If the trusted path download fails, the driver is not installed and the network printer is not added.

The possible values for this Group Policy setting are:

• Enabled.

• Disabled.

• Not defined.

Discussion

Although it might be appropriate in some organizations to allow users to install printer drivers on their own workstations, this is not suitable for servers. Installing a printer driver on a server can cause the system to become less stable. Only administrators should have this user right on servers. A malicious user might deliberately try to damage the system by installing inappropriate printer drivers.

It is advisable to set Devices: Prevent users from installing printer drivers to Enabled. Only users in the Administrative, Power User, or Server Operator groups will be able to install printers on servers. If this policy setting is enabled, but the driver for a network printer already exists on the local computer, users can still add the network printer. This policy setting does not affect a user's ability to add a local printer.

Location

GPO_name\Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options

Default Values

Server Type or GPO	Default Value
Default Domain Policy	Not defined
Default Domain Controller Policy	Not defined
Stand-Alone Server Default Settings	Enabled
DC Effective Default Settings	Enabled
Member Server Effective Default Settings	Enabled

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

The Devices: Restrict CD-ROM access to locally logged-on user only policy setting determines whether a CD-ROM will be accessible to both local and remote users simultaneously. Enabling this policy setting allows only the interactively logged-on user to access removable CD-ROM media. If this policy setting is enabled and no one is logged on interactively, the CD-ROM can be accessed over the network.

The possible values for these Group Policy settings are:

• Enabled.

• Disabled.

• Not defined.

Discussion

The security benefit of enabling this policy setting is small because it only prevents network users from accessing the drive when someone is logged on to the local console of the system at the same time. Additionally, CD drives are not automatically made available as network shares; administrators must deliberately choose to share the drive. This is important when administrators are installing software or copying data from a CD-ROM and they do not want network users to be able to execute the applications or view the data.

If this policy setting is enabled, users connecting to the server over the network will not be able to use any CD drives installed on the server whenever anyone is logged on to the local console of the server. Enabling this policy setting is not suitable for a system that serves as a CD jukebox for network users.

Location

GPO_name\Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options

Default Values

Server Type or GPO	Default Value
Default Domain Policy	Not defined
Default Domain Controller Policy	Not defined
Stand-Alone Server Default Settings	Disabled
DC Effective Default Settings	Disabled
Member Server Effective Default Settings	Disabled

Devices: Restrict floppy access to locally logged-on user only

The Devices: Restrict floppy access to locally logged-on user only policy setting determines whether removable floppy disks are accessible to both local and remote users simultaneously. Enabling this policy setting allows only the interactively logged-on user to access removable floppy disks. If this policy setting is enabled and no one is logged on interactively, the floppy disk can be accessed over the network.

The possible values for these Group Policy settings are:

• Enabled.

• Disabled.

• Not defined.

Discussion

The security benefit of enabling this policy setting is small because it only prevents network users from accessing the floppy disk drive when someone is logged on to the local console of the system at the same time. Additionally, floppy disk drives are not automatically made available as network shares; administrators must deliberately choose to share the drive. This becomes important when administrators are installing software or copying data from a floppy disk and they do not want network users to be able to execute the applications or view the data.

If this policy setting is enabled, users connecting to the server over the network will not be able to use any floppy disk drives installed on the server whenever anyone is logged on to the local console of the server.

Location

GPO_name\Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options

Default Values

Server Type or GPO	Default Value
Default Domain Policy	Not defined
Default Domain Controller Policy	Not defined
Stand-Alone Server Default Settings	Disabled
DC Effective Default Settings	Disabled
Member Server Effective Default Settings	Disabled

Devices: Unsigned driver installation behavior

The Devices: Unsigned driver installation behavior policy setting determines what happens when a user attempts to install a device driver that has not been certified by the Windows Hardware Quality Lab (WHQL) by means of Setup API.

The possible values for this Group Policy setting are:

• Silently succeed.

• Warn but allow installation.

• Do not allow installation.

• Not defined.

Discussion

This policy setting can prevent the installation of unsigned drivers or warn the administrator that an unsigned driver software is about to be installed. It can prevent Setup API from installing drivers that have not been certified to run on Windows Server 2003. This policy setting will not prevent a method used by some attack tools in which malicious .sys files are copied and registered to start as system services.

It is advisable to set Unsigned driver installation behavior to Warn but allow installation. This differs from the default value for this policy setting in Windows Server 2003, which is Not defined. A potential problem with setting Unsigned driver installation behavior to Warn but allow installation is that users who have sufficient user rights to install device drivers will still be able to install unsigned device drivers, which can result in stability problems for system servers. Another potential problem with this setting is that unattended installation scripts will fail if they attempt to install unsigned drivers.

Location

GPO_name\Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options

Default Values

Server Type or GPO	Default Value
Default Domain Policy	Not defined
Default Domain Controller Policy	Not defined
Stand-Alone Server Default Settings	Warn but allow installation
DC Effective Default Settings	Warn but allow installation
Member Server Effective Default Settings	Warn but allow installation

Domain controller: Allow server operators to schedule tasks

The Domain controller: Allow server operators to schedule tasks policy setting determines whether users in the Server Operators group are allowed to submit jobs by means of the AT schedule service. This security option only affects the AT schedule facility, it does not affect the Task Scheduler service.

The possible values for this Group Policy setting are:

• Enabled.

• Disabled.

• Not defined.

Discussion

Enabling this policy setting means that jobs created by server operators via the AT service will be executed in the context of the account that is running that service—by default, that is the local System account. This means that server operators can perform tasks that the System account is able to do but server operators would normally not be able to do, such as add their account to the local Administrators group.

The impact of enabling this policy setting should be small for most organizations. Users, including those in the Server Operators group, will still be able to create jobs by using the Task Scheduler Wizard, but those jobs will run in the context of the account the user authenticated with when they set up the job.

Location

GPO_name\Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options

Default Values

Server Type or GPO	Default Value
Default Domain Policy	Not defined
Default Domain Controller Policy	Not defined
Stand-Alone Server Default Settings	Not defined
DC Effective Default Settings	Not defined
Member Server Effective Default Settings	Not defined

Domain controller: LDAP server signing requirements

Note

• Misuse of this policy setting is a common error that can cause data loss or problems with data access or security.

The Domain controller: LDAP server signing requirements policy setting determines whether the LDAP server requires LDAP clients to negotiate data signing.

The possible values for this Group Policy setting are:

• None.

  Data signing is not required in order to bind with the server. If the client requests data signing, the server supports it.

• Require signature.

  The LDAP data-signing option must be negotiated unless Transport Layer Security/Secure Sockets Layer (TLS/SSL) is being used.

• Not defined.

Discussion

Unsigned network traffic is susceptible to man-in-the-middle attacks, where an intruder captures packets between the server and the client and modifies them before forwarding them to the client. In the case of an LDAP server, this means that a malicious user can cause a client to make decisions based on false records from the LDAP directory. You can lower the risk of a malicious user accomplishing this in a corporate network by implementing strong physical security measures to protect the network infrastructure. Furthermore, implementing Internet Protocol security (IPsec) Authentication Header (AH) mode, which provides mutual authentication and packet integrity for IP traffic, can make all types of man-in-the-middle attacks extremely difficult.

It is advisable to set Domain controller: LDAP server signing requirements to Require signature. Clients that do not support LDAP signing will be unable to execute LDAP queries against the domain controllers. This means that all computers in your organization that are managed from Windows Server 2003 or Windows XP-based computers using NTLM authentication and the Windows Server 2003 Administration Tools Pack must either have Windows 2000 Service Pack 3 (SP3) or later installed.

Location

GPO_name\Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options

Default Values

Server Type or GPO	Default Value
Default Domain Policy	Not defined
Default Domain Controller Policy	None
Stand-Alone Server Default Settings	Not defined
DC Effective Default Settings	None
Member Server Effective Default Settings	Not defined

Domain controller: Refuse machine account password changes

The Domain controller: Refuse machine account password changes policy setting determines whether or not a domain controller will accept password change requests for computer accounts.

The possible values for this Group Policy setting are:

• Enabled.

• Disabled.

• Not defined.

Discussion

Enabling this policy setting on all domain controllers in a domain prevents domain members from changing their computer account passwords. This, in turn, leaves those passwords susceptible to attack.

Location

GPO_name\Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options

Default Values

Server Type or GPO	Default Value
Default Domain Policy	Not defined
Default Domain Controller Policy	Not defined
Stand-Alone Server Default Settings	Not defined
DC Effective Default Settings	Not defined
Member Server Effective Default Settings	Not defined

Domain member: Digitally encrypt or sign secure channel data (multiple related policy settings)

Note

• Misuse of these policy settings is a common error that can cause data loss or problems with data access or security.

The following policy settings determine whether a secure channel can be established with a domain controller that is not capable of signing or encrypting secure channel traffic:

• 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)

Setting Domain member: Digitally encrypt or sign secure channel data (always) to Enabled prevents establishing a secure channel with any domain controller that cannot sign or encrypt all secure channel data.

To protect authentication traffic from man-in-the-middle, replay, and other types of network attacks, Windows-based computers create a communication channel through NetLogon called secure channels. These channels authenticate computer accounts. They also authenticate user accounts when a remote user connects to a network resource and the user account exists in a trusted domain. This is called pass-through authentication, and it allows a computer running Windows that has joined a domain to have access to the user account database in its domain and in any trusted domains.

To enable the Domain member: Digitally encrypt or sign secure channel data (always) policy setting on a member workstation or server, all domain controllers in the domain that the member belongs to must be capable of signing or encrypting all secure-channel data. This means that all such domain controllers must be running Windows NT 4.0 Service Pack 6a (SP6a) or later.

Enabling the Domain member: Digitally encrypt or sign secure channel data (always) policy setting automatically enables the Domain member: Digitally sign secure channel data (when possible) policy setting.

The possible values for this Group Policy setting are:

• Enabled.

• Disabled.

• Not defined.

When a Windows Server 2003 system joins a domain, a computer account is created. After joining the domain, the computer uses the password for that account to create a secure channel with the domain controller for its domain every time that it restarts. Requests sent on the secure channel are authenticated—and sensitive information such as passwords are encrypted—but the integrity of the channel is not checked, and not all information is encrypted. If a system is set to always encrypt or sign secure channel data, a secure channel cannot be established with a domain controller that is not capable of signing or encrypting all secure channel traffic. If the computer is configured to encrypt or sign secure channel data when possible, a secure channel can be established, but the level of encryption and signing is negotiated.

The following values are advised:

• Set Domain member: Digitally encrypt or sign secure channel data (always) to Enabled.

• Set Domain member: Digitally encrypt secure channel data (when possible) to Enabled.

• Set Domain member: Digitally sign secure channel data (when possible) to Enabled.

Digital encryption and signing of the secure channel is a good idea where it is supported. The secure channel protects domain credentials as they are sent to the domain controller. However, only Windows NT 4.0 SP6a or later supports digital encryption and signing of the secure channel. Windows 98 Second Edition clients do not support it (unless they have the dsclient installed). Thus, you cannot enable the Domain member: Digitally encrypt or sign secure channel data (always) policy setting on domain controllers that support Windows 98 clients as members of the domain. The potential impact of such a setting can include making it impossible to create or delete trust relationships with earlier versions, disabling logons from earlier-version clients, and not being able to authenticate other domains' users from a trusted domain that is running an earlier version of Windows.

You can enable this policy setting after you eliminate all Windows 95, Windows 98, and Windows Millennium Edition clients from the domain and upgrade all Windows NT 4.0 servers and domain controllers from trusted or trusting domains to Windows NT 4.0 SP6a. You can enable the other two policy settings, Domain member: Digitally encrypt secure channel data (when possible) and Domain member: Digitally sign secure channel data (when possible), on all computers in the domain that support these policy settings without affecting earlier-version clients and applications.

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

Note

• Misuse of this policy setting is a common error that can cause data loss or problems with data access or security.

Location

GPO_name\Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options

Default Values

Server Type or GPO	Default Value
Default Domain Policy	Not defined
Default Domain Controller Policy	Enabled
Stand-Alone Server Default Settings	Enabled
DC Effective Default Settings	Enabled
Member Server Effective Default Settings	Enabled

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

Note

• Misuse of this policy setting is a common error that can cause data loss or problems with data access or security.

Location

GPO_name\Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options

Default Values

Server Type or GPO	Default Value
Default Domain Policy	Not defined
Default Domain Controller Policy	Not defined
Stand-Alone Server Default Settings	Enabled
DC Effective Default Settings	Enabled
Member Server Effective Default Settings	Enabled

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

Note

• Misuse of this policy setting is a common error that can cause data loss or problems with data access or security.

Location

GPO_name\Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options

Default Values

Server Type or GPO	Default Value
Default Domain Policy	Not defined
Default Domain Controller Policy	Not defined
Stand-Alone Server Default Settings	Enabled
DC Effective Default Settings	Enabled
Member Server Effective Default Settings	Enabled

Domain member: Disable machine account password changes

The Domain member: Disable machine account password changes policy setting determines whether a domain member periodically changes its computer account password. Setting its value to Enabled prevents the domain member from changing its computer account password. Setting it to Disabled allows the domain member to change its computer account password as specified by the value of the Domain member: Maximum machine account password age policy setting, which is every 30 days by default.

Do not enable this policy setting. Computer account passwords are used to establish secure channel communications between members and domain controllers and—within the domain—between the domain controllers themselves. After it is established, the secure channel transmits sensitive information that is necessary for making authentication and authorization decisions.

Do not use this policy setting in an attempt to support dual-boot scenarios that use the same computer account. If you want to dual-boot two installations that are joined to the same domain, give the two installations different computer names. This policy setting was added to Windows to make it easier for organizations that stockpile prebuilt computers that are put into production months later; those computers do not have to be rejoined to the domain.

The possible values for this Group Policy setting are:

• Enabled.

• Disabled.

• Not defined.

Discussion

The default configuration for computers running Windows Server 2003 that belong to a domain is that they are automatically required to change the passwords for their accounts every 30 days. Disabling this feature causes computers running Windows Server 2003 to retain the same passwords as their computer accounts. Computers that are no longer able to automatically change their account password are at risk of a malicious user determining the password for the system's domain account.

Verify that the Domain member: Disable machine account password changes option is set to Disabled.

Location

GPO_name\Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options

Default Values

Server Type or GPO	Default Value
Default Domain Policy	Not defined
Default Domain Controller Policy	Not defined
Stand-Alone Server Default Settings	Disabled
DC Effective Default Settings	Disabled
Member Server Effective Default Settings	Disabled

Domain member: Maximum machine account password age

The Domain member: Maximum machine account password age policy setting determines the maximum allowable age for a computer account password. This policy setting also applies to computers running Windows 2000, but it is not available through the Security Configuration Manager tools on those computers.

The possible values for this Group Policy setting are:

• A user-defined number of days from 0 through 999.

• Not defined.

Discussion

In Active Directory–based domains, each computer has an account and password just like every user. By default, the domain members automatically change their domain password every 30 days. Increasing this interval significantly, or setting it to 0 so that the computers no longer change their passwords, gives a malicious user more time to undertake a brute-force password-guessing attack against one of the computer accounts.

It is often advisable to set Domain member: Maximum machine account password age to about 30 days.

Some organizations prebuild computers and then store them for later use or ship them to remote locations. If the computer's account has expired, it will no longer be able to authenticate with the domain. Computers that cannot authenticate with the domain must be removed from the domain and rejoined to it. For this reason, some organizations might want to create a special OU for computers that are prebuilt and configure the value for this policy setting to a larger number of days.

Location

GPO_name\Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options

Default Values

Server Type or GPO	Default Value
Default Domain Policy	Not defined
Default Domain Controller Policy	Not defined
Stand-Alone Server Default Settings	30 days
DC Effective Default Settings	30 days
Member Server Effective Default Settings	30 days

Domain member: Require strong (Windows 2000 or later) session key

Note

• Misuse of this policy setting is a common error that can cause data loss or problems with data access or security.

The Domain member: Require strong (Windows 2000 or later) session key policy setting determines whether a secure channel can be established with a domain controller that is not capable of encrypting secure channel traffic with a strong, 128-bit session key. Enabling this policy setting prevents establishing a secure channel with any domain controller that cannot encrypt secure channel data with a strong key. Disabling this policy setting allows 64-bit session keys.

Note

• To enable this policy setting on a member workstation or server, all domain controllers in the domain that the member belongs to must be capable of encrypting secure channel data with a strong, 128-bit key. This means that all such domain controllers must be running Windows 2000 or Windows Server 2003.

The possible values for this Group Policy setting are:

• Enabled.

• Disabled.

• Not defined.

Discussion

Session keys used to establish secure channel communications between domain controllers and member computers are much stronger in Windows 2000 and Windows Server 2003 than they were in previous Microsoft operating systems.

Whenever possible, you should take advantage of these stronger session keys to help protect secure channel communications from eavesdropping and session-hijacking network attacks. Eavesdropping is a form of hacking in which network data is read or altered in transit. The data can be modified to hide or change the name of the sender, or it can be redirected.

It is advisable to set Domain member: Require strong (Windows 2000 or later) session key to Enabled. Enabling this policy setting ensures that all outgoing secure channel traffic will require a strong, Windows 2000 or Windows Server 2003 encryption key. Disabling this policy setting requires that key strength be negotiated. Only enable this option if the domain controllers in all trusted domains support strong keys. By default, this value is disabled.

You will not be able to join computers with this policy setting enabled to Windows NT 4.0 domains, nor will you be able to join computers that do not support this policy setting to domains where the domain controllers have this policy setting enabled.

Location

GPO_name\Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options

Default Values

Server Type or GPO	Default Value
Default Domain Policy	Not defined
Default Domain Controller Policy	Not defined
Stand-Alone Server Default Settings	Disabled
DC Effective Default Settings	Disabled
Member Server Effective Default Settings	Disabled

Interactive logon: Do not display last user name

The Interactive logon: Do not display last user name policy setting determines whether the Log on to Windows dialog box displays the name of the last user who logged on to the computer. If the value is Enabled, the Log on to Windows dialog box does not display the name of the last user who logged on. If it is Disabled, the dialog box does display the name of the last user to log on.

The possible values for this Group Policy setting are:

• Enabled.

• Disabled.

• Not defined.

Discussion

A malicious user with access to the console—for example, someone with physical access or someone who is able to connect to the server via Terminal Services—can view the name of the last user who logged on to the server. The attacker might then attempt to log on to the server by guessing the password, using a dictionary, or by brute-force attack.

It is advisable to set Do not display last user name in logon screen to Enabled. Users will always have to type their user names when they log on to the servers.

Location

GPO_name\Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options

Default Values

Server Type or GPO	Default Value
Default Domain Policy	Not defined
Default Domain Controller Policy	Not defined
Stand-Alone Server Default Settings	Disabled
DC Effective Default Settings	Disabled
Member Server Effective Default Settings	Disabled

Interactive logon: Do not require CTRL+ALT+DEL

The Interactive logon: Do not require CTRL+ALT+DEL policy setting determines whether pressing CTRL+ALT+DELETE is required before a user can log on. Enabling this policy setting on a computer allows a user to log on without pressing CTRL+ALT+DELETE. Disabling this policy setting requires users to press CTRL+ALT+DELETE before logging on, unless they are using a smart card for Windows logon. A smart card is a tamper-proof device that stores security information.

The possible values for this Group Policy setting are:

• Enabled.

• Disabled.

• Not defined.

Discussion

Microsoft developed this feature to make it easier for users with certain types of physical impairments to log on to computers running Windows; however, not having to press the CTRL+ALT+DELETE key combination leaves users susceptible to attacks that attempt to intercept their passwords. Requiring CTRL+ALT+DELETE before users log on ensures that users are communicating by means of a trusted path when entering their passwords.

A malicious user might install a Trojan horse program that looks like the standard Windows logon dialog box and capture a user's password. The attacker can then log on to the compromised account with whatever level of user rights that user has.

It is advisable to set Disable CTRL+ALT+DEL requirement for logon to Disabled. Unless they are using a smart card to log on, users will have to simultaneously press three keys before the logon dialog box appears.

Location

GPO_name\Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options

Default Values

Server Type or GPO	Default Value
Default Domain Policy	Not defined
Default Domain Controller Policy	Not defined
Stand-Alone Server Default Settings	Disabled
DC Effective Default Settings	Disabled
Member Server Effective Default Settings	Disabled

Interactive logon: Message text for users attempting to log on

The Interactive logon: Message text for users attempting to log on and Interactive logon: Message title for users attempting to log on policy settings are closely related. Interactive logon: Message text for users attempting to log on specifies a text message to be displayed to users when they log on. Interactive logon: Message title for users attempting to log on specifies a title to appear in the title bar of the window that contains the text message. This text is often used for legal reasons — for example, to warn users about the ramifications of misusing company information, or to warn them that their actions might be audited.

Windows XP Professional adds support for configuring logon banners that can exceed 512 characters in length and can also contain carriage return/line feed sequences. However, Windows 2000 clients cannot interpret and display message text that is created by Windows XP Professional computers. You must use a Windows 2000 computer to create a logon message that applies to Windows 2000 computers. If you inadvertently create a logon message by using a Windows XP Professional computer, and you discover that it is not displayed properly on Windows 2000 computers, do the following:

• Undefine the setting.

• Redefine the setting by using a Windows 2000 computer.

Simply changing a Windows XP Professional–defined logon message setting by using a Windows 2000 computer does not work. The setting must be undefined first.

The possible values for these Group Policy settings are:

• User-defined text.

• Not defined.

Discussion

Not using this warning-message policy setting leaves your organization legally vulnerable to trespassers who unlawfully penetrate your network. Legal precedents have established that organizations that display warnings to users who connect to their servers over a network have a higher rate of successfully prosecuting trespassers.

It is advisable to set Message text for users attempting to log on to the following value:

This system is restricted to authorized users. Individuals attempting unauthorized access will be prosecuted. If unauthorized, terminate access now! Clicking OK indicates your acceptance of the information in the background.

It is advisable to set Message title for users attempting to log on to a value similar to the following:

IT IS AN OFFENSE TO CONTINUE WITHOUT PROPER AUTHORIZATION.

Any warning that you display should first be approved by representatives from your organization's legal and human resources departments.

When these policy settings are configured, users will see a dialog box before they can log on to the server console.

Location

GPO_name\Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options

Default Values

Server Type or GPO	Default Value
Default Domain Policy	Not defined
Default Domain Controller Policy	Not defined
Stand-Alone Server Default Settings	Not defined
DC Effective Default Settings	Not defined
Member Server Effective Default Settings	Not defined

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

The Interactive logon: Number of previous logons to cache (in case domain controller is not available) policy setting determines whether a user can log on to a Windows domain by using cached account information. Logon information for domain accounts can be cached locally so that, if a domain controller cannot be contacted on subsequent logons, a user can still log on. This policy setting determines the number of unique users whose logon information is cached locally.

If a domain controller is unavailable and a user's logon information is cached, the user is prompted with the following message:

A domain controller for your domain could not be contacted. You have been logged on using cached account information. Changes to your profile since you last logged on might not be available.

If a domain controller is unavailable and a user's logon information is not cached, the user is prompted with this message:

The system cannot log you on now because the domain <DOMAIN_NAME> is not available.

The possible values for this Group Policy setting are:

• A user-defined number from 0 through 50.

• Not defined.

Discussion

The value of this policy setting indicates the number of users whose logon information the server caches locally. If the value is 10, the server caches logon information for 10 users. When an eleventh user logs on to the computer, the server overwrites the oldest cached logon session.

Users who access the server console will have their logon credentials cached on that server. A malicious user who is able to access the file system of the server can locate this cached information and use a brute-force attack to determine user passwords. Windows mitigates this type of attack by encrypting the information and keeping the cached credentials in the system's registries, which are spread across numerous physical locations.

It is advisable to set Interactive logon: Number of previous logons to cache (in case domain controller is not available) to 0. Setting this value to 0 disables the local caching of logon information. Additional countermeasures include enforcing strong password policies and physically securing the computers. If the value is set to 0, users will be unable to log on to any computers if there is no domain controller available to authenticate them. Organizations might want to set Interactive logon: Number of previous logons to cache (in case domain controller is not available) to 2 for end-user systems, especially for mobile users. Setting this value to 2 means that the user's logon information will still be in the cache even if a member of the IT department has recently logged on to their computer to perform system maintenance. This way, those users will be able to log on to their computers when they are not connected to the corporate network.

Location

GPO_name\Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options

Default Values

Server Type or GPO	Default Value
Default Domain Policy	Not defined
Default Domain Controller Policy	Not defined
Stand-Alone Server Default Settings	10 logons
DC Effective Default Settings	10 logons
Member Server Effective Default Settings	10 logons

Interactive logon: Prompt user to change password before expiration

The Interactive logon: Prompt user to change password before expiration policy setting determines how many days in advance users are warned that their passwords are about to expire. With this advance warning, the user has time to construct a password that is sufficiently strong.

The possible values for this Group Policy setting are:

• A user-defined number of days from 1 through 999.

• Not defined.

Discussion

It is recommended that user passwords be configured to expire periodically. Users will need warning their passwords are going to expire, or they might inadvertently get locked out of the system. This could lead to confusion for users who access the network locally, or make it impossible for users who access the network via dial-up or virtual private network (VPN) connections to log on.

It is advisable to set Prompt user to change password before expiration to 14 days. When their password expiration date is 14 or fewer days away, users will see a dialog box each time they log on to the domain.

Location

GPO_name\Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options

Default Values

Server Type or GPO	Default Value
Default Domain Policy	Not defined
Default Domain Controller Policy	Not defined
Stand-Alone Server Default Settings	14 days
DC Effective Default Settings	14 days
Member Server Effective Default Settings	14 days

Interactive logon: Require Domain Controller authentication to unlock workstation

Unlocking a locked computer requires logon information. For domain accounts, the Interactive logon: Require Domain Controller authentication to unlock workstation policy setting determines whether it is necessary to contact a domain controller to unlock a computer. Enabling this policy setting requires a domain controller to authenticate the domain account that is being used to unlock the computer. Disabling this policy setting allows a user to unlock the computer without the computer verifying the logon information with a domain controller. However, if Interactive logon: Number of previous logons to cache (in case domain controller is not available) is set to a value greater than zero, the user's cached credentials will be used to unlock the system.

This policy setting also applies to computers running Windows 2000, but it is not available through the Security Configuration Manager on those computers.

The possible values for this Group Policy setting are:

• Enabled.

• Disabled.

• Not defined.

Discussion

The computer caches the credentials of any users that have been authenticated locally in memory. The computer uses these cached credentials to authenticate anyone who attempts to unlock the console.

When cached credentials are used, any changes that have recently been made to the account — such as user rights assignments, account lockout, or the account being disabled — are not considered or applied after this authentication process. This means not only that user rights are not updated, but more importantly that disabled accounts are still able to unlock the console of the system.

It is advisable to set Interactive logon: Require Domain Controller authentication to unlock workstation to Enabled and set Interactive logon: Number of previous logons to cache (in case domain controller is not available) to 0. When the console of a computer is locked, either by a user or automatically by a screen saver time-out, the console can only be unlocked if the user is able to reauthenticate to the domain controller. If no domain controller is available, users cannot unlock their workstations.

Location

GPO_name\Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options

Default Values

Server Type or GPO	Default Value
Default Domain Policy	Not defined
Default Domain Controller Policy	Not defined
Stand-Alone Server Default Settings	Disabled
DC Effective Default Settings	Disabled
Member Server Effective Default Settings	Disabled

Interactive logon: Require smart card

The Interactive logon: Require smart card policy setting requires users to log on to a computer by using a smart card.

This policy setting also applies to Windows 2000 computers, but it is not available through the Security Configuration Manager on those computers.

The possible values for this Group Policy setting are:

• Enabled.

• Disabled.

• Not defined.

Discussion

Requiring users to use long, complex passwords for authentication enhances network security, especially if the users must change their passwords regularly. This reduces the chance that a malicious user will be able to guess a user's password via a brute-force attack. Using smart cards rather than passwords for authentication dramatically increases security because, with today's technology, it is nearly impossible for a malicious user to impersonate another user. Smart cards that require personal identification numbers (PINs) provide two-factor authentication: the user who attempts to log on must possess the smart card and know its PIN. A malicious user who captures the authentication traffic between the user's computer and the domain controller will find it extremely difficult to decrypt the traffic: even if they do, the next time the user logs on to the network, a new session key will be generated for encrypting traffic between the user and the domain controller.

It is advisable to set Interactive logon: Require smart card to Enabled. All users will have to use smart cards to log on to the network. This means that the organization must have a reliable public key infrastructure (PKI) in place, and provide smart cards and smart card readers for all users. These are significant challenges, because planning for and deploying these technologies requires expertise and resources; however, Windows Server 2003 includes Certificate Services, a highly advanced server for implementing and managing certificates that—when combined with Windows XP—includes features such as automatic user and computer enrollment and renewal.

Location

GPO_name\Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options

Default Values

Server Type or GPO	Default Value
Default Domain Policy	Not defined
Default Domain Controller Policy	Not defined
Stand-Alone Server Default Settings	Disabled
DC Effective Default Settings	Disabled
Member Server Effective Default Settings	Disabled

Interactive logon: Smart card removal behavior

The Interactive logon: Smart card removal behavior policy setting determines what happens when the smart card for a logged-on user is removed from the smart card reader.

The possible values for this Group Policy setting are:

• No Action.

• Lock Workstation.

• Force Logoff.

• Not defined.

Discussion

If smart cards are used for authentication, the computer should automatically lock itself when the card is removed—that way, if users forget to manually lock their workstations when they are away from them, malicious users cannot gain access.

It is advisable to set Interactive logon: Smart card removal behavior to Lock Workstation. If you select Lock Workstation in the property sheet for this policy setting, the workstation is locked when the smart card is removed. This allows users to leave the area, take their smart card with them, and still maintain a protected session.

If you select Force Logoff in the property sheet for this policy setting, the user is automatically logged off when the smart card is removed. Users will have to reinsert their smart cards and reenter their PINs when they return to their workstations.

Location

GPO_name\Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options

Default Values

Server Type or GPO	Default Value
Default Domain Policy	Not defined
Default Domain Controller Policy	Not defined
Stand-Alone Server Default Settings	No Action
DC Effective Default Settings	No Action
Member Server Effective Default Settings	No Action

Microsoft network client and server: Digitally sign communications (four related policy settings)

Note

• Misuse of these policy settings is a common error that can cause data loss or problems with data access or security.

There are four separate policy settings relating to digitally signing SMB communications: Microsoft network client: Digitally sign communications (always), Microsoft network server: Digitally sign communications (always), Microsoft network client: Digitally sign communications (if server agrees), and Microsoft network server: Digitally sign communications (if client agrees).

The possible values for these Group Policy settings are:

• Enabled.

• Disabled.

• Not defined.

Implementing digital signing in high-security networks helps to prevent the impersonation of clients and servers. This type of impersonation is known as “session hijacking,” in which a malicious user who has access to the same network as the client or server interrupts, ends, or steals a session in progress. Attackers can potentially intercept and modify unsigned SMB packets, then modify the traffic and forward it so the server performs undesirable actions. Alternatively, the attacker can pose as the server or client after a legitimate authentication and gain unauthorized access to data.

SMB is the resource-sharing protocol supported by many Microsoft operating systems. It is the basis of NetBIOS and many other protocols. SMB signing authenticates both the user and the server hosting the data. If either side fails the authentication process, data transmission will not take place.

An alternative countermeasure that can protect all network traffic is to implement digital signatures by using IPsec. There are hardware-based accelerators for IPsec encryption and signing that can be used to minimize the performance impact on the servers' CPUs. There are no such accelerators available for SMB signing.

The following values are advisable

• Set Microsoft network client: Digitally sign communications (always) to Disabled.

• Set Microsoft network server: Digitally sign communications (always) to Disabled.

• Set Microsoft network client: Digitally sign communications (if server agrees) to Enabled.

• Set Microsoft network server: Digitally sign communications (if client agrees) to Enabled.

Some sources recommend setting all of these policy settings to Enabled, but enabling them can cause slower performance on client computers and prevent them from communicating with legacy SMB applications and operating systems.

The Windows 2000, Windows Server 2003, and Windows XP Professional file and print sharing protocol SMB supports mutual authentication, which closes session-hijacking attacks and supports message authentication, thus preventing man-in-the-middle attacks. SMB signing provides this authentication by placing a digital signature into each SMB, which is then verified by both the client and the server. Implementing SMB signing can cause a noticeable performance impact as a result of having to sign and verify each packet between the servers. Configuring computers to ignore all unsigned SMB communications prevents legacy applications and operating systems from connecting. Completely disabling all SMB signing leaves the computers vulnerable to session-hijacking attacks.

Microsoft network client: Digitally sign communications (always)

Note

• Misuse of this policy setting is a common error that can cause data loss or problems with data access or security.

Location

GPO_name\Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options

Default Values

Server Type or GPO	Default Value
Default Domain Policy	Not defined
Default Domain Controller Policy	Not defined
Stand-Alone Server Default Settings	Disabled
DC Effective Default Settings	Disabled
Member Server Effective Default Settings	Disabled

Microsoft network client: Digitally sign communications (if server agrees)

Note

• Misuse of this policy setting is a common error that can cause data loss or problems with data access or security.

Location

GPO_name\Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options

Default Values

Server Type or GPO	Default Value
Default Domain Policy	Not defined
Default Domain Controller Policy	Not defined
Stand-Alone Server Default Settings	Enabled
DC Effective Default Settings	Enabled
Member Server Effective Default Settings	Enabled

Microsoft network server: Digitally sign communications (always)

Note

• Misuse of this policy setting is a common error that can cause data loss or problems with data access or security.

Location

GPO_name\Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options

Default Values

Server Type or GPO	Default Value
Default Domain Policy	Not defined
Default Domain Controller Policy	Enabled
Stand-Alone Server Default Settings	Not defined
DC Effective Default Settings	Enabled
Member Server Effective Default Settings	Not defined

Microsoft network server: Digitally sign communications (if client agrees)

Note

• Misuse of this policy setting is a common error that can cause data loss or problems with data access or security.

Location

GPO_name\Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options

Default Values

Server Type or GPO	Default Value
Default Domain Policy	Not defined
Default Domain Controller Policy	Enabled
Stand-Alone Server Default Settings	Not defined
DC Effective Default Settings	Enabled
Member Server Effective Default Settings	Not defined

Microsoft network client: Send unencrypted password to third-party SMB servers

Enabling the Microsoft network client: Send unencrypted password to third-party SMB servers policy setting allows the SMB redirector to send plaintext passwords to non-Microsoft SMB servers that do not support password encryption during authentication.

The possible values for this Group Policy setting are:

• Enabled.

• Disabled.

• Not defined.

Discussion

Enabling this policy setting allows the server to transmit passwords in plaintext across the network to other systems that offer SMB services. These others systems might not use any of the SMB security mechanisms included with Windows Server 2003.

It is advisable to set Microsoft network client: Send unencrypted password to connect to third - party SMB servers to Disabled. Some very old applications and operating systems such as MS-DOS, Windows for Workgroups 3.11, and Windows 95 might not be able to communicate with the servers in your organization via the SMB protocol.

Location

GPO_name\Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options

Default Values

Server Type or GPO	Default Value
Default Domain Policy	Not defined
Default Domain Controller Policy	Not defined
Stand-Alone Server Default Settings	Disabled
DC Effective Default Settings	Disabled
Member Server Effective Default Settings	Disabled

Microsoft network server: Amount of idle time required before suspending session

The Microsoft network server: Amount of idle time required before suspending session policy setting determines the amount of continuous idle time that must pass in an SMB session before the session is suspended due to inactivity. Administrators can use this policy setting to control when a computer suspends an inactive SMB session. The session is automatically reestablished when client activity resumes.

For this policy setting, a value of 0 means to disconnect an idle session as quickly as is reasonably possible. The maximum value is 99,999, which is 208 days—in effect, this disables the policy setting.

The possible values for this Group Policy setting are:

• A user-defined number of minutes from 0 through 99,999.

• Not defined.

Discussion

Each SMB session consumes server resources. Establishing numerous null sessions will slow or possibly crash the server. A malicious user might repeatedly establish SMB sessions until the server stops responding; at this point, SMB services will become slow or unresponsive.

It is advisable to set Microsoft network server: Amount of idle time required before disconnecting session to 15 minutes. There will be little impact because SMB sessions will be reestablished automatically if the client resumes activity.

Location

GPO_name\Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options

Default Values

Server Type or GPO	Default Value
Default Domain Policy	Not defined
Default Domain Controller Policy	Not defined
Stand-Alone Server Default Settings	15 minutes
DC Effective Default Settings	15 minutes
Member Server Effective Default Settings	15 minutes

Microsoft network server: Disconnect clients when logon hours expire

The Microsoft network server: Disconnect clients when logon hours expire policy setting determines whether to disconnect users who are connected to the local computer outside their user account's valid logon hours. This policy setting affects the SMB component. Enabling this policy setting causes client sessions with the SMB service to be forcibly disconnected when the client's logon hours expire. Disabling this policy setting maintains an established client session after the client's logon hours have expired. When you enable this policy setting, you should also enable Network security: Force logoff when logon hours expire.

The possible values for this Group Policy setting are:

• Enabled.

• Disabled.

• Not defined.

Discussion

If your organization has configured logon hours for users, it makes sense to enable this policy setting; if it is disabled, users who are assumed to be unable to access network resources outside their logon hours might actually be able to continue to use those resources with sessions that were established during allowed hours.

Enable the Microsoft network server: Disconnect clients when logon hours expire policy setting. If logon hours are not used in your organization, enabling this policy setting will have no impact. If logon hours are used, existing user sessions will be forcibly terminated when their logon hours expire.

Location

GPO_name\Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options

Default Values

Server Type or GPO	Default Value
Default Domain Policy	Not defined
Default Domain Controller Policy	Not defined
Stand-Alone Server Default Settings	Enabled
DC Effective Default Settings	Enabled
Member Server Effective Default Settings	Enabled

Network access: Allow anonymous SID/Name translation

Note

• Misuse of this policy setting is a common error that can cause data loss or problems with data access or security.

The Network access: Allow anonymous SID/Name translation policy setting determines whether an anonymous user can request SID attributes for another user.

The possible values for this Group Policy setting are:

• Enabled.

• Disabled.

• Not defined.

Discussion

If this policy setting is enabled, a user might use the well-known Administrators SID to get the real name of the built-in Administrator account, even if the account has been renamed. That person might then use the account name to initiate a brute-force password-guessing attack.

It is advisable to set Network access: Allow anonymous SID/Name translation to Disabled. This is the default value on member computers; therefore, it will have no impact on them. The default value for domain controllers is Enabled. Disabling this policy setting on domain controllers means that legacy systems might be unable to communicate with Windows Server 2003-based domains. For example, the following systems might not work:

• Windows NT 4.0–based Remote Access Service servers.

• Microsoft SQL Server running on Windows NT 3.51–based or Windows NT 4.0–based computers.

• Remote Access Service or Microsoft SQL Server running on Windows 2000–based computers that are located in Windows NT 3.51 domains or Windows NT 4.0 domains.

Location

GPO_name\Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options

Default Values

Server Type or GPO	Default Value
Default Domain Policy	Not defined
Default Domain Controller Policy	Not defined
Stand-Alone Server Default Settings	Disabled
DC Effective Default Settings	Enabled
Member Server Effective Default Settings	Disabled

Network access: Do not allow anonymous enumeration of SAM accounts

Note

• Misuse of this policy setting is a common error that can cause data loss or problems with data access or security.

The Network access: Do not allow anonymous enumeration of SAM accounts policy setting determines which additional permissions will be assigned for anonymous connections to the computer. Windows allows anonymous users to perform certain activities, such as enumerating the names of domain accounts and network shares. This is convenient, for example, when an administrator wants to give access to users in a trusted domain that does not maintain a reciprocal trust. However, even with this policy setting enabled, anonymous users will still have access to any resources that have permissions that explicitly include the special built-in group ANONYMOUS LOGON.

This policy setting has no impact on domain controllers.

In Windows 2000, a similar policy setting named Additional Restrictions for Anonymous Connections managed a registry entry RestrictAnonymous, located in the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA key. In Windows Server 2003, the policy settings Network access: Do not allow anonymous enumeration of SAM accounts and Network access: Do not allow anonymous enumeration of SAM accounts and shares replace the Windows 2000 policy setting. They manage the registry entries RestrictAnonymousSAM and RestrictAnonymous, respectively, both located in the HKLM\System\CurrentControlSet\Control\Lsa\ key.

The possible values for this Group Policy setting are:

• Enabled.

• Disabled.

• Not defined.

Discussion

A malicious user can anonymously list account names and use the information to attempt to guess passwords or perform social-engineering attacks. "Social engineering" is a term for tricking people into revealing their password or some other form of security information.

If you set Network access: Do not allow anonymous enumeration of SAM accounts to Enabled, it will be impossible to establish trusts with Windows NT 4.0–based domains. This value will also cause problems with earlier-version clients such as Windows NT 3.51 and Windows 95 that are trying to use resources on the server.

Location

GPO_name\Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options

Default Values

Server Type or GPO	Default Value
Default Domain Policy	Not defined
Default Domain Controller Policy	Not defined
Stand-Alone Server Default Settings	Enabled
DC Effective Default Settings	Enabled
Member Server Effective Default Settings	Enabled

Network access: Do not allow anonymous enumeration of SAM accounts and shares

Note

• Misuse of this policy setting is a common error that can cause data loss or problems with data access or security.

The Network access: Do not allow anonymous enumeration of SAM accounts and shares policy setting determines which additional permissions will be assigned for anonymous connections to the computer. Windows allows anonymous users to perform certain activities, such as enumerating the names of domain accounts and network shares. This is convenient, for example, when an administrator wants to give access to users in a trusted domain that does not maintain a reciprocal trust. However, even with this policy setting enabled, anonymous users will still have access to any resources that have permissions that explicitly include the special built-in group ANONYMOUS LOGON.

This policy setting has no impact on domain controllers.

In Windows 2000, a similar policy setting named Additional Restrictions for Anonymous Connections managed a registry value RestrictAnonymous, located in the HKLM\SYSTEM\CurrentControlSet\Control\LSA key. In Windows Server 2003, the policy settings Network access: Do not allow anonymous enumeration of SAM accounts and Network access: Do not allow anonymous enumeration of SAM accounts and shares replace the Windows 2000 policy setting. They manage the registry entries RestrictAnonymousSAM and RestrictAnonymous, respectively, both located in the HKLM\System\CurrentControlSet\Control\Lsa\ key.

The possible values for this Group Policy setting are:

• Enabled.

• Disabled.

• Not defined.

Discussion

If this policy setting is disabled, an unauthorized user could anonymously list account names and use the information to attempt to guess passwords or perform social-engineering attacks.

It is advisable to set Network access: Do not allow anonymous enumeration of SAM accounts and shares to Enabled. Note that when this is enabled, it will be impossible to establish trusts with Windows NT 4.0–based domains. This policy setting will also cause problems with earlier-version clients such as Windows NT 3.51 and Windows 95 that are trying to use resources on the server.

Location

GPO_name\Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options

Default Values

Server Type or GPO	Default Value
Default Domain Policy	Not defined
Default Domain Controller Policy	Not defined
Stand-Alone Server Default Settings	Disabled
DC Effective Default Settings	Disabled
Member Server Effective Default Settings	Disabled

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

The Network access: Do not allow storage of credentials or .NET Passports for network authentication policy setting determines whether Stored User Names and Passwords saves passwords or credentials for later use when it gains domain authentication. Enabling this policy setting prevents Stored User Names and Passwords from storing passwords and credentials.

The possible values for this Group Policy setting are:

• Enabled.

• Disabled.

• Not defined.

Discussion

Passwords cached by Stored User Names and Passwords can be accessed by a user when logged on to the computer. A problem can arise if the user unknowingly executes hostile code that reads the passwords and forwards them to another, malicious user.

It is advisable to set Network access: Do not allow storage of credentials or .NET Passports for network authentication to Enabled. Users will be forced to enter passwords whenever they log on to their Passport account or other network resources that are not accessible to their domain account. This will not have an impact when the user visits Web sites that require him to log on, because enabling this policy setting does not prevent passwords from being saved when the user requests that they be. Enabling this policy setting should have no impact on users when they access network resources that have been configured to allow access with their Active Directory–based domain account.

Location

GPO_name\Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options

Default Values

Server Type or GPO	Default Value
Default Domain Policy	Not defined
Default Domain Controller Policy	Not defined
Stand-Alone Server Default Settings	Disabled
DC Effective Default Settings	Disabled
Member Server Effective Default Settings	Disabled

Network access: Let Everyone permissions apply to anonymous users

The Network access: Let Everyone permissions apply to anonymous users policy setting determines which additional permissions are assigned for anonymous connections to the computer. Enabling this policy setting allows anonymous users to perform certain activities, such as enumerating the names of domain accounts and network shares. This is convenient, for example, when an administrator wants to give access to users in a trusted domain that does not maintain a reciprocal trust. By default, the token created for anonymous connections does not include the Everyone SID; therefore, permissions assigned to the Everyone group do not apply to anonymous users. Enabling this policy setting adds the Everyone SID to the token created for anonymous connections, which allows anonymous users to access any resource for which the Everyone group has been given permissions.

The possible values for this Group Policy setting are:

• Enabled.

• Disabled.

• Not defined.

Discussion

A malicious user might anonymously list account names and shared resources and use the information to attempt to guess passwords or perform social-engineering attacks. It is advisable to set Network access: Let Everyone permissions apply to anonymous users to Disabled.

Location

GPO_name\Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options

Default Values

Server Type or GPO	Default Value
Default Domain Policy	Not defined
Default Domain Controller Policy	Not defined
Stand-Alone Server Default Settings	Disabled
DC Effective Default Settings	Disabled
Member Server Effective Default Settings	Disabled

Network access: Named Pipes that can be accessed anonymously

The Network access: Named Pipes that can be accessed anonymously policy setting determines which communication sessions, or pipes, will have attributes and permissions that allow anonymous access.

The possible values for this Group Policy setting are:

• A user-defined list of shares.

• Not defined.

Discussion

Restricting access over named pipes such as COMNAP and LOCATOR helps prevent unauthorized access to the network. The following table lists default named pipes and their purpose.

Default Named Pipes That Are Accessible Anonymously

Named Pipe	Purpose
COMNAP	SnaBase named pipe. Systems Network Architecture (SNA) is a collection of networking protocols originally developed for IBM mainframe computers.
COMNODE	SNA Server named pipe.
SQL\QUERY	Default named pipe for SQL Server.
SPOOLSS	Named pipe for the Print Spooler service.
EPMAPPER	End Point Mapper named pipe.
LOCATOR	RPC Locator service named pipe.
TrkWks	Distributed Link Tracking Client named pipe.
TrkSvr	Distributed Link Tracking Server named pipe.

It is advisable to set Network access: Named Pipes that can be accessed anonymously to a null value; that is, enable the policy setting, but do not enter named pipes in the text box. This will disable null session access over named pipes, and applications that rely on this feature or on unauthenticated access to named pipes will no longer function. For example, with Microsoft Commercial Internet System 1.0, the Internet Mail Service runs under Inetinfo.exe. Inetinfo.exe starts in the context of the System account. When Internet Mail Service needs to query the Microsoft SQL Server database, it uses the System account, which uses null credentials to access a SQL pipe on the computer running SQL Server.

Location

GPO_name\Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options

Default Values

Server Type or GPO	Default Value
Default Domain Policy	Not defined
Default Domain Controller Policy	Not defined
Stand-Alone Server Default Settings	COMNAP,COMNODE, SQL\QUERY, SPOOLSS, EPMAPPER, LOCATOR,TrkWks,TrkSvr
DC Effective Default Settings	COMNAP,COMNODE, SQL\QUERY, SPOOLSS, EPMAPPER, LOCATOR,TrkWks,TrkSvr
Member Server Effective Default Settings	COMNAP,COMNODE, SQL\QUERY, SPOOLSS, EPMAPPER, LOCATOR,TrkWks,TrkSvr

Network access: Remotely accessible registry paths

The Network access: Remotely accessible registry paths policy setting determines which registry paths will be accessible after referencing the WinReg key to determine access permissions to those paths.

The possible values for this Group Policy setting are:

• A user-defined list of paths.

• Not defined.

Discussion

The registry is a database for computer configuration information, much of which is sensitive. A malicious user can use the registry to facilitate unauthorized activities. To reduce the risk of this happening, suitable access control lists (ACLs) are assigned throughout the registry to help protect it from access by unauthorized users.

It is advisable to set Network access: Remotely accessible registry paths to a null value; that is, enable the policy setting but do not enter any paths in the text box. Remote management tools, such as the Microsoft Baseline Security Analyzer and Microsoft Systems Management Server (SMS), require remote access to the registry. Removing the default registry paths from the list of accessible paths might cause these and other management tools to fail.

If you do want to allow remote access, you must also enable the Remote Registry service.

Location

GPO_name\Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options

Default Values

Server Type or GPO	Default Value
Default Domain Policy	Not defined
Default Domain Controller Policy	Not defined
Stand-Alone Server Default Settings	A (see below)
DC Effective Default Settings	A (see below)
Member Server Effective Default Settings	A (see below)

A = System\CurrentControlSet\Control\ProductOptions, System\CurrentControlSet\Control\Server Applications, Software\Microsoft\Windows NT\CurrentVersion

Network access: Remotely accessible registry paths and sub-paths

The Network access: Remotely accessible registry paths and sub-paths policy setting determines which registry paths and subpaths will be accessible after referencing the WinReg key to determine access permissions to those paths.

The possible values for this Group Policy setting are:

• A user-defined list of paths.

• Not defined.

Discussion

The registry is a database for computer configuration information, much of which is sensitive. A malicious user can use it to facilitate unauthorized activities. The chance of this happening is reduced by the fact that the default ACLs assigned throughout the registry are fairly restrictive, and they help protect it from access by unauthorized users.

It is advisable to set Networkaccess: Remotely accessible registry paths and sub-paths to a null value; that is, enable the policy setting but do not enter any paths in the text box. Remote management tools such as the Microsoft Baseline Security Analyzer and SMS require remote access to the registry. Removing the default registry paths from the list of accessible paths might cause these and other management tools to fail.

If you do want to allow remote access, you must also enable the Remote Registry service.

Location

GPO_name\Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options

Default Values

Server Type or GPO	Default Value
Default Domain Policy	Not defined
Default Domain Controller Policy	Not defined
Stand-Alone Server Default Settings	A (see below)
DC Effective Default Settings	A (see below)
Member Server Effective Default Settings	A (see below)

A = System\CurrentControlSet\Control\Print\Printers, System\CurrentControlSet\Services\Eventlog, Software\Microsoft\OLAP Server, Software\Microsoft\Windows NT\CurrentVersion\Print, Software\Microsoft\Windows NT\CurrentVersion\Windows, System\CurrentControlSet\Control\ContentIndex, System\CurrentControlSet\Control\Terminal Server, System\CurrentControlSet\Control\Terminal Server\UserConfig, System\CurrentControlSet\Control\Terminal Server\DefaultUserConfiguration, Software\Microsoft\Windows NT\CurrentVersion\Perflib, System\CurrentControlSet\Services\SysmonLog

Network access: Restrict anonymous access to Named Pipes and Shares

When enabled, the Network access: Restrict anonymous access to Named Pipes and Shares policy setting restricts anonymous access to shares and pipes to the settings for Network access: Named pipes that can be accessed anonymously and Network access: Shares that can be accessed anonymously. This setting controls null session access to shares on your computers by adding the registry entry RestrictNullSessAccess with the value 1 to the registry key HKLM\System\CurrentControlSet\Services\LanManServer\Parameters. This registry entry toggles null session shares on or off to determine whether the Server service restricts access to clients that have logged on to the System account without user name and password authentication.

The possible values for this Group Policy setting are:

• Enabled.

• Disabled.

• Not defined.

Discussion

Null sessions are a weakness that can be exploited through the various shares on the computers in your environment.

It is advisable to set Network access: Restrict anonymous access to Named Pipes and Shares to Enabled. Enabling this policy setting restricts null session access to unauthenticated users to all server pipes and shares except those listed in the NullSessionPipes and NullSessionShares registry entries.

Location

GPO_name\Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options

Default Values

Server Type or GPO	Default Value
Default Domain Policy	Not defined
Default Domain Controller Policy	Not defined
Stand-Alone Server Default Settings	Enabled
DC Effective Default Settings	Enabled
Member Server Effective Default Settings	Enabled

Network access: Shares that can be accessed anonymously

The Network access: Shares that can be accessed anonymously policy setting determines which network shares anonymous users can access.

The possible values for this Group Policy setting are:

• A user-defined list of shares.

• Not defined.

Discussion

Enabling this policy setting is very dangerous. Any shares listed can be accessed by any network user. This might lead to the exposure or corruption of sensitive corporate data.

It is advisable to set Network access: Shares that can be accessed anonymously to a null value. There should be little impact because this is the default value. All users will have to be authenticated before they can access shared resources on the server.

Location

GPO_name\Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options

Default Values

Server Type or GPO	Default Value
Default Domain Policy	Not defined
Default Domain Controller Policy	Not defined
Stand-Alone Server Default Settings	COMCFG,DFS$
DC Effective Default Settings	COMCFG,DFS$
Member Server Effective Default Settings	COMCFG,DFS$

Network access: Sharing and security model for local accounts

The Network access: Sharing and security model for local accounts policy setting determines how network logons that use local accounts are authenticated. If it is set to Classic - local users authenticate as themselves, network logons that use local account credentials authenticate by using those credentials. If it is set to Guest only - local users authenticate as Guest, network logons that use local accounts are automatically mapped to the Guest account. The Classic model allows fine control over access to resources. By using the Classic model, you can assign different types of access to different users for the same resource. Using the Guest-only model treats all users equally. All users authenticate as Guest, and they all receive the same level of access to a given resource, which can be either Read Only or Modify.

The default value for this policy setting on stand-alone Windows XP Professional is Guest only. The default for Windows XP systems joined to a domain and Windows Server 2003 systems is Classic. This policy setting does not affect network logons that use domain accounts, nor does it affect interactive logons that are performed remotely by using services such as Telnet or Terminal Services.

When the computer is not joined to a domain, this policy setting also tailors the Sharing and Security tabs in Windows Explorer to correspond to the sharing and security model that is being used. This policy setting has no effect on Windows 2000 computers.

The possible values for this Group Policy setting are:

• Classic - local users authenticate as themselves.

• Guest only - local users authenticate as Guest.

• Not defined.

Discussion

When the value of this policy setting is Guest only - local users authenticate as Guest, any user who can access your computer over the network does so with Guest user rights. This means that they will probably be unable to write to those shares. Although this does increase security, it makes it impossible for authorized users to access shared resources on those systems. When the value is Classic - local users authenticate as themselves, local accounts must be password-protected; otherwise, anyone can use those user accounts to access shared system resources.

For network servers, set Network access: Sharing and security model for local accounts to Classic - local users authenticate as themselves. On end-user systems, set it to Guest only - local users authenticate as Guest.

Location

GPO_name\Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options

Default Values

Server Type or GPO	Default Value
Default Domain Policy	Not defined
Default Domain Controller Policy	Not defined
Stand-Alone Server Default Settings	Classic (local users authenticate as themselves)
DC Effective Default Settings	Classic (local users authenticate as themselves)
Member Server Effective Default Settings	Classic (local users authenticate as themselves)

Network security: Do not store LAN Manager hash value on next password change

The Network security: Do not store LAN Manager hash value on next password change policy setting determines whether, at the next password change, LAN Manager will be prevented from storing hash values for the new password.

The possible values for this Group Policy setting are:

• Enabled.

• Disabled.

• Not defined.

Discussion

By attacking the Security Accounts Manager file, attackers can potentially gain access to user names and password hashes. Attackers can use a password-cracking tool to determine what the password is. After they have access to this information, they can use it to gain access to resources on your network by impersonating users. Enabling this policy setting will not prevent these types of attacks, but it will make them much more difficult.

It is advisable to set Network security: Do not store LAN Manager hash value on next password change to Enabled. Require all users to set new passwords the next time they log on to the domain so that LAN Manager hashes are removed. Legacy operating systems—such as Windows 95, Windows 98, and Windows Millennium Edition—will fail, as will some non-Microsoft applications.

Location

GPO_name\Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options

Default Values

Server Type or GPO	Default Value
Default Domain Policy	Not defined
Default Domain Controller Policy	Not defined
Stand-Alone Server Default Settings	Disabled
DC Effective Default Settings	Disabled
Member Server Effective Default Settings	Disabled

Network security: Force logoff when logon hours expire

The Force logoff when logon hours expire policy setting determines whether to disconnect users who are connected to the local computer outside their user account's valid logon hours. This policy setting affects the SMB component. Enabling this policy setting forcibly disconnects client sessions with the SMB Service when the client's logon hours expire. Disabling this policy setting maintains an established client session after the client's logon hours have expired.

The possible values for this Group Policy setting are:

• Enabled.

• Disabled.

• Not defined.

Discussion

If this policy setting is disabled, a user can remain connected to the system outside of their allotted logon hours. It is advisable to set Network security: Force logoff when logon hours expire to Enabled. SMB sessions will be terminated on member servers when a user's logon time expires, and the user will be unable to log on to the system until their next scheduled access time begins.

This policy setting does not apply to Administrator accounts.

Location

GPO_name\Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options

Default Values

Server Type or GPO	Default Value
Default Domain Policy	Disabled
Default Domain Controller Policy	Not defined
Stand-Alone Server Default Settings	Disabled
DC Effective Default Settings	Disabled
Member Server Effective Default Settings	Disabled

Network security: LAN Manager authentication level

Note

• Misuse of this policy setting is a common error that can cause data loss or problems with data access or security.

LAN Manager (LM) is a family of early Microsoft client/server software that allows users to link personal computer systems together on a single network. Networking capabilities include transparent file and print sharing, user security features, and network administration tools. In Active Directory domains, Kerberos is the default for authentication, but if Kerberos is not negotiated for some reason, Active Directory will use LM, NTLM, or NTLM version 2 (NTLMv2).

LM authentication—including the LM, NTLM, and NTLMv2 variants—is the protocol used to authenticate all Windows clients for such operations as:

• Joining a domain.

• Authenticating between Active Directory forests.

• Authenticating to earlier-version domains.

• Authenticating to systems that are not based on Windows 2000, Windows Server 2003, or Windows XP.

• Authenticating to systems that are not in the domain.

The Network security: LAN Manager authentication level policy setting determines which challenge/response authentication protocol is used for network logons. This choice affects the authentication protocol level clients use, the session security level the systems negotiate, and the authentication level servers accept, as follows:

• Send LM & NTLM responses. Clients use LM and NTLM authentication and never use NTLMv2 session security; domain controllers accept LM, NTLM, and NTLMv2 authentication.

• Send LM & NTLM - use NTLMv2 session security if negotiated. Clients use LM and NTLM authentication and use NTLMv2 session security if the server supports it. Domain controllers accept LM, NTLM, and NTLMv2 authentication.

• Send NTLM response only. Clients use NTLM authentication only and use NTLMv2 session security if the server supports it. Domain controllers accept LM, NTLM, and NTLMv2 authentication.

• Send NTLMv2 response only. Clients use NTLMv2 authentication only and use NTLMv2 session security if the server supports it. Domain controllers accept LM, NTLM, and NTLMv2 authentication.

• Send NTLMv2 response only\refuse LM. Clients use NTLMv2 authentication only and use NTLMv2 session security if the server supports it. Domain controllers refuse LM (accept only NTLM and NTLMv2 authentication).

• Send NTLMv2 response only\refuse LM & NTLM. Clients use NTLMv2 authentication only and use NTLMv2 session security if the server supports it. Domain controllers refuse LM and NTLM (accept only NTLMv2 authentication).

The possible values for this Group Policy setting are:

• Send LM & NTLM responses.

• Send LM & NTLM - use NTLMv2 session security if negotiated.

• Send NTLM responses only.

• Send NTLMv2 responses only.

• Send NTLMv2 responses only\refuse LM.

• Send NTLMv2 responses only\refuse LM & NTLM.

• Not defined.

These settings correspond to the levels discussed in other Microsoft documents, as follows:

• Level 0–Send LM and NTLM response; never use NTLMv2 session security. Clients use LM and NTLM authentication, and never use NTLMv2 session security. Domain controllers accept LM, NTLM, and NTLMv2 authentication.

• Level 1–Use NTLMv2 session security if negotiated. Clients use LM and NTLM authentication, and use NTLMv2 session security if the server supports it. Domain controllers accept LM, NTLM, and NTLMv2 authentication.

• Level 2–Send NTLM response only. Clients use only NTLM authentication, and use NTLMv2 session security if the server supports it. Domain controllers accept LM, NTLM, and NTLMv2 authentication.

• Level 3–Send NTLMv2 response only. Clients use NTLMv2 authentication, and use NTLMv2 session security if the server supports it. Domain controllers accept LM, NTLM, and NTLMv2 authentication.

• Level 4–Domain controllers refuse LM responses. Clients use NTLM authentication, and use NTLMv2 session security if the server supports it. Domain controllers refuse LM authentication, that is, they accept NTLM and NTLMv2.

• Level 5–Domain controllers refuse LM and NTLM responses (accept only NTLMv2). Clients use NTLMv2 authentication, use and NTLMv2 session security if the server supports it. Domain controllers refuse NTLM and LM authentication (they accept only NTLMv2).

Discussion

Windows 2000, Windows Server 2003, and Windows XP are configured by default to send LM and NTLM authentication responses. Windows 95, Windows 98, and Windows Millennium Edition clients only send LM. The default server setting allows all clients to authenticate with servers and use their resources; however, this means that LM responses—the weakest form of authentication response—are sent over the network, and it is potentially possible for attackers to sniff that traffic to more easily reproduce a user's password.

The Windows 95, Windows 98, Windows Me, and Windows NT operating systems cannot use the Kerberos version 5 protocol for authentication. For this reason, in a Windows Server 2003 domain, these systems authenticate by default with both the LM and NTLM protocols for network authentication. You can enforce a more secure authentication protocol for Windows 95, Windows 98, Windows Me, and Windows NT by using NTLMv2. For the logon process, NTLMv2 uses a secure channel to protect the authentication process. Even if you do use NTLMv2 for legacy clients and servers, Windows-based clients and servers that are members of the domain will authenticate with Windows Server 2003 domain controllers by using the Kerberos protocol.

Windows NT 4.0 requires Service Pack 4 (SP4) to support NTLMv2, and Windows 95, Windows 98, and Windows Me need the directory service client installed in order to support NTLMv2.

It is advisable to set LAN Manager Authentication Level to Send NTLMv2 responsesonly. When all clients support NTLMv2, this level of authentication is strongly recommended by Microsoft and a number of independent organizations. Clients that do not support NTLMv2 authentication will not be able to authenticate in the domain or access domain resources by using LM and NTLM.

Location

GPO_name\Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options

Default Values

Server Type or GPO	Default Value
Default Domain Policy	Not defined
Default Domain Controller Policy	Send NTLM response only
Stand-Alone Server Default Settings	Send NTLM response only
DC Effective Default Settings	Send NTLM response only
Member Server Effective Default Settings	Send NTLM response only

Network security: LDAP client signing requirements

Note

• Misuse of this policy setting is a common error that can cause data loss or problems with data access or security.

The Network security: LDAP client signing requirements policy setting determines the level of data signing that is requested on behalf of clients that issue LDAP BIND requests, as follows:

• None. The LDAP BIND request is issued with the caller-specified options.

• Negotiate signing. If TLS/SSL has not been started, the LDAP BIND request is initiated with the LDAP data signing option set in addition to the caller-specified options. If TLS/SSL has been started, the LDAP BIND request is initiated with the caller-specified options.

• Require signature. This is the same as Negotiate signing. However, if the LDAP server's intermediate saslBindInProgress response does not indicate that LDAP traffic signing is required, the caller is told that the LDAP BIND command request failed.

This policy setting does not have any impact on ldap_simple_bind or ldap_simple_bind_s. No Microsoft LDAP clients that are included with Windows XP Professional use ldap_simple_bind or ldap_simple_bind_s to communicate with a domain controller.

The possible values for this Group Policy setting are:

• None.

• Negotiate signing.

• Require signature.

• Not defined.

Discussion

Unsigned network traffic is susceptible to man-in-the-middle attacks, where an intruder captures the packets between the client and server and modifies them before forwarding them to the server. In the case of an LDAP server, this means that a malicious user might cause a server to make decisions based on false queries from the LDAP client. You can lower this risk in a corporate network by implementing strong physical security measures to protect the network infrastructure. Furthermore, all types of man-in-the-middle attacks can be made extremely difficult by requiring digital signatures on all network packets via IPsec Authentication Headers.

It is advisable to set Domain controller: LDAP server signing requirements to Require signature. If you set the server to require LDAP signatures, you must also set the client to do so. Not setting the client will prevent the client from communicating with the server—this can cause many features to fail, including user authentication, Group Policy, and logon scripts.

Location

GPO_name\Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options

Default Values

Server Type or GPO	Default Value
Default Domain Policy	Not defined
Default Domain Controller Policy	Not defined
Stand-Alone Server Default Settings	Negotiate signing
DC Effective Default Settings	Negotiate signing
Member Server Effective Default Settings	Negotiate signing

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

The Network security: LDAP client signing requirements security policy setting determines the level of data signing that is requested on behalf of clients issuing LDAP BIND requests, as follows:

• None: The LDAP BIND request is issued with the caller-specified options.

• Negotiate signing: If TLS/SSL has not been started, the LDAP BIND request is initiated with the LDAP data-signing option set in addition to the caller-specified options. If TLS/SSL has been started, the LDAP BIND request is initiated with the caller-specified options.

• Require signature: This is the same as Negotiate signing. However, if the LDAP server's intermediate saslBindInProgress response does not indicate that LDAP traffic signing is required, the caller is told that the LDAP BIND command request failed.

This policy setting does not have any impact on ldap_simple_bind or ldap_simple_bind_s. No Microsoft LDAP clients that are included with Windows XP Professional use ldap_simple_bind or ldap_simple_bind_s to communicate with a domain controller.

The possible values for this Group Policy setting are:

• None.

• Negotiate signing.

• Require signature.

• Not defined.

Discussion

Unsigned network traffic is susceptible to man-in-the-middle attacks, where an intruder captures the packets between the client and server and modifies them before forwarding them to the server. In the case of an LDAP server, this means that a malicious user could cause a server to make decisions based on false queries from the LDAP client. You can lower this risk in a corporate network by implementing strong physical security measures to protect the network infrastructure. Furthermore, all types of man-in-the-middle attacks can be made extremely difficult by requiring digital signatures on all network packets by way of IPsec Authentication Headers.

It is advisable to set Domain controller: LDAP server signing requirements to Require signature. If you set the server to require LDAP signatures, you must also set the client. Not setting the client will prevent the client from communicating with the server — this can cause many features to fail, including user authentication, Group Policy, and logon scripts.

Location

GPO_name\Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options

Default Values

Server Type or GPO	Default Value
Default Domain Policy	Not defined
Default Domain Controller Policy	Not defined
Stand-Alone Server Default Settings	No minimum
DC Effective Default Settings	No minimum
Member Server Effective Default Settings	No minimum

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

The Network security: Minimum session security for NTLM SSP based (including secure RPC) servers policy setting allows a server to require the negotiation of message confidentiality (encryption), message integrity, 128-bit encryption, or NTLMv2 session security. These values are dependent on the value of the Network security: LAN Manager authentication level policy setting.

The possible values for this Group Policy setting are:

• Require message confidentiality.

  The connection will fail if encryption is not negotiated. Encryption converts data into a form that is not readable by anyone until it is decrypted.

• Require message integrity.

  The connection will fail if message integrity is not negotiated. The integrity of a message can be assessed through message signing. Message signing proves that the message has not been tampered with by attaching a cryptographic signature, which identifies the sender and contains a numeric representation of the contents of the message.

• Require 128-bit encryption.

  The connection will fail if strong encryption (128-bit) is not negotiated.

• Require NTLMv2 session security.

  The connection will fail if the NTLMv2 protocol is not negotiated.

• Not defined.

Discussion

Setting all of these values for this policy setting will help protect network traffic that uses the NTLM Security Support Provider (NTLM SSP) from being exposed or tampered with by a malicious user who has gained access to the same network. That is, these settings help protect against man-in-the-middle attacks.

Enable all four values that are available for the Network security: Minimum session security for NTLM SSP based (including secure RPC) servers object. Legacy clients that do not support these policy settings will be unable to communicate with the computer.

Location

GPO_name\Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options

Default Values

Server Type or GPO	Default Value
Default Domain Policy	Not defined
Default Domain Controller Policy	Not defined
Stand-Alone Server Default Settings	No minimum
DC Effective Default Settings	No minimum
Member Server Effective Default Settings	No minimum

Recovery console: Allow automatic administrative logon

The Recovery console: Allow automatic administrative logon policy setting determines whether a user must give the Administrator account password before getting access to the system. Enabling this policy setting allows any user to automatically log on to the system without giving a password at the Recovery Console.

The possible values for this Group Policy setting are:

• Enabled.

• Disabled.

• Not defined.

Discussion

The Recovery Console can be very useful when troubleshooting and repairing systems that cannot be restarted; however, enabling this policy setting so a user can automatically log on to the console is dangerous. Anyone can walk up to the server, shut it down by disconnecting the power, reboot it, select Recovery Console from the Restart menu, and then assume full control of the server.

It is advisable to set Recovery Console: Allow automatic administrative logon to Disabled. This requires a user to enter a user name and password to access the Recovery Console account.

Location

GPO_name\Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options

Default Values

Server Type or GPO	Default Value
Default Domain Policy	Not defined
Default Domain Controller Policy	Not defined
Stand-Alone Server Default Settings	Disabled
DC Effective Default Settings	Disabled
Member Server Effective Default Settings	Disabled

Recovery console: Allow floppy copy and access to all drives and all folders

Enabling the Recovery console: Allow floppy copy and access to all drives and all folders policy setting makes the Recovery Console SET command available, which allows you to set the following Recovery Console environment variables.

• AllowWildCards. Enables wildcard support for some commands (such as the DEL command).

• AllowAllPaths. Allows access to all files and folders on the computer.

• AllowRemovableMedia. Allows files to be copied to removable media, such as a floppy disk.

• NoCopyPrompt. Do not prompt when overwriting an existing file.

The possible values for this Group Policy setting are:

• Enabled.

• Disabled.

• Not defined.

Discussion

An authorized administrator might forget to remove a CD or floppy disk with sensitive data or applications that a malicious user could then steal. An authorized administrator could accidentally leave a startup disk in the computer after using the Recovery Console. If the computer is restarted for any reason and the BIOS has been configured to boot from the CD-ROM or floppy disk drive before the hard disk, the server will start from the removable disk. This causes the server's network services to be unavailable.

It is advisable to set Recovery Console: Allow floppy copy and access to drives and folders to Disabled. Users who have started a server by using the Recovery Console and logged in with the built-in Administrator account will not be able to copy files and folders to a floppy disk.

Location

GPO_name\Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options

Default Values

Server Type or GPO	Default Value
Default Domain Policy	Not defined
Default Domain Controller Policy	Not defined
Stand-Alone Server Default Settings	Disabled
DC Effective Default Settings	Disabled
Member Server Effective Default Settings	Disabled

Shutdown: Allow system to be shut down without having to log on

The Shutdown: Allow system to be shut down without having to log on policy setting determines whether a computer can be shut down by a user who has not logged on to Windows. Enabling this policy setting makes the Shut Down command available on the Windows logon screen. Disabling this policy setting removes the Shut Down command from the Windows logon screen. When the setting is disabled, users must be able to log on to the computer successfully and have the Shut down the system user right before they can perform a system shutdown.

The possible values for this Group Policy setting are:

• Enabled.

• Disabled.

• Not defined.

Discussion

Users who can access the console locally can shut the system down. Attackers or misguided users can connect to the server using Terminal Services and shut it down or restart it without having to identify themselves. A malicious user might also cause a temporary denial-of-service condition by walking up to the local console and restarting the server, or shutting down the server and thus rendering unavailable all its applications and services.

It is advisable to set the Allow system to be shut down without having to log on user right to Disabled. Administrators must log on to servers to shut them down or restart them.

Location

GPO_name\Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options

Default Values

Server Type or GPO	Default Value
Default Domain Policy	Not defined
Default Domain Controller Policy	Not defined
Stand-Alone Server Default Settings	Disabled
DC Effective Default Settings	Disabled
Member Server Effective Default Settings	Disabled

Shutdown: Clear virtual memory page file

The Shutdown: Clear virtual memory page file policy setting determines whether the virtual memory paging file is cleared when the system is shut down. Virtual memory support uses a system paging file to swap pages of memory to disk when they are not used. On a running system, this paging file is opened exclusively by the operating system, and it is well-protected. However, systems that have been configured to allow starting other operating systems might have to make sure that the system paging file is wiped clean when the running system shuts down. This will ensure that sensitive information from process memory that might have been written to the paging file is not available to an unauthorized user who might manage to access the paging file directly.

When this policy setting is enabled, it clears the system paging file when the system shuts down properly. On a portable computer system on which hibernation has been disabled, the system will also clear the hibernation file, Hiberfil.sys.

The possible values for this Group Policy setting are:

• Enabled.

• Disabled.

• Not defined.

Discussion

Important information kept in real memory might be written periodically to the paging file. This helps Windows Server 2003 handle multitasking functions. A malicious user who has physical access to a server that has been shut down can view the contents of the paging file. The attacker can move the system volume into a different computer and then analyze the contents of the paging file. This is a time-consuming process, but it can expose data cached from RAM to the paging file. A malicious user who has physical access to the server can bypass this countermeasure by simply unplugging the server from its power source.

It is advisable to set Shutdown: Clear virtual memory page file to Enabled. This causes Windows Server 2003 to clear the paging file when the system is shut down. Depending on the size of the paging file, this process might take several minutes before the system completely shuts down. This delay in shutting down the server is especially noticeable on servers with large paging files. For a server with 2 gigabytes (GB) of RAM and a 2-GB paging file, this setting can add 20 to 30 minutes, or more, to the shutdown process. For some organizations, this downtime violates their internal service level agreements. Use caution when implementing this countermeasure in your environment.

Location

GPO_name\Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options

Default Values

Server Type or GPO	Default Value
Default Domain Policy	Not defined
Default Domain Controller Policy	Not defined
Stand-Alone Server Default Settings	Disabled
DC Effective Default Settings	Disabled
Member Server Effective Default Settings	Disabled

System cryptography: Force strong key protection for user keys stored on the computer

The System cryptography: Force strong key protection for user keys stored on the computer policy setting determines whether users can use private keys, such as their Secure/Multipurpose Internet Mail Extensions (S/MIME) key, without a password.

The possible values for this Group Policy setting are:

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

• User is prompted when the key is first used.

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

• Not defined.

Discussion

Configuring this policy setting so that users must provide a password every time they use a key — in addition to their domain password — makes it more difficult for a malicious user to access locally-stored user keys, even if the attacker takes control of the user's computer and determines their logon password.

It is advisable to set System cryptography: Force strong key protection for user keys stored on the computer to User must enter a password each time they use a key. Users must enter their password every time they access a key that is stored on their computer. For example, if users use an S/MIME certificate to digitally sign their e-mail, they will be forced to enter the password for that certificate every time they send a signed e-mail message. For some organizations, the overhead caused by using this value might be too high, but even they should set the value at a minimum to User is prompted when the key is first used.

Location

GPO_name\Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options

Default Values

Server Type or GPO	Default Value
Default Domain Policy	Not defined
Default Domain Controller Policy	Not defined
Stand-Alone Server Default Settings	Not defined
DC Effective Default Settings	Not defined
Member Server Effective Default Settings	Not defined

System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing

The System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing policy setting determines whether the TLS/SSL security provider will only support the strong cipher suite known as TLS_RSA_WITH_3DES_EDE_CBC_SHA. In effect, this means that the provider only supports the TLS protocol as a client and as a server, if applicable. It uses only the Triple Data Encryption Standard (3DES) encryption algorithm for the TLS traffic encryption, only the Rivest - Shamir-Adleman (RSA) public key algorithm for the TLS key exchange and authentication, and only the Secure Hash Algorithm version 1 (SHA-1) hashing algorithm for the TLS hashing requirements.

For Encrypting File System (EFS), it supports only the 3DES encryption algorithm for encrypting file data supported by NTFS. By default, EFS uses the DESX algorithm (a variation of the DES algorithm) for encrypting file data.

The possible values for this Group Policy setting are:

• Enabled.

• Disabled.

• Not defined.

Discussion

Enabling this policy setting ensures that the computer will use the most powerful algorithms available for digital encryption, hashing, and signing. This minimizes the risk of a malicious user compromising digitally encrypted or signed data.

It is advisable to set System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing to Enabled. Clients with this policy setting enabled will be unable to communicate via digitally encrypted or signed protocols with servers that do not support these algorithms. Network clients that do not support these algorithms will not be able to use servers that require them for network communications. If you enable this policy setting, you must also configure Internet Explorer to use TLS.

To enable Internet Explorer to use TLS

1. In Internet Explorer, on the Tools menu, click Internet Options.

2. Click the Advanced tab.

3. Select the Use TLS 1.0 check box.

It is also possible to configure this setting by using Group Policy or the Internet Explorer Administrators Kit.

Location

GPO_name\Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options

Default Values

Server Type or GPO	Default Value
Default Domain Policy	Not defined
Default Domain Controller Policy	Not defined
Stand-Alone Server Default Settings	Disabled
DC Effective Default Settings	Disabled
Member Server Effective Default Settings	Disabled

System objects: Default owner for objects created by members of the Administrators group

The System objects: Default owner for objects created by members of the Administrators group policy setting determines whether the Administrators group or the object creator is the default owner of any system objects that are created.

The possible values for this Group Policy setting are:

• Administrators group.

• Object creator.

• Not defined.

Discussion

Setting the value to Administrators group makes it impossible to hold individuals accountable for creating new system objects.

It is advisable to set System objects: Default owner for objects created by members of the Administrators group to Object creator. When a system object is created, its ownership reflects which specific account created the object, rather than the more generic Administrators group.

Location

GPO_name\Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options

Default Values

Server Type or GPO	Default Value
Default Domain Policy	Not defined
Default Domain Controller Policy	Not defined
Stand-Alone Server Default Settings	Administrators group
DC Effective Default Settings	Administrators group
Member Server Effective Default Settings	Administrators group

System objects: Require case insensitivity for non-Windows subsystems

The System objects: Require case insensitivity for non-Windows subsystems policy setting determines whether case-insensitivity is enforced for all subsystems. The Microsoft Win32 subsystem is not case-sensitive; however, the kernel supports case-sensitivity for other subsystems, such as Portable Operating System Interface for UNIX (POSIX). Enabling this policy setting enforces case-insensitivity for all directory objects, symbolic links, and input/output (I/O) objects, including file objects. Disabling this policy setting does not allow the Win32 subsystem to become case-sensitive.

The possible values for this Group Policy setting are:

• Enabled.

• Disabled.

• Not defined.

Discussion

Because Windows is case-insensitive but the POSIX subsystem will support case-sensitivity, if this policy setting is not enforced it will be possible for a user of that subsystem to create a file with the same name as another file but with a different mix of capital letters. That might confuse users when they try to access these files by using normal Win32 tools, because only one of the files will be available.

It is advisable to set System objects: Require case insensitivity for non-Windows subsystems to Enabled. All subsystems will be forced to observe case-insensitivity. This might confuse users who are familiar with one of the UNIX-based operating systems and are used to a case-sensitive operating system.

Location

GPO_name\Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options

Default Values

Server Type or GPO	Default Value
Default Domain Policy	Not defined
Default Domain Controller Policy	Not defined
Stand-Alone Server Default Settings	Enabled
DC Effective Default Settings	Enabled
Member Server Effective Default Settings	Enabled

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

The System objects: Strengthen default permissions of internal system objects (e.g. Symbolic Links) policy setting determines the strength of the default discretionary access control list (DACL) for objects. Windows maintains a global list of shared system resources, such as MS-DOS device names, mutexes, and semaphores. By using this list, processes can locate and share objects.

The possible values for this Group Policy setting are:

• Enabled.

• Disabled.

• Not defined.

Discussion

This policy setting determines the strength of the default DACL for objects. Windows Server 2003 maintains a global list of shared system resources such as MS-DOS device names, mutexes, and semaphores. By using this list, processes can locate and share objects. Each type of object is created with a default DACL that specifies who can access the objects with what permissions. Enabling this policy setting strengthens the default DACL and allows users who are not administrators to read, but not to modify, shared objects that they did not create.

It is advisable to set Strengthen default permissions of global system objects (for example, Symbolic Links) to Enabled.

Location

GPO_name\Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options

Default Values

Server Type or GPO	Default Value
Default Domain Policy	Not defined
Default Domain Controller Policy	Not defined
Stand-Alone Server Default Settings	Enabled
DC Effective Default Settings	Enabled
Member Server Effective Default Settings	Enabled

System settings: Optional subsystems

The System settings: Optional subsystems policy setting determines which subsystems support your applications. With this policy setting, you can specify as many support subsystems as your environment demands.

The possible values for this Group Policy setting are:

• A user-defined list of subsystems.

• Not defined.

Discussion

The POSIX subsystem is an Institute of Electrical and Electronic Engineers (IEEE) standard that defines a set of operating system services. The POSIX subsystem is required if the server supports applications that use that subsystem.

The subsystem introduces a security risk relating to processes that can potentially persist across logons. If a user starts a process and then logs out, the next user who logs on to the system might access the process the previous user started. This is dangerous, because the process started by the first user can retain that user's system user rights; therefore, anything the second user does using that process is performed with the user rights of the first user. This makes it difficult to trace who creates processes and objects, which is essential for post-security incident forensics.

It is advisable to set the System settings: Optional subsystems policy setting to a null value. The default value is POSIX, so applications that rely on the POSIX subsystem will no longer run. For example, Microsoft Services for UNIX 3.0 installs an updated version of the POSIX subsystem. Reset this policy setting in Group Policy for any servers that use Services for UNIX 3.0.

Location

GPO_name\Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options

Default Values

Server Type or GPO	Default Value
Default Domain Policy	Not defined
Default Domain Controller Policy	Not defined
Stand-Alone Server Default Settings	Posix
DC Effective Default Settings	Posix
Member Server Effective Default Settings	Posix

System settings: Use Certificate Rules on Windows Executables for Software Restriction Policies

The System settings: Use Certificate Rules on Windows Executables for Software Restriction Policies policy setting determines whether digital certificates are processed when a user or process attempts to run software with an .exe file name extension. This policy setting enables or disables certificate rules (a type of Software Restriction Policies rule). By using policy settings under Software Restriction Policies, you can create a certificate rule that allows or disallows the running of Authenticode-signed software, based on the digital certificate that is associated with the software. In order for certificate rules to take effect, you must enable this policy setting.

The possible values for this Group Policy setting are:

• Enabled.

• Disabled.

• Not defined.

Discussion

Software restriction policies help to prevent users and computers from executing unauthorized code, such as viruses or Trojan horses.

It is advisable to set System settings: Use Certificate Rules on Windows Executables for Software Restriction Policies to Enabled. Enabling certificate rules results in software restriction policies checking a certificate revocation list (CRL) to make sure the software's certificate and signature are valid. When you start signed programs, this setting can decrease system performance. You can disable CRLs by editing Software Restriction Policies in the desired GPO. In the Trusted Publishers Properties dialog box, clear the Publisher and Timestamp check boxes.

Location

GPO_name\Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options

Default Values

Server Type or GPO	Default Value
Default Domain Policy	Not defined
Default Domain Controller Policy	Not defined
Stand-Alone Server Default Settings	Disabled
DC Effective Default Settings	Disabled
Member Server Effective Default Settings	Disabled