The Users and Computers snap-in for Active Directory enables you to create Organizational Units (OUs) to set up an OUT Tree in the domain. This chapter coves setting up and managing OUs in Active Directory.

This chapter is from the book

The most visible part of Active Directory administration is managing objects with the Users and Computers snap-in. This snap-in
enables you to create organizational units (OUs) to set up an OU tree in a domain. You also use this snap-in to populate the OU tree by creating objects of the following eight classes in the OUs you want:

Users (or alternatively, inetOrgPersons, new in AD2003)

Contacts

Computers

Groups

MSMQ queue aliases (new in AD2003)

Shared folders

Printers

This chapter covers managing OUs and the first five classes in the list. We will proceed as follows:

First, we describe the contents of your Active Directory domain right after installation.

Second, we explore how to manage OUs and objects of each of the five other classes (i.e., users, inetOrgPersons, contacts,
computers, and groups).

Finally, we discuss some additional features of the Users and Computers snap-in, and we discuss or list additional tools for
managing objects.

This chapter focuses on the Users and Computers snap-in. If you have to create many objects, other tools you can use include
DSAdd (new in AD2003), LDIFDE, CSVDE, scripting, or some Resource Kit tools. DSAdd we cover at the end of this chapter; the other tools we just list there, but cover later in the book.

Behind the scenes, a domain object can contain objects of 35 classes (23 in AD2000), and an OU can contain objects of 59 classes (35 in AD2000). However, with the Users and Computers snap-in, you can normally create
and see objects of only the nine classes just listed.

MSMQ Queue Alias is listed as an alternative when you create new objects in the Users and Computers snap-in. You can, however,
create and use such objects only if you first install Microsoft Message Queuing 3.0 (MSMQ). Because such aliases (corresponding to the msMQ-Custom-Recipient class) reside in the directory, they help applications to locate message queues. Further discussion of the topic is outside
the scope of this book. Also, we don't mention MSMQ queue aliases later in this chapter, even though they would appear in some lists, and so on.

Active Directory after Installation

After you have created your first domain by installing Active Directory on a server (i.e., promoting it to a domain controller),
there are certain users, computers, groups, and containers already in place (see Figure 3.1). You see these objects with the Users and Computers snap-in, which you start by clicking the Start button and selecting
Administrative Tools, Active Directory Users and Computers.

Figure 3.1 A newly installed domain (sanao.com in the figure), which is the root domain of a forest

Another way to start the Users and Computers snap-in is to click the Start button, select Run, type dsa.msc, and press Enter.

You will see the following predefined objects in the snap-in:

Five containers, one of which is an OU

Some user objects (or user accounts)

Some group objects (sometimes referred to as group accounts)

One computer object (or computer account) for your domain controller

Active Directory contains only objects. Users, groups, and computers, however, are often called accounts instead of objects. You could also argue that an account is something that can authenticate (user or computer), so a group
is not an account, but "just" a group of accounts.

If you upgrade a Windows NT domain, you will see the users, groups, and computers of that domain in Active Directory.

Predefined OUs and Other Containers

The objects in a domain should reside in containers instead of at the domain level, just as files on disk should reside in
folders instead of in the root folder. Accordingly, the predefined objects are stored in containers below the domain level.
Table 3.1 describes the five predefined containers. Because they have extra system-flags protection, you cannot rename, move, or delete
themthey are always there (unless you redirect some of them, as explained a little later in the section "Redirecting the Users and Computers Containers to OUs").

Table 3.1. The Predefined Containers in Active Directory

Container

OU

Purpose

Possible Contents

Builtin

No

This is a container for the predefined built-in local security groups (you cannot create them yourself).

Computer, group, user, inetOrgPerson

Computers

No

This is a default container for computer objects corresponding to Windows NT/2000/XP workstations and member servers in this
domain.

Computer, contact, group, printer, user, inetOrgPerson, shared folder

Domain Controllers

Yes

This is a default container for computer objects corresponding to domain controllers of this domain.

This is a container for placeholders that represent group members from domains external to the forest. This includes well-known
security principals, such as Authenticated Users, if they are members of some group in the domain.
[*]
Objects in this container are visible only when the snap-in's Advanced Features are turned on.

Computer, contact group, printer, user, inetOrgPerson, shared folder

Users

No

This is a default container for users and groups.

Computer, contact, group, printer, user, inetOrgPerson, shared folder

