Allow log on locally - security policy setting
- 4 minutes to read
Describes the best practices, location, values, policy management, and security considerations for the Allow log on locally security policy setting.
This policy setting determines which users can start an interactive session on the device. Users must have this user right to log on over a Remote Desktop Services session that is running on a Windows-based member device or domain controller.
Note: Users who do not have this right are still able to start a remote interactive session on the device if they have the Allow logon through Remote Desktop Services right.
- User-defined list of accounts
- Not Defined
By default, the members of the following groups have this right on workstations and servers:
- Backup Operators
By default, the members of the following groups have this right on domain controllers:
- Account Operators
- Backup Operators
- Print Operators
- Server Operators
- Restrict this user right to legitimate users who must log on to the console of the device.
- If you selectively remove default groups, you can limit the abilities of users who are assigned to specific administrative roles in your organization.
Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment
The following table lists the actual and effective default policy values for the most recent supported versions of Windows. Default values are also listed on the policy’s property page.
|Server type or GPO||Default value|
|Default Domain Policy||Not Defined|
|Default Domain Controller Policy||Account Operators|
|Stand-Alone Server Default Settings||Administrators|
|Domain Controller Effective Default Settings||Account Operators|
|Member Server Effective Default Settings||Administrators|
|Client Computer Effective Default Settings||Administrators|
Restarting the device is not required to implement this change.
Any change to the user rights assignment for an account becomes effective the next time the owner of the account logs on.
Modifying this setting might affect compatibility with clients, services, and applications. Use caution when removing service accounts that are used by components and by programs on member devices and on domain controllers in the domain from the default domain controller's policy. Also use caution when removing users or security groups that log on to the console of member devices in the domain, or removing service accounts that are defined in the local Security Accounts Manager (SAM) database of member devices or of workgroup devices. If you want to grant a user account the ability to log on locally to a domain controller, you must make that user a member of a group that already has the Allowed logon locally system right or grant the right to that user account. The domain controllers in the domain share the Default Domain Controllers Group Policy Object (GPO). When you grant an account the Allow logon locally right, you are allowing that account to log on locally to all domain controllers in the domain. If the Users group is listed in the Allow log on locally setting for a GPO, all domain users can log on locally. The Users built-in group contains Domain Users as a member.
Group Policy settings are applied through GPOs in the following order, which will overwrite settings on the local computer at the next Group Policy update:
- Local policy settings
- Site policy settings
- Domain policy settings
- OU policy settings
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
Any account with the Allow log on locally user right can log on to the console of the device. If you do not restrict this user right to legitimate users who must log on to the console of the computer, unauthorized users could download and run malicious software to elevate their privileges.
For domain controllers, assign the Allow log on locally user right only to the Administrators group. For other server roles, you may choose to add Backup Operators in addition to Administrators. For end-user computers, you should also assign this right to the Users group. Alternatively, you can assign groups such as Account Operators, Server Operators, and Guests to the Deny log on locally user right.
If you remove these default groups, you could limit the abilities of users who are assigned to specific administrative roles in your environment. If you have installed optional components such as ASP.NET or IIS, you may need to assign the Allow log on locally user right to additional accounts that are required by those components. IIS requires that this user right be assigned to the IUSR_<ComputerName> account. You should confirm that delegated activities are not adversely affected by any changes that you make to the Allow log on locally user rights assignments.
Although the built-in capabilities for accounts cannot be changed, user rights for accounts can be administered. These rights authorize users to perform specific actions, such as logging on to a system interactively or backing up files and directories. User rights are different from permissions because they apply to user accounts, whereas permissions are attached to objects. Keep in mind that changes made to user rights can have a far-reaching effect. Because of this, only experienced administrators should make changes to the user rights policy.
Microsoft defines user rights in two types of categories: Logon Rights and Privileges. These are defined as follows:
Logon Right: A user right that is assigned to a user and that specifies the ways in which a user can log onto a system. An example of a logon right is the right to log on to a system remotely.
Privilege: A user right that is assigned to a user and that specifies allowable actions on the system. An example of a privilege is the right to shut down a system.
User rights define capabilities at the local level. Although they can apply to individual user accounts, user rights are best administered on a group account basis. This ensures that a user logging on as a member of a group automatically inherits the rights associated with that group. By assigning rights to groups rather than individual users, user account administration can be simplified. When users in a group all require the same user rights, they can be assigned the set of rights once to the group, rather than repeatedly assigning the same set to each individual user account.
User rights that are assigned to a group are applied to all members of the group while they remain members. If a user is a member of multiple groups, the user's rights are cumulative, which means that the user has more than one set of rights and privileges. The only time that rights assigned to one group might conflict with those assigned to another is in the case of certain logon rights. For example a member of multiple groups who is given the "Deny Access to This Computer from the Network" logon right would not be able to log on despite the logon rights granted to the user by other groups. The user would be logged on locally with cached credentials, but when attempting to access the domain resources would receive the following message:
In general, however, user rights assigned to one group do not conflict with the rights assigned to another group. To remove rights from a user, the administrator simply removes the user from the group. In this case, the user no longer has the rights assigned to that group.
The following lists show the logon rights and privileges that can be assigned to a user.
Some of the privileges can override permissions set on an object. For example, a user logged on to a domain account as a member of the Backup Operators group has the right to perform backup operations for all domain servers. However, this requires the ability to read all files on those servers, even files on which their owners have set permissions that explicitly deny access to all other users, including members of the Backup Operators group. A user privilege, in this case, the right to perform a backup, takes precedence over all file and directory permissions. The privileges, which can override permissions set on an object, are listed below.
Take Ownership of Files or Other Object
Manage Auditing and Security Log
Back Up Files and Directories
Restore Files and Directories
Bypass Traverse Checking
The Take Ownership of Files or Other Object (TakeOwnership) privilege grants WriteOwner access to an object. Backup and Restore privileges grant read and write access to an object. The Debug Programs (debug) privilege grants read or open access to an object. The Bypass Traverse Checking (ChangeNotify) privilege provides the reverse access on directories. This privilege is given, by default, to all users and is not considered security relevant. The Manage Auditing and Security Log (Security) privilege provides several abilities including access to the security log, overriding access restrictions to the security log. The Event Logger is responsible for enforcing the Security privilege in this context. The TakeOwnership, Security, Backup, Restore, Debug privileges should only be assigned to administrator accounts (See Appendix C, User Rights and Privileges, of the Windows 2000 Security Configuration Guide, for the restrictions of the assignment of privileges to be in accordance with the Evaluated Configuration).
The special user account LocalSystem has almost all privileges and logon rights assigned to it, because all processes that are running as part of the operating system are associated with this account, and these processes require a complete set of user rights.
Appendix C – User Rights and Privileges, of the Windows 2000 Security Configuration Guide, contains a cross-reference table of user rights and privileges to applicable Security Target requirements that should be used as reference when implementing a user rights policy that must address specific ST requirements.
Assigning User Rights
User rights are assigned through the Local Policies node of Group Policy. As the name implies, local policies pertain to a local computer. However, local policies can be configured and then imported into Active Directory. Local policies can also be configured as part of an existing Group Policy for a site, domain, or organizational unit. When this is done, the local policies will apply to computer accounts in the site, domain, or organizational unit.
User rights policies can be administered as follows:
Log on using an administrator account.
Open the Active Directory Users and Computers tool.
Right-click the container holding the domain controller and click Properties.
Click the Group Policy tab, and then click Edit to edit the Default Domain Policy.
In the Group Policy window, expand Computer Configuration, navigate to Windows Settings, to Security Settings, and then to Local Policies.
Select User Rights Assignment.
Note: All policies are either defined or not defined. That is, they are either configured for use or not configured for use. A policy that is not defined in the current container could be inherited from another container.
To configure user rights assignment, double-click a user right or right-click on it and select Security. This opens a Security Policy Setting dialog box.
For a site, domain, or organizational unit, individual user rights can be configured by completing the following steps:
Open the Security Policy Setting dialog box for the user right to be modified.
Select Define these policy settings to define the policy.
To apply the right to a user or group, click Add.
In the Add user or group dialog box, click Browse. This opens the Select Users Or Groups dialog box. The right can now be applied to users and groups.
The following selection options appear on the Select Users Or Groups box:
Name: The Name column shows the available accounts of the currently selected domain or resource.
Add: Add selected names to the selection list.
Check Names: Validate the user and group names entered into the selection list. This is useful if names are typed in manually and it is necessary ensure that they're actually available.
To access account names from other domains, click the Look In list box. A drop-down list will appear that shows the current domain, trusted domains, and other resources that can be accessed. Select Entire Directory to view all the account names in the directory.
Note: Only domains that have been designated as trusted are available in the Look In drop-down list. Because of the transitive trusts in Windows 2000, this usually means that all domains in the domain tree or forest are listed. A transitive trust is one that is not established explicitly. Rather, the trust is established automatically based on the forest structure and permissions set in the forest.
After selecting the account names to add to the group, click OK. The Add user or group dialog box should now show the selected accounts. Click OK again.
The Security Policy Setting dialog box is updated to reflect the selections. If a mistake is made, select a name and remove it by clicking Remove.
When finished granting the right to users and groups, click OK.
Top Of Page
Configuring Local User Rights
For local computers, such as Windows 2000 Professional, apply user rights by completing the following steps:
Log in as Administrator.
Open Start, point to Programs, point to Administrative Tools, and then click Local Security Policy.
In the Local Security Settings window, navigate to Local Policies, and then select User Rights Assignment.
To configure user rights assignment, double-click a user right or right-click on it and select Security. This opens a Security Policy Setting dialog box. The effective policy for the computer is displayed, but it cannot be changed. However, the local policy settings can be adjusted. Use the fields provided to configure the local policy. Remember that site, domain, and organizational unit policies have precedence over local policies.
The Assigned To column shows current users and groups that have been given a user right. Select or clear the related check boxes under the Local Policy Setting column to apply or remove the user right.
Apply the user right to additional users and groups by clicking Add. This opens the Select Users Or Groups dialog box. Local users and groups can now be added.
To access account names from the domain, click the Look In list box. There should be a list that shows the current machine, the local domain, trusted domains, and other resources that can be accessed. Select the local domain to view all the account names in the domain.
Top Of Page