Organizing Users

Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

By Gregg Branham

Chapter 9 of Windows NT Domain Architecture, published by MacMillan Technical Publishing

This chapter will review:

• User and Group Fundamentals
  Seeing the big picture related to user and group administration is important to understanding enterprise strategies.

• Understanding Rights and Abilities
  Rights and abilities are granted to built-in local groups on Windows NT. They play a key role in the delegation of administration within NT domains.

• The Impact of Trusts on Users and Groups
  Trusts limit the flexibility of your user and group strategy by making only global users and global groups visible to the trusting domain.

• Account Standards and Maintenance
  Large networks demand standard practices for defining user and group accounts. Most networks also require ongoing account maintenance, including such tasks as disabling and deleting inactive accounts.

• User and Group Infrastructure
  Establishing a good user and group infrastructure for a large network is essential. The last section of this chapter presents the benefits of local groups and illustrates strategies for multiple-domain environments.

On This Page

User and Group Fundamentals
Understanding Rights and Abilities
The Impact of Trusts on Users and Groups
Account Standards and Maintenance
User and Group Infrastructure

User and Group Fundamentals

Before delving into user and group strategies, it is important to understand user and group fundamentals. You should define a user account for every person who needs access to the system. By establishing separate user accounts, you gain the ability to control and audit each person's access to the system. Groups are used to organize users that require similar access to resources. Groups are also used to grant administrative privileges such as the ability to create shared directories.

Groups simplify administration in the following ways:

• Groups allow you to use fewer operations to control resource access. Suppose you have 100 users in your engineering department who all need access to a shared folder containing design files. You can organize all 100 users into a single group, and then add the group to the folder and file access control lists (ACLs). This is easier than adding 100 individual accounts to the ACLs.

• Groups make ACLs simpler. By adding groups rather than users to ACLs, you create ACLs that are simpler and easier to understand. You also improve the system's efficiency because it has fewer ACL entries to _compare.

• Groups make it easier to manage users. Suppose a new user enters the accounting department. If your system is set up properly, you should only have to copy a user account template for an accounting department user—after that, the new account has access to the proper accounting resources. In other words, if your resource access is set up properly based on group memberships, you can control it by adding or removing users from groups.

Windows NT supports two types of users and groups: local and global. Local users and groups are visible only on the machine on which they are defined; thus, the term local refers to a user's or group's limited scope. On the other hand, global users and groups must be defined in the domain SAM and are visible to all machines in the domain.

In addition to the local and global characterization, users and groups can be classified as built-in or user-defined. When you install Windows NT, the system creates built-in user and group accounts with specific privileges on the system. Although NT workstations and Member Servers have the same built-in users and groups, NT domain controllers include additional built-in groups. These built-in users and groups are outlined in the following section.

Built-In Users and Groups

On a Windows NT workstation and Member Server, Windows NT creates the following built-in users and groups:

Users:

Administrator
Guest (disabled)

Local Groups:

Administrators
Backup Operators
Guests
Power Users
Replicator
Users

Global Groups:

None
On a Windows NT domain controller, Windows NT creates the following built-in users and groups:

Users:

Administrator
Guest (disabled)

Local Groups:

Administrators
Account Operators
Backup Operators
Print Operators
Server Operators
Guests
Replicator
Users

Global Groups:

Domain Admins
Domain Guests
Domain Users

Tip Windows NT keeps track of the built-in Administrator and Guest accounts, so you can rename them but not delete them. It is highly advisable for you to rename the built-in Administrator account because it is not subject to the account lockout policy you define for all domain accounts (see Chapter 8, "Domain Security," to review this topic).

Built-in local groups play an important role in the assignment of rights and abilities on NT systems. The additional built-in local groups on domain controllers exist for the purpose of domain administration. The global groups provide you with basic groups that are available to all machines in the domain for the purpose of assigning access to resources.

Special Groups

In addition to the built-in groups, Windows NT has the following special groups:

Authenticated Users (added by Service Pack 3)

Creator/Owner

Everyone

Interactive

Network

System

The special groups are not visible from User Manager or User Manager for Domains. However, they are available for assigning access to resources and can be added to any ACL.

User-Defined Users and Groups

