Revisit this often-overlooked method of granting advanced functionality to users, groups, and processes.

Windows NT user rights determine the tasks that a user can and can't perform on systems. NT gives you two groups of user rights—11 standard and 16 advanced. Generally, only programmers use advanced rights, and you should grant them to users or groups only when absolutely necessary. When you set user rights on a domain controller (DC), those settings apply to all the domain's DCs. When you set rights on a workstation or member server, those settings apply only to that computer. However, before you start assigning rights, you must understand thoroughly what each right does and how you can use these rights to your advantage.

Setting User Rights
In User Manager for Domains, choose Policies, User Rights. A list of user rights appears, as Figure 1, page 64, shows. In the Grant To window, you can see the accounts and groups that already have a specified user right. To add a user or group to this window (i.e., to grant a right), click Add, then specify the user or group. To remove a user or group from this window (i.e., to take away a right), highlight the name and click Remove. If you need to administer an advanced right, you must select the Show Advanced User Rights check box so that the advanced rights appear in the list of user rights.

If you prefer to use the command line or a batch file to grant rights, you can use the Microsoft Windows NT Server 4.0 Resource Kit Supplement 3's ntrights.exe utility. You can also use ntrights.exe in an unattended NT installation in which you need to change default NT rights. Rights are easier to manage if you grant them to groups rather than to individual accounts. After you grant or remove a right, affected users must log off the network, then log on again so that their access tokens reflect the change. Keep in mind that you can also assign rights to processes (typically while programming code). Many rights are specifically intended for processes rather than users.

11 Standard User Rights
The following standard user rights are the rights that administrators most commonly use. These rights apply to the most common NT tasks that require user rights.

Access this computer from network. The Access this computer from network right lets users connect to a computer over the network. Users who need to connect to a resource (e.g., shared directories, shared printers) that a certain network computer offers must have this right. If you're performing maintenance on a computer and need to prevent users from connecting to its resources—while still letting the computer access resources that it needs—you can temporarily remove the Everyone group from this right. If you keep sensitive shares on a particular member server, you can create one user group that contains all contract workers and another group that contains all noncontract workers. Then, to ensure that contract workers don't accidentally stumble on your sensitive data shares, grant only noncontract workers the Access this computer from network right.

Add workstations to domain. The Add workstations to domain right lets users who aren't members of the Administrators or Account Operators group add workstations to the domain. For example, if a contractor is helping you roll out a new batch of NT computers, you can assign the contractor a user account that has this right, rather than grant the higher security levels inherent in the Administrator and Account Operators groups. According to the Microsoft article "Capabilities of the 'Add Workstations to Domain' Right" (http://support.microsoft
.com/support/kb/articles/q139/3/65.asp), this right also lets users access Server Manager (from Server Tools) to add and remove computer accounts. After thorough testing, I determined that the right doesn't grant this reported capability. Using Server Manager remotely to try to add a workstation to a domain, I received an Access Denied error message. However, on a clean NT installation, a user who has only this right can create the computer account during installation.

Back up files and directories. The Back up files and directories right lets users back up all files and directories, including those they otherwise can't access. I recommend that you grant this right only to the Backup Operators group and use User Manager for Domains to add users to the group as necessary. Be aware that some utilities (e.g., the resource kit's Scopy utility) can also bypass an object's file and directory permissions.

