User Rights

Applies To: Windows Server 2008

User rights govern the methods by which a user can log on to a system. User rights are applied at the local computer level and allow users to perform tasks on a computer or a domain. User rights include 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 computer and domain resources and can override permissions that have been set on specific objects. Privileges are managed in Group Policy under the User Rights Assignment item.

An example of a logon right is the ability to log on to a computer locally. An example of a privilege is the ability to shut down the computer. Both types of user rights are assigned by administrators to individual users or groups as part of the security settings for the computer.

User Rights Assignment Settings

Each user right has a constant name and Group Policy name associated with it. The constant names are used when referring to the right in log events. You can configure the user rights assignment settings in the following location within the Group Policy Management Console (GPMC), Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment

The following table identifies the user right short name and its associated friendly name as it appears in Windows Vista and Windows Server 2008.

Group Policy Name	Constant Name
Access this computer from the network	SeNetworkLogonRight
Access Credential Manager as a trusted caller	SeTrustedCredManAccessPrivilege
Act as part of the operating system	SeTcbPrivilege
Add workstations to domain	SeMachineAccountPrivilege
Adjust memory quotas for a process	SeIncreaseQuotaPrivilege
Allow log on locally	SeInteractiveLogonRight
Allow log on through Terminal Services	SeRemoteInteractiveLogonRight
Back up files and directories	SeBackupPrivilege
Bypass traverse checking	SeChangeNotifyPrivilege
Change the system time	SeSystemtimePrivilege
Change the time zone	SeTimeZonePrivilege
Create a pagefile	SeCreatePagefilePrivilege
Create a token object	SeCreateTokenPrivilege
Create global objects	SeCreateGlobalPrivilege
Create permanent shared objects	SeCreatePermanentPrivilege
Create symbolic links	SeCreateSymbolicLinkPrivilege
Debug programs	SeDebugPrivilege
Deny access to this computer from the network	SeDenyNetworkLogonRight
Deny access to this computer from the network	SeDenyBatchLogonRight
Deny log on as a service	SeDenyServiceLogonRight
Deny log on locally	SeDenyInteractiveLogonRight
Deny log on through Terminal Services	SeDenyRemoteInteractiveLogonRight
Enable computer and user accounts to be trusted for delegation	SeEnableDelegationPrivilege
Force shutdown from a remote system	SeRemoteShutdownPrivilege
Generate security audits	SeAuditPrivilege
Impersonate a client after authentication	SeImpersonatePrivilege
Increase a process working set	SeIncreaseWorkingSetPrivilege
Increase scheduling priority	SeIncreaseBasePriorityPrivilege
Load and unload device drivers	SeLoadDriverPrivilege
Lock pages in memory	SeLockMemoryPrivilege
Log on as a batch job	SeBatchLogonRight
Log on as a service	SeServiceLogonRight
Manage auditing and security log	SeSecurityPrivilege
Modify an object label	SeRelabelPrivilege
Modify firmware environment values	SeSystemEnvironmentPrivilege
Perform volume maintenance tasks	SeManageVolumePrivilege
Profile single process	SeProfileSingleProcessPrivilege
Profile system performance	SeSystemProfilePrivilege
Remove computer from docking station	SeUndockPrivilege
Replace a process level token	SeAssignPrimaryTokenPrivilege
Restore files and directories	SeRestorePrivilege
Shut down the system	SeShutdownPrivilege
Synchronize directory service data	SeSyncAgentPrivilege
Take ownership of files or other objects	SeTakeOwnershipPrivilege

Access this computer from the network

This policy setting determines which users can connect to the computer from the network. This capability is required by a number of network protocols, including Server Message Block (SMB)-based protocols, NetBIOS, Common Internet File System (CIFS), and Component Object Model Plus (COM+).

Possible values:

• User-defined list of accounts

• Not Defined

By default the members of the following groups have this right on workstations and servers:

• Administrators

• Backup Operators

• Everyone

• Users

By default the members of the following groups have this right on domain controllers:

• Administrators

• Authenticated Users

• Enterprise Domain Controllers

• Everyone

• Pre-Windows 2000 Compatible Access

Vulnerability

Users who can connect from their computer to the network can access resources on target computers for which they have permission. For example, the Access this computer from the network user right is required for users to connect to shared printers and folders. If this user right is assigned to the Everyone group, anyone in the group can read the files in those shared folders. This situation is unlikely because the groups created by a default installation of Windows Server 2008 and Windows Vista do not include the Everyone group. However, if a computer is upgraded to Windows Server 2008 or Windows Vista and the original computer includes the Everyone group as part of its defined users and groups, that group is transitioned as part of the upgrade process and is present on the system.

Countermeasure

Restrict the Access this computer from the network user right to only those users and groups who require access to the computer. For example, if you configure this policy setting to the Administrators and Users groups, users who log on to the domain can access resources shared from servers in the domain if members of the Domain Users group are included in the local Users group.

Potential impact

If you remove the Access this computer from the network user right on domain controllers for all users, no one can log on to the domain or use network resources. If you remove this user right on member servers, users cannot connect to those servers through the network. If you have installed optional components such as ASP.NET or Internet Information Services (IIS), you may need to assign this user right to additional accounts that are required by those components. It is important to verify that authorized users are assigned this user right for the computers that they need to access the network.

Access Credential Manager as a trusted caller

This policy setting is used by Credential Manager during Backup/Restore. No accounts should have this privilege because it is assigned only to Winlogon. Saved credentials of users may be compromised if this privilege is given to other entities.

Possible values:

• User-defined list of accounts

• Not Defined

Vulnerability

