Controlling User Rights and Built-in Groups

More cornerstones of NT security

As I demonstrate in the previous articles in this series about Windows NT security fundamentals, NT security isn't as centralized as many people believe. (See "Related Articles in Previous Issues," page 42, for a list of the other articles in the series.) You need to carefully configure and maintain security settings—including NT user rights and built-in groups—on each system in your domain. Each member server and workstation has a local SAM with a discrete set of rights assignments and built-in groups; also, the domain controllers (DCs) in each domain share a common set of rights and built-in groups. You need to understand the different repercussions of rights you assign on a member server or workstation and those you assign on a DC. You also need to understand the authorities that NT's built-in groups grant, and how local groups on member servers and workstations can interact with domain groups to enhance or weaken your network's security.

Know the Scope
User rights control users' ability to perform certain actions, such as changing the system time. (You assign user rights at the system level; you assign permissions at the object level.) The first step in properly assigning user rights is to understand their scope.

Regardless of which computer you log on to, User Manager for Domains' focus defaults to the domain SAM on the PDC (the title bar displays the domain's name). When you select Policies, User Rights from the menu bar, the resulting User Rights Policy dialog box that Figure 1 shows displays the rights assignments in the PDC's SAM. (Each BDC simply maintains a replica of the PDC's SAM. Therefore, the rights assignments that User Manager for Domains displays when focusing on the domain are the effective rights assignments on all the DCs in the domain.)

However, each member server and workstation maintains its own rights assignments. For example, when you use User Manager for Domains to grant the Change the system time right to the ClockWatchers group, you give that group the authority to set the system clock on the DCs in the domain—but not on the member servers and workstations. To edit the rights assignments on a member server or workstation, log on to that system and open User Manager for Domains. Choose User, Select Domain from the menu bar. Enter the computer's name, preceded by a double backslash (\), then click OK. User Manager for Domains refocuses on that computer's local SAM and displays the computer's name in the title bar.

Powerful User Rights
You should closely monitor several important rights, especially on computers that store sensitive information, host critical operations, or serve as workstations for highly privileged users. Allocation of these rights can improve—or weaken—the security of your entire domain.

Access this computer from the network. The Access this computer from the network right is necessary and useful for users and administrators. To connect over the network to a computer's shared folders, registry, event log, SAM, or Control Panel Services applet, you must use an account that possesses this right on the remote computer. However, you can restrict the assignment of this right to protect computers from certain remote attacks.

You should avoid the use of local accounts because they aren't subject to your DCs' centralized control, and attackers often try to use these accounts to connect to remote systems. The Everyone group has the Access this computer from the network right by default—an assignment that's too permissive because that group includes local user accounts. I recommend that you assign the right only to the Domain Users group on member servers (so that users and administrators can access servers as necessary for daily operations) and to the Domain Admins group on workstations (so that administrators can manage workstations remotely). The Domain Users and Domain Admins groups exclude local user accounts, so these rights assignments will protect you against local user account—based attacks even when a computer's passwords and lockout controls are weak.