Windows NT allows you to define local and global user accounts and local and global group accounts. Each of these accounts is described in the following sections. (The "User and Group Infrastructure" section later in this chapter provides detailed information and strategies for achieving the best arrangement for your circumstances.)

Local User Accounts

Local user accounts have a limited scope and are visible only on the machine on which they are defined. The account appears on all domain controllers because the SAM is replicated. A local user account does not support interactive logon. To create a local user account, you must explicitly set the account type to local on the user account property sheet (see Figure 9.1). Local user accounts are needed only in specific situations and are rarely used.

Figure 9.1: By default, User Manager for Domains sets all account types to global unless otherwise specified.

According to Microsoft, a local user account should be used for the purpose of granting untrusted users access to domain resources. A local user account provides extra protection through its limited visibility. An untrusted user has limited access to domain resources because the account is visible only on the machine in which it is defined. In other words, because the account is not visible to other machines, it cannot be added to the ACLs of resources on the other machines.

Tip If an untrusted user requires access to resources on more than one server, you must define more than one local user account and set the same password for each one.

Global User Accounts

The new accounts you create on Windows NT are automatically set to a global account type. Global accounts are visible on all machines in the domain for the purpose of assigning resource access.

Local Group Accounts

Local group accounts are limited in scope and visible only on the machine in which they are defined. Depending on your user and group strategy, you may or may not need to use local groups. In certain cases, local groups can simplify administration and eliminate certain speed problems associated with assigning resource permissions over a WAN.

Local groups can contain

• Local users

• Global users

• Global groups

Global Group Accounts

Global groups are visible on all machines in the domain. Thus, you can assign global groups to any resource in the domain.

Global groups can contain

• Local Users

• Global Users

Understanding Rights and Abilities

You must understand rights and abilities to understand how administrative capabilities are delegated to Windows NT users. The NT operating system assigns rights and abilities to the built-in local groups on NT servers and workstations. Abilities are inherent powers that cannot be modified. They are granted by virtue of membership in built-in local groups. The only way to change a user's ability is to change the user's group membership. For example, suppose you must give a user the ability to back up the system. You can do so by adding the user's account to the Backup Operators group, giving him or her the ability to back up and restore files and directories.

Tables 9.1 and 9.2 show the abilities assigned on NT workstations, Member Servers, and domain controllers. Users and Guests have no defined abilities on domain controllers.

Table 9.1 Abilities on Workstations and Member Servers

Abilities on Workstations and Member Servers	Administrators	Power Users	Users	Everyone	Guests	Backup Operators
Assign user rights	X
Create and manage global groups	X
Create and manage local groups	X	X	X
Create and manage user accounts	X	X
Create common groups	X	X
Format server's hard disk	X
Keep a local profile	X	X	X			X
Lock the server	X	X		X
Manage auditing of system events	X
Override lock of the server	X
Share and stop sharing folders	X	X
Share and stop sharing printers	X	X

Table 9.2 Abilities on Domain Controllers

Abilities on Domain Controllers	Administrators	Server Operators	Account Operators	Print Operators	Backup Operators	Everyone
Create and manage user accounts	X		X
Create and manage global groups	X		X
Create and manage local groups	X		X
Assign user rights	X
Manage auditing of system events	X
Lock the server	X	X				X
Override lock of the server	X	X
Format server's hard disk	X	X
Create common program groups	X	X
Keep a local profile	X	X	X	X	X
Share and stop sharing folders	X	X
Share and stop sharing printers	X	X		X

Rights are similar to abilities, but they can be controlled by administrators. Specifically, a right is an authorization for a user to perform an administrative task on the system, such as managing the security log or changing the system time. Tables 9.3 and 9.4 show the rights assigned on NT workstations, Member Servers, and domain controllers. No rights are defined for Users or Guests on domain controllers.

Tip You can use NTRIGHTS.EXE from the Windows NT Resource Kit to automate the modification of user rights on multiple machines.

Table 9.3 Rights on Workstations and Member Servers