In Table 3.1, the Possible Contents column lists the object types (that is, classes) that you can create in the corresponding container
using the Users and Computers snap-in. With an "under-the-hood" tool, such as ADSI Edit, you could create other types of objects. However, there is no need to use the predefined containers for anything but
what is described in the table.

You shouldn't use the Builtin container for anything, even though it is possible to create computers, groups, and users in
it. Likewise, you could create users in the Computers container or computers in the Users container, but there is no point in doing so. Putting
such things together is comparable to placing your cookbooks and music CDs on the same shelf. It is possible, but why do it?

If you want, you can keep your users in the Users container and computers in the Computers container. If you do so, however,
you can neither create OUs in them nor assign Group Policy for them, because these containers are not OUs. If you have more
than 20 users, for example, and you want to delegate some administration, you will probably end up creating new OUs for your
users and computers (i.e., outside the Users or Computers containers). We will come back to this issue in the "Administering OUs" section later in this chapter.

The Domain Controllers container is an OU, and therefore you can create OUs in it and assign Group Policy(ies) for it. This OU already has a Default Domain Controllers Policy Group Policy object (GPO) assigned, which affects the security and other settings of your domain controllers. You are likely to keep the computer
objects for your domain controllers in this container and other OUs that you create below it.

Why These Containers?

It may seem that the way these predefined containers were chosen is odd. Why are most of them not OUs? Some explanation is
given by the fact that these containers ease the upgrade from Windows NT to Active Directory. During the upgrade process,
the old user accounts and groups are migrated to the Users container, old workstation and member server accounts are migrated
to the Computers container, and old domain controller accounts are migrated to the Domain Controllers container.

In addition to migration, the default Users and Computers containers are also used whenever users, groups, and computers are
created using downlevel tools. Such tools are Windows NT User Manager and Server Manager, Net commands (Net User, Net Group,
Net Localgroup, Net Computer), Windows Support Tools NetDom Add command without the /OU switch, and any tool that uses the old Windows NT APIs to create these objects. Also, when a Windows NT/2000/XP workstation
joins a domain and there is no precreated computer account, the account will be created in the default Computers container.

In Windows NT, built-in local groups were internally stored separately from other groups, users, and computer accounts. This
separation was brought over to Active Directory in the form of the Builtin container.

So why are these three containers not OUs? One explanation could be that this way you are intentionally discouraged from using
them in the long run and you must create new OUs instead.

Redirecting the Users and Computers Containers to OUs

If your domain is on the Windows Server 2003 functional level, you can redirect the predefined Users container and the Computers
container to OUs you have created. After the redirection, these new OUs will be the default containers for users, groups,
and computers. For example, you can create the Employees OU and the Workstations OU, and then perform the redirection using the following commands:

During the redirection, the system-flags protection is moved from the old default containers to the new ones. Therefore, you
could rename or delete the old containers.

The predefined Users container and Computers container don't allow you to apply group policies to them, but if you perform
the redirection to a normal OU, you can apply group policies. On the other hand, if your users and computers are already in normal OUs and you don't use
any tools that would create new users or computers in the default containers, there is not much advantage in the redirection.

Predefined Users

Two user objects are always present: Administrator and Guest. You cannot delete either of them, but you can rename them at
will. Renaming Administrator offers some extra protection because a potential network intruder would need to guess the new
name in addition to the password. However, if you have a large network and many administrative personnel, it may be confusing
for the Administrator account to have a different name.

The default permissions of Active Directory allow any user of the forest to see the names of administrative accounts, so renaming
them is really minimal "protection." You can think of it as adding a small extra hurdle in a potential intruder's path. If
you chose permissions compatible with preWindows 2000 servers, anonymous users can also see this information.

Table 3.2. The Predefined User Accounts in Active Directory

Name

Present

Description

Administrator

Always (although could be renamed); cannot be disabled in AD2000 but can be disabled in AD2003

The only user account you can use when you log on for the first time. The Administrator account of the first domain in a forest
has the widest possible administrative permissions on Active Directory and the domain controllers in the same forest. You
can create other user accounts with permissions as wide. The Administrator accounts of the later domains in a forest have
the widest possible administrative permissions for their own domains.

Guest

Always (although could be renamed); disabled by default

If someone doesn't have a user account, he can use the Guest account (if the account is enabled). (See the discussion in the
text.)

Always; disabled by default; hidden by default; cannot be enabled or renamed

