• Every member computer in an AD DS domain maintains a computer account with a user name (sAMAccountName) and password, just like a user account does.
  • The computer stores its password in the form of a local security authority (LSA) secret, and changes its password in the domain approximately every 30 days.
  • Each domain‑joined computer has an account in AD DS. Computer accounts are used in the same ways that user accounts are used for users.
  • Each computer has a Security Identification (SID) and attributes.
  • when you create a domain, a Computers container is created. A container is different from an OU.
    • You cannot create an OU within a container, so you cannot subdivide the Computers container.
    • You also cannot link a group policy object (GPO) to a container. So, you cannot create security policies for the Computers container. For these reasons, as a best practice, we recommend that instead of using the Computers container, you create custom OUs to host your computer accounts.

Computer Organization

Most organizations create at least two OUs for computer objects—one for servers (other than domain controllers), and one for clients. You may want to further divide your server and client OUs into additional OUs. This will allow you to delegate administration and link GPOs at a more granular level.

Organize your servers.

For example, under a Server OU you might create an OU for File and Print Servers, an OU for Database Servers, or any number of OUs that categorize the server types in your organization. This allows you delegate management of database servers to the database team or link a GPO for email servers to an OU that only contains email servers.

- Servers OU
| - Print Servers
| - Database Servers
| - Email Servers
\ -Other Servers

Organize your clients.

For clients, it is common to create Desktop and Laptop OUs. You may go a step further and create OUs for geographical areas. This approach enables each site’s support team to be delegated the rights to create and manage computer objects in the site for client computers, and to join computers to the domain by using those computer objects. You could also start with geographical locations and then subdivide into client types.

- Computers | - Lodon | | - Desktop | \ - Laptops \ - Paris | - Desktop \ - Laptops

You can use the redircmp command‑line tool to change the default location for computers. For example, if you want to change the default location for computers to an OU named MyComputers, run the following command redircmp “OU=MyComputers,DC=adatum,dc=com”

Computer Naming

Implement a naming convention that helps you identify the role and location of a computer. For example, Include an abbreviation on the computer’s role. Such as, SVR (servers), CL (clients), FS (file server), PS (print server), and DTP (desktop). Include an abbreviation on the computer’s location. Such as, LON (London) and MEL (Melbourne). Decide on a delimiter, such as hyphen or underscore. Use a descriptive computer name that has meaning in your organization. Avoid generic names like Client1 and DC1. Implement the Description property on your computer accounts. Use the property to provide additional security, site, and administrative information. Avoid including information that can change. Such as, a user name or department position.

Computer Permissions

Certain groups have computer permissions. It is important that you control who will be able to create and delete computers in the domain. By default, the Enterprise Admins, Domain Admins, Administrators, and Account Operators groups have permissions to perform some management of computer objects.

We recommend you delegate the Computer Objects permission to a smaller group of administrators or support personnel. For example, you might create a group containing just the desktop support team and the file server administrators. Then you could give permissions to allow your desktop support team to create computer objects in a Clients OU, and your file server administrators to create computer objects in a File Servers OU.

To delegate permissions, you can use the Delegate Control Wizard. Computer objects permissions include Create selected objects in the folder and Delete selected objects. If you want to allow a delegated administrator to move computer accounts, consider that the administrator must have the appropriate permissions both in the source container (where the computer currently exists) and in the target container (where the computer will be moved to).

Pre-staging

As a best practice, we recommend you create your computer objects in advance. The is called pre-staging a computer. There are several advantages to this method.

  • Enforces delegated control. If you have delegated control to your computer OUs, then you ensure only the specific people you have identified will be able to create the computer accounts.
  • Enforces the OU structure. When Windows Server attempts to join a computer to the domain it looks for an existing object. If it does not find the object, it creates the computer object in the default Computers container. It is easy to forget to move the computer from the default container into the OUs you took the time to define and create.
  • Enforces the Group Policy settings. When you link GPOs to your computer OUs the computer is immediately within scope before the computer joins the domain. This reduces the chance a computer will be out of compliance once it joins the domain.

Secure Channels

