The default location for computer objects in a domain is the cn=Computers container located directly off the domain root. You can, however, create computer objects anywhere in a domain. You can also modify the default location for computer objects as described in Modifying the Attributes of a computer Object. Table 8-1 contains a list of some of the interesting attributes that are available on computer objects.

You want to create a computer account.

Creating a computer object in Active Directory is not much different from creating a user object. We set the description attribute in the CLI solutions, but it is not a mandatory attribute. The only mandatory attribute is sAMAccountName, which should be set to the name of the computer with a $ appended. Note that ADAC and ADUC will both populate the sAMAccountName automatically based on the name given to the computer during the creation process. Also note that these solutions simply create a computer object. This does not mean any user can join a computer to the domain with that computer account. For more information on creating a computer object and allowing a specific user or group to join the computer to the domain, see Creating a Computer for a Specific User or Group.

Creating a Computer for a Specific User or Group for creating a computer for a user; “New-ADComputer”; MSDN: ADS_USER_FLAG_ENUM

You want to create a computer account for a specific user or group to join to the domain. This requires setting permissions on the computer account so that the user or group can modify certain attributes.

By default, members of the Authenticated Users group can join up to 10 computers to an Active Directory domain. If you’ve modified this default behavior or need to allow a user to add computers to the domain on a regular basis, you need to grant certain permissions so that the user has rights to modify the computer object. When you create a computer via ADAC or the ADUC snap-in (dsa.msc), you have the option to select a user or group to manage the computer object and join a computer to the domain using that object. When you use that method, eight ACEs are added to the ACL of the computer object. They are:

Creating a Computer for creating a computer account

You want to delete a computer account.

You want to join a computer to a domain after the computer object has already been created in Active Directory.

When trying to add a computer to Active Directory, either you can pre-create the computer object as described in Recipes and before joining it to the domain, or you can perform both operations at the same time.

Add-Computer cmdlet reference

You want to move a computer object to a different container or OU within the same domain.

You can move computer objects around a domain without much impact on the computer itself. You just need to be cautious of the security settings on the new parent OU, which may impact a user’s ability to manage the computer object in Active Directory. Also, if GPOs are used differently on the new parent, it could impact booting and logon times, and how the computer’s operating system behaves after a user has logged on.

Moving an Object to a Different OU or Container for moving an object to a different OU; Moving a Computer to a New Domain for moving a computer to a different domain

You want to move a computer object to a different domain.

You can move objects between domains assuming you follow a few guidelines:

Using LDAP Controls for more on LDAP controls; MSDN: IADsContainer::MoveHere; “Active Directory Migration Tool (ADMT) Guide: Migrating and Restructuring Active Directory Domains”

You want to rename a computer.

Renaming a computer consists of two operations: renaming the computer object in Active Directory and renaming the hostname on the machine itself. To do it in one step—an option that each of the three solutions offers—you must have permission in Active Directory to rename the account and administrator permissions on the target machine. For the rename operation to be complete, you must reboot the computer.

Renaming an Object for renaming objects; “Netdom renamecomputer”

You want to add or remove a computer account from an Active Directory security group.

In Active Directory, both user and computer objects are security principals that can be assigned rights and permissions in a domain. As such, computer objects can be added to or removed from group objects to make for simpler resource administration. You can make this change through ADAC, ADUC, or ADSI Edit, or by manually editing the member attribute of the appropriate group object.

MSDN: NT-Group-Members attribute [AD Schema]; MSDN: Member Attribute [AD Schema]

You want to test the secure channel of a computer.

Every member computer in an Active Directory domain establishes a secure channel with a domain controller. The computer’s password is stored locally in the form of an LSA secret and in Active Directory. The NetLogon service uses this password to establish the secure channel with a domain controller. If for some reason the LSA secret and computer password become out of sync, the computer will no longer be able to authenticate in the domain. The nltest /sc_query command can query a computer to verify its secure channel is working. Here is sample output from the command when things are working:

Flags: 30 HAS_IP HAS_TIMESERV
Trusted DC Name \dc1.adatum.com
Trusted DC Connection Status Status = 0 0x0 NERR_Success
The command completed successfully

If a secure channel is failing, you’ll need to reset the computer as described in Resetting a Computer Account. Here is sample output when things are not working:

Flags: 0
Trusted DC Name
Trusted DC Connection Status Status = 1311 0x51f ERROR_NO_LOGON_SERVERS
The command completed successfully

