Subscribe to Windows IT Pro
February 20, 2002 12:00 AM

Controlling User Rights and Built-in Groups

Windows IT Pro
InstantDoc ID #23837
Rating: (0)

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.


Related Articles in Previous Issues
This article is the fourth in Randy Franklin Smith's "NT Security Fundamentals" series, which is adapted from Audit and Security of Windows NT Server, a course that the author developed for MIS Training Institute. You can obtain the previous articles in the series from Windows & .NET Magazine's Web site at http://www.winnetmag.com.

"A Model Network," October 2001, InstantDoc ID 22249
"PDCs, BDCs, and Trust Relationships," September 2001, InstantDoc ID 21844
"NT Security Fundamentals," August 2001, InstantDoc ID 21510
Corrections to this Article:
  • "Controlling User Rights and Built-In Groups" incorrectly states that the Log on locally right is required for Windows NT LAN Manager (NTLM) Challenge/Response authentication with Microsoft IIS. Basica authentication requires Log on locally; NTLM Challenge/Response requires Network logon.

Related Content:

ARTICLE TOOLS

Comments
  • Jakob Hussfelt
    10 years ago
    Mar 25, 2002

    The article mentions that "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".

    I would like readers to disregard this statement since such a User Rights setting is too permissive. To make use of NTLM Challenge/Response authentication through IE, "Access this computer from the network" is needed and enough.

    To succeed with a Basic Authentication, the "Log on locally" Right is needed though.

You must log on before posting a comment.

Are you a new visitor? Register Here

advertisement

advertisement

Windows is a trademark of the Microsoft group of companies. Windows IT Pro is used by Penton Media Inc. under license from owner.