Rights on Workstations and Member Servers	Administrators	Power Users	Users	Everyone	Guests	Backup Operators
Access this computer from network	X	X		X
Back up files and directories	X					X
Change the system time	X	X
Force shutdown from a remote system	X	X
Load and unload device drivers	X
Log on locally	X	X	X	X	X	X
Manage auditing and security log	X
Restore files and directories	X					X
Shut down the system	X	X	X	X		X
Take ownership of files and other objects	X

Table 9.4 Rights on Domain Controllers

Rights on Domain Controllers	Administrators	Server Operators	Account Operators	Print Operators	Backup Operators	Everyone
Access this computer from network	X					X
Back up files and directories	X	X			X
Change the system time	X	X
Force shutdown from a remote system	X	X
Load and unload device drivers	X
Log on locally	X	X	X	X	X
Manage auditing and security log	X
Restore files and directories	X	X			X
Shut down the system	X	X	X	X	X
Take ownership of files and other objects	X

Without membership in a built-in local group (either directly or indirectly), an account has no rights or abilities and is unusable. Recall that a workstation's local groups are modified when it joins the domain. The specific modifications are as follows:

• The Domain Admins global group is added to the local Administrators group on the workstation.

• The Domain Users global group is added to the local Users group on the workstation.

• The Domain Guests global group is added to the local Guests group on the workstation.

These modifications give the Domain Admins group the necessary rights and abilities to administer all domain workstations. The modifications also give the Domain Users group the needed rights and abilities to log on and use any workstation in the domain. These modifications are important because enterprise domain models require you to manually apply similar modifications to workstations in trusting domains.

Author's Note To see the effect of an account with no rights or abilities, try the following example:

1. Create a new group called "Test."

2. Create a new account and add it to the Test group only. You must set the account's primary group to Test to remove the Domain Users group from the Member Of list box.

3. Try to log on to the account. You should receive an error message saying the local policy of the system does not permit you to log on interactively. Because the account does not have the needed right to log on locally (refer to Table 9.3), the user is not permitted to log on.

Author's Note If you are new to NT rights and abilities, do not fret. When adding a new user account, you should not think, "What rights do I grant to this user?" or "Will the user have the needed abilities?" Unlike the NT file system permissions, NT rights and abilities are set up very well out-of-the-box and warrant little change. In general, you do not have to make any modifications to user rights; if you do, you should modify them by adding or removing groups and not individual user accounts.

The most common user right I modify is the right to change the system time. It is often desirable to synchronize a workstation's time with a server. You can use the net time command in a login script, but a user must have the right to change the system time to successfully complete the command.

Another user right that is sometimes modified is the right to access a computer from the network. On some networks, the security policy dictates that administrators must work from the console of the server. Consequently, the Administrators group is removed from the right to access the computer from the network on all servers. Because administrators cannot access the server remotely, potential hackers are forced to gain physical access to the system or compromise security using an ordinary user account.

The Impact of Trusts on Users and Groups

Trust relationships introduce limitations on group membership in the trusting domain. Local users and groups from a trusted domain are not visible in the trusting domain and cannot be included in any trusting domain groups or added to ACLs in the trusting domain. Thus, users from the trusted domain must be organized at the global level.

As a domain admin of a trusting resource domain, you depend on the domain admin of the trusted domain (usually the accounts domain) to properly organize global users into global groups. Otherwise, your resource administration is complicated, and extra steps are introduced.

Author's Note You cannot specify whether a user is trusted in User Manager for Domains. A user is considered trusted based on a trust relationship established between two domains, not based on an account definition. As soon as a trust is in place, all users and groups in the trusted domain are considered trusted by the trusting domain.

Figure 9.2 illustrates the group membership possibilities for users and groups within a single domain.

Figure 9.2: You have many group membership options within a single domain.

In a single domain, you have a large degree of freedom for organizing your users and groups. However, when your network consists of multiple domains the flexibility is limited. Figure 9.3 shows the group membership possibilities for users and groups from a trusted domain.

Figure 9.3: If your domain is trusting of another domain, you are limited to adding trusted global users and trusted global groups from the other domain to your local groups.