Resetting a Computer Account for resetting a computer

You want to reset a computer because its secure channel is failing.

When you’ve identified that a computer’s secure channel has failed, you’ll need to reset the computer object, which consists of setting the computer object password to the name of the computer. This is the default initial password for new computers. Every 30 days, Windows computers automatically change their passwords in the domain. After you’ve set the password, you’ll need to rejoin the computer to the domain since it will no longer be able to communicate with a domain controller due to unsynchronized passwords. However, the netdom reset command and the Test-ComputerSecureChannel command will try to reset the password both on the computer and in Active Directory, which will not necessitate rejoining it to the domain if successful.

From a practical standpoint, you should first attempt to reset the secure channel between the computer and the domain using the netdom, Test-ComputerSecureChannel, or nltest syntax, since doing so will not require you to unjoin and rejoin the computer to the domain; in particular, this will save you from performing the associated reboots involved with rejoining the domain. If resetting the secure channel does not correct the issue you’re facing, you can then resort to resetting the computer’s password.

A new utility from joe Richards, named MachinePwd, is another way to change computer passwords from the command line. See joeware for more detail.

Joining a Computer to a Domain for joining a computer to a domain

You want to find inactive computer accounts in a domain.

Preventing a User’s Password from Expiring for finding users whose passwords are about to expire; “Find Inactive Users using Powershell” (can be used with the -computersonly switch)

You want to grant users the ability to join more or fewer than 10 computers to a domain. This limit is called the machine account quota.

In a default Active Directory installation, members of the Authenticated Users group can add and join up to 10 computer accounts in the default Computers container. The number of computer accounts that can be created is defined in the attribute ms-DS-MachineAccountQuota on the domainDNS object for a domain. The default setting is 10, but you can easily change that to whatever number you want, including 0, via the methods described in this recipe. If you set it to 0, users have to be granted explicit permissions in Active Directory to join computers; refer to Joining a Computer to a Domain for instructions on granting these permissions.

Another method for granting users the right to add computer objects, although not recommended, is via Group Policy. If you grant the “Add workstation to domain” right via Computer Configuration→Windows Settings→Security Settings→Local Policies→User Rights Assignment on a GPO that’s been linked to the Domain Controllers OU, then users will be able to create computer accounts even if they do not have create child permissions on the default Computers container. This is a holdover from Windows NT to maintain backward compatibility and should not be used unless absolutely necessary. In fact, a good security best practice would be to remove this user right from any user or group objects that do not require it.

Joining a Computer to a Domain for permissions needed to join computers to a domain; MS KB 251335 (Domain Users Cannot Join Workstation or Server to a Domain); “Default limit to number of workstations a user can join to the domain”

You want to modify one or more attributes of a computer object.

Like all objects within Active Directory, computer objects have various attributes that can be queried, modified, and deleted during the day-to-day management of your domain. Because computer objects inherit from the user class, they include similar informational attributes to the user objects, as well as attributes that are specific to computer objects, including:

Finding Inactive or Unused Computers for finding inactive or unused computers; Finding Computers with a Particular OS for finding computers with a particular OS; MSDN: Computer System Hardware Classes [WMI]

You want to find computers that have a certain OS version, release, or service pack in a domain.

When a computer joins an Active Directory domain, the operating system attributes are updated for the computer object. There are three of these attributes, which can be used in queries to find computers that match certain OS-specific criteria, such as service pack level.

These attributes include the following:

“Operating System Version (Windows)”

You want to bind to the default container that new computer objects are created in.

In much the same way that the TCP/IP protocol defines a list of well-known ports that are commonly used by industry applications (TCP ports 20 and 21 for FTP, TCP port 80 for HTTP, and so on), Active Directory defines Well-Known GUIDs that map to container objects that are present in every AD installation. The Domain NC defines the following WKGUIDs:

The Configuration NC also defines its own Deleted Objects WKGUID.

For example, the default Computers container has the following WKGUID:

aa312825768811d1aded00c04fd8d5cd

You can use the GUID to bind to the default Computers container in the domain using the following ADsPath:

LDAP://<WKGUID=aa312825768811d1aded00c04fd8d5cd,dc=apac,dc=adatum,dc=com>

The list of well-known objects for a domain is contained in the wellKnownObjects attribute of the domainDNS object for the domain. The wellKnownObjects attribute is multivalued with DNWithBinary syntax. The following is an example of what that attribute looks like for the adatum.com domain:

