Windows 2000 provides new mechanisms for keeping track of users and groups. But the familiar rules for managing them still apply.

Group Think

Windows 2000 provides new mechanisms for keeping track of users and groups. But the familiar rules for managing them still apply.

• By Michael Chacon
• 03/01/2000

As I’ve mentioned before, Windows 2000 brings many new concepts to the table while still maintaining plenty of the core technologies and practices of Windows NT 4.0. This is also true in the area of User Management and the application of permissions to resources. You might think that the Active Directory (AD) changes how permissions are applied to users, but for the most part this isn’t the case. Rather than change the whole ballgame, Microsoft added functionality to what existed before.

The Use of User Management

The main reason we even need to focus on managing users is that there are security concerns with virtually any network. The nature of business information demands that we have discretionary control over which user has access to what resource or information. But before we get too deep into the technological aspects of managing users with the new tools available in Win2K, let’s make clear the first rule of user management: The procedural aspects are as important as the technical ones. Planning thus rises to the top of the list for long-term manageability. Of course, the nature of any procedural planning depends upon the underlying technical foundation of AD.

Organizational Units (OUs) and groups are completely different components of Win2K. OUs are getting most of the attention because of their central role in AD. However, groups still play a major part in user management, particularly in their role of applying permissions to resources. For now, I’m going to focus on the role of security groups and leave OUs and distribution groups for future discussion.

With security in mind, let’s look at how to manage users and permissions in Win2K. The most fundamental characteristic to remember is that a Win2K user, as well any group, is really a Security Identifier (SID), just as with NT 4.0. This central fact hasn’t changed. If you’re new to NT, SIDs are automatically generated unique numbers that identify a user. The SID number is based upon and identifies the domain the user is created in; if a user is deleted, that SID cannot be re-created.

Organizational Units Aren’t What You Think

If you were ready to use OUs as the objects to grant permissions, take another look. Despite all the fanfare and expectations that AD will solve all problems large and small, OUs aren’t used as security principals. While you can use OUs to delegate administrative privileges, you can’t use them to pass out user permissions to access resource objects. As such, groups are still necessary to give permissions to objects.

This is a major difference between AD and NetWare NDS. NDS users are security equivalent to their OU, so it’s common to grant access to the OU in NetWare. The Microsoft reasoning, rather, is that it’s easier to assign permissions to groups, which can easily span OUs. It’s debatable whether this is the only approach that would be useful—the marketplace will determine if the lack of OU-based resource access is a good idea. I think it would be nice if both options were available to the administrator (but then I wasn’t consulted).

Resource objects are associated with a Security Descriptor (SD) that contains a Discretionary Access Control List (DACL), which is simply a list of SIDs that are permitted access, and a System Access Control List (SACL) that controls auditing to keep track of which SIDs are accessing the object. In addition, a permissions mask controls the granularity of access permitted, such as Read, Write, or Change. So far, so good; all this is familiar to the NT 4.0 engineer. Now comes a little expansion to the system and our thinking.

One would also think that the flat namespace is completely dead now that we have the new and wonderful hierarchical Active Directory. However, in the quest to maintain a simple logon and prevent a deep restructuring of the core Win2K system code, you still need to keep a flat namespace in mind when designing your naming conventions.

Also keep in mind that with AD, you now have different types of usernames, each with different characteristics that relate directly to groups. First, there’s the User Principal Name (UPN). It can contain up to 64 characters and must be unique within the AD forest, as we would expect. The UPN is a concatenated name that can be well served by following the DNS name or email address. It’s used to log on to the AD for authentication. [email protected] would be an example of a UPN.

The User Account Full Name must be unique within the Domain or OU where it exists. Also referred to as the display name, it shows up as the main label in the directory. This name can contain a virtually unlimited number of characters.

The down-level Name is the traditional Domain\Mchacon SAM account name used for logging onto an NT 4.0 network. This name must be unique within the domain, and the user name part is limited to 20 characters. This name is also necessary only when you have a mixed NT 4.0 and Win2K environment—another reason to go all Win2K as soon as possible. If you have a mixed NT 4.0 and Win2K environment, it’s a good idea to match this name to the first part of the UPN so logon is consistent across platforms.

There are, of course, other names stored in the AD, including Distinguished Name (DN), Relatively Distinguished Name (RDN), and the Global Unique Identifier (GUID) number, but these don’t relate to groups. I’ll cover them later.

Naming Conventions

Before you even add a name to the AD database, sit down with your support group and some sort of business practice group and come up with a naming convention that will be meaningful to both the technical support staff and the user community. This convention discussion between the technical and the business process should go beyond just the naming conventions for logon and security purposes. The directory also presents opportunities to store a virtually unlimited amount of other information about the user. The key word is virtual. The amount of data you add here will have a direct impact on replication traffic across your physical network, as well as with directory-enabled applications.

It will also have support consequences. You can retrieve useful information only if it has been entered in the first place. This can be tedious, as most detailed database massaging is; but it’s also extremely important as the unfolding of directory-enabled applications enter the scene and take on a more important role. Make sure that the information you plan to collect in the AD is useful and not gratuitous. Finally, ensure that the naming convention supports the flat characteristic that groups in Win2K inherently require.