Notice that you cannot add a trusted global user to a global group in the trusting domain. Consider the illustration in Figure 9.4. Suppose you manage the 20 workstations in the ATL domain and want to grant domain administrator privileges to Tom in the Corp domain. You cannot add Tom (a trusted global user) to the Domain Admins group. Your only choice is to add Tom to the local Administrators group on your domain controllers. This gives Tom the ability to administer the domain controllers, but what about the domain workstations? To give Tom administrative control over the workstations, you must explicitly add the Tom account to the local Administrators group on each workstation. The next section presents precautionary steps you can take to avoid this situation.

Figure 9.4: Granting administrative control of all ATL workstations to Tom can be a difficult task.

Account Standards and Maintenance

Conventions are important when administering an enterprise NT network. You should establish standard naming conventions for all user and group accounts. You may notice the convention of starting all global groups with the letter G and all local groups with the letter L later in this chapter. Such conventions save time and clarify the user and group structure. You should also note that NT does not allow you to rename a group account. Your only solution is to _re-create the group with a new name and add all the necessary members.

Tip There are a couple of conventions I would recommend for enterprise networks with a large SAM. First, you should use an underscore at the beginning of all template account names. This moves the template accounts to the top of the list in User Manager for Domains and allows you to quickly copy them for new users. You can extend this idea further by using two underscores (__) at the beginning of service accounts to separate them from the ordinary user accounts.

Secondly, when you disable an account, you should rename it with a Z at the front of the account name. This moves all disabled (and unused) accounts to the bottom of the list in User Manager.

A typical problem on most large networks is unused accounts. Unused accounts can result from several actions. Sometimes accounts are created with the wrong username and are never deleted. In other cases, you may have test accounts with simplistic passwords lying dormant in the Security Accounts Manager. If you work with several other administrators or if you are a new administrator, it is likely there are unused accounts on the system that you do not know about. Thus, you should periodically inspect the system for unused accounts and delete them.

A great utility to help you determine whether an account is active is USRSTAT.EXE from the NT Resource Kit. USRSTAT.EXE generates a list of all accounts and their most recent logon time. You can easily import the USRSTAT.EXE output into a spreadsheet, sort by last logon time, and—voilá—you quickly know which accounts are experiencing a period of inactivity.

Another problem associated with large networks occurs when no one sets up a communication system to let administrators know when a user leaves or changes a position within the company. To solve the problem, you should establish a good line of communication with the human resources department. It is important that you are notified immediately when users leave the company or change positions within the company—otherwise, you are left with dormant accounts and unneeded group memberships. When a user leaves the company, you should disable his or her account immediately. If you do not take action to disable the user's account, he or she may be able to dial in and destroy network resources, enter fictitious product orders, and so on.

Author's Note You should always disable—not delete—accounts of former users because of the SIDs used by NT. If you disable the account, you can rename it when someone else takes the previous user's place, and the new user will have access to all the resources needed by the old user.

On the other hand, if you delete the old account, the SID associated with the account is gone forever. For a deleted account, your only choice is to take ownership of all resources belonging to the deleted account and delegate them to a new user or other users on the network. Such an operation is meticulous and time-consuming. Disabling and later renaming the account is a much better solution.

User and Group Infrastructure

Your organizational strategy depends on the domain model your company selects. It also depends greatly on the number of domains and number of global groups required by your organization. The remainder of this section provides information to help you develop a successful user and group strategy for your network.

There are two key issues concerning your user and group strategy that you must address:

• You must organize users and groups in a way that simplifies the administration of network resources.

• For centralized-administration domain models, you must create groups for the purpose of delegating control of servers and workstations in the trusting domains.

Figure 9.5 presents the two primary approaches to user and group organization. Each triangle in the figure represents a layered pyramid that describes a particular organizational approach. Each pyramid starts with a large number of global users at the base, which are then organized into a small number of global groups. For an organization with 10,000 users, you may only have 200 global groups, which are created on the domain controller.

Notice the pyramid on the left side in Figure 9.5 contains a local group layer. The local groups are defined on the servers that store resources, and the ACLs illustrated in the pyramids are attached to those resources. Thus, an ACL contains permission assignments to local groups, the local groups contain global groups, and the global groups contain global users.

Figure 9.5: There are two major approaches to user and group organization.

