- Active Directory after Installation
- Administering OUs
- Administering Users, InetOrgPersons, and Contacts
- Administering Computer Objects
- Administering Groups
- Tips on Tools
- Conclusion
This chapter is from the book
This chapter is from the book
This chapter is from the book
Administering Computer Objects
Just as Active Directory has a user object for each network user, it has a computer object for each computer in the domain. However, this applies "only" to Windows Server 2003, Windows XP, Windows 2000, and Windows NT computers. Other workstations (e.g., Windows 95 and 98 and non-Microsoft operating systems) that are not using the NT-based integrated security cannot have a computer object.
NDS allows a broader range of workstation types than does Active Directory, which means that you can manage more types of workstations with the help of the directory service.
Also, computer objects are used only for computers that join a domain. If a stand-alone server or workstation will be in a workgroup instead of a domain, it will not be assigned a computer object in Active Directory.
You could categorize computer object properties as either significant or informational, just as we did with user objects. However, the distinction among computer objects is not as clear as it is among user objects, so we don't use these terms with computer objects in this book (short of a couple of exceptions).
The purposes of computer objects are as follows:
-
As inherited from the very first version of Windows NT back in 1993, a computer account ties the workstation or server to the Windows NT/2000/XP/Server 2003 security model.
-
A computer object is a placeholder for properties that help you when you are remotely installing and managing workstations.
-
A computer object is a placeholder for properties that are purely informational.
-
A computer object is a security principal. This means that just as with a user, you can give permissions for resources and assign security group memberships to the computer.
-
The location of a computer object in Active Directory dictates which group policies apply to the corresponding computer.
Computer objects are treated slightly differently, depending on whether they are for domain controllers or for workstations and member servers. Table 3.14 compares the two.
Table 3.14. Comparing Domain Controllers and Other Computer Objects
|
Feature |
Domain Controller |
Workstation and Member Server |
|---|---|---|
|
Creation of the object |
Automatically while installing Active Directory on the server (using DCPromo). |
|
|
Default container of the object |
Domain Controllers. |
Computers. |
|
Use of the default location |
Probably yes. |
Probably not (place the computer objects in OUs instead). |
|
Computer GUID |
You cannot set this property. |
You may set this property, which helps when using Remote Installation Services and signifies a managed computer. |
When you start to manage computer objects, your tasks will include the following:
-
Create computer objects.
-
Set computer object properties.
-
Move, rename, disable, reset, and delete computer objects.
-
Assign Group Policy and permissions, and delegate administrative tasks.
In this chapter, we focus on the first three items in the list. The last item is discussed in later chapters. If you want to try the management tasks discussed in this section, you can create some test computer objects in your test OU. To test all the features, however, you will need some test workstations.
Creating Computer Objects
As Table 3.14 in the previous section implies, computer objects are created in three ways.
-
A computer object for a domain controller is created automatically in the Domain Controllers OU when you install Active Directory on that server by running the Active Directory Installation Wizard (i.e., DCPromo).
-
When you join a stand-alone server or workstation to a domain, either during computer installation or afterward, you have the option to create the computer object. An object created in this way goes to the Computers container.
-
You precreate the computer object manually using one of the four ways listed in Table 3.14. The Users and Computers snap-in way—the graphical choice—is explained next. The DSAdd Computer command is introduced at the end of this chapter.
The second and third items in the list require appropriate permissions or user rights, which are explained in Chapter 4. In short, any forest user can by default join ten workstations to a domain.
You can store the computer objects either in the Computers container or in various OUs in the domain. The latter option allows different OU-based group policies for different computers.
When you right-click the appropriate target OU and select New, Computer, you will launch a three-page or four-page creation wizard, the first page of which you see in Figure 3.18. Here you specify the name for the object, the downlevel name for the computer, and the user or group who can later join the computer to the domain. If the joining computer is running Windows NT, you must select the "pre-Windows 2000" check box. If the joining computer will be a Windows NT backup domain controller, you must select the "backup domain controller" check box.
)
Figure 3.18 When you create a computer object, on the first page of the creation wizard you are prompted to specify the name for the object,
the downlevel name for the computer, and the user or group who can later join the computer to the domain.
Figure 3.19 shows the second page of the creation wizard. If you use Windows 2000, the pages beyond the first one will appear only if you have installed Remote Installation Services (RIS) to install Windows 2000 Professional computers.
)
Figure 3.19 On the second page of the creation wizard you can specify that this is a "managed computer" (to indicate that you will use
Remote Installation Services, or RIS, "prestaging" for this computer) and enter the computer's GUID.
Whether you get the additional wizard pages in Windows 2000 or not depends on which computer you are sitting at. For example, if there are two domain controllers in your domain (DC1 and DC2) and you have installed RIS on DC2, you will see the two additional pages if you are sitting at DC2 or any workstation. However, if you are sitting at DC1, you won't see the pages.
Computer manufacturers assign a unique GUID to each computer they sell. If you enter this GUID into Active Directory, it will help RIS to match a certain computer system to a certain computer object.
After you have bought a computer and turned it on for the first time to install Windows 2000 or Windows XP onto it, the RIS service sends the computer's GUID to a RIS server. This way, RIS can locate the correct computer object in Active Directory.
If you selected the "This is a managed computer" option on the wizard's second page, you will see a third page, which is shown in Figure 3.20. The last page displays the summary of your selections, and we don't show this screen.
)
Figure 3.20 If you selected the "This is a managed computer" option in the creation wizard's second page (Figure 3.19), you will see a
third page that enables you to specify a certain remote installation server. You can use this for load balancing, so that
certain client computers (identified by the GUID) install Windows 2000 or Windows XP from a certain server.
The computer GUID shown in Figure 3.19 is not the same as the GUID that each Active Directory object has. Chapter 8 offers more in-depth treatment of object GUIDs.
You cannot specify the computer GUID or RIS server name for an existing computer object using the Users and Computers snap-in if you didn't specify "managed computer" when you first created the object. To edit properties directly, you need to use ADSI Edit or some other means. The aforementioned information is stored in the properties netbootGUID and netbootMachineFilePath.
A computer object has several names, which are listed in Table 3.15.
Table 3.15. Name Properties of a Computer Object
|
Property |
LDAP Name |
Maximum Length |
Required |
Unique |
Comments |
|---|---|---|---|---|---|
|
Computer name |
name (RDN) and cn (Common-Name) |
64 |
X |
Within OU |
This becomes the object common name in the tree. |
|
DNS name |
dNSHostName |
2048 |
In the world |
The target computer updates this property automatically. |
|
|
Computer name (pre-Windows 2000) |
sAMAccount-Name |
256 (schema rule), 20 (SAM rule) |
X |
Within the enterprise |
This is the downlevel name of the computer, which is also the same as the computer NetBIOS name. Internally, Active Directory stores a dollar sign ($) at the end of the name. |
Setting Computer Object Properties
The Users and Computers snap-in shows you about 15 computer object properties, and you can set about 8 of them. Behind the scenes, a computer object may have 280 properties (228 in AD2000.)
Table 3.16 lists the properties in five tabs. We discuss a sixth tab, Member Of, later in this chapter in the "Administering Groups" section, and a seventh tab, Delegation, in Chapter 4. An eighth tab, Dial-in, relates to managing communication settings, so we don't cover it in this book about Active Directory. We don't include screen shots, because they would show just a number of text boxes. Many of the setting names are self-explanatory. Note that Windows Server 2003 also provides context-sensitive help for each of the settings.
Table 3.16. Properties of a Computer Object
|
Property |
LDAP Name |
Syntax [*] |
Index |
GC |
Comments |
|---|---|---|---|---|---|
|
General Tab |
|||||
|
Computer name (pre-Windows 2000) |
sAMAccount-Name |
Text (256 [schema rule], 20 [SAM rule]) |
X |
X |
This is the downlevel name of the computer, which is also the same as the computer NetBIOS name. Internally, Active Directory stores a dollar sign ($) at the end of the name. |
|
DNS name |
dNSHostName |
Text (2048) |
X |
||
|
Role |
userAccount-Control |
Two choices |
X |
X |
Bit 0x2000 indicates a "Domain controller"; bit 0x1000 indicates a "Workstation or server". |
|
Description |
description |
Text (1024) |
X |
||
|
Trust computer for delegation |
userAccount-Control |
Yes/no |
X |
X |
This setting is described in Chapter 4 in the "Impersonation and Delegation" section. Note that when the domain is on the Windows Server 2003 functional level, this setting appears on the Delegation tab. |
|
Operating System Tab |
|||||
|
Name |
operating-System |
Text |
A read-only text such as "Windows Server 2003." |
||
|
Version |
operating-System-Version |
Text |
A read-only text to indicate the normal version, such as "5.2" (Windows 2000 is "5.0", Windows XP is "5.1", and Windows Server 2003 is "5.2"), and the more precise version (i.e., build number), such as "3790." |
||
|
Service Pack |
operating-System-ServicePack |
Text |
A read-only text to indicate whether or not you have installed any service packs on the machine, such as "Service Pack 1." |
||
|
Location Tab |
|||||
|
Location |
location |
Text (1,024) |
X |
X |
|
|
Managed By Tab |
|||||
|
Managed By |
managedBy |
DN; you select a user or contact from a list |
The user or contact you select gets no permissions for the computer. This setting is purely informational. The other fields on the tab are the manager's properties. Note that this setting is not related to the "This is a managed computer" check box that you saw in the creation wizard. |
||
|
Remote Install Tab [**] |
|||||
|
Computer's unique ID |
netbootGUID |
Binary (text in the user interface) |
X |
X |
Same as the computer's GUID. It helps when using RIS, and it signifies a managed computer. |
|
Remote Installation server |
netboot-Machine-FilePath |
Text |
X |
This property specifies the DNS name of the selected installation server. |
|
|
Server Settings |
N/A |
N/A |
N/A |
N/A |
This button takes you to the properties of the server object. |
Other Operations to Manage Computer Objects
Other operations you can do to manipulate computer objects are move, delete, disable, and reset. You can also rename computers or start computer management to manage the computer corresponding to the object.
Moving Computer Objects
If you need to move a computer object from one OU to another, you do it in the same way you move users. When you are moving a computer within a domain, either (a) drag it to a new location with the mouse, (b) use cut/paste with the keyboard or mouse, or (c) right-click the computer, select Move, and then choose the destination from the OU tree that opens up and click OK. Between domains in a forest you use another tool, such as the Support Tools command-line tool MoveTree, which is discussed in Chapter 6.
You can move several sibling objects at once by selecting them in the right-hand pane of the snap-in by using the Shift and/or the Ctrl key.
When you move computer objects
-
Permissions that are assigned for the object being moved move with the object.
-
Group policies and permissions that are inherited from above do not move with the object being moved. Instead, the moved object inherits the policies and permissions from its new location.
Deleting Computer Objects
You delete an object by right-clicking it and selecting Delete or by selecting the object and pressing the Delete key. Because there is no Undo option, a safety mechanism asks you to confirm the deletion.
A computer object is a security principal like a user object. Therefore, if you delete a computer object and then re-create it, the new object doesn't have the memberships or permissions of the old one.
If you delete a computer object, the corresponding computer is no longer part of the domain. Therefore, no one can log on to the computer using a domain user account.
Disabling Computer Accounts
You can disable the computer account by right-clicking the computer object and selecting Disable Account. Doing so will prevent users sitting at that computer from logging on using a domain user account.
You cannot disable a domain controller.
Resetting Computer Accounts
When a Windows NT/2000/XP/Server 2003 computer that is a member of a domain starts, the computer logs on to the domain using the computer account and some password known to the machine. After this, a user sitting at the computer can enter his username and password to log on to the domain.
The aforementioned machine logon sets up a secure channel, which enables the member computer to communicate with a domain controller to exchange user and password information. For example, if the computer account password stored in the local computer (called LSA secret) doesn't match the one stored in Active Directory, authentication to the domain is not possible, and the user will receive an error such as the one shown in Figure 3.21.
)
Figure 3.21 If the member computer cannot establish a secure channel with a domain controller, the user receives an error message such
as the one shown here and is not able to log on using a domain user account.
An administrator can solve the problem by using the Reset Account context menu item on the corresponding computer object. Resetting a computer account resets its password to the initial value, which is "computername$" (without quotes). In addition, the member computer must be joined to a workgroup and then joined to the domain again.
You can reset a computer account also with the DSMod Computer command and -reset option. In addition, Support Tools includes two command-line utilities, NetDom and NLTest, which you can use to reset computer accounts, among other things.
Managing Computers
When you right-click the computer object and select Manage, the Computer Management snap-in starts and sets the focus to the corresponding computer. This way you can manage its system tools, storage, server applications, and services.
Renaming Computers
You rename a Windows 2000/XP workstation or a Windows 2000/Server 2003 member server using the Control Panel of that computer. Select System, then the Computer Name tab, and finally the Change button. Once you enter a new name and click OK, you are prompted for the name of a domain user who has permission to change the name of the workstation or member server, as well as that user's password.
This operation renames the computer (i.e., the NetBIOS name and DNS name) and changes the common name and the pre–Windows 2000 name of the computer object.
Renaming domain controllers was discussed in Chapter 2.