Managing Users
and Groups
I
f you are passionate about being a network or domain
administrator, then managing users and groups will give
you a lot of satisfaction . . . it can be a very powerful position
in a company. On the other hand, unless you understand the
fundamentals, manage the processes sensibly, and learn the
tools and resources, it can become an extremely frustrating
responsibility. Our administration mantra is: Use your common
sense and learn to do it right before you take up the task. This
chapter helps you to get the best out of the Windows 2000 user
and group management philosophy and tools.
Despite Microsoft’s Zero Administration Windows (ZAW)
initiative, user and group management has become a lot more
complex in Windows 2000. The complexity has a lot to do with
the improved User and Group objects and the new support in
Active Directory, such as Group Policy. Combined with the
burden of integrating Windows NT 4.0 and earlier networks,
the administrative task will not be easy in the short-term.
This might improve over the years because many companies
and, especially, administrators are certain to develop tools
for the Active Directory that automate the repetitive stuff
and enhance the experience of working with Active Directory
(and we touch on that in here). In that the directory is open
and supports a widely available API (ADSI) and access proto-
col (LDAP), we have to give credit where credit is due. For
example, you can extend the User and Group objects to suit
your enterprise requirements or custom applications. What
you will learn in this chapter will put you on the road to such
advanced administration.

What Is a User?
This question may seem patronizing at first, but in a Windows network domain
(and also the local computer), the definition of user relates to autonomous
processes, network objects (devices and computers), and humans. Human
users exploit the networks or machines to get work done, meet deadlines,
and get paid. But any process, machine, or technology that needs to exploit
another object on the network or machine is treated as a user by the Windows
operating systems. In a nutshell, the Windows 2000 security subsystem does
not differentiate between a human and a device using its resources. All users
are viewed as “security principals,” which at first are trusted.
When you install Windows 2000 (not upgrade) or create a new Active Directory
domain, the operating system and its elements are completely exposed. The
governing policy on a new domain is that everyone can access everything. This
makes sense: Keep the doors open until the jewels have been delivered. As soon
as you begin adding users to the system, and they begin adding resources that
need protection, you should begin using the tools described in this chapter and in
several others to lock down the elements and secure the network.
User objects are derived from a single user class in Active Directory, which in
turn derives from several parents. Machine accounts are thus derived from the User
object. To obtain access to the User object, you need to reference its distinguished
name (DN) in program or script code. This is handled automatically by the various
GUI objects, but if you plan to write scripts that access the object, you should be
referencing the object’s GUID.
What Are Contacts?
Contacts are new objects in Windows 2000 networks. They are derived from
the same class hierarchy as the User object; however, the Contact object does
not inherit security attributes from its parent. A contact is thus only used for
communication purposes: for e-mail, faxing, phoning, and so on. Windows 2000
distribution lists are made up of contacts.
Note

See Chapter 25 for information on how to log on locally to a domain controller.
What Is a Group?
Groups are collections of users, contacts, computers, and other groups (a process
known as nesting). Groups are supported in Active Directory (much to the horror
of directory purists) and in the local computer’s security subsystem. How Windows
2000 works with groups is discussed later in this chapter. Figure 10-1 illustrates the
group container philosophy.
You would be right to wonder why Microsoft gives us both groups and organizational
units (OUs) to manage. Groups, however, are a throwback to the Windows NT era.
Remember, Windows 2000 is built on NT, and groups were thus inherited from the
earlier technology and enhanced for Windows 2000. Although groups may appear
to be a redundant object next to OUs, they are a fact of Windows 2000 and are here
to stay. They are also extremely powerful management objects.
Note
4667-8 ch10.f.qc 5/15/00 2:01 PM Page 321
322
Part III ✦ Active Directory Services
Figure 10-1: Groups are collections or concentrations of users, computers,
and other groups.
The difference between groups and OUs is explained in Chapters 2 and 7, and
later in this chapter.
Specifically, we create and use groups to contain the access rights of User objects
and other groups within a security boundary. We also use groups to contain User
objects that share the same access rights to network objects, such as shares,
folders, files, printers, and so on. Groups thus provide a security filter against
which users and other groups are given access to resources. This critical role
of the groups is illustrated in Figure 10-2.
It is not good practice to stick user accounts into every nook and cranny of
a Windows domain. If you start that practice, you will soon have a domain
that resembles a bowl of rice noodles at your local dim sum. It is a wonder that

