Threats and Countermeasures

User rights 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.

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. For a summary of the prescribed settings in this chapter, see the Microsoft® Excel® workbook "Windows Default Security and Services Configuration" that is included with this guide. This workbook documents the default user rights assignment settings.

Note: Internet Information Server (IIS) expects certain user rights to be assigned to the built-in accounts that it uses. The user rights assignment settings in this chapter identify which rights IIS requires; for more information about these requirements, see the "IIS and Built-In Accounts (IIS 6.0)" list at www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/3648346f-e4f5-474b-86c7-5a86e85fa1ff.mspx.

On This Page

	User Rights Assignment Settings
	More Information

User Rights Assignment Settings

You can configure the user rights assignment settings in the following location within the Group Policy Object Editor:

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

Access this computer from the network

This policy setting determines whether 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+).

The possible values for the Access this computer from the network setting are:

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 and some shared folders have both share and NTFS file system (NTFS) permissions configured so that the same group has read access, then anyone in the group will be able to view files in those shared folders. However, this situation is unlikely for new installations of Microsoft Windows Server™ 2003 with Service Pack 1 (SP1), because the default share and NTFS permissions in Windows Server 2003 do not include the Everyone group. This vulnerability may have a higher level of risk for computers that you upgrade from Windows NT® 4.0 or Windows 2000, because the default permissions for these operating systems are not as restrictive as the default permissions in Windows Server 2003.

Countermeasure

Restrict the Access this computer from the network user right to only those users who require access to the server. For example, if you configure this policy setting to the Administrators and Users groups, users who log on to the domain will be able to 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 will be able to log on to the domain or use network resources. If you remove this user right on member servers, users will not be able to 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 they need to access the network.

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. Note that potential access is not limited to what is associated with the user by default. The calling process might request that arbitrary additional privileges be added to the access token. The calling process might also build an access token that does not provide a primary identity for auditing in the system event logs.

The possible values for the Act as part of the operating system setting are:

Vulnerability

The Act as part of the operating system user right is extremely powerful. Anyone 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 whether a user 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 Active Directory® directory service. 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.

The possible values for the Add workstations to domain setting are:

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 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 with that account and then add their domain account to the local Administrators group.

Countermeasure