If an account is given this right, the user of the account may create an application that calls into Credential Manager and is returned the credentials for another user.

Countermeasure

Do not define the Access Credential Manager as a trusted caller policy setting for any accounts besides Credential Manager.

Potential impact

None. Not Defined is the default configuration.

Act as part of the operating system

This policy setting determines whether a process can assume the identity of any user and thereby gain access to the resources that the user is authorized to access. Typically, only low-level authentication services require this user right. Potential access is not limited to what is associated with the user by default. The calling process may request that arbitrary additional privileges be added to the access token. The calling process may also build an access token that does not provide a primary identity for auditing in the system event logs.

Possible values:

• User-defined list of accounts

• Not Defined

Default value:

• Not defined

Vulnerability

The Act as part of the operating system user right is extremely powerful. Users with this user right can take complete control of the computer and erase evidence of their activities.

Countermeasure

Restrict 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 typical circumstances. When a service requires this user right, configure the service to log on with the Local System account, which has this privilege inherently. Do not create a separate account and assign this user right to it.

Potential impact

There should be little or no impact because the Act as part of the operating system user right is rarely needed by any accounts other than the Local System account.

Add workstations to domain

This policy setting determines which users can add a computer to a specific domain. For it to take effect, it must be assigned so that it applies to at least one domain controller. A user who is assigned this user right can add up to ten workstations to the domain. Users can also join a computer to a domain if they have the Create Computer Objects permission for an organizational unit (OU) or for the Computers container in the directory. Users who are assigned this permission can add an unlimited number of computers to the domain regardless of whether they have the Add workstations to domain user right.

Possible values:

• User-defined list of accounts

• Not Defined

Default value:

• Authenticated Users group

Vulnerability

The Add workstations to domain user right presents a moderate vulnerability. Users with this right could add a computer to the domain that is configured in a way that violates organizational security policies. For example, if your organization does not want its users to have administrative privileges on their computers, a user could install Windows on his or her computer and then add the computer to the domain. The user would know the password for the local administrator account, could log on with that account, and then add his or her domain account to the local Administrators group.

Countermeasure

Configure this setting so that only authorized members of the IT team are allowed to add computers to the domain.

Potential impact

For organizations that have never allowed users to set up their own computers and add them to the domain, this countermeasure has no impact. For those that have allowed some or all users to configure their own computers, this countermeasure forces the organization to establish a formal process for these procedures going forward. It does not affect existing computers unless they are removed from and re-added to the domain.

Adjust memory quotas for a process

This policy setting determines which users can adjust the maximum amount of memory that is available to a process. Although this capability is useful when you must tune computers, it has potential for abuse.

Possible values:

• User-defined list of accounts

• Not Defined

By default, members of the following groups have this right:

• Administrators

• Local Service

• Network Service

Vulnerability

A user with the Adjust memory quotas for a process privilege can reduce the amount of memory that is available to any process, which could cause business-critical network applications to become slow or to fail. In the wrong hands, this privilege could be used to start a denial of service (DoS) attack.

Countermeasure

Restrict the Adjust memory quotas for a process user right to users who require it to perform their jobs, such as application administrators who maintain database management systems or domain administrators who manage the organization's directory and its supporting infrastructure.

Potential impact

Organizations that have not restricted users to roles with limited privileges may find it difficult to impose this countermeasure. Also, if you have installed optional components such as ASP.NET or IIS, you may need to assign the Adjust memory quotas for a process user right to additional accounts that are required by those components. IIS requires that this privilege be explicitly assigned to the IWAM_<ComputerName>, Network Service, and Service accounts. Otherwise, this countermeasure should have no impact on most computers. If this user right is necessary for a user account, it can be assigned to a local computer account instead of a domain account.

Allow log on locally

This policy setting determines which users can start an interactive session on the computer. Users who do not have this right are still able to start a remote interactive session on the computer if they have the Allow logon through Terminal Services right.

Possible values:

• User-defined list of accounts

• Not Defined

By default the members of the following groups have this right on workstations and servers:

• Administrators

• Backup Operators

• Users

By default the members of the following groups have this right on domain controllers:

• Account Operators

• Administrators

• Backup Operators

• Print Operators

• Server Operators.

Vulnerability

Any account with the Allow log on locally user right can log on at the console of the computer. If you do not restrict this user right to legitimate users who must log on to the console of the computer, unauthorized users could download and run malicious software to elevate their privileges.

Countermeasure

For domain controllers, assign the Allow log on locally user right only to the Administrators group. For other server roles, you may choose to add Backup Operators as well as Administrators. For end-user computers you should also assign this right to the Users group.

Alternatively, you can assign groups such as Account Operators, Server Operators, and Guests to the Deny Log on Locally user right.

Potential impact

If you remove these default groups, you could limit the abilities of users who are assigned to specific administrative roles in your environment. If you have installed optional components such as ASP.NET or IIS, you may need to assign the Allow log on locally user right to additional accounts that are required by those components. IIS requires that this user right be assigned to the IUSR_<ComputerName> account. You should confirm that delegated activities are not adversely affected by any changes that you make to the Allow log on locally user rights assignments.

Allow log on through Terminal Services

This policy setting determines which users can log on to the computer through a Remote Desktop connection. You should not assign this user right to additional users or groups. Instead, it is a best practice to add users to or remove users from the Remote Desktop Users group to control who can open a Remote Desktop connection to the computer.

Possible values:

• User-defined list of accounts

• Not Defined

By default members of the Administrators group have this right on domain controllers, workstations, and servers. The Remote Desktops Users group also has this right on workstations and servers.