A secure channel is used for all computer communications. The NetLogon service uses the computer credentials to log on to the domain, which establishes the secure channel with a domain controller. This secure channel between a computer and a domain controller is used for all communication with the domain. If the computer is unable to sign in successfully, the secure channel is not established. The effect is similar to when a user enters the wrong user name or password. In both circumstances, the user is not able to authenticate to the domain.

Know the symptoms of a broken secure channel.

A broken computer account manifests itself with a variety of symptoms, error messages, and event‑log entries. The most common signs of computer account problems are sign-in messages and event log messages.

  • Sign-in messages. Messages at sign-in indicate that a domain controller cannot be contacted, that the computer account might be missing, that the password on the computer account is incorrect, or that the trust relationship (also called the secure relationship) between the computer and the domain has been lost.

  • Event log messages. Error messages or events in the event log indicate similar problems or suggest that passwords, trusts, secure channels, or relationships with the domain or a domain controller have failed.

Broken Channels

Computer accounts and the secure relationships between computers and their domain are robust. Nevertheless, there are certain scenarios in which a computer cannot authenticate with the domain.

  • Reinstalling the operating system. After reinstalling the operating system, the computer cannot authenticate, even though the same computer name was used in the previous installation. This is because the new installation generated a new SID, and because the new computer does not know the original computer account password in the domain. This new computer does not belong to the domain and cannot authenticate.
  • Computer inactivity. If a computer has not been used for an extended period, an administrator may have reset or deleted the computer account. This could occur when a user works offline for an extended time, or when a computer spare has not been needed for a long time.
  • Password synchronization. A computer’s LSA secret gets out of synchronization with the password that the domain knows. You can think of this as the computer forgetting its password. Although it did not forget its password, it just disagrees with the domain over what the password really is. When this happens, the computer cannot authenticate, and the secure channel cannot be created.

Resetting the channel

When the secure channel fails, you must reset the computer account. To do this you can use the Active Directory Users and Computers snap-in.

When you reset an account the computer's SID remains the same, and the computer maintains its group memberships. If you prefer to use PowerShell the command is Test-ComputerSecureChannel -Repair. You can reset a computer account by disjoining the computer from the domain (putting it in a workgroup), and then rejoining the domain. This is not a good practice because it has the potential to delete the computer account, which loses the computer’s SID, and its group memberships. When you rejoin the computer to the domain, even when the computer has the same name, the account has a new SID, and all the group memberships of the previous computer object must be recreated.

Domain Join

After resetting the account, join the computer to the domain. To join a computer to an AD DS domain, three conditions must be met:

  • You must have appropriate permissions on the computer object that allows you to join a physical computer with the same name to the domain.
  • You must be a member of the local Administrators group on the computer. This allows you to change the computer’s domain or workgroup membership.
  • You must have delegated rights to add computers to the domain or you must not have exceeded the maximum number of computer accounts that users, by default, can add to the domain. By default, users can add a maximum of 10 computers to the domain. The machine account quota determines the maximum number of computer accounts you can add to the domain. You can modify the value of this attribute, MS-DS-MachineAccountQuota, by using the Active Directory Service Interfaces Editor (ADSI Edit) snap‑in.

To configure offline domain join follow these steps paying particular attention to whether the process is on the domain controller or the client.

  1. Provision a computer account in AD DS and create the domain join file.

    • djoin.exe /provision /domain <domainname> /machine <machinename> /savefile <save path> /reuse
    • The /provision option creates and configures the computer account in AD DS.
    • The /savefile option specifies a text file (blob) file will all the necessary information such as machine account password, domain name, domain controller name, and domain SID.
    • The /reuse option (optional) indicates the computer has been pre-staged and an existing computer account exists in the domain.

  2. Transfer the provisioning information to the provisioned computer. This inserts the blob into the operating system of the computer that is being joined.

    • djoin.exe /requestODJ /‍loadfile <file path> /‍windowspath %‍systemroot‍% /‍localos
    • The /requestODJ option requests an offline domain join at the next start.
    • The /windowspath option specifies the path to the Windows directory of the offline image.
    • The /localos targets the local operating system installation, instead of an offline image.

  3. Start or reboot the computer to complete the domain join operation. The offline domain join does not have to be completed within a specific time period. The computer account that is provisioned remains in AD DS unless an administrator intervenes.