Windows 2000 provides new mechanisms for keeping track of users and groups. But the familiar rules for managing them still apply.
Windows 2000 provides new mechanisms for keeping track of users and groups. But the familiar rules for managing them still apply.
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.
|Group policy admins
|Table 1. The groups that are built
into the system when Active Directory gets
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
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. firstname.lastname@example.org
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
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
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
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.
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
|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
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
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
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. 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.