Change the system time. The Change the system time right lets users set the time on their computer. Most administrators use a time-synchronization utility (e.g., Net Time, the resource kit's timeserv.exe) to keep all desktops synchronized. Because time is important to many job functions, correct computer-function timestamping is probably crucial in your organization. To ensure that users don't change their system time from that of the official company time server, you can restrict this right.

Force shutdown from a remote system. The self-explanatory Force shutdown from a remote system right is listed in NT but inactive. However, this right is active in Windows 2000 Server. Administrators of NT networks use the resource kit's shutdown.exe utility to perform this function. In pre­Service Pack 4 (SP4) NT installations, users must have the Shut down the system right to use shutdown.exe.

Load and unload device drivers. The Load and unload device drivers right lets users load and unload device drivers. In NT, users must also belong to the Administrators group to have this right. In Win2K, Microsoft changed the right so that users needn't belong to the Administrators group.

Log on locally. The Log on locally right lets users log on directly to a computer. This right and the Access this computer from network right are probably the two rights that new NT administrators most often overlook. I recommend that you remove this right from all groups except Administrators on servers. Doing so ensures that even if unauthorized users gain physical access to your server, they won't be able to log on unless they know an administrator-level username and password. Unauthorized users will see the message The local policy of this system does not permit you to log on interactively. Restricting this right won't prevent users from connecting to the system over the network, and restricting the Access this computer from network right won't prevent users from logging on locally to a computer.

Restricting the Log on locally right is one of the most effective ways to prevent unauthorized access to your servers. Consider the popularity of the GetAdmin utility on hacker sites a few years ago. This utility permitted any user with the ability to boot a computer (except members of the Guests account) to join that computer's Administrators group. If the computer was a PDC, the user could join the Domain Admins group and no trace of the action would appear in the Security log. Although Microsoft included the getadmin-fix hotfix in SP4 and later, another utility—sechole.exe—exploited another security hole in NT by permitting a user to run GetAdmin despite the installed hotfix. However, the user still must gain physical access to the computer and be able to log on locally. Restricting this right adds one more level of protection to your server.

Manage auditing and security log. The Manage auditing and security log right lets users manage the Security log. (It doesn't let users set the auditing policy through User Manager for Domains—that right belongs to administrators.) Users can open Event Viewer to view and manage the log. This right was nonfunctional before the arrival of SP3; users and groups who didn't have this right could still manage the log. SP4 corrected this error so that groups now need this right to manage the log. Companies that separate network management and network auditing into two separate functions find this right useful. If you take this right away from an administrator—and simultaneously enable auditing of security policy changes—you ensure that he or she can't erase or modify log entries without producing an audit trail (unless a hacker tool is involved).

Restore files and directories. The Restore files and directories right is similar to the Back up files and directories right. It lets users bypass NTFS permissions to restore files and directories on partitions they otherwise can't access.

Shut down the system. The Shut down the system right lets users shut down the local computer. To prevent users from shutting down a system, simply restrict this right. Suppose two computers in your drafting department hold important CAD drawings. You've configured your backup program to back up these files every evening. If a user shuts the computers down, the backup will fail. If one of these computers fails to start up properly in the morning, you might have lost crucial data. By restricting this right to administrators, you ensure that the system remains online and ready for backup. Of course, a determined user can press the power button or unplug the computer from its power source, but such measures are beyond your control unless you purchase protective enclosures for your equipment.

Take ownership of files or other objects. The Take ownership of files or other objects right lets users take ownership of an object that they don't own. Because of the power inherent in this right, you should grant this right only to administrators or high-level management personnel. You'll find Take ownership of files or other objects useful if a user with exclusive access to a home directory leaves the company and a different user needs to access that user's files. As an administrator, you can take ownership of those files, as Figure 2 shows, then temporarily grant this right to a given user, who can then take ownership.

16 Advanced User Rights
In addition to the 11 standard user rights, NT offers 16 advanced user rights that you can access by selecting the Show advanced user rights check box in the User Rights Policy dialog box. Although you'll use these rights less frequently than the standard rights, you can use many advanced rights to permit a user to perform actions at the OS's Local Security Authority (LSA) and kernel levels. Remember to use caution when granting these advanced rights to users and groups; you might inadvertently compromise security if you grant them incorrectly. For more information about NT's advanced user rights, see the Microsoft article "Definition and List of Windows NT Advanced User Rights" (http://support.microsoft.com/support/kb/articles/q101/3/66.asp).

Act as part of the operating system. The Act as part of the operating system right lets processes act as a trusted part of the OS. Typically, you assign this right to subsystems that need privileged access. For example, Microsoft Exchange Server's installation program creates a service account that has this right; Exchange uses this account for authenticating communication between Exchange servers.

Bypass traverse checking. The Bypass traverse checking right lets users navigate through a directory tree that they otherwise can't access. However, users still can't read or change any files as they drill through directories (unless they have permissions that permit such access). You can use this right to permit a user to drill down to a file that he or she has permissions to—without worrying about the user accessing a file that he or she doesn't have permissions to. By default, the Everyone group has this right. Be extremely cautious if you decide to modify this default setting; if you do so, I recommend you grant the right to Domain Users and Administrators at the very least. Logon scripts and other routine functions depend on this right.

Create a pagefile. If a user receives a warning that his or her system is running low on virtual memory, the Create a pagefile right lets him or her use the Control Panel System applet to increase virtual memory. This right also lets the user use Performance Monitor to observe the Paging File % Usage Peak measurement and adjust the size of the pagefile to maximize performance.

Create a token object. The Create a token object right lets users or processes create access tokens. Because of this right's power, I recommend that you not grant it to any accounts or users. By default, only the LSA should have this right. (When you view this right, LSA won't appear in the Grant To list. Only user accounts appear in the Grant To list.) By creating an access token, a user or process can access any local resources.

Create permanent shared objects. The Create permanent shared objects right lets users create special shared objects that NT uses. NT reserves this right primarily for process usage. No listed account will have this right, but many OS processes have it by default. You can use this right to control who can implement peer-to-peer networking. Administrators have this ability by default. Users who don't have this right won't see a Share tab when they access a folder's Properties sheet. By removing this right, you can shut down those Quake II servers that consume all your bandwidth around lunchtime.

Debug programs. The Debug programs right lets users—typically programmers—debug programs. Users who have this right can gain full access to any system-level process—a dangerous prospect that users can easily abuse. I recommend that you grant this right only to users whom you fully trust won't abuse the right's inherent power. For example, a user who has this right can run the GetAdmin utility (which I discuss under the Log on locally right), even if you've installed the hotfix for the utility. Users can also start and stop processes and initiate new threads. A malicious user can easily use this right to cripple a domain.

Generate security audits. The Generate security audits right lets users or processes create Security log entries. Software developers use this right to give their programs the ability to generate log entries for certain actions. Typically, software that requires this right will either grant it automatically during installation or instruct you to grant it to the software's service account. For example, to function correctly, SNA service accounts must have this right; therefore, SNA grants it during installation.

Increase quotas. The Increase quotas right lets users or processes increase a given object's disk-space quota. This right isn't functional in NT but is active in Win2K.

Increase scheduling priority. The Increase scheduling priority right lets users increase a process's scheduling priority. Users who want to run a process with realtime priority need this right. Increasing priority can lead to system instability, so use this right carefully.

Lock pages in memory. The Lock pages in memory right permits NT to lock pages into memory, thereby preventing the system from paging them to the pagefile.sys file. You can instruct a program that has this right to assign itself a chunk of memory. Doing so lets the program run faster because it isn't paging. The drawback to this capability is that it decreases the amount of memory available to other processes and the system by the same amount—a detriment to systems that have limited memory.

Log on as a batch job. Many NT administrators use scheduler programs, such as Microsoft Internet Explorer's (IE's) Task Scheduler, to run routine tasks automatically with batch files. To successfully execute, the account that IE uses to run a batch job might need this right. The Log on as a batch job right lets you use the account running the batch job without physically logging on to the computer.

