Joining a Computer to the Domain
By prestaging the computer object, you fulfill the first two
requirements for joining a computer to a domain: the computer object
exists, and you have specified who has permissions to join a computer
with the given name to the domain. Now, a local administrator of the
computer can change the computer’s domain membership and
enter the specified domain credentials to successfully complete the
process.
To join a computer to the domain, follow these steps:
-
Log on to the computer with credentials that belong to the
local Administrators group on the computer.
Only local administrators can alter the domain or workgroup
membership of a computer. -
Open the System Properties dialog box using one of the
following methods:
On earlier versions of Windows (Windows XP or Windows Server
2003), open the System properties dialog box by doing one of the
following:
On newer versions of Windows (Windows Vista, Windows 7,
Windows Server 2008, or Windows Server 2008 R2), perform the
following steps:
-
Open the System properties dialog box. You can
right-click Computer, and then click Properties, or press
Windows Logo+Pause. -
In the Computer Name, Domain, And Workgroup Settings
section, click Change Settings. -
If prompted by User Account Control, click Continue or
enter administrative credentials as appropriate.
-
On the Computer Name tab, click Change. -
Under Member Of, select Domain. -
Type the name of the domain you want to join and click
OK.
Note
USE THE FULL DNS NAME OF THE
DOMAIN
Use the full DNS name of the Active Directory domain. Not
only is this more accurate and more likely to succeed, but if it
does not succeed, it indicates that there could be a problem
with DNS name resolution that should be rectified before
joining the computer to the domain.
-
Windows prompts for the credentials of your user account in
the domain.
The domain checks to see whether a computer object already
exists with the name of the computer. One of the following three
things happens:
-
If the object exists and a computer with that name has
already joined the domain, an error is returned, and you
cannot join the computer to the domain. -
If the object exists and it is prestaged—a computer with
the same name has not joined the domain—the domain confirms
that the domain credentials you entered have permission to
join the domain using that account.
-
If the computer account is not prestaged, Windows
verifies whether you have permissions to create a new computer
object in the default computer container. If you do have
permissions, the object is created with the name of the
computer. This method of joining a domain is supported for backward
compatibility but is not recommended.
The computer then joins the domain by assuming the identity
of its Active Directory object. It configures its SID to match the
domain computer account’s SID and sets an initial password with
the domain. The computer then performs other tasks related to
joining the domain. It adds the Domain Admins group to the local
Administrators group and the Domain Users group to the local Users group. -
You are prompted to restart the computer. Click OK to close
this message. -
Click Close (in newer versions of Windows) or OK (in earlier
versions of Windows) to close the System Properties dialog
box. -
You are prompted, again, to restart the computer, after
which the system is fully a member of the domain and you can log
on using domain credentials.
The Netdom.exe command allows you to join a computer to the
domain in Command Prompt. The basic syntax of the command is:
netdom join MachineName /Domain:DomainName [/OU:"DN of OU"]
[/UserO:LocalUsername] [/PasswordO:{LocalPassword|*} ]
[/UserD:DomainUsername] [/PasswordD:{DomainPassword|*} ]
[/SecurePasswordPrompt] [/REBoot[:TimeInSeconds]]
It can be useful to join a computer to a domain from the Command
Prompt. The first reason this is useful is because the join can be
included in a script that performs other actions. For example, you
could create a batch file that creates the computer account using
NetDom or DSAdd—the latter of which allows you to specify other
attributes, including description—and then joins the machine to that
account using NetDom. Second, NetDom can be used to remotely join a
computer to the domain. Third, NetDom lets you specify the OU for the
computer object. The command’s parameters are, for the most part,
self-explanatory. UserO and
PasswordO are credentials that are members of the
workgroup computer’s local Administrators group. Specifying
* for the password causes NetDom to prompt for
the password at the command prompt. UserD and
PasswordD are domain credentials with permission
to create a computer object, if the account is not prestaged, or with
permission to join a computer to a prestaged account. The
REBoot parameter causes the system to reboot
after joining the domain. The default timeout is 30 seconds. The
SecurePasswordPrompt parameter displays a popup
for credentials when * is specified for either
PasswordO or
PasswordD.
Note
USING NETDOM REMOTELY REQUIRES FIREWALL
CONFIGURATION
If you want to use NetDom remotely, the Windows Firewall
configuration on the computer that will be joined to the domain must
allow Network Discovery and Remote Administration.
Secure Computer Creation and Joins
It is important to secure your enterprise so that only
appropriate users can create computer accounts and join computers to
the domain. The following sections outline best practices for managing
computer account creation and domain joins.
Prestaging Computer Objects
The best practice is to prestage a computer account prior to
joining the computer to the domain. Unfortunately, Windows allows
you to join a computer to a domain without following best practices.
You can log on to a workgroup computer as a local administrator and
change the computer’s membership to the domain. Then, on demand,
Windows creates a computer object in the default computer container, gives you permission to join a
computer to that object, and then proceeds to join the system to the
domain.
There are three problems with this behavior of Windows:
-
First, the computer account created automatically by
Windows is placed in the default computer container, which is not where the
computer object belongs in most enterprises. -
Second, you must move the computer from the default
computer container into the correct OU, which is an extra step
that is often forgotten. -
Third, any user can do this—no domain-level administrative
permissions are required. Any user can join any computer to the
domain if you don’t manage and secure the process. Because a
computer object is a security principal, and because the creator
of a computer object owns the object and can change its
attributes, this exposes a potential security vulnerability. The
next sections detail these disadvantages.
Configuring the Default Computer Container
When you join a computer to the domain and the computer object
does not already exist in Active Directory, Windows automatically
creates a computer account in the default computer container, which
is called Computers
(CN=Computers,DC=domain, by default). The
problem with this relates to the discussion of OU design earlier in
the lesson. If you have implemented the best practices described
there, you have delegated permissions to administer computer objects
in specific OUs for clients and servers. Additionally, you might
have linked GPOs to those OUs to manage the configuration of these
computer objects. If a new computer object is created outside of
those OUs, in the default computer container, the permissions and
configuration it inherits from its parent container will be
different than what it should have received. You will then need to
remember to move the computer from the default container to the
correct OU after joining the domain.
Two recommended steps reduce the likelihood of this problem.
First, you should endeavor to always prestage computer accounts. If
an account is prestaged for a computer in the correct OU, the
computer will use the existing account when it joins the domain and
will be subject to the correct delegation and configuration.
Second, to reduce the impact of systems being joined to the
domain without a prestaged account, you should change the default computer container so that it is not the Computers
container itself but, instead, an OU that is subject to appropriate
delegation and configuration. For example, if you have an OU called
Clients, you can instruct Windows to use that OU as the default
computer container, so that if computers are joined to
the domain without prestaged accounts, the objects are created in
the Clients OU.
The Redircmp.exe command, available on domain controllers,
is used to redirect the default computer container with the following
syntax:
redircmp "DN of OU for new computer objects"
Now, if a computer joins the domain without a prestaged
computer account, Windows creates the computer object
in the specified organizational unit.
Tip
EXAM TIP
The Redircmp.exe command redirects the default computer
container to a specified OU. Redirusr.exe does the same for the
default user container. You might see these two commands used as
distracters—presented as potential (but
incorrect) answers to questions that have nothing to do with the
default computer or user containers. As you look at any exam
question, evaluate the possible answers to determine whether the
answers are proposing to use real commands but in the wrong
application of those commands.
Restricting the Ability of Users to Create Computers
When a computer account is prestaged, the permissions on the
account determine who is allowed to join that computer to the
domain. When an account is not prestaged, Windows will, by default,
allow any authenticated user to create a computer object in the
default computer container. In fact, Windows will allow any
authenticated user to create 10 computer objects in the default
computer container. The creator of a computer object, by default,
has permission to join that computer to the domain. It is through
this mechanism that any authenticated user can join 10 computers to
the domain without any explicit permissions to do so.
The 10-computer quota is configured by the
ms-DS-MachineAccountQuota attribute of the
domain. It allows any authenticated user to join a computer to the domain, no questions asked. This is
problematic from a security perspective because computers are
security principals. And the creator of a security principal has
permission to manage that computer’s properties. In a way, the quota
is like allowing any domain user to create 10 user accounts, without any controls.
It is highly recommended that you close this loophole so that
non-administrative users cannot join computers to the domain. To
change the ms-DS-MachineAccountQuota attribute,
follow these steps:
-
Open ADSI Edit from the Administrative Tools
folder. -
Right-click ADSI Edit and click Connect To. -
In the Connection Point section, click Select A Well Known
Naming Context, and then select Default Naming Context from the
drop-down list. -
Click OK. -
In the console tree, expand Default Naming Context. -
Right-click the domain folder—“dc=contoso,dc=com”, for
example—and then choose Properties. -
Select ms-DS-MachineAccountQuota and click Edit. -
Type 0 and click OK.
The Authenticated Users group also is assigned the user
right to add workstations to the domain, but you do not have to
modify this right if you have changed the default value of the
ms-DS-MachineAccountQuota attribute.
After you have changed the
ms-DS-MachineAccountQuota attribute to 0, you
can be assured that the only users who can join computers to the
domain are those who have been specifically delegated permission to
join prestaged computer objects or create new computer
objects.
After you’ve eliminated this loophole, you must make sure you
have given appropriate administrators explicit permission to create
computer objects in the correct OUs; otherwise, the error message shown in Figure 4 will
appear.
|