Vulnerability

Any account with the Allow log on through Terminal Services user right can log on to the remote console of the computer. If you do not restrict this user right to legitimate users who must log on to the console of the computer, unauthorized users could download and run malicious software to elevate their privileges.

Countermeasure

For domain controllers, assign the Allow log on through Terminal Services user right only to the Administrators group. For other server roles and end-user computers, add the Remote Desktop Users group. For servers that have Terminal Server enabled and do not run in Application Server mode, ensure that only authorized IT personnel who must manage the computers remotely belong to either of these groups.

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

Potential impact

Removal of the Allow log on through Terminal Services user right from other groups or membership changes in these default groups could limit the abilities of users who perform specific administrative roles in your environment. You should confirm that delegated activities are not adversely affected.

Back up files and directories

This policy setting determines which users can circumvent file and directory permissions to back up the computer. This user right is effective only when an application attempts access through the NTFS backup application programming interface (API) through a backup tool such as NTBACKUP.EXE. Otherwise, standard file and directory permissions apply.

Possible values:

• User-defined list of accounts

• Not Defined

By default this right is granted to Administrators and Backup Operators on workstations and servers. On domain controllers, Administrators, Backup Operators, and Server Operators have this right.

Vulnerability

Users who can back up data from a computer could take the backup media to a non-domain computer on which they have administrative privileges and restore the data. They could take ownership of the files and view any unencrypted data that is contained within the backup set.

Countermeasure

Restrict the Back up files and directories user right to members of the IT team who must back up organizational data as part of their day-to-day job responsibilities. If you are using backup software that runs under specific service accounts, only these accounts (and not the IT staff) should have the Back up files and directories user right.

Potential impact

Changes in the membership of the groups that have the Back up files and directories user right could limit the abilities of users who are assigned to specific administrative roles in your environment. You should confirm that authorized backup administrators can still perform backup operations.

Bypass traverse checking

This policy setting determines which users can pass through folders without being checked for the special access permission "Traverse Folder" when they navigate an object path in the NTFS file system or in the registry. This user right does not allow the user to list the contents of a folder. It only allows the user to traverse folders.

Possible values:

• User-defined list of accounts

• Not Defined

Vulnerability

The default configuration for the Bypass traverse checking setting is to allow all users, including the Everyone group, to bypass traverse checking. Permissions to files and folders are controlled though appropriate configuration of file system access control lists (ACLs) because the ability to traverse the folder does not provide any read or write permissions to the user. The only scenario in which the default configuration could lead to a mishap would be if the administrator who configures permissions does not understand how this policy setting works. For example, the administrator might expect that users who are unable to access a folder are unable to access the contents of any child folders. Such a situation is unlikely, and, therefore, this vulnerability presents little risk.

Countermeasure