Log on as a service. The Log on as a service right lets accounts run under a service's security context. Sometimes, a service requires an elevated level of access to accomplish its task—access that the currently logged-on user might not have. This right lets that service run without elevating a user's level of access or requiring the user to log off and another user with the required level of access to log on. The Replication account, which handles replication among servers, commonly uses this right. Also, if you were to create special accounts under which certain services would run, those accounts would need this right.

Modify firmware environment values. The Modify firmware environment values right lets users modify system environment variables through the System applet (e.g., changing the Startup/Shutdown options) or through a process.

Profile single process. The Profile single process right lets users perform NT performance sampling to observe a nonsystem process. By default, NT grants this right to administrators and power users. Typically, only programmers and processes use this right.

Profile system performance. The Profile system performance right is similar to the Profile single process right, except that users who have this right can use NT performance sampling to observe system processes. Typically, only programmers and processes use this right.

Replace a process level token. The Replace a process level token right lets users modify a process's access token. For example, Microsoft SQL Server 2000's service account needs this right so that it can run xp_cmdshell for a user who isn't a SQL Server administrator. For more information about xp_cmdshell, see MS SQL Server Transact-SQL and Utilities Reference (Microsoft TechNet CD-ROM).

What's Next?
Now that you're more familiar with the way NT 4.0 user rights can help you do your job, you'll be more prepared when special circumstances arise and you don't want to add users to high-power groups. Your next step is to ensure that users don't abuse these rights. For information about auditing user-rights assignments, see the sidebar "Avoid User-Rights Abuse."