User Rights Assignment Gpo 2008 Ram

In this section

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

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

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

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

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

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

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

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

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

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

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

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

Audit account logon events

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

The possible values for this Group Policy setting are:

  • Success.

  • Failure.

  • No auditing.

Discussion

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

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

Location

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

Default Values

Server Type or GPO Default Value

Default Domain Policy

Not defined

Default Domain Controller Policy

Success

Stand-Alone Server Default Settings

Success

DC Effective Default Settings

Success

Member Server Effective Default Settings

Success

Audit account management

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

The possible values for this Group Policy setting are:

  • Success.

  • Failure.

  • No auditing.

Discussion

Examples of account management events include the following:

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

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

  • A password is set or changed.

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

Location

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

Default Values

Server Type or GPO Default Value

Default Domain Policy

Not defined

Default Domain Controller Policy

Success

Stand-Alone Server Default Settings

No auditing

DC Effective Default Settings

Success

Member Server Effective Default Settings

No auditing

Audit directory service access

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

The possible values for this Group Policy setting are:

  • Success.

  • Failure.

  • No auditing.

Discussion

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

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

Location

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

Default Values

Server Type or GPO Default Value

Default Domain Policy

Not defined

Default Domain Controller Policy

Success

Stand-Alone Server Default Settings

No auditing

DC Effective Default Settings

Success

Member Server Effective Default Settings

No auditing

Audit logon events

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

The possible values for this Group Policy setting are:

  • Success.

  • Failure.

  • No auditing.

Discussion

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

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

Location

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

Default Values

Server Type or GPO Default Value

Default Domain Policy

Not defined

Default Domain Controller Policy

Success

Stand-Alone Server Default Settings

Success

DC Effective Default Settings

Success

Member Server Effective Default Settings

Success

Audit object access

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

The possible values for this Group Policy setting are:

  • Success.

  • Failure.

  • No auditing.

Discussion

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

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

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

Location

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

Default Values

Server Type or GPO Default Value

Default Domain Policy

Not defined

Default Domain Controller Policy

No auditing

Stand-Alone Server Default Settings

No auditing

DC Effective Default Settings

No auditing

Member Server Effective Default Settings

No auditing

Audit policy change

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

The possible values for this Group Policy setting are:

  • Success.

  • Failure.

  • No auditing.

Discussion

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

Location

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

Default Values

Server Type or GPO Default Value

Default Domain Policy

Not defined

Default Domain Controller Policy

Success

Stand-Alone Server Default Settings

No auditing

DC Effective Default Settings

Success

Member Server Effective Default Settings

No auditing

Audit privilege use

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

The possible values for this Group Policy setting are:

  • Success.

  • Failure.

  • No auditing.

Discussion

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

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

  • Bypass traverse checking

  • Debug programs

  • Create a token object

  • Replace process level token

  • Generate security audits

  • Backup files and directories

  • Restore files and directories

Location

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

Default Values

Server Type or GPO Default Value

Default Domain Policy

Not defined

Default Domain Controller Policy

No auditing

Stand-Alone Server Default Settings

No auditing

DC Effective Default Settings

No auditing

Member Server Effective Default Settings

No auditing

Audit process tracking

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

The possible values for this Group Policy setting are:

  • Success.

  • Failure.

  • No auditing.

Discussion

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

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

Location

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

Default Values

Server Type or GPO Default Value

Default Domain Policy

Not defined

Default Domain Controller Policy

No auditing

Stand-Alone Server Default Settings

No auditing

DC Effective Default Settings

No auditing

Member Server Effective Default Settings

No auditing

Audit system events

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

The possible values for this Group Policy setting are:

  • Success.

  • Failure.

  • No auditing.

Discussion

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

Location

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

Default Values

Server Type or GPO Default Value

Default Domain Policy

Not defined

Default Domain Controller Policy

Success

Stand-Alone Server Default Settings

No auditing

DC Effective Default Settings

Success

Member Server Effective Default Settings

No auditing

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

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

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

Access this computer from the network

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

Note

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

The possible values for this Group Policy setting are:

  • A user-defined list of accounts.

  • Not defined.

Discussion

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

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

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

Location

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

Default Values

Server Type or GPO Default Value

Default Domain Policy

Not defined

Default Domain Controller Policy

Everyone, Administrators, Authenticated Users, ENTERPRISE DOMAIN CONTROLLERS, Pre-Windows 2000 Compatible Access

Stand-Alone Server Default Settings

Everyone, Administrators, Users, Power Users, Backup Operators

DC Effective Default Settings

Everyone, Administrators, Authenticated Users, ENTERPRISE DOMAIN CONTROLLERS, Pre-Windows 2000 Compatible Access

Member Server Effective Default Settings