several Accounting departments throughout the enterprise.
object(objectname)
1. Read
2. Execute
3. Write
4667-8 ch10.f.qc 5/15/00 2:01 PM Page 323
324
Part III ✦ Active Directory Services
Figure 10-3: The Accounting group
is a universal container that allows its
members to access resources in the
departments of several corporate
domains in a forest.
Microsoft could have given the same power to the OU, but it did not, at least in the
first version of Windows 2000. Instead, it is hoping we will see how groups and OUs
fit into the overall management philosophy. Our guess is that it would have caused
a serious delay in the release of Windows 2000 had Microsoft made OU security
principals behave like groups. We look at the differences a little later; suffice it to
say now that the Group object is certainly not redundant; it is a very powerful
management tool.
What is a network from the viewpoint of users and groups?
There are several definitions of a network. From the perspective of users and
containers of users, a network is a collection of resources (collection of network
objects as opposed to device) that can be accessed for services. Users exploit
network objects to assist them with their work. Network resources include
messaging, printers, telecommunications, information retrieval, collaboration
services, and more.
Administrators new to Windows 2000 should get familiar with the meaning of
network object, for it is used to reference or “obtain a handle” on any network
component, both hard and soft.

✦ The Domain Controllers folder will always contain at least one computer . . .
the domain controller you are currently working on.
4667-8 ch10.f.qc 5/15/00 2:01 PM Page 325
326
Part III ✦ Active Directory Services
✦ The ForeignSecurityPrincipals folder is the default container for security
identifiers (SIDs) associated with objects from other trusted domains.
✦ The Users folder contains built-in user and group accounts. When you
upgrade Windows NT to Windows 2000, all the user accounts from the old
NT domain are placed into this folder. This folder is not an OU, and no OU
group policy can be linked to it. For all intents and purposes, this folder
should be blank or at least should not contain any accounts when you first
do a clean install of Windows 2000 and promote it to Active Directory. Instead,
the built-in accounts should have been placed in the built-in folder, period.
We guess it is one of those things that Microsoft did without very much
forethought. But they did give us the ability to move items from folder to
folder, and it may make more sense for you to move all the built-in objects
to the built-in folder . . . especially since you cannot delete them.
✦ The LostAndFound folder contains objects that have been orphaned.
✦ The System folder contains built-in system settings.
Now, before we proceed, know that there are two levels to understanding how
user accounts work. You can cover the basics of user accounts by poking around
in the Active Directory User and Computers snap-in MMC panels, or you can make
an effort to learn about the most important attributes (compulsory and optional)
of user accounts at a lower level. If you are a serious network and Windows
administrator, then we suggest the latter. Why?
Firstly, as an administrator, knowing the stuff of which user accounts are made
will take your management knowledge and skills to a higher level. You will be able
to contribute much more to the overall management of your enterprise network
if you know how to perform advanced searches for users, scientifically manage

2 and 7 for conceptual discussions on attributes.) If the password matches the
record, then the user is cleared to proceed and use network resources, perform
activities on computers, and communicate.
Remember, Active Directory is a “multi-master” directory service. This means that
changes to users and groups are replicated to other member DCs (but not to a
local account database). You can manage users on any DC on the network and not
worry about locating a primary DC, as was the case with Windows NT 4.0 and
earlier. User objects also contain certain attributes that are not replicated to
other DCs. These attributes can be considered of interest only to the local domain
controller. For example, the attribute LastLogon is of interest only to the
local network’s domain controller; it is of no importance to the other domain
controllers in the domain or the forest.
You can also create a user account in any part of the AD . . . as long as you have
rights to create or manage that User object. While container objects such as OUs
and groups serve to assist in the management of collections of users, there is no
mechanism other than having admin rights to prevent a user account from being
created anywhere in a forest.
Local accounts
Local accounts (users) are identical to network accounts in every way, but they
are not stored in Active Directory. Local accounts are machine-specific objects.
In other words, a local user account can only be validated against a local security
database — the SAM or Security Account Manager. Secondly, local accounts only
provide access to resources within the “boundaries” of the machine “domain” and
no further. An analogy might be that the key to your house only lets you enter your
house. All other houses in your neighborhood are off limits.
Note
4667-8 ch10.f.qc 5/15/00 2:01 PM Page 327
328
Part III ✦ Active Directory Services
If you are new to Windows networking, you may be wondering why machines on a