Organizations that are extremely concerned about security may want to remove the Everyone group, or perhaps even the Users group, from the list of groups with the Bypass traverse checking user right. Taking explicit control over traversal assignments can be an effective way to limit access to sensitive information. (Also, the Access–based Enumeration feature that was added in Windows Server® 2003 operating systems with Service Pack 1 (SP1) can be used. If you use access–based enumeration, users cannot see any folder or file to which they do not have access. For more information about this feature, see Access-based Enumeration (https://go.microsoft.com/fwlink/?LinkId=100745).

Potential impact

The Windows operating systems, as well as many applications, were designed with the expectation that anyone who can legitimately access the computer will have this user right. Therefore, we recommend that you thoroughly test any changes to assignments of the Bypass traverse checking user right before you make such changes to production systems. In particular, IIS requires this user right to be assigned to the Network Service, Local Service, IIS_WPG, IUSR_<ComputerName>, and IWAM_<ComputerName> accounts. (It must also be assigned to the ASPNET account through its membership in the Users group.) We recommend that you leave this policy setting at its default configuration.

Change the system time

This policy setting determines which users can adjust the time on the computer's internal clock. It is not required to change the time zone or other display characteristics of the system time.

Possible values:

• User-defined list of accounts

• Not Defined

By default on workstations and server, members of the Administrators and Local Service group have this right. On domain controllers, members of the Administrators, Server Operators, and Local Service have this right.

Vulnerability

Users who can change the time on a computer could cause several problems. For example, time stamps on event log entries could be made inaccurate, time stamps on files and folders that are created or modified could be incorrect, and computers that belong to a domain may not be able to authenticate themselves or users who try to log on to the domain from them. Also, because the Kerberos authentication protocol requires that the requester and authenticator have their clocks synchronized within an administrator-defined skew period, an attacker who changes a computer's time may cause that computer to be unable to obtain or grant Kerberos tickets.

The risk from these types of events 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 and member servers use the authenticating domain controller as their inbound time partner.

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

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

• The PDC emulator operations master at the root of the domain is authoritative for the organization. Therefore, we recommend that you configure this computer to synchronize with a reliable external time server.

This vulnerability becomes much more serious if an attacker is able to change the system time and then stop the Windows Time service or reconfigure it to synchronize with a time server that is not accurate.

Countermeasure

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

Potential impact

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

Change the time zone

This policy setting determines which users can adjust the time zone used by the computer for displaying the local time, which is the computer's system time plus the time zone offset.

Possible values:

• User-defined list of accounts

• Not Defined

By default, members of the Administrators and Users group have this right.

Vulnerability

Changing the time zone represents little vulnerability because the system time is not affected. This setting merely enables users to display their preferred time zone while being synchronized with domain controllers in different time zones.

Countermeasure

Countermeasures are not required because system time is not affected by this setting.

Potential impact

None. Not defined is the default configuration.

Create a pagefile

This policy setting determines which users can create and change the size of a page file. Specifically, it determines whether they can specify a page file size for a particular drive in the Performance Options box located on the Advanced tab of the System Properties dialog box or through using internal application interfaces (APIs).

Possible values:

• User-defined list of accounts

• Not Defined

By default members of the Administrators group have this right.

Vulnerability

Users who can change the page file size could make it extremely small or move the file to a highly fragmented storage volume, which could cause reduced computer performance.

Countermeasure

Restrict the Create a page file user right to members of the Administrators group.

Potential impact

None. Restricting this right to members of the Administrators group is the default configuration.

Create a token object

This policy setting determines what accounts that a process can use to create a token, which it can then use to gain access to any local resources when the process uses NtCreateToken() or other token-creation APIs.

Possible values:

• User-defined list of accounts

• Not Defined

This user right is used internally by the operating system; by default, it is not assigned to any user groups.

Vulnerability

The operating system examines a user's access token to determine the level of the user's privileges. 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 privilege, the change is immediately recorded, but the change is not reflected in the user's access token until the next time the user logs on or connects. Users with the ability to create or modify tokens can change the level of access for any currently logged on account. They could escalate their own privileges or create a DoS condition.

Countermeasure

Do not assign the Create a token object user right to any users. Processes that require this user right should use the Local System account, which already includes it, instead of a separate user account that has this user right assigned.

Potential impact

None. Not defined is the default configuration.

Create global objects

This policy setting determines which users can create global objects that are available to all sessions. Users can still create objects that are specific to their own session if they do not have this user right.

Possible values:

• User-defined list of accounts

• Not Defined

By default members of the Administrators group have this right, as do Local Service and Network Service accounts.

Vulnerability

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

Countermeasure

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

Potential impact

None. Restricting the Create global objects user right to members of the local Administrators and Service groups is the default configuration.

Create permanent shared objects

This policy setting determines which users can create directory objects in the object manager. Users who have this capability can create permanent shared objects, including devices, semaphores, and mutexes. This user right is useful to kernel-mode components that extend the object namespace, and they have this user right inherently. Therefore, it is typically not necessary to specifically assign this user right to any users.

Possible values:

• User-defined list of accounts

• Not Defined

Vulnerability

Users who have the Create permanent shared objects user right could create new shared objects and expose sensitive data to the network.

Countermeasure

Do not assign the Create permanent shared objects user right to any users. Processes that require this user right should use the System account, which already includes this user right, instead of a separate user account.

Potential impact

None. Not defined is the default configuration.

Create symbolic links

This policy setting determines which users can create a symbolic link from the currently logged on computer to a file or folder in a different location.

Possible values:

• User-defined list of accounts

• Not Defined

By default members of the Administrators group have this right.

Vulnerability

Users who have the Create Symbolic Links user right could inadvertently or maliciously expose your system to symbolic link attacks. Symbolic link attacks can be used to change the permissions on a file, to corrupt data, to destroy data, or as a DoS attack.

Countermeasure

Do not assign the Create Symbolic Links user right to standard users. Restrict this right to trusted administrators. You can use the fsutil command to establish a symlink file system setting that controls the kind of symbolic links that can be created on a computer. For more information about fsutil and symbolic links, type fsutil behavior set symlinkevaluation /? at an elevated command prompt.

Potential impact

None. Not defined is the default configuration.

Debug programs

This policy setting determines which users can open or attach to any process, even those they do not own. This user right provides access to sensitive and critical operating-system components.

Possible values:

• User-defined list of accounts

• Not Defined

Vulnerability

The Debug programs user right can be exploited to capture sensitive computer information from system memory or to access and modify kernel or application structures. Some attack tools exploit this user right to extract hashed passwords and other private security information or to insert rootkit code. By default, the Debug programs user right is assigned only to administrators, which helps to mitigate the risk from this vulnerability.

Countermeasure

Remove the accounts of all users and groups that do not require the Debug programs user right.

Potential impact

If you revoke this user right, no one can debug programs. However, typical circumstances rarely require this capability on production computers. If a problem arises that requires an application to be debugged on a production server, you can move the server to a different OU temporarily and assign the Debug programs user right to a separate Group Policy for that OU.

Deny access to this computer from the network

This policy setting determines which users are prevented from accessing this computer over the network.

Possible values:

• User-defined list of accounts

• Not Defined

Vulnerability

Users who can log on to 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.

Countermeasure

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

• ANONYMOUS LOGON

• Built-in local Administrator account

• Local Guest account

• All service accounts

An important exception to this list is any service accounts that are used to start services that must connect to the computer over the network. For example, if you have configured a shared folder for Web servers to access and present content within that folder through a Web site, you may need to allow the account that runs IIS to log on to the server with the shared folder from the network. This user right is particularly effective when you must configure servers and workstations on which sensitive information is handled because of regulatory compliance concerns.

Potential impact

If you configure the Deny access to this computer from the network user right for other groups, you could limit the abilities of users who are assigned to specific administrative roles in your environment. You should verify that delegated tasks are not negatively affected.

Deny log on as a batch job

This policy setting determines which accounts are prevented from logging on by using a batch-queue tool, the feature in Windows Vista and Windows Server 2008 that is used to schedule and start jobs automatically one or more times in the future. The ability to log on by using a batch-queue tool is needed for any accounts that are used to start scheduled jobs by means of the Task Scheduler.

Possible values:

• User-defined list of accounts

• Not Defined

Vulnerability

Accounts that have the Deny log on as a batch job user right could be used to schedule jobs that could consume excessive computer resources and cause a DoS condition.

Countermeasure

Assign the Deny log on as a batch job user right to the local Guest account.

Potential impact

If you assign the Deny log on as a batch job user right to other accounts, you could deny users who are assigned to specific administrative roles the ability to perform their required job activities. You should confirm that delegated tasks are not affected adversely.

Deny log on as a service

This policy setting determines which users are prevented from logging on as a service.

Possible values:

• User-defined list of accounts

• Not Defined

Vulnerability

Accounts that can log on as a service could be used to configure and start new unauthorized services, such as a keylogger or other malicious software. The benefit of the specified countermeasure is somewhat reduced by the fact that only users with administrative privileges can install and configure services, and an attacker who has already attained that level of access could configure the service to run with the System account.

Countermeasure

We recommend that you not assign the Deny log on as a service user right to any accounts, which is the default configuration. Organizations that are extremely concerned about security may want to assign this user right to groups and accounts that they are certain will never need to log on as a service.

Potential impact

If you assign the Deny log on as a service user right to specific accounts, services may not start and a DoS condition could result.

Deny log on locally

This policy setting determines which users are prevented from logging on directly at the computer's console.

Possible values:

• User-defined list of accounts

• Not Defined

Vulnerability

Any account with the ability to log on locally could be used to log on at the console of the computer. If this user right is not restricted to legitimate users who must log on to the console of the computer, unauthorized users might download and run malicious software that elevates their privileges.

Countermeasure

Assign the Deny log on locally user right to the local guest account. If you have installed optional components such as ASP.NET, you may want to assign this user right to additional accounts that are required by those components.

Potential impact

If you assign the Deny log on locally user right to additional accounts, you could limit the abilities of users who are assigned to specific roles in your environment. However, this user right should explicitly be assigned to the ASPNET account on computers that are configured with the Web Server role. You should confirm that delegated activities are not adversely affected.

Deny log on through Terminal Services

This policy setting determines which users are prevented from logging on to the computer through a Remote Desktop connection.

Possible values:

• User-defined list of accounts

• Not Defined

Vulnerability

Any account with the right to log on through Terminal Services could 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 computer, unauthorized users might download and run malicious software that elevates their privileges.

Countermeasure

Assign the Deny log on through Terminal Services logon right to the built-in local guest account and all service accounts. If you have installed optional components such as ASP.NET, you may want to assign this logon right to additional accounts that are required by those components.

Potential impact

If you assign the Deny log on through Terminal Services user right to other groups, you could limit the abilities of users who are assigned to specific administrative roles in your environment. Accounts that have this user right cannot connect to the computer through either Terminal Services or Remote Assistance. You should confirm that delegated tasks are not negatively impacted.

Enable computer and user accounts to be trusted for delegation

This policy setting determines which users can change the Trusted for Delegation setting on a user or computer object in Active Directory Domain Services. Users and Computers that are assigned this user right must also have write access to the account control flags on the object.

Delegation of authentication is a capability that multitiered client and server applications use. It allows a public-facing service to use client credentials to authenticate to an application or database service. For this configuration to be possible, both client and server must run under accounts that are trusted for delegation.

Possible values:

• User-defined list of accounts

• Not Defined

Vulnerability

Misuse of the Enable computer and user accounts to be trusted for delegation user right could allow unauthorized users to impersonate other users on the network. An attacker could exploit this privilege to gain access to network resources and make it difficult to determine what has happened after a security incident.

Countermeasure

The Enable computer and user accounts to be trusted for delegation user right should be assigned only if there is a clear need for its functionality. When you assign this right, you should investigate the use of constrained delegation to control what the delegated accounts can do. On domain controllers, this right is assigned to the Administrators group by default.

Potential impact

None. Not defined is the default configuration.

Force shutdown from a remote system

This policy setting determines which users can shut down a computer from a remote location on the network.

Possible values:

• User-defined list of accounts

• Not Defined

Vulnerability

Any user who can shut down a computer could cause a DoS condition to occur. Therefore, this user right should be tightly restricted.

Countermeasure

Restrict the Force shutdown from a remote system user right to members of the Administrators group or other specifically assigned roles that require this capability, such as non-administrative operations center staff.

Potential impact

If, on a domain controller, you remove the Force shutdown from a remote system user right from the Server Operator group, you could limit the abilities of users who are assigned to specific administrative roles in your environment. You should confirm that delegated activities are not adversely affected.

Generate security audits

This policy setting determines which accounts can be used by a process to generate audit records in the Security log. You can use the information in the Security log to trace unauthorized computer access.

Possible values:

• User-defined list of accounts

• Not Defined

Vulnerability

Accounts that can write to the Security log could be used by an attacker to fill that log with meaningless events. If the computer is configured to overwrite events as needed, attackers could 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 and it is not configured to automatically back up the log files, this method could be used to create a DoS condition.

Countermeasure

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

Potential impact

None. Restricting the Generate security audits user right to the Local Service and Network Service accounts is the default configuration.

Impersonate a client after authentication

This policy setting determines which programs are allowed to impersonate a user or another specified account and act on behalf of the user. If this user right is required for this kind of impersonation, an unauthorized user cannot cause a client to connect—for example, by remote procedure call (RPC) or named pipes—to a service that they have created to impersonate that client, which could elevate the unauthorized user's permissions 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 that are started by the COM infrastructure and configured to run under a specific account also have the Service group added to their access tokens. As a result, these processes are assigned this user right when they are started.

Also, a user can 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, logged on to the network with explicit credentials to create the access token.

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

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

Possible values:

• User-defined list of accounts

• Not Defined

Vulnerability

An attacker with the Impersonate a client after authentication user right could create a service, trick a client to make the client connect to the service, and then impersonate that client to elevate the attacker's level of access to that of the client.

Countermeasure

On member servers, ensure that only the Administrators and Service groups (SERVICE, Local Service, and Network Service) have the Impersonate a client after authentication user right assigned to them.

Potential impact

In most cases this configuration has no impact. If you have installed optional components such as ASP.NET or IIS, you may need to assign the Impersonate a client after authentication user right to additional accounts that are required by those components, such as IUSR_<ComputerName>, IIS_WPG, ASP.NET, or IWAM_<ComputerName>.

Increase a process working set

This policy setting determines which users can increase or decrease the size of a process's working set. The working set of a process is the set of memory pages currently visible to the process in physical RAM memory. These pages are resident and available for an application to use without triggering a page fault. The minimum and maximum working set sizes affect the virtual memory paging behavior of a process.

Possible values:

• User-defined list of accounts

• Not Defined

By default, standard users have this right.

Vulnerability

Increasing the working set size for a process decreases the amount of physical memory available to the rest of the system.

Countermeasure

Increase user awareness of the impact of increasing a process working set and how to recognize when their system is adversely impacted by changing this setting.

Potential impact

None. Allowing standard users to increase the process working set is the default configuration.

Increase scheduling priority

This policy setting determines which users can increase the base priority class of a process. It is not a privileged operation to increase relative priority within a priority class. This user right is not required by administrative tools that are supplied with the operating system but might be required by software development tools.

Possible values:

• User-defined list of accounts

• Not Defined

Vulnerability

A user who is assigned this user right could increase the scheduling priority of a process to Real-Time, which would leave little processing time for all other processes and could lead to a DoS condition.

Countermeasure

Verify that only Administrators have the Increase scheduling priority user right assigned to them.

Potential impact

None. Restricting the Increase scheduling priority user right to members of the Administrator's group is the default configuration.

Load and unload device drivers

This policy setting 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.

Possible values:

• User-defined list of accounts

• Not Defined

Vulnerability

Device drivers run as highly privileged code. A user who has the Load and unload device drivers user right could unintentionally install malicious software that masquerades as a device driver. Administrators should exercise greater care and install only drivers with verified digital signatures.

Countermeasure

Do not assign the Load and unload device drivers user right to any user or group other than Administrators on member servers. On domain controllers, do not assign this user right to any user or group other than Domain Admins.

Potential impact

If you remove the Load and unload device drivers user right from the Print Operators group or other accounts, you could limit the abilities of users who are assigned to specific administrative roles in your environment. You should ensure that delegated tasks are not negatively affected.

Lock pages in memory

This policy setting determines which accounts can use a process to keep data in physical memory, which prevents the computer from paging the data to virtual memory on disk. If you assign this user right, significant degradation of computer performance can occur.

Possible values:

• User-defined list of accounts

• Not Defined

Vulnerability

Users with the Lock pages in memory user right could assign physical memory to several processes, which could leave little or no RAM for other processes and result in a DoS condition.

Countermeasure

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

Potential impact

None. Not defined is the default configuration.

Log on as a batch job

This policy setting determines which accounts can log on by using a batch-queue tool 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 is automatically assigned 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 instead of as an interactive user, and the task runs in the user's security context.

Possible values:

• User-defined list of accounts

• Not Defined

Vulnerability

The Log on as a batch job user right presents a low-risk vulnerability. For most organizations, the default setting of Not Defined is sufficient. Members of the local Administrators group have this right by default.

Countermeasure

You should allow the computer to manage this logon right automatically if you want to allow scheduled tasks 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 account.

For IIS servers, you should configure this policy locally instead of through domain–based Group Policy settings so that you can ensure that the local IUSR_<ComputerName> and IWAM_<ComputerName> accounts have this logon right.

Potential impact

If you configure the Log on as a batch job setting by using domain-based Group Policy settings, the computer cannot assign the user right to accounts that are used for scheduled jobs in the Task Scheduler. If you install optional components such as ASP.NET or IIS, you may need to assign this user right to additional accounts that are required by those components. For example, IIS requires assignment of this user right to the IIS_WPG group and the IUSR_<ComputerName>, ASPNET, and IWAM_<ComputerName> accounts. If this user right is not assigned to this group and these accounts, IIS cannot run some COM objects that are necessary for proper functionality.

Log on as a service

This policy setting determines which service accounts can register a process as a service. In Windows Server 2008 and Windows Vista, only the Network Service account has this right by default. Any service that runs under a separate user account must be assigned this user right.

Possible values:

• User-defined list of accounts

• Not Defined

Vulnerability

Log on as a service is a powerful user right because it allows accounts to start network services or services that run continuously on a computer, even when no one is logged on to the console. The risk is reduced by the fact that only users with administrative privileges can install and configure services. An attacker who has already attained that level of access could configure the service to run with the Local System account.

Countermeasure

By definition the Network Service account has the Log on as a service user right. This right is not granted through the group policy setting. You should minimize the number of other accounts that are granted this user right.

Potential impact

On most computers, restricting the Log on as a service user right to the Local System, Local Service, and Network Service built-in accounts is the default configuration, and there is no negative impact. However, if you have installed optional components such as ASP.NET or IIS, you may need to assign the Log on as a service user right to additional accounts that are required by those components. IIS requires that this user right be explicitly granted to the ASPNET user account.

Manage auditing and security log

This policy setting determines which users can specify object access audit options for individual resources such as files, Active Directory objects, and registry keys. Object access audits are not performed unless you enable them by using either the GPMC or the Auditpol command-line tool. A user who is assigned this user right can also view and clear the Security log in Event Viewer. For more information about audit policy, see the Audit Policy section of this guide.

Possible values:

• User-defined list of accounts

• Not Defined

Vulnerability

The Manage auditing and security log user right is a powerful user right and it should be closely guarded. Anyone with this user right can clear the Security log to erase important evidence of unauthorized activity.

Countermeasure

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

Potential impact

None. Restricting the Manage auditing and security log user right to the local Administrators group is the default configuration.

Modify an object label

This policy setting determines which users can modify the integrity label of objects, such as files, registry keys, or processes owned by other users. The integrity label is used by the Windows Integrity Controls (WIC) feature and is new to Windows Vista. WIC keeps lower-integrity processes from modifying higher-integrity objects by assigning one of six possible labels to objects on the system. The following list describes the integrity levels in order from lowest to highest integrity:

• Untrusted. Default assignment for processes that are logged on anonymously.

• Low. Default assignment for processes that interact with the Internet.

• Medium. Default assignment for standard user accounts and any object not explicitly designated with a lower or higher integrity level.

• High. Default assignment for administrator accounts and processes that request to run using administrative rights.

• System. Default assignment for Windows kernel and core services.

• Installer. Used by setup programs to install software. It is important that only trusted software is installed on computers because objects that are assigned the Installer integrity level can install, modify, and uninstall all other objects.

Possible values:

• User-defined list of accounts

• Not Defined

By default no user accounts are given this right.

Vulnerability

Modify an object label is a powerful user right and it should be closely guarded. Anyone with this user right can change the integrity level of a file or process so that it becomes elevated or decreased to a point where it can be deleted by lower-level processes. Either of these states effectively circumvents the protection offered by Windows Integrity Controls and makes your system vulnerable to attacks by malicious software. If malicious software is set with an elevated integrity level such as Trusted Installer or System, administrator accounts do not have sufficient integrity levels to delete the program from the system. In that case, use of the Modify an object label right is mandated so that the object can be relabeled. However, the relabeling must occur by using a process that is at the same or a higher level of integrity than the object that you are attempting to relabel.

Countermeasure

Do not give any group this right. If necessary, implement it for a constrained period of time to a trusted individual to respond to a specific organizational need.

Potential impact

None. Not defined is the default configuration.

Modify firmware environment values

This security setting determines who can modify firmware environment values. The effect of the setting depends on the processor.

On x86-based computers, the only firmware environment value that can be modified by assigning this user right is the Last Known Good Configuration setting, which should only be modified by the system.

On Itanium-based computers, boot information is stored in nonvolatile RAM. Users must be assigned this user right to run bootcfg.exe and to change the Default Operating System setting on Startup and Recovery in System Properties.

On all computers, this user right is required to install or upgrade Windows.

Possible values:

• User-defined list of accounts

• Not Defined

Vulnerability

Anyone who is assigned the Modify firmware environment values user right could configure the settings of a hardware component to cause it to fail, which could lead to data corruption or a DoS condition.

Countermeasure

Ensure that only the local Administrators group is assigned the Modify firmware environment values user right.

Potential impact

None. Restricting the Modify firmware environment values user right to the members of the local Administrators group is the default configuration.

Perform volume maintenance tasks

This policy setting determines which users can perform volume or disk management tasks, such as defragmenting an existing volume, creating or removing volumes, and running the Disk Cleanup tool.

Possible values:

• User-defined list of accounts

• Not Defined

Vulnerability

A user who is assigned the Perform volume maintenance tasks user right could delete a volume, which could result in the loss of data or a DoS condition. Also, disk maintenance tasks can be used to modify on disk data such as user rights assignments that might lead to escalation of privileges.

Countermeasure

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

Potential impact

None. Restricting the Perform volume maintenance tasks user right to the local Administrator's group is the default configuration.

Profile single process

This policy setting determines which users can sample the performance of an application process. Typically, you do not need this user right to use the Performance console. However, you do need this user right if System Monitor is configured to collect data through Windows Management Instrumentation (WMI).

Possible values:

• User-defined list of accounts

• Not Defined

Vulnerability

The Profile single process user right presents a moderate vulnerability. Attackers with this user right could monitor a computer's performance to help identify critical processes they might want to attack directly. Attackers may also be able to determine what processes run on the computer so that they could identify countermeasures that they may need to avoid, such as antivirus software or an intrusion-detection system, or which other users are logged on to a computer.

Countermeasure

Ensure that only the local Administrators group is assigned the Profile single process user right.

Potential impact

If you remove the Profile single process user right from the Power Users group or other accounts, you could limit the abilities of users who are assigned to specific administrative roles in your environment. You should ensure that delegated tasks are not negatively affected.

Profile system performance

This policy setting determines which users can sample the performance of computer system processes. This privilege is required by the Performance console only if it is configured to collect data through WMI. Typically, you do not need this user right to use the Performance console. However, you must have this user right if System Monitor is configured to collect data through WMI.

Possible values:

• User-defined list of accounts

• Not Defined

Vulnerability

The Profile system performance user right poses a moderate vulnerability. Attackers with this user right could monitor a computer's performance to help identify critical processes that they might want to attack directly. Attackers may also be able to determine what processes are active on the computer so that they could identify countermeasures to avoid, such as antivirus software or an intrusion detection system.

Countermeasure

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

Potential impact

None. Restricting the Profile system performance user right to the local Administrators group is the default configuration.

Remove computer from docking station

This policy setting determines which users of a portable computer need to log on and then click Eject PC on the Start menu to undock the computer.

Possible values:

• User-defined list of accounts

• Not Defined

By default, members of the following group have this right:

• Local Administrators

Vulnerability

Anyone who has the Remove computer from docking station user right can log on and then remove a portable computer from its docking station. If this setting is not defined, it has the same effect as if everyone were granted this right. However, the value of implementing this countermeasure is reduced by the following factors:

• If attackers can restart the computer, they could remove it from the docking station after the BIOS starts but before the operating system starts.

• This setting does not affect servers because they typically are not installed in docking stations.

• An attacker could steal the computer and the docking station together.

• Computers that can be mechanically undocked can be physically removed by the user whether or not they use the Windows undocking functionality.

Countermeasure

Ensure that only the local Administrators group and the user account to which the computer is allocated are assigned the Remove computer from docking station user right.

Potential impact

By default, only members of the local Administrators group are granted this right. Other user accounts must be explicitly granted the right as necessary. If your organization's users are not members of the local Administrators groups on their portable computers, they cannot remove their own portable computers from their docking stations without shutting them down first. Therefore, you may want to assign the Remove computer from docking station privilege to the local Users group for portable computers.

Replace a process level token

This policy setting determines which parent processes can replace the access token that is associated with a child process. In Windows Vista and Windows Server 2008, there are a significantly larger number of service hosts than in Windows Server 2003. This is because, in Windows Server 2008 and Windows Vista, multiple services with the same access and security requirements are collected together and run in a common environment to reduce boot time and system overhead, instead of running many services in separate memory spaces.

Possible values:

• User-defined list of accounts

• Not Defined

Vulnerability

Users with the Replace a process level token privilege can start processes as other users whose credentials they know. They could use this method to hide their unauthorized actions on the computer. (On Windows 2000-based computers, use of the Replace a process level token user right also requires the user to have the Adjust memory quotas for a process user right that is discussed earlier in this section.)

Countermeasure

For member servers, ensure that only the Local Service and Network Service accounts have the Replace a process level token user right.

Potential impact

On most computers, restricting the Replace a process level token user right to the Local Service and Network Service built-in accounts is the default configuration, and there is no negative impact. However, if you have installed optional components such as ASP.NET or IIS, you may need to assign the Replace a process level token privilege to additional accounts. For example, IIS requires that the Service, Network Service, and IWAM_<ComputerName> accounts be explicitly granted this user right.

Restore files and directories

This security setting determines which users can bypass file, directory, registry, and other persistent objects permissions when restoring backed up files and directories, and determines which users can set any valid security principal as the owner of an object.

Granting this user right to an account is similar to granting the account the following permissions to all files and folders on the system:

• Traverse Folder/Execute File

• Write

By default this right is granted to the Administrators and Backup Operators groups. On domain controllers, it is also granted to the Server Operators group.

Possible values:

• User-defined list of accounts

• Not Defined

Vulnerability

An attacker with the Restore files and directories user right could restore sensitive data to a computer and overwrite data that is more recent, which could lead to loss of important data, data corruption, or a DoS condition. Attackers could overwrite executable files that are used by legitimate administrators or system services with versions that include malicious software to grant themselves elevated privileges, compromise data, or install programs that provide for continued access to the computer.

Countermeasure

Ensure that only the local Administrators group is assigned the Restore files and directories user right unless your organization has clearly defined roles for backup and for restore personnel.

Potential impact

If you remove the Restore files and directories user right from the Backup Operators group and other accounts, users who are not members of the local Administrators group cannot load data backups. If your organization delegates the restoration of backups to a subset of your information technology staff, you should verify that this change does not negatively affect the ability of your organization's personnel to do their jobs.

Shut down the system

This policy setting determines which users can shut down the local computer.

Possible values:

• User-defined list of accounts

• Not Defined

Vulnerability

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

When a domain controller is shut down, it is no longer available to process logons, serve Group Policy, and answer Lightweight Directory Access Protocol (LDAP) queries. If you shut down domain controllers that possess Flexible Single–Master Operations (FSMO) roles, you can disable key domain functionality, such as processing logons for new passwords—the Primary Domain Controller (PDC) Emulator role.

For other server roles, especially those where non-administrators have rights to log on to the server (such as terminal servers), it is critical that this privilege be removed from users that do not have a legitimate reason to restart the servers.

Countermeasure

Ensure that only Administrators and Backup Operators are assigned the Shut down the system user right on member servers and that only Administrators have it on domain controllers.

Potential impact

The impact of removing these default groups from the Shut down the system user right could limit the delegated abilities of assigned roles in your environment. You should confirm that delegated activities are not adversely affected.

Synchronize directory service data

This policy setting determines which users and groups have the authority to synchronize all directory service data, regardless of the protection on the objects and properties. This privilege is required to use LDAP directory synchronization (dirsync) services.

Possible values:

• User-defined list of accounts

• Not Defined

Vulnerability

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

Countermeasure

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

Potential impact

None. Not defined is the default configuration.

Take ownership of files or other objects

This policy setting determines which users can take ownership of any securable object in the computer, including Active Directory objects, NTFS files and folders, printers, registry keys, services, processes, and threads.

Possible values:

• User-defined list of accounts

• Not Defined

Vulnerability

Any users with the Take ownership of files or other objects user right can take control of any object, regardless of the permissions on that object, and then make any changes they want to that object. Such changes could result in exposure of data, corruption of data, or a DoS condition.

Countermeasure

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

Potential impact

None. Restricting the Take ownership of files or other objects user right to the local Administrators group is the default configuration.