Backup Operators, Power Users, Users, Administrators, Everyone

Act as part of the operating system

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

The possible values for this Group Policy setting are:

  • A user-defined list of accounts.

  • Not defined.

Discussion

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

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

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

Location

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

Default Values

Server Type or GPO Default Value

Default Domain Policy

Not defined

Default Domain Controller Policy

No one

Stand-Alone Server Default Settings

Not defined

DC Effective Default Settings

No one

Member Server Effective Default Settings

Not defined

Add workstations to domain

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

The possible values for this Group Policy setting are:

  • A user-defined list of accounts.

  • Not defined.

Discussion

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

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

Location

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

Default Values

Server Type or GPO Default Value

Default Domain Policy

Not defined

Default Domain Controller Policy

Authenticated Users

Stand-Alone Server Default Settings

Not defined

DC Effective Default Settings

Authenticated Users

Member Server Effective Default Settings

Not defined

Adjust memory quotas for a process

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

The possible values for this Group Policy setting are:

  • A user-defined list of accounts.

  • Not defined.

Discussion

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

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

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

Location

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

Default Values

Server Type or GPO Default Value

Default Domain Policy

Not defined

Default Domain Controller Policy

LOCAL SERVICE, NETWORK SERVICE, Administrators

Stand-Alone Server Default Settings

LOCAL SERVICE, NETWORK SERVICE, Administrators

DC Effective Default Settings

LOCAL SERVICE, NETWORK SERVICE, Administrators

Member Server Effective Default Settings

Administrators, NETWORK SERVICE, LOCAL SERVICE

Allow log on locally

Note

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

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

The possible values for this Group Policy setting are:

  • A user-defined list of accounts.

  • Not defined.

Discussion

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

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

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

Location

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

Default Values

Server Type or GPO Default Value

Default Domain Policy

Not defined

Default Domain Controller Policy

Administrators, Backup Operators, Account Operators, Server Operators, Print Operators

Stand-Alone Server Default Settings

Administrators, Users, Power Users, Backup Operators

DC Effective Default Settings

Administrators, Backup Operators, Account Operators, Server Operators, Print Operators

Member Server Effective Default Settings

Backup Operators, Power Users, Users, Administrators

Allow log on through Terminal Services

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

The possible values for this Group Policy setting are:

  • A user-defined list of accounts.

  • Not defined.

Discussion

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

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

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

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

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

Location

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

Default Values

Server Type or GPO Default Value

Default Domain Policy

Not defined

Default Domain Controller Policy

Not defined

Stand-Alone Server Default Settings

Administrators, Remote Desktop Users

DC Effective Default Settings

Administrators

Member Server Effective Default Settings

Remote Desktop Users, Administrators

Back up files and directories

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

If you haven’t noticed yet, Windows Server 2008 has several more User Right Assignments in the Local Policy settings.  If you’re looking for a definition of one or all take a look below.  These are the same settings that are found in Group Policy located at this path – Computer ConfigurationWindows SettingsLocal PoliciesUser Right Assignment.

 

Access Credential Manager as a trusted caller

This policy setting is used by Credential Manager during Backup and Restore. No accounts should have this user right, as it is only assigned to Winlogon. Users” saved credentials might be compromised if this user right is assigned to other entities.

By default, no accounts are assigned this right. However, to enforce the default setting, the Access Credential Manager as a trusted caller setting is restricted to No One for the SSLF environment discussed in the security guide.

Act as part of the operating system

This policy setting allows a process to assume the identity of any user and thus gain access to the resources that the user is authorized to access. For this reason, the Act as part of the operating system setting is restricted to No one for both of the environments that are discussed in this guide.

Add workstations to domain

This policy setting only takes effect when applied to domain controllers.

Adjust memory quotas for a process

This policy setting allows a user to adjust the maximum amount of memory that is available to a process. The ability to adjust memory quotas is useful for system tuning, but it can be abused. In the wrong hands, this setting could be used to launch a denial of service (DoS) attack.

For this reason, the Adjust memory quotas for a process setting is restricted to Administrators, Local Service, and Network Service groups for the SSLF environment. The setting is configured to Not Defined for the EC environment.

Allow log on locally

This policy setting determines which users can interactively log on to computers in your environment. Logons that are initiated by pressing the CTRL+ALT+DEL key sequence on the computer keyboard require this user right.

Microsoft recommends that you enable this setting through Group Policy and restrict this right to members of the Administrators group. Assign this user right to the other Operator level administrative security groups,such as Backup Operators or Server Operators,if your organization requires that they have this capability.

Allow log on through Terminal Services