purpose and thus its access and security level (hiding was not possible on Windows
NT). If you have security fears, you can audit the activity of the Administrator to
determine who or what is using the account and when.
When you demote a domain controller (DC) to a standalone server, and especially
if it is the last DC on the network, the OS prompts you for the password you will
use for the local Administrator account. In the process of stripping away AD and
its administrator accounts, the OS ensures that you will be able to log on locally
and gain access to the machine after the conversion. When AD departs from the
server, it hands control of the machine back to the machine-specific domain and
Security Account Manager (SAM).
Note
4667-8 ch10.f.qc 5/15/00 2:01 PM Page 328
329
Chapter 10 ✦ Managing Users and Groups
Administrator account
The Administrator account is the first user account created when you install Windows
2000, regardless of which of the four versions of Windows 2000 you are installing. The
Administrator account is created in both the local SAM and in Active Directory.
The Administrator is the CEO on Windows 2000 and all earlier versions. By logging on
as the Administrator, you get total access to the entire system and network. Without
the power of this built-in user, it would be impossible to set up the first objects.
The Administrator account is dangerous, however. Over time, the password to this
account gets handed around, and your network goes to hell. We have even seen situa-
tions where the Administrator’s account password finds its way around the world in
large corporations, even allowing users in foreign domains to mess things up without
the key MIS people at HQ finding out. In one situation, it ended up in the hands of a
subcontractor who managed to bring an office to a standstill for a week.
So how do you protect this account from abuse? For starters, you cannot delete
or disable the account because then it would be too easy to get locked out of the
system or fall victim to a denial-of-service (DoS) attack.

