Log on locally. On member servers, the Administrators group and the local operator hold the Log on locally right by default; on workstations, the Everyone group holds the right by default. Maintaining the member servers' more limited assignment is a good idea: Most servers are hardened only against remote users, so giving ordinary users permission to log on locally to a server's console can be a dangerous move.
However, using Microsoft IIS and NT Server 4.0, Terminal Server Edition might force you to give users this right. For example, when you configure an IIS intranet server to use NT LAN Manager (NTLM) Challenge/Response authentication, users who access that server through Microsoft Internet Explorer (IE) need the Log on locally right. Users who access a server through the Terminal Services Advanced Client (TSAC) also need the right. Therefore, implementing physical security on your IIS and WTS servers is especially important.
Manage auditing and security log. The Manage auditing and security log right lets you change the audit control list on files, folders, registry keys, and printers. This right also lets you view, dump, or clear the Security log, so the right can give attackers the ability to disable auditing or cover up evidence (although NT logs event ID 517 whenever someone clears the Security log).
By default, the local Administrators group holds this right, but I recommend that you create a custom group (e.g., ManageAuditing) and populate that group only with users who regularly need to change object auditing or work with the Security log. Even though administrators can grant themselves the right at any time, creating such a specialized group might give you added protection. (Attackers who gain Administrator access through a limited interface such as Telnet won't have the means to grant themselves the right.) I've heard reports of bugs in this right, but I've never experienced such bugs in any of my tests with NT 4.0 Service Pack 4 (SP4).
Take ownership of files or other objects. The Take ownership of files or other objects right lets you assume ownership of any object on the computer, regardless of the object's ACL. (The right's purpose is to ensure that administrators can regain access to objects owned by deleted users.) Carefully guard assignment of this right because the right permits access to any confidential data on the system.
Advanced User Rights
NT has an additional class of advanced rights, which you can view when you select the Show Advanced User Rights check box in the User Rights Policy dialog box. These rights, which grant special authority to internal NT services and certain types of third-party services that extend the OS, are extremely powerful. Never grant them to ordinary users, and grant them to service accounts and administrators only as needed.
The one exception is Bypass traverse checking, which NT grants by default to the Everyone group. This right lets you access a file—provided you have the proper permissions in that file's ACL—regardless of whether the parent folder's ACL grants access. Without Bypass traverse checking, users would need permissions not only to an object but also to all the object's parent folders. Aside from the complications to access control that deleting this right would present, revoking the right has historically caused occasional blue screens of death. According to the Microsoft article "Stop 0x00000024 May Occur When Bypass Traverse Checking Is Disabled" (http://support.microsoft.com/default.aspx?scid=kb;en-us;q177676), NT 4.0 SP4 solves the problem, but I'm still leery of changing the default assignment, given the degree to which doing so fundamentally changes NT's access control model. I recommend that you leave Bypass traverse checking granted to Everyone.
Built-in Groups
Aside from letting you assign user rights to user accounts and groups, NT automatically grants certain authorities to its built-in groups. These groups reflect various predesigned roles (e.g., Administrator, Power Users), and built-in group membership inherently grants numerous sets of authorities that you can't grant or revoke manually. Although you can change default rights assignments, you must accept the preconceived roles and authorities that correspond to each built-in group. As with user rights, member servers and workstations maintain a different set of built-in groups than DCs do.
Member server and workstation built-in groups. NT member servers and workstations maintain six machine local groups that exist in each workstation's and member server's SAM. These groups are Administrators, Power Users, Users, Guests, Replicator, and Backup Operators. Each group can contain local users or domain users from its domain and from trusted domains. Three of the groups—Administrators, Power Users, and Users—have special authorities beyond NT's default user rights assignments.
Members of the Administrators group can share folders and printers, maintain users and groups, edit rights assignments, change account and audit policy, unlock the computer when another user has locked it, start and stop services, and change services' startup options. (All other machine local groups have a subset of these authorities.) Members of Power Users can start and stop services, change the membership of the Power Users and Users groups, and share folders and printers. Members of Power Users also can create new user accounts and groups and edit or delete accounts that they created. Members of the Users group can create new groups—but not user accounts—and edit or delete groups that they created.
DC built-in groups. DCs maintain two types of groups: domain local and global. Domain local groups are similar to member servers' and workstations' machine local groups. However, because all DCs in a domain share a copy of the same SAM, any permissions or rights that you grant to one domain local group apply to all the domain's DCs (but not to member servers or workstations). Like machine local built-in groups, domain local built-in groups can contain users from the DC's domain and from trusted domains.
Register