This policy setting determines which users or groups have the right to log on as a Terminal Services client. Remote desktop users require this user right. Microsoft recommends that you restrict this user right to the Administrators group to prevent unwanted users from gaining access to computers on your network by means of the Remote Assistance feature. Dedicated Terminal Servers will require additional configuration.

Back up files and directories

This policy setting allows users to circumvent file and directory permissions to back up the system. This user right is enabled only when an application (such as NTBACKUP) attempts to access a file or directory through the NTFS file system backup application programming interface (API). Otherwise, the assigned file and directory permissions apply.

Bypass traverse checking

This policy setting allows users who do not have the special "Traverse Folder" access permission to "pass through" folders when they browse an object path in the NTFS file system or in the registry. This user right does not allow users to list the contents of a folder, but only allows them to traverse directories.

Change the system time

This policy setting determines which users and groups can change the time and date of the internal clock of the computers in your environment. Users who are assigned this user right can affect the appearance of event logs. When a computer’s time setting is changed, logged events reflect the new time, which may not be the actual time that the events occurred.

Change the time zone

This setting determines which users can change the time zone of the computer. This setting capability poses no great risk for the computer. However, modifications to this setting affect all users and applications on the computer, which could cause confusion in shared terminal server environments.

Create a pagefile

This policy setting allows users to change the size of the pagefile. By making the pagefile extremely large or extremely small, an attacker could easily affect the performance of a compromised computer.

Create a token object

This policy setting allows a process to create an access token, which may provide elevated rights to access sensitive data. In environments in which security is a high priority, this user right should not be assigned to any users. Any processes that require this capability should use the Local System account, which is assigned this user right by default.

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.

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.

Create permanent shared objects

This policy setting allows users to create directory objects in the object manager. This user right is useful to kernel-mode components that extend the object namespace. However, components that run in kernel mode have this user right inherently. Therefore, it is typically not necessary to specifically assign this user right.

Create symbolic links

This policy setting determines which users can create symbolic links. In Windows Server 2008, existing NTFS file system objects, such as files and folders, can be accessed by referring to a new kind of file system object called a symbolic link. A symbolic link is a pointer (much like a shortcut or .lnk file) to another file system object, which can be a file, folder, shortcut or another symbolic link. The difference between a shortcut and a symbolic link is that a shortcut only works from within the Windows shell. To other programs and applications, shortcuts are just another file, whereas with symbolic links, the concept of a shortcut is implemented as a feature of the NTFS file system.

Symbolic links can potentially expose security vulnerabilities in applications that are not designed to use them. For this reason, the privilege for creating symbolic links should only be assigned to trusted users. By default, only members of the Administrators group can create symbolic links.

Debug programs

This policy setting determines which user accounts will have the right to attach a debugger to any process or to the kernel, which provides complete access to sensitive and critical operating system components. Developers who are debugging their own applications do not need to be assigned this user right. However, developers who are debugging new system components need it.

Deny access to this computer from the network

This security setting determines which users are prevented from accessing a computer over the network. This policy setting supersedes the Access this computer from the network policy setting if a user account is subject to both policies.

Deny log on as a batch job

This policy setting prohibits users from logging on to a computer through a batch-queue facility, which is a feature in Windows Server 2008 that you can use to schedule jobs to run automatically one or more times in the future.

Deny log on as a service

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

Deny log on locally

This policy setting prohibits users from logging on locally to the computer console. If unauthorized users can log on locally to a computer, they can download malicious code or elevate their privileges on the computer. In addition, if attackers have physical access to the console, there are other risks to consider. This user right should not be assigned to those users who need physical access to the computer console.

Deny log on through Terminal Services

This policy setting prohibits users from logging on to computers in your environment through Remote Desktop connections. If you assign this user right to the Everyone group, you also prevent members of the default Administrators group from using Terminal Services to log on to computers in your environment.

Enable computer and user accounts to be trusted for delegation

This policy setting allows users to change the Trusted for Delegation setting on a computer object in Active Directory®. Abuse of this privilege could allow unauthorized users to impersonate other users on the network.

Force shutdown from a remote system

This policy setting allows users to shut down Windows–based computers from remote locations on the network. An unauthorized shut down of a server is a type of denial of service (DoS) condition that makes the computer unavailable to service user requests. Microsoft recommends to only assign this user right to highly trusted administrators.

Generate security audits

This policy setting determines which users or processes can generate audit records in the Security log. An attacker could use this capability to create a large number of audited events, which would make it more difficult for a system administrator to locate any illicit activity. Also, if the event log is configured to overwrite events as needed, any evidence of unauthorized activities could be overwritten by a large number of unrelated events.

Impersonate a client after authentication

This policy setting allows programs to impersonate a user so that the program can act on behalf of the user. Requiring authentication first helps prevent elevation of privilege attacks.