B:32:AA312825768811D1ADED00C04FD8D5CD:cn=Computers,dc=adatum,dc=com;
B:32:F4BE92A4C777485E878E9421D53087DB:cn=Microsoft,cn=Program
Data,dc=adatum,dc=com;
B:32:09460C08AE1E4A4EA0F64AEE7DAA1E5A:cn=Program Data,dc=adatum,dc=com;
B:32:22B70C67D56E4EFB91E9300FCA3DC1AA:
cn=ForeignSecurityPrincipals,dc=adatum,dc=com;
B:32:18E2EA80684F11D2B9AA00C04F79F805:cn=Deleted Objects,dc=adatum,dc=com;
B:32:2FBAC1870ADE11D297C400C04FD8D5CD:cn=Infrastructure,dc=adatum,dc=com;
B:32:AB8153B7768811D1ADED00C04FD8D5CD:cn=LostAndFound,dc=adatum,dc=com;
B:32:AB1D30F3768811D1ADED00C04FD8D5CD:cn=System,dc=adatum,dc=com;
B:32:A361B2FFFFD211D1AA4B00C04FD7D83A:ou=Domain Controllers,dc=adatum,dc=com;
B:32:A9D1CA15768811D1ADED00C04FD8D5CD:cn=Users,dc=adatum,dc=com;

Each value has the format of:

B:NumberofBytes:GUID:DistinguishedName

As you can see, the GUID for the first value is the same as the one we used in the ADsPath earlier to bind to the default Computers container.

Changing the Default Container for Computers for changing the default Computers container; MSDN: Binding to Well-Known Objects Using WKGUID

You want to change the container that computers are created in by default.

Many Active Directory administrators do not use the Computers container within the Domain Naming context as their primary computer repository. One reason is that since it is a container and not an OU, you cannot apply Group Policy Objects to it. If you have another location where you store computer objects, you might want to consider changing the default container used to bind to the Computers container by changing the well-known objects attribute, as shown in this recipe. This can be beneficial if you want to ensure computers cannot sneak into Active Directory without having the appropriate group policies applied to them. While you can also apply GPOs at the site or the domain level, forcing new computers into a particular organizational unit ensures that those computers receive the Group Policy settings that you want them to receive through GPOs linked at the OU level. However, this does not protect you from an administrator (whether intentionally or accidentally) explicitly creating a computer object in the incorrect OU; this only protects you from applications or utilities that do not allow or do not require you to specify an OU when creating the computer.

“Redirecting the users and computers containers in Active Directory domains” (KB 324949)

You want to obtain a list of all computer accounts in an Active Directory domain.

Get-ADComputer cmdlet reference; MSDN: Object Class and Object Category [Active Directory]; MSDN: Object-Class Attribute [AD-Schema]

You want to identify the role that a particular computer serves in an Active Directory domain.

The DomainRole attribute returns a numeric value that identifies the role, as shown in the following list:

You want to prevent a computer object from being accidentally deleted by an administrator who selects the incorrect option in Active Directory Users and Computers.

By default, all new OUs that are created in Windows Server 2008 and later will have this protection enabled; however, no other object types are configured with this default protection. If you attempt to delete a computer object that is protected using this option, even when signed on as a Domain Admin or other similarly elevated account, you will receive an “Access Denied” message until you manually remove the checkbox or manually remove the deny ACE associated with it.

Using the command-line or PowerShell method, you can apply this protection to group objects in all versions of Windows Server, even though the GUI checkbox is available only in Windows Server 2008 and later.

You wish to view the RODCs that have cached a computer account’s password secrets.

As discussed in Chapter 3, Windows Server 2008 introduced the Read-Only Domain Controller (RODC) to improve the security of branch office and other remote environments. One of the security measures introduced by the RODC is the Password Replication Policy (PRP), which specifies a list of users, computers, and groups that can and cannot have their password secrets cached on one or more DCs. Each RODC maintains a forward-link attribute called msDS-RevealedUsers, which lists the user and computer accounts for whom each RODC has cached password secrets. Each computer account, in turn, maintains a backlink called msDS-RevealedDSAs. This backlink can be queried to determine which RODCs have stored password information for a particular user account; however, like all backlinks, this attribute cannot be modified directly.

Promoting a Server to a Read-Only Domain Controller; Modifying the Password Replication Policy