Microsoft recommends the strategy on the left side of Figure 9.5: organizing global groups into local groups. Although the approach makes sense for most enterprise organizations with hundreds of global groups, it is not the best design for most networks. In most cases, local groups offer no significant benefit and only complicate the user and group structure. To better understand when and if to use local groups, you must consider the advantages they offer and whether your infrastructure can benefit from the advantages. The following section explains these topics in greater detail.

The Role of Local Groups

Local groups have two benefits:

• In organizations with a large number of global groups, they help you simplify administration and improve system efficiency through the addition of local groups.

• They can be used to alleviate speed problems introduced by slow WAN links.

To illustrate the simplified administration created by local groups, suppose your company has a master domain model with 12 resource domains located at 12 different company locations (see Figure 9.6). Now suppose you have a shared research directory on a NY marketing server, and you must grant read access to the marketing users of 10 resource domains. Although you can add the 10 trusted global groups directly to the ACL of the research directory, you would benefit more by creating a local group on the marketing server (see Figure 9.7).

Figure 9.6: This company has one master domain and 12 resource domains that are geographically separated.

Figure 9.7: Administration is simplified by combining the trusted global groups into a local group.

The second benefit of local groups is that they help you overcome the administrative problems associated with slow WANs. When setting the ACLs on resources, the list of users and groups is pulled from a PDC. If the PDC is located across a WAN link, a serious delay in retrieving the users and groups is introduced. The length of the delay depends on the size of the SAM database containing the users and groups you must enumerate. Although you cannot shorten the delay, you can arrange an alternate group structure that allows you to quickly modify resource permissions on networks that communicate with the PDC over a WAN. The trick is to mirror each global group located across the WAN with a local group that contains the global group. With local groups defined in the machine's local SAM, you can quickly modify ACLs by assigning permissions to local groups.

Consider the network in Figure 9.8. The Corp domain is located in Chicago across a 64K WAN link, and the resource domain is located in New York. When you set up the NY file server, you can create a local group for each global group in Corp and add the Corp global group. There is no doubt that this increases your setup time; however, you only have to pull the global groups from Corp once. After all Corp global groups are mirrored to local groups in the local SAM, you can assign permissions quickly based on the local groups. For instance, suppose you have a shared Sales folder and need to give access to the global sales group GSales. Instead of waiting to pull all the global groups across the WAN, you can add the LSales group to the ACL more quickly (see Figure 9.9).

Figure 9.8: The administration problems introduced by the 64K WAN link are alleviated through the mirroring of global groups to local groups on each server in the NY domain.

Figure 9.9: Administration is simplified by combining the trusted global groups into a local group.

Author's Note I know it is impractical to mirror hundreds of global groups to local groups, and I do not advocate mirroring every single group. However, servers usually have a specific purpose, and if you mirror the groups related to the server, the advantage can be realized. For instance, if you have a research file server, you would likely benefit from mirroring 10 to 12 global research-related groups.

Ideally, you should avoid the use of local groups. However, if you have a large number of global groups, or if your resource administration is significantly degraded by a slow WAN link, you should consider using them.

Delegating Administrator and User Privileges

In multiple domain structures that use centralized administration (master and multiple master domain models), you must create groups in the accounts domain specifically for users and administrators of the resource domains.

Let's go through an example to illustrate the user and group interaction in a centralized administration model. Consider the network in Figure 9.10. (The figure shows only one resource domain, but the network likely contains many more.) Following is an outline of the user and group interaction:

Figure 9.10: Corp and NY are part of a master domain model.

