Understanding Workgroups, Domains, and Trusts
In a workgroup, each system maintains an identity store of user and group accounts against which
users can be authenticated and access can begin. The local identity
store on each computer is called the Security Accounts
Manager (SAM) database. If a user logs on to a workgroup
computer, the system authenticates the user against its local SAM
database. If a user connects to another system, to access a file, for
example, the user is re-authenticated against the identity store of
the remote system. From a security perspective, a workgroup computer
is, for all intents and purposes, a stand-alone system.
When a computer joins a domain, it delegates the task of
authenticating users to the domain. Although the computer continues to
maintain its SAM database to support local user and group accounts,
user accounts are typically created in the central domain directory.
When a user logs on to the computer with a domain account, the user is
now authenticated by a domain controller rather than by the SAM. Said
another way, the computer now trusts another
authority to validate a user’s identity. Trust relationships are
generally discussed in the context of two domains, but there is also a trust between each domain member
computer and its domain that is established when the computer joins
the domain.
Identifying Requirements for Joining a Computer to the
Domain
To join a computer to an Active Directory domain, the following
three requirements must be met:
-
A computer object must be created in the directory
service.
-
You must have appropriate permissions to the computer
object. The permissions allow you to join a computer with the same
name as the object to the domain.
-
You must be a member of the local Administrators group on
the computer to change its domain or workgroup membership.
The next sections examine each of these requirements.
The Computers Container and OUs
Before you create a computer object in the directory service—the
first of the three requirements for joining a computer to the domain—you must have a place
to put it.
The Default Computers Container
When you create a domain, the Computers container is created
by default
(CN=Computers,dc=company,dc=com).
This container is not an organizational unit (OU); it is an object
of class container. There are subtle but
important differences between a container and an OU: You cannot
create an OU within a container, so you cannot subdivide the
Computers OU; and you cannot link a Group Policy object to a
container. Therefore, it is highly recommended that you create
custom OUs to host computer objects instead of using the Computers
container.
Most organizations create at least two OUs for computer
objects: one to host computer accounts for client computers—desktops,
laptops, and other user systems—and another for servers. These two
OUs are in addition to the Domain Controllers OU created by default
during the installation of Active Directory. In each of these OUs,
computer objects are created. There is no technical difference
between a computer object in a clients OU and a computer object in a
servers or domain controllers OU; computer objects are computer
objects. But separate OUs are typically created to provide unique
scopes of management so that you can delegate management of client
objects to one team and management of server objects to
another.
Your administrative model might necessitate further dividing
your client and server OUs. Many organizations create sub-OUs
beneath a server OU to collect and manage specific types of
servers—for example, an OU for file and print servers and an OU for
database servers. By doing so, the team of administrators for each
type of server can be delegated permissions to manage computer
objects in the appropriate OU. Similarly, geographically distributed
organizations with local desktop support teams often divide a parent
OU for clients into sub-OUs for each site. This approach allows each
site’s support team to create computer objects in the site for client computers and join computers to the domain using those computer objects.
This is an example only: What is most important is that your OU
structure reflect your administrative model so that your OUs provide
single points of management for the delegation of
administration.
Figure 1
illustrates a typical OU design for an organization whose server
administration teams are focused on specific types of servers and
whose desktop support teams are focused on clients in specific
geographical areas.
Additionally, separate OUs allow you to create different
baseline configurations, using different Group Policy objects (GPOs)
linked to the client and the server OUs. Group Policy, lets you
specify configuration for collections of computers by linking GPOs
that contain configuration instructions to OUs. Organizations
commonly separate clients into desktop and laptop OUs. GPOs
specifying desktop or laptop configuration can then be linked to
appropriate OUs.
If your organization has decentralized, site-based
administration and wants to manage unique configurations for
desktops and laptops, you face a design dilemma. Should you divide
your clients OU based on administration and then subdivide desktops
and laptops, or should you divide your clients OU into desktop and
laptop OUs and then subdivide based on administration? The options
are illustrated in Figure 2.
Because the primary design driver for Active Directory OUs is
the efficient delegation of administration through the inheritance
of access control lists (ACLs) on OUs, the design on the left is
recommended.
Delegating Permission to Create Computers
By default, the Enterprise Admins, Domain Admins,
Administrators, and Account Operators groups have permission to
create computer objects in any new OU. However, it is recommended
that you tightly restrict membership in the first three groups and
that you do not add administrators to the Account Operators group.
Instead, you should delegate the permission to create computer objects to appropriate administrators or
support personnel. The permission required to create a computer object is Create Computer Objects. This
permission, assigned to a group for an OU, allows members of the group
to create computer objects in that OU. For example, you might allow
your desktop support team to create computer objects in the clients OU
and allow your file server administrators to create computer objects
in the file servers OU.
Note
PRACTICE IT
At the end of this lesson, Exercise 3, “Delegate the Ability
to Create Computer Objects,” steps you through the procedure
required to delegate the creation of computer objects.
Prestaging a Computer Account
You can and should create a computer account in the correct OU
before joining the computer to the domain. This process of
pre-creating a computer account is called
prestaging a computer.
After you have been given permission to create computer objects,
you can do so by right-clicking the OU and choosing Computer from the
New menu. The New Object – Computer dialog box, shown in Figure 3, appears.
Enter the computer name, following the naming convention of your
enterprise, and select the user or group that will be allowed to join
the computer to the domain with this account. The two computer
names—Computer Name and Computer Name (Pre–Windows 2000)—should be the
same: There is rarely, if ever, a justification for configuring them
separately.
Note
THE NEW OBJECT – COMPUTER WIZARD
OVER-DELEGATES
The permissions applied to the user or group you select in the
New Object – Computer Wizard are more than are necessary simply to
join a computer to the domain. The selected user or group is also
given the ability to modify the computer object in other ways. For
guidance regarding a least-privilege approach to delegating
permission to join a computer to the domain, see Windows
Administration Resource Kit: Productivity Solutions for IT
Professionals by Dan Holme (Microsoft Press,
2008).
Prestaging a computer offers two major
advantages:
-
The account is in the correct OU and is therefore delegated
according to the security policy defined by the ACL of the
OU.
-
The computer is within the scope of GPOs linked to the OU,
before the computer joins the domain.