✦ Anyone looking for the Administrator will go here first, and denying access
to this folder may be impractical.
✦ The security policy governing the Users folder is inherited from the root
domain. This means that if for any reason the default or root domain policy
changes, it may affect the account without you being aware of the event.
✦ The Administrator accounts are better grouped in the main IS OU where
access is controlled by specific OU policy, focused management, and
delegated responsibility.
Here’s how to move the Administrator account:
1. Open Active Directory Users and Computers. Double-click the Users folder.
2. Select the Administrator account in the right-hand pane and right-click your
mouse. Now select the move option. The list of folders and OUs appears.
3. Drill down to a different OU of your choice. Select that OU and click OK.
The Administrator account is now moved to the new OU.
Another means of protecting the network and the Administrator account, and a
sophisticated means of management and troubleshooting, is to use the RunAs
service. Also known as the secondary login, it allows a user who is logged on
with their regular user account to perform functions with the privileges of
another account, typically an administrator’s. RunAs is demonstrated later
in this chapter in the configuration of user accounts (see also Chapter 25).
Guest account
The Guest account is the second of the default accounts that are pre-built when you
install Windows 2000 the first time, and when you create a domain controller and
install Active Directory. The account is useful for guests and visitors who either do
not have accounts on any domain in the forest, or whose accounts may be disabled.
The Guest account does not require a password, and you can grant it certain access
and rights to resources on the computer (see Rights and Permissions discussed
later in this chapter). We believe the Guest account on any domain should be relo-
cated to an OU whose security and account policy is appropriate to manage secu-
rity risks. You can leave the Guest account in the Users folder (which is a domain

done on a computer. They can, for example, begin reading company policy or
the employee handbook, and they can fill in employee forms, and so on.
✦ With a Guest account, a user who has been locked out for whatever reason
can at least log on to the domain and gain access to the company intranet and
local resources. Let’s say you have an intranet Web site that allows the user to
access the help-desk and open a ticket; then a user who cannot log onto the
domain can still generate a ticket for an account lockout problem. Lockouts
can and will happen often.
✦ An employee suspected of a misdeed can be asked to log on to a Guest
account while the reason for an account lockout is being investigated. This
may help diffuse a situation that has the potential of becoming tense. The
user’s account can also be transferred out of his or her usual OU to the
Visitors OU or a holding OU. This gives the user the impression that he
or she is still able to log on to the domain, but certain access rights have
been removed.
The Internet user account
Windows 2000 also provides default or built-in accounts for anonymous access to
IIS and for generic access to Terminal Services. See Chapters 23 and 25.
Account Policy
Before you go creating users, you must first take the time to fully understand how
account policy on Windows 2000 affects account creation and management on an
account-by-account basis.
4667-8 ch10.f.qc 5/15/00 2:01 PM Page 331
332
Part III ✦ Active Directory Services
The Windows Group Policy technology (which also includes account and security
policy) governs how all accounts can be configured on both standalone servers and
in the Active Directory. If you create users from the get-go, the accounts will be set
up with the default account policy attributes. They will remain this way until Active
Directory site, domain, or OU policies override this (when a domain controller and

if the password provided matches the password stored in the relevant database.
If the user is authenticated, Windows 2000 creates an access token for the user
(see Chapters 1 and 3).
4667-8 ch10.f.qc 5/15/00 2:01 PM Page 332
333
Chapter 10 ✦ Managing Users and Groups
If the domain controller does not receive the correct password or the user account
is unknown, the user is gracefully returned to the logon dialog box. But once a user
is authenticated, Windows then proceeds to activate whatever rights and permis-
sions the user has on the network.
The process that Windows 2000 uses to “follow” the user through the domain is
known as access token assignment. In other words, the access token is assigned to
the user for the duration of the logon and acts as a security tag a user wears when
“roaming” from computer to computer and from resource to resource. User account
information is replicated to all domain controllers in the enterprise, even across
slow WAN links.
To more fully understand the authentication process at the lower levels of
Windows 2000 and the security subsystem, refer to Chapters 1 and 3.
Security Identifiers
The security identifier (SID) is a unique value of variable length that is used to
identify an account (known as a trustee to the kernel) to the security subsystem.
Windows refers to the SID rather than the user or group name when referencing
these objects for security purposes. The SID is not the same thing as the object
identifier or OID. OIDs are explained in Chapter 7. SIDs guarantee that the account
and all its associated rights and permissions are unique. If you delete an account
and then recreate it under the same name, you will find that all rights and permis-
sions of the deceased account are gone. This is because the old SID was deleted
with the original account.
When you create an account, the system also creates the SID and stores it in the
security structures of AD or the SAM. The first part of the SID identifies the domain

✦ To provide special local access to devices. In order for a device to be installed
and gain access to system resources, it might have to be authenticated by the
LSA. Such an example is a tape-backup device driver, which might need to gain
access to a local database management system or to machine-protected pro-
cesses that require it to be logged on locally.
✦ To provide heterogeneous local authentication. Not everyone will be able to
take advantage of the Active Directory authentication and logon process, and
not everyone will want to. The LSA thus provides these “users” (processes)
with a local logon facility they were accustomed to, or built for, on Windows
NT 4.0 and earlier.
As discussed earlier in Chapter 4, when you set up a standalone server, Windows
creates default or built-in accounts. These are actually created in a local Windows 4.0-
type domain stored in the local SAM. The two local domains created are Account
and Builtin.
When you first install Windows 2000, these local domain systems are named after
the NETBIOS-type name of the machine. If you change the machine’s name, the
domain name will be changed to the new machine name the next time you restart
the server. In other words, if you set up a standalone server named LONELY1, a
local domain named LONELY1 will be created in the local SAM. The OS will then
create the built-in accounts for this domain. Later, you’ll be able to create any
local user in the local legacy domain. Services will also use the local domain
for system accounts.
The Active Directory includes a SAM service provider that allows Windows 2000
domain controllers to interoperate with NT 4.0 domain controllers. Such service
providers also exist for other directory services, such as Novell NDS.
Note
4667-8 ch10.f.qc 5/15/00 2:01 PM Page 334
335
Chapter 10 ✦ Managing Users and Groups
User Accounts in Action

from your workstation. Perhaps the best way to describe RunAs usage is to provide
a simple example.
Create a shortcut to the Command Console on the desktop and allow it to be used
to test a User ID and password as follows:
1. Create a shortcut to the command prompt on your desktop. This is explained
at the beginning of Appendix A.
2. Right-click the shortcut and select Properties. On the Shortcut tab, check the
“Run as different user” option.
3. Click OK.
Note
4667-8 ch10.f.qc 5/15/00 2:01 PM Page 335
336
Part III ✦ Active Directory Services
You will now notice that when you right-click the shortcut the Run as. . . line has
been added into the Context menu in bold type. But you can just double-click the
shortcut icon and the Run As Other User dialog box will appear. Now you can enter
your user’s account, domain, and password.
If you investigate RunAs further, you will discover that you can test alternate logons
and troubleshoot problems such as access to shares, printers, and so on. You can
log on and switch to the environment provided by the alternate account, and you
can allow users to run an application in the context of another account.
Naming User Accounts
You can make your life as a user administrator more enjoyable if you follow the
recommended convention for naming user accounts. You can and should plan
your user namespace carefully, publish the rules and policy surrounding the
chosen convention, and stick to it. There is nothing worse than inheriting a
directory of accounts where no naming convention exists.
In order to set up your naming convention checklist, consider the following:
1. User account names must be unique in the domain the accounts are created.
For example, you cannot have two names set up as

337
Chapter 10 ✦ Managing Users and Groups
In order to set up your password convention checklist, consider the following:
1. The passwords can be up to 128 characters in length. That does not mean
Microsoft expects you to saddle your users with a password that takes all
day to input. But smart cards and non-interactive logon devices can use a
field of that length.
2. Do not create passwords that are less than five characters; a minimum of
eight is recommended.
3. The following characters are not permissible in the password:
“ < > ? * / \ | ; : = , + [ ]
Password management is a nightmare for everyone. Most administrators we know
keep lists of passwords in various database files and helpdesks because users often
find themselves locked out of domains and resources for “no apparent reason.” To
troubleshoot and assist the user, we often need to log on to his or her account and
“experience” what might be going wrong. Many administrators troubleshoot this
way; it helps to be in the user’s context when troubleshooting. The new RunAs
service we describe in this chapter is a useful tool for managing user accounts
and troubleshooting passwords.
The password issuance and management-style questions are similar from platform
to platform, especially from NetWare to Windows NT and Windows 2000. In giving
users passwords, you have three choices that can be adapted and become policy:
✦ Assign the passwords.
✦ Let the user choose the password.
✦ Assign passwords to certain users; allow others to set their own.
All three choices have their pros and cons, and every company will have a reason
for going with one option or the other.
If you go with the first option, you will either have to adopt a password-naming
scheme that lends itself to easy recollection by administrators (as secure as an
open field) or enter the user’s passwords in a secure database.

word in a secure place: either a database management system that is hard to crack,
like an encrypted Microsoft Access database file, or in an SQL server table. The one
weakness of this option is giving new users their passwords. Often, the password
ends up going through several hands before ending up at the user. You could create
a temporary password assignment scheme.
You might also try your hand at adding a field to the Active Directory User object that
displays the password in plain text (the schema is there to be extended, see Chapter
6). You can secure the objects in the AD so that only certain administrators have
access to the field. You would also have to create a GUI to read the field because
the Account tab on the User Properties dialog box is off limits to such wild ideas.
Protecting passwords is more important under Windows 2000 than under Windows
NT, or any other OS for that matter. The reason is the Single Sign-on Initiative (SSO)
and the Kerberos ticket-granting service discussed in Chapter 3. On older OSs, you
need new user IDs and passwords for just about any service, such as voice mail, fax
mail, SQL Server, Internet access, and so on. As more applications support the SSO,
one password will eventually suffice for all. But this is a double-edged sword. If the
password or access falls into mischievous hands, the culprit will have access to
everything authenticated in the SSO process.
4667-8 ch10.f.qc 5/15/00 2:01 PM Page 338
339
Chapter 10 ✦ Managing Users and Groups
Logon
We have discussed the concept of local logon in various places, but this is a
right and not an automatic privilege. In order for a user to connect to the machine
standing next to him or her or to a remote machine across the network, he or she
would need authority in two places:
1. The domain the user is a member of must allow the user to request logon
permission from a machine. The default is to allow the user to request logon
from any machine, which means the target machine’s SAM gets to say yes or
no and not the domain.

or still uses to log on to the legacy NT domain. It is not the name of the machine
that is connecting. Remember that this is a NetBIOS name; it must be less than
20 characters, and you need to watch for the illegal characters discussed earlier.
You can create a new user account anywhere in the domain and later move it
as needed.
Figure 10-5: Create New
Object - User dialog box
The User Principal Name
In the beginning, on legacy NT, we had little flexibility with logon names. We would
typically use contractions of first and last names, such as jshapiro or jeffreys, or
names typically assigned to people serving 25 years to life, such as psjrs08676.
Now, everything is different. The user’s logon name and e-mail addresses are the
same. There are good reasons to do this. First, this change supports the SSO initia-
tive, better known as Single Sign-On. As long as the resources the user needs access
to support TCP/IP, RFC 822 naming, and Kerberos authentication, the user ID or the
resulting authentication certificates can be relayed to these technologies. Second,
the UPN allows you to use an e-mail address to log on to the domain from anywhere
on the Internet. As long as the domain controller is exposed to the Internet, or the
packets find the DC through a firewall, it is possible to log on and access resources.
As discussed earlier, if you can resolve CITYHALL.GENESIS.MCITY.ORG on the
Internet, you’ll be able to log in. The prefix part of the UPN provides the so-called
user ID, while the suffix identifies the domain.
So, given that life would be easier if your users’ logon IDs and e-mail addresses were
the same, you have some serious restructuring to do. Perhaps the best place to start
is at your e-mail server. Here, all the accounts are set up with UPNs already. And if
you have been running an Exchange server, then all the better. Simply dump all the
names into a comma separated file (
.csv
) and use these as the basis for your UPNs.
Note

js
. Anyone who ends up with a UPN of more than, say, eight letters may never
want to log in again.
Before you add the name, you will need to check that the UPN you entered when
you created the account conforms to the standards you have set for your network.
This double-checking exercise is worthwhile here because there will be many times
when the UPN has to be entered after the account has been created. If you copy an
account, the UPN field will have to be updated. Remember, the UPN conforms to
the Internet standard e-mail address governed by RFC 822, such as
jeffrey.

or

.
Click Next to fill in the password in the next dialog box, shown in Figure 10-6. Click
Finish when you’re done. That’s all there is to creating a user. Next, you need to set
the properties for the user.
Figure 10-6: Adding the password
to the New Object - User dialog box
4667-8 ch10.f.qc 5/15/00 2:01 PM Page 341
342
Part III ✦ Active Directory Services
Setting properties
After the account has been created, you need to set the Properties to define the
user’s rights and privileges, access to resources, contact information, and so on.
To access the property sheets of the user account object, simply double-click the
account in Active Directory, or right-click it and select the Properties option in
the Context menu. In this example, you double-click Armando R. Martinez, and
Armando’s Properties dialog box loads, as illustrated in Figure 10-7.
Figure 10-7: The User Properties dialog box

✦ Office: Enter the user’s physical office address.
✦ Telephone number: Enter the user’s telephone number and extension, if any.
✦ E-mail: Enter the user’s e-mail address. It might be intuitive for this field
to default to the UPN, but it doesn’t. However, the field is also not e-mail
format-sensitive, so if an SMTP format is out, you can enter a cc:Mail address,
an X:400 address, or something else. It is important to keep the entries here
consistent because access to this field is open via the ADSI and the field will
no doubt be a key repository of information for many people-tracking tools,
ERP apps, communications applications, and more. At the time of this
writing, we don’t know what e-mail applications will be using this field,
but it is available to access.
✦ Web page: Enter the user’s home page, if applicable. The idea of this field may
be foggy at first, because why would you have all your users worry about home
pages? However, these fields can be used for other applications, such as an ISP
whose user accounts “rent” homepages. If you are an ISP, you can set up user
accounts in the directory to manage access and accounting from the directory.
The field is a string data type, so an IP address is feasible here too.
✦ Address: On the Address tab, enter the user’s address.
✦ Logon to: This is the path of the workstation or server to which the users
can log in. For an administrator, leave this at the default. If the employee
were new or questionable, we would restrict him or her to the department’s
machine and lock the person out of the other MIS machines. For the sake
of demonstration, Figure 10-8 shows the restriction in force. This restriction
applies to all member machines, not just workstations, as it might suggest.
By not setting any values in this dialog box, you give the user access to all
machines on the network.
4667-8 ch10.f.qc 5/15/00 2:01 PM Page 343