The Kerberos key distribution center (KDC) uses this account. "Krbtgt" is part of the KDC's service principal name (SPN). Also, a symmetric key is derived from the password of krbtgt, and this key is used to encrypt and decrypt TGTs. Only the
KDC knows this password and it changes the password periodically.

TsInternetUser

For Windows 2000 Terminal Services

When an optional Internet Connector license is enabled, Terminal Services clients are not prompted with a logon dialog box.
Instead, they are logged on automatically with the TsInternetUser account.

If you enable the Guest account, be careful about the permissions you give to it or the Everyone group (and in AD2000 also
to the Domain Users or Users groups). After all, anyone who "walks in the door" can use the Guest account. There are two ways
to use the Guest account.

If your workstation is a member of a domain of the forest where the Guest account is enabled (in some of its domains), you
just type "guest" in the logon dialog box, select the correct domain, and start using the workstation and the network.

If your workstation is in a workgroup or in a different forest from the one in which the Guest account is enabled (in some
of its domains), you first need to log on with some other user account. When you connect to the resources of the domain where
the Guest account is enabled, you are granted access based on that Guest account's permissions. You never type "guest" anywhereyou
just use "Jack," for example. When the server doesn't recognize "Jack," it switches to use "Guest" automatically. The catch
is that if there is another Jack, who most likely uses a different password, you are denied access. The server just thinks
that someone is trying to crack Jack's account and doesn't use Guest at all.

Predefined Groups

Active Directory includes predefined security groups. Some of them reside in the Builtin container and the rest reside in
the Users container, as follows:

Builtin:
Built-in local security groups

Users:
Mostly global security groups

The primary purpose of most of these predefined groups is to be the means by which administrative rights and permissions are
assigned. To be anything more than an end user in the network, a user needs one or more of the following types of permission
or rights:

User rights, such as permission to change the system time or log on locally. These rights are controlled with Group Policy
settings and/or local policy settings. There are also some fixed rights. For example, only members of the Administrators group
can format hard drives, and you cannot give this right to anyone else.

Administrative permissions (i.e., the ability to create, delete, change, and so on) for Active Directory objects.

Administrative permissions for registry keys.

Administrative permissions for folders and files.

Administrative permissions for other resources (printers, for example).

Most of the predefined groups have specific administrative rights or permissions associated with them, so you can give some
users the appropriate rights and permissions by adding their names to the corresponding groups. Instead of worrying about
all of the items in the list individually, it is far easier to just put Jack in the Account Operators group and Jill in the
DNS Admins group, for example. They will get suitable permissions in one package.

Sticking just to "predefined" doesn't get you through life, thoughat least not with Active Directory. You often need to assign
individual rights and permissions, probably not using the predefined groups. But that's another story for another chapter
(Chapter 4, to be exact).

Figure 3.2 shows the relationship among the groups in the Builtin and Users containers in an Active Directory domain. It also shows
the corresponding relationships that existed in Windows NT.

Figure 3.2 In Windows NT, the only meaning of predefined global groups (Domain Admins, Domain Users, and Domain Guests) was that they
were members of some built-in local groups, which in turn had rights to administer the system. This is true also for Active
Directory, but in addition both group categories have certain direct permissions to Active Directory objects.

In addition to the permissions and rights shown in Figure 3.2, built-in local (security) groups have permissions for system files and registry keys.

In Windows NT it was easy to make a user of another domain an administrator in a local domain. It only required making him
a member of the Administrators group in the local domain. Because of the difference in how global groups get permissions,
as illustrated in Figure 3.2, this is more difficult in Active Directory. If you make the foreign user a member of Administrators in Active Directory,
he won't get the permissions of Domain Admins, so he will be only a partial administrator. You cannot make him a member of
Domain Admins, because that group accepts members only from the same domain. Note that this note only applies to the administrative privileges for the domain account database and domain controllers. It doesn't apply to the administrative
privileges for any member servers or workstations.

Predefined Built-in Local Security Groups

Table 3.3 describes the predefined groups in the Builtin container. You cannot delete, rename, or move any of them, because of their
system-flags protection. Note that each group in the table is always present in all domains. They have rights and/or permissions
to their local domain only, and those rights/permissions apply only on the domain controllers. For example, the Remote Desktop
Users group members can use the remote desktop of the domain controllers of the domain in question.

Table 3.3. The Predefined Built-in Local Security Groups

By default, members of this group have almost total control of the domain controllers of the domain, including formatting
hard drives and all the rights that the following four "operators" have. For Active Directory, this group has by default "Full
Control except Delete Subtree or Delete All Child Objects" permission for almost all objects in the domain.