1. Grant logon privileges for NY users. Even though NY trusts Corp, Corp users cannot log on to workstations in the NY domain. Consider a single workstation in the NY domain: To be able to log on, the account or group must possess the right to log on locally (see Table 9.3). On a workstation, the right is assigned to the local Users group. Because the workstation has been joined to the NY domain, the local Users group contains the global NY Domain Users group. However, all accounts are defined centrally in the Corp domain, not the NY domain. So your challenge is to allow users from the Corp domain to log on to workstations in the NY domain.

   The problem is solved by organizing all the accounts for New York users into a global group in the Corp domain. Then add the global group (we'll call it NY Domain Users) to the local Users group on each workstation in the NY domain (see Figure 9.11).

   

   Figure 9.11: NY Domain Users are added to the local Users group on each NY Domain workstation to permit New York users to log on.

   Notice that only members of the NY Domain Users group can log on to the NY workstations. What if you want to allow users from other domains to visit the NY domain and use the workstations there? If you want to grant total mobility, you can add the Corp\Domain Users global group to the local Users group on each workstation. Otherwise, you must add only the groups from other selected domains.

2. Grant administration privileges for NY domain controllers. The second challenge is deciding how the NY domain should be administered. Should the Corp\Domain Admins be responsible for NY domain controllers, or should you create a separate group for the administration of the NY domain controllers? This can be a tough question, and the answer really depends on your infrastructure.

   For example, it is not plausible to give two help desk users from the NY domain membership in the Corp\Domain Admins group so that they may reset passwords for NY users. Let's assume two people at the New York office, Tom and Sally, will be responsible for the administration of all domain controllers, servers, and workstations in the NY domain. Now the challenge is clearly defined: You must give Tom and Sally control over the NY domain controllers. You can solve the problem by creating a NY Domain Admins global group in the Corp domain and adding the NY Domain Admins group to the local administrators group on the NY PDC (see Figure 9.12). Because the SAM is replicated, you only need to add the trusted global group to the local group on the PDC.

   

   Figure 9.12: NY Domain Admins is added to the local Administrators group on each NY Domain controller to grant administrative control of the NY domain to Tom and Sally.

3. Grant administration privileges for NY workstations. Although Tom and Sally can administer the NY domain controllers, they cannot administer the NY workstations without one more group modification: You must add the NY Domain Admins to the local Administrators group on all NY domain workstations (see Figure 9.13).

   

   Figure 9.13: To grant control over all NY domain workstations, the trusted global NY Domain Admins must be added to the Administrators group of each NY domain workstation.

This example covered the basics of delegating user and admin privileges for resource domains. If necessary, you should go beyond the example and create global print operators, backup operators, or whatever is needed for the resource domain.

NT's Lack of Granular Administration

Windows NT 4.0 does not provide the granular level of administration demanded by enterprise networks. For example, suppose you are a help desk administrator and someone calls because he or she cannot access a file. How do you check his or her access and permissions? You can likely view the permissions on the file and display the groups on the ACL, but how do you ensure the user is a member of one of the listed groups? Unless you are a domain administrator, you cannot.

There are many administrative powers that need to be delegated for enterprise networks. Such powers include resetting user passwords, unlocking accounts, granting dial-in access, and so on. Fortunately, several third-party tools exist for the purpose of subdividing administration on a granular level. Following is a list of third-party administration tools for NT 4 and contact information for the manufacturer:

Enterprise Administrator

Mission Critical Software

https://www.missioncritical.com

Trusted Enterprise Manager

Master Design & Development

https://www.mddinc.com

Virtual Administration Tool

FastLane Technologies

https://www.qwest.com

Windows 2000 will offer a greater ability to delegate administrative powers. However, Windows 2000 and Active Directory will not natively provide the advanced administrative functions needed to deploy NT on an enterprise scale. The Active Directory falls short of providing the multiple lines of administration needed by most companies. You should be able to organize administrative units based on geographic sites as well as functional divisions. You should also be able to have an administrator who is responsible for all user and group accounts in Chicago and an administrator who is responsible for all user and group accounts in the Sales division, which may span several geographic networks. For such functionality, you will be pressed to seek third-party administration add-ons for Windows NT.

About the Author

Gregg Branham has been working with Windows NT since its first release. Currently, he is the president of Altus Network Solutions, Inc. (https://www.altusnet.com).

Copyright © 1999 by MacMillan Technical Publishing

We at Microsoft Corporation hope that the information in this work is valuable to you. Your use of the information contained in this work, however, is at your sole risk. All information in this work is provided "as -is", without any warranty, whether express or implied, of its accuracy, completeness, fitness for a particular purpose, title or non-infringement, and none of the third-party products or information mentioned in the work are authored, recommended, supported or guaranteed by Microsoft Corporation. Microsoft Corporation shall not be liable for any damages you may sustain by using this information, whether direct, indirect, special, incidental or consequential, even if it has been advised of the possibility of such damages. All prices for products mentioned in this document are subject to change without notice. International rights = English only.

International rights = English only.

Click to order