Backup files and directories. A user with the Backup files and directories right can access any object on the computer, regardless of the object's permissions. To protect confidential information, restrict the assignment of this right. You need the right to run NT's native backup program, but most companies use a third-party backup solution (e.g., Computer Associates'—CA's—BrightStor ARCserve Backup, VERITAS Software's Backup Exec) that runs as a service. In that case, the backup application's service account needs the right, and you can avoid assigning the right to user accounts. (However, each backup application tends to have individual arcane requirements, so be sure to review your product's documentation.)

Restore files and directories. The Restore files and directories right complements Backup files and directories and lets you restore (from backup media) any object on the system, regardless of whether the user has access to the object. Guard this right as closely as you do Backup files and directories because attackers can use Restore files and directories to replace files with previous versions and thus cover up evidence of intrusion.

Load and unload device drivers. The right to load device drivers carries a great security risk because device drivers run in kernel mode. The OS trusts programs running in kernel mode more than it trusts typical applications. Thus, malicious users can code and load a device driver to escalate their privileges and perform unauthorized operations. Administrators and consultants commonly consider the Load and unload device drivers right as a means to permit an ordinary user to load device drivers, but even users who hold this right must be members of the Administrators group. Therefore, I suggest that you grant the right to that group only.

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.

The eight domain local groups are Administrators, Account Operators, Server Operators, Print Operators, Users, Backup Operators, Guests, and Replicator. Five of these groups—Administrators, Account Operators, Server Operators, Print Operators, and Users—have special authorities.

The domain local Administrators group holds the same rights as the machine local Administrators group, but on the domain's DCs rather than on the local system. (The other domain local groups have a subset of these authorities.) Account Operators can create new user accounts and groups and edit or delete most existing accounts and groups. To prevent members of this group from escalating their authority, members can't modify the Administrator user account or most of the built-in groups. Members of Server Operators can share folders and printers, lock DCs and override locked DCs, and start and stop services. Members of Print Operators can share printers. Members of the Users group can create new domain local groups and edit or delete groups that they created.

Domain global groups, unlike domain local groups, can hold rights and permissions on any computer (not just DCs) in the domain or in any trusting domain. However, a global group can contain users only from its domain. The three domain global groups are Domain Admins, Domain Users, and Domain Guests. You can nest domain global groups (which can access objects from any trusted domain) in machine or domain local groups (which can contain users from any trusted domain), but you can't nest local groups in domain global groups. This restriction helps prevent redundant groups in multidomain environments without breaking the transitive trust relationship rule (i.e., domain A doesn't trust domain C simply because domain A trusts domain B and domain B trusts domain C). For more information about trust relationships, see "Related Articles in Previous Issues."

Group Interaction
Administrators new to NT often wonder about the existence of local Users groups as well as a global Domain Users group. When you create a new user account in your domain, NT automatically adds that account to the Domain Users group, which automatically is a member of the domain local Users group and the machine local Users group on each member server and workstation in the domain. When you create a local user account on a member server or workstation, NT adds that account to the machine local Users group. Therefore, when you grant permissions or rights to a machine local Users group, you empower all machine local users and all domain users, but when you grant permissions or rights to Domain Users, you empower only the domain users (not the machine local users). You can use the global Domain Users group to grant access to users from a trusted domain.

New NT administrators also ask about the difference between the Everyone group and the Users groups. The Everyone group isn't an actual list of users; it's simply a symbol that includes anyone who's logged on locally or over the network. Therefore, no real difference exists between Everyone and Users when your domain doesn't trust any other domains. (Concern over the inclusion of unauthenticated users in the Everyone group led Microsoft to provide the Authenticated Users group in NT, and some sources suggest that you replace occurrences of the Everyone group with Authenticated Users. The purported risks are largely unfounded, however, and I don't consider such an action worth the effort.) However, a difference does exist when your domain trusts at least one other domain. In that case, the Everyone group includes all the users in your domain and any trusted domains, whereas the Users groups contain users only within your domain.

NT automatically makes the global Domain Admins group a member of a computer's local Administrators group when the computer joins the domain. Similarly, Domain Guests is a member of each computer's local Guests group. When you successfully use the Guests account to log on to your domain, you have access to objects on any domain system on which permissions have been granted to Guests, Domain Guests, or Everyone. Therefore, I recommend that you keep the built-in Guests account disabled (as it is by default).

Respect Authority
Understanding user rights and the special authority that NT's built-in groups hold on each computer in your domain is an important piece of fundamental security. Still, reviewing the existing rights and built-in group membership on all your systems can be a lot of work. For a free reporting tool to help you assess numerous systems, check out SomarSoft's DumpSec (http://www.somarsoft.com). This tool lets you create a report that shows user rights assignment, group membership, and other reports from local and remote computers and in a variety of text file formats. You can run DumpSec interactively or from the command line, so you can use it in scripts. The security benefits will be well worth the effort.

Corrections to this Article: