Windows 2000 allows administrators to define precisely what users can and can't do. By defining user rights, administrators authorize users to perform specific actions. Although you can apply these rights to user accounts, you're better off administering them on group accounts so that users will inherit the rights associated with that group.
After this lesson, you will be able to
- Determine how to design user rights for your Active Directory
Estimated lesson time: 30 minutes
Defining User Rights with Group Policy
User rights define who can log on to a computer, the methods that can be used to log on to a computer, and the privileges that have been assigned to a user or group on that computer. Although user rights can be applied locally at a computer, in a Windows 2000 network it's preferable to define user rights by using Group Policy. Using Group Policy to apply user rights ensures consistent application of user rights and ensures that local changes won't be able to override settings applied at a site, domain, or organizational unit (OU).
Within a Group Policy Object, user rights are defined in the following location: Computer Configuration\Windows Settings\Security Settings \Local Policies\User Rights Assignments. As with all Group Policy settings, the Group Policy Object defined closest to the computer object in Active Directory will take precedence in the case of conflicting settings. The only exception is Account Policy settings within Group Policy. Account Policy settings are always applied from the Default Domain Policy.
User Rights Within Windows 2000
The following user rights can be defined within local policy or applied through Windows 2000 Group Policy, as shown in Figure 5.7.
Figure 5.7 Defining user rights in local policies of Group Policy
You can define several user rights. You have to base your choice on knowing which privileges a user right provides to any security principals (users or security groups) assigned the user right. You can assign the following user rights:
- Access This Computer From Network. This user right allows a security principal to access the computer from the network. Default membership in this group includes Administrators, Everyone, and Power Users.
- Act As Part Of The Operating System. You commonly assign this user right to service accounts that must authenticate as a user and access resources where they must authenticate as a user. Because this right provides elevated privileges to a security principal, use it sparingly.
- Add Workstations To A Domain. This user right allows a security principal to add a computer to a specific domain. You must assign this right at the Domain Controllers OU to affect the domain. A security principal assigned this permission may add only up to 10 computers within the domain.
Alternatively, you can delegate a security principal the Create Computer Objectspermission in Active Directory. This permission allows a security principal to create an unlimited number of computers within the domain or OU where the permission is delegated.
- Backup Files And Directories. This user right allows a security principal to access files using the NTFS backup application programming interface (API) even if NTFS permissions don't normally allow the security principal access.
- Bypass Traverse Checking. This user right allows security principals to navigate through folders where they don't have explicit or implicit permissions when navigating to a folder or object where they do have permissions. The security principal can't list the contents of the folder but can only traverse the folder. This applies to both the NTFS file system and the registry.
- Change The System Time. This user right allows a security principal to modify the time of the computer's internal clock.
- Create Pagefile. This user right allows a security principal to create a new pagefile on any computer volume or to modify the size of an existing pagefile.
- Create A Token Object. This user right allows a security principal associated with a process to create an access token through an API.
- Create Permanent Shared Objects. This user right allows a security principal associated with a process to create a directory object in the Windows 2000 object manager. This task is commonly performed by components that run in kernel mode. This right is necessary only if the object doesn't run in kernel mode.
- Debug Programs. This user right allows a security principal to debug any process using a kernel or application debugger.
- Deny Access To This Computer From The Network. This user right prevents a security principal from connecting to the computer where the user right is applied from the network.
- Deny Logon As A Batch Job. This user right prevents a security principal from authenticating with the computer where the user right is applied through a batch-queue process.
- Deny Logon As A Service. This user right prevents a security principal's credentials from being used by a service for authentication.
- Deny Logon Locally. This user right prevents a security principal from logging on at the console of the computer with this user right applied.
- Enable Computer And User Accounts To Be Trusted For Delegation. This user right allows a security principal to change the Trusted For Delegation setting on a user or computer object within Active Directory. In addition to this user right, the security principal must also have write access to the object's account control flags. Setting the Trusted For Delegation setting lets a computer or process hosting an application authenticate to a back-end service by using the credentials of the user running the application.
- Force Shutdown From A Remote System. This user right allows a security principal to shut down a computer remotely by using tools such as Shutdown.exe from the Microsoft Windows 2000 Server Resource Kit.
- Generate Security Audits. This user right ensures that a security principal associated with a process generates entries in the security log.
- Increase Quotas. This user right allows a process associated with a security principal to increase the processor quota assigned to other processes. To do this, the initial process must have write access to the second process.
- Increase Scheduling Priority. This user right allows a security principal to increase the execution priority of another process programmatically or by using Task Manager.
- Load And Unload Device Drivers. This user right allows a security principal to install and uninstall Plug and Play device drivers. Only administrators can install or uninstall non-Plug and Play device drivers.
- Lock Pages In Memory. This user right allows a security principal associated with a process to prevent memory used by the process from being swapped from physical memory to the paging file. In Windows 2000 this privilege is obsolete and isn't set by default.
- Log On As A Batch Job. This user right allows a security principal to log on by using a batch-queue process.
- Log On As A Service. This user right allows a security principal's credentials to be used by a service for authentication.
- Log On Locally. This user right allows a security principal to log on at the local console (the keyboard) of the computer where this user right applied.
- Manage Auditing And Security Log. This user right allows a security principal to modify the SACL for individual objects. The SACL specifies auditing options for the object.
Just modifying the SACL doesn't enable auditing for object access. In addition, the audit policy for the computer must enable either Success or Failure auditing for object access.
- Modify Firmware Environment Values. This user right allows a security principal to modify system environment variables. The modification can take place manually by using the System program in Control Panel or through an API call.
- Profile Single Process. This user right allows a security principal to run performance-monitoring utilities such as the Performance Logs and Alerts MMC console to monitor nonsystem processes.
- Profile System Performance. This user right allows a security principal to run performance-monitoring utilities such as the Performance Logs and Alerts MMC console to monitor system processes.
- Remove Computer From A Docking Station. This user right allows a security principal to undock a portable computer from a docking station.
- Replace A Process Level Token. This user right allows a security principal associated with a process to replace the access token for a child process that's spawned by the initial process.
- Restore Files And Directories. This user right allows a security principal to restore backed-up files and directories to the file system even if the security principal doesn't have permissions to the affected directories. This user right also allows the security principal to change the owner of the object.
- Shut Down The System. This user right allows a security principal to shut down the local computer.
- Synchronize Directory Service Data. This user right allows a security principal associated with a process to provide directory synchronization services. This user right is only applied at DCs where the Active Directory is maintained.
- Take Ownership Of Files Or Other Objects. This user right allows a security principal to take ownership of any securable object in the system. Objects that this affects include Active Directory objects, files, folders, printers, registry keys, processes, and threads.
Assessing Where to Apply User Rights
You can define user rights in local computer policy or at Group Policy defined at the site, domain, or OU. Group Policy settings always take precedence over local computer policy. Therefore, for a centrally administered network, it's always preferable to define user rights by using Group Policy.
When you decide where to apply user rights, it's important for you to group computers that require like assignments into the same container. Consider the following strategy:
Making the Decision
When you determine the user rights definitions for your organization, you must make the following decisions:
- Determine what user rights to grant to a security principal. It's best to assign user rights to a group rather than to an individual user account. Assigning the user right to a group ensures that if you need to change who requires the user right, you only have to modify the group's membership, not the user right assignment.
- Determine where to apply user rights. You can apply user rights to the local computer policy or by using Group Policy at the site, domain, or OU level. For DCs, you should always apply user rights at the Domain Controllers OU. This ensures consistent application of user rights at all DCs within a domain.
- Determine whether to apply user permissions or user rights. The key to this decision is to realize that user rights always take precedence over permissions on objects. For example, you could assign permissions to a user for a directory structure so that the user can read each file in the directory structure. This action is sufficient to allow the user to back up all folders and files that the user has permissions to. However, if the folder structure contains any files to which the user doesn't have access, the user would be unable to back up these files. If the user were assigned the permission Backup Files And Directories, it wouldn't matter what permissions existed on the files and folders for the purpose of backup. The user right would take precedence over the permissions assigned at the file and folder level.
Applying the Decision
For the deployment of Exchange Server, the Exchange service account must be assigned the required user rights in each domain where an Exchange Server will be installed. Because Hanson Brothers has two domains, the assignment of user rights must be duplicated in each of them.
Normally, the assignment of user rights should be applied to a domain local group rather than to an individual user account. Because the Exchange service account is often dedicated solely to the purpose of Exchange Server, however, it's permissible to consider assigning user rights directly to the user account. When you design the user rights assignments for the Exchange service account, you must make the following decisions:
- Determine a name for the service account.You must name the Exchange service account so that the name doesn't reveal the service account's purpose. For example, using an account name such as Exchange, Service, or Exservice wouldn't be appropriate for a secure network. Selecting a fictitious name for the service account, such as Amy Jones (Ajones), often provides the best security.
You should name all service accounts and administrative accounts so that the name doesn't reveal the user account's security level. Revealing the purpose through the name can introduce security weaknesses to the network.
- Determine which user rights to assign to the service account.As mentioned in the scenario's requirements, the Exchange service account requires three user rights to be assigned directly to the Exchange service account. These user rights are: Act As Part Of The Operating System, Log On As A Service, and Restore Files And Directories.
- Determine where to assign the user rights.If the Exchange servers are installed as member servers in the domain, you should create a separate organizational unit (OU) in both the Corporate and Quebec domains to contain the Exchange servers. At the OU you must define a Group Policy that assigns the three user rights to the Exchange service account. If the Exchange servers are installed as DCs, then Group Policy would be defined at the Domain Controllers OU. Whatever type of Windows 2000–based computer is used for Exchange Server, the user rights assignments must be performed in both the Corporate and Quebec domains.
User rights take precedence over any explicit permissions assigned to objects in a Windows 2000 domain, Your security design must ensure that excess rights are not assigned to security principals in your domain.
Ensure that your security plan evaluates what user rights must be assigned to a security principal to accomplish specific tasks. In addition, the design must determine the correct location to apply the user rights. Typically, user rights are always applied at the highest level in Active Directory as possible. This ensures that uniform user rights are applied to all Windows 2000–based computers in the domain.