Windows IT Pro is the leading independent community for IT professionals deploying Microsoft Windows server and client applications and technologies.
  
  
  Advanced Search 


March 2002

Controlling User Rights and Built-in Groups


RSS
Subscribe to Windows IT Pro | See More Security Articles Here | Reprints | Or get the Monthly Online Pass—only $5.95 a month!

 See corrections to this article

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

End of Article

   Previous  1  2  [3]  Next  


Reader Comments
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.

Jakob Hussfelt March 25, 2002


You must be a registered user or online subscriber to comment on this article. Please log on before posting a comment. Are you a new visitor? Register now




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.
Top Viewed ArticlesView all articles
Command Prompt Tricks

One reader shares his tip for setting up the command prompt to reflect a remote path. ...

WinInfo Short Takes: Week of November 9, 2009

An often irreverent look at some of the week's other news, including some more Windows 7 sales momentum, some Sophos stupidity, Microsoft's cloud computing self-loathing, more whining from the browser makers, Zoho's "Fake Office," and much, much more ...

Understanding File-Size Limits on NTFS and FAT

A general confusion about files sizes on FAT seems to stem from FAT32's file-size limit of 4GB and partition-size limit of 2TB. ...


Security Whitepapers Reducing the Costs and Risks of Branch Office Data Protection

Solving Desktop Management Challenges in Healthcare

Solving Desktop Management Challenges in Education

Related Events WinConnections and Microsoft® Exchange Connections

Deep Dive into Windows Server 2008 R2 presented by John Savill

Cutting Costs with Client Management

Check out our list of Free Email Newsletters!

Security eBooks Spam Fighting and Email Security for the 21st Century

Understanding and Leveraging Code Signing Technologies

A Guide to Windows Certification and Public Keys

Related Security Resources Introducing Left-Brain.com, the online IT bookstore
Looking for books, CDs, toolkits, eBooks? Prime your mind at Left-Brain.com

Discover Windows IT Pro eLearning Series!
Clear & detailed technical information and helpful how-to's, all in our trademark no-nonsense format


Windows IT Pro Home Register FAQ for Windows WinInfo News
Europe Edition About Us Contact Us/Customer Service Media Kit Affiliates / Licensing  
SQL Server Magazine Office & SharePoint Pro DevProConnections IT Job Hound
Left-Brain.com Technology Resource Directory asp.netPRO ITTV Windows SuperSite 
 
 Windows IT Pro is a Division of Penton Media Inc.
 © 2009 Penton Media, Inc. Terms of Use | Privacy Statement