Configure the Add workstations to domain setting so that only authorized members of the information technology (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 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 going forward. It will 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 whether users can adjust the maximum amount of memory that is available to a process. Although this capability is useful when you need to tune computers, you should consider its potential for abuse. In the wrong hands, it could be used to launch a denial of service (DoS) attack.

The possible values for the Adjust memory quotas for a process setting are:

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.

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 will 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 to a domain account.

Allow log on locally

This policy setting determines whether a user 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.

The possible values for the Allow log on locally setting are:

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 need to be able to log on to the console of the computer, unauthorized users could download and execute malicious code to elevate their privileges.

Countermeasure

For domain controllers, only assign the Allow log on locally user right to the Administrators group. For other server roles, you may choose to add Backup Operators and Power Users. 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 Internet Information Services, you may need to assign 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 will not be adversely affected.

Allow log on through Terminal Services

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

The possible values for the Allow log on through Terminal Services setting are:

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 need to log on to the console of the computer, unauthorized users could download and execute malicious code to elevate their privileges.

Countermeasure

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

Warning: For Terminal Servers that run in Application Server mode, 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 has this logon right by default.

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 will not be adversely affected.

Back up files and directories

This policy setting determines whether 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 utility such as NTBACKUP.EXE. Otherwise, standard file and directory permissions apply.

The possible values for the Back up files and directories setting are:

Vulnerability

Users who are able to 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 need to be able to backup 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 are still able to perform backup operations.

Bypass traverse checking

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

The possible values for the Bypass traverse checking setting are:

Vulnerability

The default configuration for the Bypass traverse checking setting is to allow anyone to bypass traverse checking, and experienced Windows system administrators configure file system access control list (ACLs) accordingly. 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, they might expect that users who are unable to access a folder will be 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 a very effective way to control access to sensitive information. (Also, the Access–based Enumeration feature that was added in Windows Server 2003 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 http://technet2.microsoft.com/WindowsServer/en/library/f04862a9-3e37-4f8c-ba87-917f4fb5b42c1033.mspx.

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, Microsoft recommends 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.) This guide recommends that you leave this policy setting at its default configuration.

Change the system time

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

The possible values for the Change the system time setting are:

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 requestor 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:

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.

Create a page file

This policy setting determines whether 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 that is located on the Advanced tab of the System Properties dialog box.

The possible values for the Create a page file setting are:

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. This is the default configuration.

Create a token object

This policy setting determines whether a process can 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.

The possible values for the Create a token object setting are:

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. A user 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 System account, which already includes it, instead of a separate user account that has this user right assigned.

Potential Impact

None. This is the default configuration.

Create global objects

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

The possible values for the Create global objects setting are:

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. This is the default configuration.

Create permanent shared objects

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

The possible values for the Create permanent shared objects setting are:

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. This is the default configuration.

Debug programs

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

The possible values for the Debug programs setting are:

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 effect rootkit code insertions. By default, the Debug programs user right is assigned only to administrators, which helps to mitigate the risk from this vulnerability.

Countermeasure

Revoke the Debug programs user right from all users and groups that do not require it.

Potential Impact

If you revoke this user right, no one will be able to 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 temporarily, you can move the server to a different OU and assign the Debug programs user right to a separate Group Policy for that OU.

The service account that is used for the cluster service needs the Debug programs privilege; if it does not, Windows Clustering will fail. For additional information about how to configure Windows Clustering in conjunction with computer hardening, see Microsoft Knowledge Base article 891597, “How to apply more restrictive security settings on a Windows Server 2003–based cluster server” at http://support.microsoft.com/default.aspx?scid=891597.

Utilities that are used to manage processes will be unable to affect processes that are not owned by the person who runs the utilities. For example, the Windows Server 2003 Resource Kit tool Kill.exe requires this user right for an administrator to terminate processes that they did not launch.

Also, some older versions of Update.exe (which is used to install Windows product updates) require the account that applies the update to have this user right. If you install one of the patches that uses this version of Update.exe, the computer could become unresponsive. For more information, see Microsoft Knowledge Base article 830846, “Windows Product Updates may stop responding or may use most or all the CPU resources” at http://support.microsoft.com/default.aspx?scid=830846.

Deny access to this computer from the network

This policy setting determines whether users have the ability to connect to the computer from the network.

The possible values for the Deny access to this computer from the network setting are:

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. You can explicitly deny this user right to high-risk accounts (such as the local Guest account and other accounts that have no business need to access the computer over the network) to provide an additional layer of protection.

Countermeasure

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

An important exception to this list is any service accounts that are used to launch 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 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 through the network. This user right is particularly effective when you need to 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 will not be negatively affected.

Deny log on as a batch job

This policy setting determines whether users can log on through a batch-queue facility, which is the feature in Windows Server 2003 that is used to schedule and launch jobs automatically one or more times in the future. This user right is needed for any accounts that are used to launch scheduled jobs by means of the Task Scheduler.

The possible values for the Deny log on as a batch job setting are:

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 built-in Support account and 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 will not be affected adversely. For example, if you assign this user right to the IWAM_<ComputerName> account, the MSM Management Point will fail. On a newly installed computer that runs Windows Server 2003 this account does not belong to the Guests group, but on a computer that was upgraded from Windows 2000 this account is a member of the Guests group. Therefore, it is important that you understand which accounts belong to any groups that you assign the Deny log on as a batch job user right.

Deny log on as a service

This policy setting determines whether users can log on as a service.

The possible values for the Deny log on as a service setting are:

Vulnerability

Accounts that can log on as a service could be used to configure and launch new unauthorized services, such as a keylogger or other malware. The benefit of the specified countermeasure is somewhat mitigated 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

This guide recommends 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 wish 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 be able to start and a DoS condition could result.

Deny log on locally

This policy setting determines whether users can log on directly at the computer's keyboard.

The possible values for the Deny log on locally setting are:

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 need to log on to the console of the computer, then unauthorized users might download and execute malicious code that elevates their privileges.

Countermeasure

Assign the Deny log on locally user right to the built-in Support 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.

Note: The Support_388945a0 account enables Help and Support Service interoperability with signed scripts. This account is primarily used to control access to signed scripts that are accessible from within Help and Support Services. Administrators can use this account to delegate the ability for a typical user who does not have administrative access to run signed scripts from links that are embedded within Help and Support Services. 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 that otherwise would not be supported by the typical user's account.

When the delegated user clicks on a link in Help and Support Services, the script will execute under the security context of the Support_388945a0 account. This account has limited access to the computer and is disabled by default.

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 run IIS 6.0. You should confirm that delegated activities will not be adversely affected.

Deny log on through Terminal Services

This policy setting determines whether users can log on to the computer through a Remote Desktop connection.

The possible values for the Deny log on through Terminal Services setting are:

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, then unauthorized users might download and execute malicious code that elevates their privileges.

Countermeasure

Assign the Deny log on through Terminal Services logon right to the built-in local Administrator 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 will be unable to connect to the computer through either Terminal Services or Remote Assistance. You should confirm that delegated tasks will not be negatively impacted.

Enable computer and user accounts to be trusted for delegation

This policy setting determines whether users can change the Trusted for Delegation setting on a user or computer object in Active Directory. Users or 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 is used by multi-tier client/server applications. It allows a front-end service to use client credentials to authenticate to a back-end service. For this configuration to be possible, both client and server must run under accounts that are trusted for delegation.

The possible values for the Enable computer and user accounts to be trusted for delegation setting are:

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 only be assigned 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.

Note: There is no reason to assign this user right to anyone on member servers and workstations that belong to a domain because it has no meaning in those contexts; it is only relevant on domain controllers and stand-alone computers.

Potential Impact

None. This is the default configuration.

Force shutdown from a remote system

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

The possible values for the Force shutdown from a remote system setting are:

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 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 will not be adversely affected.

Generate security audits

This policy setting determines whether a process can generate audit records in the Security log. You can use the information in the Security log to trace unauthorized computer access.

The possible values for the Generate security audits setting are:

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, the attacker 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 denial of service.

Countermeasure

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

Potential Impact

None. This is the default configuration.

Impersonate a client after authentication

The Impersonate a client after authentication user right allows programs that run on behalf of a user to impersonate that user (or another specified account) so that they can act on behalf of the user. If this user right is required for this kind of impersonation, an unauthorized user will not be able to convince 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:

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

The possible values for the Impersonate a client after authentication setting are:

Vulnerability

An attacker with the Impersonate a client after authentication user right could create a service, trick a client to make them 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 have the Impersonate a client after authentication user right assigned to them. Computers that run IIS 6.0 must have this user right assigned to the IIS_WPG group (which grants it to the Network Service account).

Potential Impact

In most cases this configuration will have 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 scheduling priority

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

The possible values for the Increase scheduling priority setting are:

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. This is the default configuration.

Load and unload device drivers

This policy setting determines whether 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 the Load and unload device drivers setting are:

Vulnerability

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

Note: 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 to manage a local printer and configure defaults for options such as duplex printing. The requirement to have both the user right and membership in Administrators or Power Users is new to Windows XP and Windows Server 2003.

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 tight 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 will not be negatively affected.

Lock pages in memory

This policy setting determines whether a process can 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.

The possible values for the Lock pages in memory setting are:

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. This is the default configuration.

Log on as a batch job

This policy setting determines whether users can log on through 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 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.

The possible values for the Log on as a batch job setting are:

Vulnerability

The Log on as a batch job user right presents a low-risk vulnerability. For most organizations, the default settings are sufficient.

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 and the local support account (Support_388945a0). For IIS servers, you should configure this policy locally instead of through domain–based Group Policies 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 through domain–based Group Policies, the computer will not be able to 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 might 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 o this group and these accounts, IIS will be unable to run some COM objects that are necessary for proper functionality.

Log on as a service

This policy setting determines whether a security principal can 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 user right.

The possible values for the Log on as a service setting are:

Vulnerability

Log on as a service is a powerful user right because it allows accounts to launch 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

The default set of security principals that have the Log on as a service user right is restricted to Local System, Local Service, and Network Service, all of which are built-in local accounts. You should minimize the number of other accounts that have this user right.

Potential Impact

On most computers, this is the default configuration and there will be 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 whether 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 through Audit Policy, which is located under Security Settings, Local Policies. A user who is assigned this user right can also view and clear the Security event log from Event Viewer.

The possible values for the Manage auditing and security log setting are:

Vulnerability

The ability 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 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. This is the default configuration.

Modify firmware environment values

This policy setting determines whether users can modify system environment variables by either a process through an API or by a user through System Properties.

The possible values for the Modify firmware environment values setting are:

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. This is the default configuration.

Perform volume maintenance tasks

This policy setting determines whether non-administrative or remote users can perform volume or disk management tasks, such as defragment an existing volume, create or remove volumes, and run the Disk Cleanup tool. Windows Server 2003 checks for this user right in a user’s access token when a process that runs in the user’s security context calls SetFileValidData().

The possible values for the Perform volume maintenance tasks setting are:

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.

Countermeasure

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

Potential Impact

None. This is the default configuration.

Profile single process

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

The possible values for the Profile single process setting are:

Vulnerability

The Profile single process user right presents a moderate vulnerability. An attacker with this user right could monitor a computer's performance to help identify critical processes that they might wish to attack directly. The attacker 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, 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 will not be negatively affected.

Profile system performance

This policy setting determines whether a user can sample the performance of computer system processes. This privilege is required by the MMC Performance snap-in only if it is configured to collect data through WMI. Typically, you do not need this user right to use the Performance snap-in. However, you do need this user right if System Monitor is configured to collect data through WMI.

The possible values for the Profile system performance setting are:

Vulnerability

The Profile system performance user right a moderate vulnerability. An attacker with this user right could monitor a computer's performance to help identify critical processes that they might wish to attack directly. The attacker may also be able to determine what processes are active on the computer so that they could identify countermeasures that they may need 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. This is the default configuration.

Remove computer from docking station

This policy setting determines whether the user of a portable computer can click Eject PC on the Start menu to undock the computer.

The possible values for the Remove computer from docking station setting are:

Vulnerability

Anyone who has the Remove computer from docking station user right can remove a portable computer from its docking station. The value of this countermeasure is reduced by the following factors:

Countermeasure

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

Potential Impact

This configuration is the default setting, so it should have little impact. However, if your organization's 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 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 whether a parent process can replace the access token that is associated with a child process.

The possible values for the Replace a process level token setting are:

Vulnerability

A user with the Replace a process level token privilege is able to launch processes as other users. They could use this method to hide their unauthorized actions on the computer. (On Windows 2000 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 chapter.)

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, this is the default configuration and there will be 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 policy setting determines whether a user can circumvent file and directory permissions when they restore backed up files and directories and whether they can set any valid security principal as the owner of an object.

The possible values for the Restore files and directories setting are:

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 denial of service. An attacker could overwrite executable files that are used by legitimate administrators or system services with versions that include malicious code to grant themselves elevated privileges, compromise data, or install backdoors for continued access to the computer.

Note: Even if this countermeasure is configured, an attacker could still restore data to a computer in a domain that is controlled by the attacker. Therefore, it is critical that organizations carefully protect the media that are used to back up data.

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 you could make it impossible for users who have been delegated specific tasks to perform those tasks. You should verify that this change won't negatively affect the ability of your organization’s personnel to do their jobs.

Shut down the system

This policy setting determines whether a user can shut down the local computer.

The possible values for the Shut down the system setting are:

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 the 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.

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 will not be adversely affected.

Synchronize directory service data

This policy setting determines whether a process can read all objects and properties in the directory, regardless of the protection on the objects and properties. This privilege is required to use LDAP directory synchronization (dirsync) services.

The possible values for the Synchronize directory service data setting are:

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. An attacker who has 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. This is the default configuration.

Take ownership of files or other objects

This policy setting determines whether a user 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.

The possible values for the Take ownership of files or other objects setting are:

Vulnerability

Any user 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 wish 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. This is the default configuration.

Top of page

More Information

The following links provide additional information about user rights assignment in Windows Server 2003 and Windows XP.

Top of page

5 of 14