Account Operators

None

By default, members of this group can create, delete, and manage user, inetOrgPerson, group, and computer objects in the Active
Directory domain, except in the Domain Controllers OU. Account operators can log on locally to domain controllers of the domain and shut them down. In Windows 2000, Account Operators
can modify their own account and the accounts of other account operators. However, they cannot modify administrator accounts.
Starting with Windows 2000 SP4 and Windows Server 2003, Account Operators cannot modify account operators. For more information,
see the "AdminSDHolder Object" section in Chapter 4.

Server Operators

None

In the domain controllers of the domain, members of this group can create, delete, and manage file shares and printers, and
start, stop, and configure services. Also in the domain controllers, they can log on locally, back up and restore files, change
computer time, and shut down the domain controller either locally or remotely. Note that the list here is descriptive, but
not quite exhaustive.

Backup Operators

None

By default, members of this group can back up and restore files and folders in the domain controllers of the domain, even
if the member user doesn't have permissions for those files and folders. They can also log on locally on the domain controllers
of the domain and shut the domain controllers down.

Print Operators

None

Members of this group can create, delete, manage, and share printers in the domain controllers of the domain, and by default
they can create, delete, and manage printer objects in the Active Directory domain. They can also log on locally on the domain
controllers of the domain and shut the domain controllers down.

Users

Domain Users, Authenticated Users, Interactive

By default, this group has no user rights or permissions. You can just ignore this group.
[**]
If you want to give permissions to all forest users, you can use Authenticated Users. You can also create groups such as
SanaoUsers or SanaoBostonUsers and use them instead of the predefined Users group.

Guests

Guest, Domain Guests, IUSR-_servername, IWAM_servername (in AD2000)

By default, this group has no rights or permissions. You can just ignore this group.

Pre-Windows 2000 Compatible Access

Everyone
[***]
and Anonymous Logon, if you selected "Permissions compatible with pre-Windows 2000 server operating systems" when you installed
the domain; otherwise, Authenticated Users (the latter is the default)

By default, this group has permission to see all the objects in a domain and all the properties of all users, inetOrgPersons,
and groups. Everyone/Anonymous need these permissions if you have certain server services (e.g., Remote Access Service) running
on Windows NT servers in your Active Directory domain.

Replicator

None

Windows NT servers and workstations use this group for the Directory Replicator service.

Remote Desktop Users

None

Members of this group are allowed to use the Remote Desktop connection.

Network Configuration Operators

None

Members of this group can modify the local TCP/IP settings and some other network settings of the domain control lers. For
a complete list, see Microsoft Knowledge Base article 297938.

Performance Monitor Users

None

Members of this group can use the Performance console, or perform similar monitoring with another tool.

Performance Log Users

Network Service

Members of this group can use the Performance Logs and Alerts console, or perform similar monitoring with another tool.

Incoming Forest Trust Builders

None

This group appears only in the forest root domain. The members can create incoming, one-way trusts to the forest.

Windows Authorization Access Group

Enterprise Domain Controllers

Members of this group can read the constructed tokenGroupsGlobalAndUniversal (TGGAU) attribute on user, inetOrgPerson, group, and computer objects. TGGAU contains a list of the object's global and universal group memberships, and an application can use this information, for
example, to make decisions about users that are not logged on. The Pre-Windows 2000 Compatible Access group can also read
TGGAU, but if the application is not in that group, you could use the Windows Authorization Access Group instead. For more information,
see Microsoft Knowledge Base article 331951.

Terminal Server License Servers

None

This group is used for Terminal Server licensing.

In the next chapter, we describe in more detail the default user rights and default Active Directory permissions of the groups
in Table 3.3.

Predefined Groups in the Users Container

The remaining predefined groups are in the Users container. They are mostly global security groups, but there are also some
domain local security groups. Table 3.4 describes the predefined groups in the Users container of a domain.

Table 3.4. The Predefined Groups in the Users Container

Name

Predefined Members

Description

Enterprise Admins

Administrator of the first domain of the forest

Members of this group can administer all the domains in the enterprise. By default, this group is a member of Administrators
in all domains of the forest. Enterprise Admins has Full Control to practically all objects in all domains of the forest.
In addition, membership in this group is necessary to create child domains or sites. This group appears only in the first
domain of the forest (that is, the forest root domain.)

Schema Admins

Administrator of the first domain of the forest