Services that the Service Control Manager starts have the built-in group "Service" added by default to their access tokens. COM servers that the COM infrastructure starts and configures 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.

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

  • The access token that is being impersonated is for the same user that is making the request.
  • 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.

An attacker with the Impersonate a client after authentication user right could create a service that impersonates any logged on user in order to elevate the attacker”s level of access to that of the logged on user or to the level of the client computer”s system account.

Increase a process working set

This policy setting determines which user accounts can increase or decrease the size of a process 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.

This right is granted to all users by default. However, increasing the working set size for a process decreases the amount of physical memory available to the rest of the system. It would be possible for malicious code to increase the process working set to a level that could severely degrade system performance and potentially cause a denial of service. Certain environments can help mitigate this risk by limiting which users can increase the process working set.

Increase scheduling priority

This policy setting allows users to change the amount of processor time that a process uses. An attacker could use this capability to increase the priority of a process to real-time and create a denial of service (DoS) condition for a computer.

Load and unload device drivers

This policy setting allows users to dynamically load a new device driver on a system. An attacker could potentially use this capability to install malicious code that appears to be a device driver. This user right is required to add local printers or printer drivers in Windows Server 2008.

Lock pages in memory

This policy setting allows a process to keep data in physical memory, which prevents the system from paging the data to virtual memory on disk. If this user right is assigned and abused, significant degradation of system performance can occur.

Log on as a batch job

This policy setting allows accounts to log on using the Task Scheduler service. Because the Task Scheduler is often used for administrative purposes, you may need this right in the EC environment. However, Microsoft recommends restricting its use in the SSLF environment to prevent misuse of system resources or to prevent attackers from using the right to launch malicious code after gaining user level access to a computer.

Log on as a service

This policy setting allows accounts to launch network services or to register a process as a service running on the system. This user right should be restricted on all computers in an SSLF environment, but because many applications may require this right, you should carefully evaluate and test this setting before configuring it in an EC environment. On servers running Windows Server 2008, no users or groups have this right by default.

Manage auditing and security log

This policy setting determines which users can change the auditing options for files and directories and clear the Security log. Because this capability represents a relatively small threat, this setting enforces the default value of the Administrators group for both the EC and SSLF environments.

Modify an object label

This policy setting determines which users can change the integrity level of objects, such as files, registry keys or processes owned by other users. Note that a user can change the integrity level of an object that is owned by that user to a lower level without holding this privilege.

Modify firmware environment values

This policy setting allows users to configure the system-wide environment variables that affect hardware configuration. This information is typically stored in the Last Known Good Configuration. Modification of these values could lead to a hardware failure that would result in a DoS condition.

Because this capability represents a relatively small threat, this setting enforces the default value of the Administrators group for both the EC and SSLF environments.

Perform volume maintenance tasks

This policy setting allows users to manage the system”s volume or disk configuration, which could allow a user to delete a volume and cause data loss as well as a DoS condition.

Profile single process

This policy setting determines which users can use tools to monitor the performance of non-system processes. Typically, you do not need to configure 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 using Windows Management Instrumentation (WMI). Restricting the Profile single process user right prevents intruders from gaining additional information that they could use to mount an attack on the system.

Profile system performance

This policy setting allows users to use tools to view the performance of different system processes, which could be abused to allow attackers to determine a system”s active processes and provide insight into the potential attack surface of the computer. This setting enforces the default of the Administrators group for both the EC and SSLF environments.

Remove computer from docking station

This policy setting allows the user of a portable computer to click Eject PC on the Start menu to undock the computer. This setting is not usually relevant in server scenarios.

Replace a process level token

This policy setting allows one process or service to start another service or process with a different security access token, which an intruder can use to modify the security access token of that sub-process to escalate privileges. This setting enforces the default values of Local Service and Network Service for both the EC and SSLF environments.

Restore files and directories

This policy setting determines which users can bypass file, directory, registry, and other persistent object permissions when restoring backed up files and directories on computers that run Windows Server 2008. This right also determines which users can set valid security principals as object owners; it is similar to the Back up files and directories user right.

Shut down the system

This policy setting determines which users who are logged on locally to the computers in your environment can shut down the operating system with the Shut Down command. Misuse of this user right can result in a DoS condition.

Synchronize directory service data

This policy setting determines which users have the authority to synchronize all directory service data.

Take ownership of files or other objects

This policy setting allows users to take ownership of files, folders, registry keys, processes, or threads. This user right bypasses any permissions that are in place to protect objects and give ownership to the specified user. This setting enforces the default value of the Administrators group for both the EC and SSLF environments.

0 Replies to “User Rights Assignment Gpo 2008 Ram”

Lascia un Commento

L'indirizzo email non verrà pubblicato. I campi obbligatori sono contrassegnati *