After you’ve agreed upon user naming and organizational conventions for users, you need to turn your attention to how you will give users permission to the various objects on the network. As with NT 4.0, the best way to accomplish this with manageability in mind is through the proper use of the different types of groups. Giving permissions to individual users is not only problematic when widespread changes are necessary; it also overloads the ACLs with unnecessary entries. Groups are the only realistic approach to providing scalable access to resources.

Group Thinking

As you may recall, the recommended way to apply permissions in NT 4.0 is to assign them to a Local Group (LG) that exists in the SAM where the resource resides. You then add all of the users to a Global Group (GG) that exists in the domain where the users reside. Placing the GGs into the LGs then controls permissions to the resources. Even though there are several other ways to accomplish the same task, this method proves the most flexible. Regardless of the approach you’ve implemented, consistency is the watchword in manageability and scalability. See Figure 1.

Figure 1. The recommended way to apply permissions in NT 4.0.

The first thing to take notice of with Win2K is that even with the AD, the SAM doesn’t fade away. It’s alive and well on each machine as a repository for the SID-based accounts and groups on Win2K Professional and Win2K standalone and member servers. All of the other groups in the AD are stored by default in %systemroot%\ntds\ntds.dit on the domain controllers.

So which groups do we now use? And when do we use them? First, let’s explore an overview of the groups that exist in Win2K and where they’ve changed from NT 4.0.

The nesting of groups is a powerful feature of Win2K, which simplifies the application of permissions. Nesting is the ability of groups to be placed into other groups of the same or different type. This is available only with Win2K, as NT 4.0 down-level clients don’t recognize nesting. Nesting helps make up for the flat characteristic of groups. For example, you could create groups based upon OU membership and then place the different OU-based groups into a domain-wide group. Removing or placing the OU-based group into the domain-wide group would be a way to assign permissions to resources by OU. However, as with all “powerful” features, it can cause complex headaches if not used appropriately.

The new Universal Group (UG) exists across the entire AD forest of domains. It can contain other UGs, GGs, and individual user accounts. A key characteristic of the UG is that the group and its members are automatically listed in the Global Catalog (GC). This can have strong implications for replication and search time; the GC will exist on every site within the forest and will grow as you add members to the UGs. UGs are only available in native mode, and therefore NT 4.0 clients can’t view them.

As mentioned previously, GGs are similar to the NT 4.0 variety and contain users that exist in the same domain in which the GG was created. However, in Win2K they can also contain other GGs from the same domain. While GGs are listed in the GC, the members of the GGs aren’t. LGs exist on machines in the domain they’re created in and can contain users, GGs, and UGs from any other domain in the AD domain forest. Since all domains in a forest use the Kerberos transitive trust relationships, all existing groups in the forest are always available to the LG without having to build trust relationships manually. Nesting GGs is only available in native mode; therefore, NT 4.0 clients don’t see or acknowledge any nested GGs.

Several strategies exist for the creation and application of groups. In a mixed environment it’s rather straightforward, since you follow the permissions on LGs: users in GGs, and GGs placed in LGs.

In native mode or in a complete Win2K enterprise, you have more options. You can use only UGs and apply permissions directly to them. You use nesting with smaller UGs to control which users are gaining any particular permission. This has profound implications on bandwidth because, as you recall, all members of UGs are also included in the GC. See Figure 2.

Figure 2. The all-universal group strategy in Windows 2000.

Recommendations have surfaced that small installations can use universal groups exclusively and not concern themselves with global and local groups. However, we saw this type of recommendation in the early days of NT 4.0, and it caused problems for many companies. Networks have one common characteristic: They grow. I think using all UGs can create some confusion in regards to which groups have permissions directly applied and which UGs are for nesting purposes only.

A close cousin to the all-UG strategy is to use UGs only as containers, similar to using GGs in NT 4.0, and placing UGs in LGs that have permissions directly applied. The benefit of this strategy is that you always know that LGs have permissions and no users, and UGs have users and no directly applied permissions. This still has the drawback of having users listed directly in the GC. See Figure 3.

Figure 3. The use of universal groups as containers (similar to the use of global groups in NT 4.0).

Another model that appears complex but has an organized elegance is the following: Use GGs to contain the users from the domain using nesting on the OU level or where appropriate. Place these GGs into UGs that are forest-wide. Give permissions to LGs where the resources reside and place the UGs in the LGs. The benefits? LGs always have the permissions, GGs always contain OU users, and UGs always contain groups defined in domains. This also minimizes the changes of group membership in the GC to help control replication traffic. See Figure 4.

Figure 4. An elegant approach uses global groups to contain users and universal groups to contain groups defined in domains.

No Right Method

The bottom line: There is no “right” method for creating and applying groups. There’s only a method that makes sense for your network, users, and support staff. I’m sure it will be some time before issues such as these are generally settled. If you have any doubts, just recall the proliferation of domains in early NT 4.0 networks. The only thing I would argue in the “right” department is that you should apply a method in a documented and consistent manner. Other than that, experiment, test, and then let everyone else know what you find out as we finally start implementing Win2K in production networks.

As always, conventions translate to navigational understanding by the user and supportability by the administrator. This was true with NT 4.0 and remains true with Win2K.

The other areas that impact user management in Win2K are Group Policies, and, of course, OU structure. I’ll cover these aspects of Win2K in a future column.