Members of this group can modify the schema of the forest. This group appears only in the first domain of the forest (that
is, the forest root domain.)

Domain Admins

Administrator

Members of this group can administer this domain. By default, this group is a member of Administrators in this domain and
all joined workstations/member servers. Domain Admins has Full Control to most objects of the domain.

Group Policy Creator Owners

Administrator

Members of this group can create Group Policy objects if they also have appropriate permissions for the OU for which they are creating the GPO. In addition, they can manage the GPOs they have created.

Domain Users

Every user account of the same domain

By default, this group has no rights or permissions. You can use it if you need to give permissions to all users of the domain.

Domain Guests

Guest

By default, this group has no rights or permissions. You probably don't need this group.

Domain Controllers

Each domain controller of the same domain

By default, this group has no rights or permissions. You can use it if you need to give permissions to all domain controllers
of the domain.

Domain Computers

Each workstation and member server of the same domain

By default, this group has no rights or permissions. You can use it if you need to give permissions to all workstations and
member servers of the domain.

Cert Publishers

Each computer that is running an enterprise certificate authority

By default, this group has permission to read and write the userCertificate property of the users and computers in the domain. Therefore, members of this group can publish certificates for users and
computers.

DnsUpdate Proxy

None

DHCP servers may dynamically register DNS resource records on behalf of DHCP clients. In this case, the DHCP servers become the owners of those records. This is a problem if the client or some other DHCP server later wants to start maintaining those records. By placing the computer objects of the DHCP servers as members in this group, the servers won't become record owners, so the problem described here is resolved. This
group is missing if there is no DNS service in the domain.

IIS_WPG

None

The IIS_WPG group (worker process group) appears with Internet Information Services (IIS) 6.0, and it is used for the needs of IIS.

DnsAdmins

None

Members of this group can administer the DNS service. This group is missing if there is no DNS service in the domain.

RAS and IAS Servers

Each computer that is running the Routing and Remote Access Services (RRAS)

By default, this group has permission to read Logon Information, Remote Access Information, Group Membership, and Account
Restrictions of all users of the domain. RRAS servers need those permissions.

When you install the first domain of the forest, Enterprise Admins and Schema Admins are global groups. When you later change
this domain to the Windows 2000 native or Windows Server 2003 functional level (as discussed in Chapter 2), those groups will change to universal groups, which allows them to have members from other domains.

By default, Domain Admins is a member of the Administrators group of all workstations and member servers. Similarly, Domain
Users is a member of the Users group of those computers.

Figure 3.3 illustrates the memberships of some predefined users, global groups, and built-in local groups that are listed in Tables 3.2 through 3.4.

Figure 3.3 The predefined users and groups have several predefined memberships. In addition, any new user is a member of Domain Users.

In Chapter 4, we discuss the well-known security principals. Many of them are like groups, and you can assign permissions to them. They
are not real groups, however, because the operating system, not a network administrator, controls their "membership."

Well-known security principals include Authenticated Users and Everyone, which you already saw as group members in Table 3.3 and Table 3.4. Therefore, we have included Figure 3.4 to illustrate those memberships here, even though the remaining discussion is in the next chapter.

Figure 3.4 The well-known security principals Authenticated Users, Everyone, and Anonymous Logon can be seen as part of the membership
hierarchy. However, their "membership" is controlled by the operating system, not by a network administrator.

In AD2000, Anonymous Logon is a "member" of Everyone. In AD2003, the security was tightened, and the "membership" is true
only if you enable the security policy "Network access: Let Everyone permissions apply to anonymous users." This policy is
located in Computer Configuration, Windows Settings, Security Settings, Local Policies, Security Options. See Chapter 7 for more information on policies.

Figure 3.4 reveals the memberships for the various end-user groups. Table 3.5 lists the end users (users of the group's domain, users of the whole forest, and so on) that are members of each user group.

Table 3.5. End-User Memberships

Group

Type

All Users in Group's Domain

All Forest Users

Guest

Anonymous

Everyone

Well-known

X

X

X

(see the Note)

Users

Built-in local

X

X

only in AD2000

Authenticated Users

Well-known

X

X

Domain Users

Global

X

only in AD2000

Typically, an administrator uses Authenticated Users to assign permissions to all users of a forest and Domain Users to assign
permissions only to the users of one domain.

Predefined Computer Objects

In the beginning, there is just one computer object. It is for your first (and at that point, only) domain controller in the
Domain Controllers container.