Occasionally, the security relationship between a computer account and its domain can be broken; this results in a number of symptoms and errors. The most common signs of computer account problems are:
• Messages at logon 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 (another way of saying the secure
relationship) between the computer and the domain has been lost.
• 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. One such error is “NETLOGON Event ID 3210: Failed To Authenticate,” which appears in the computer’s event log.
• A computer account is missing in AD DS.
When the secure channel fails, you must reset it. Many administrators do this by removing the computer from the domain, putting it in a workgroup, and then rejoining the domain. When you remove the computer from the domain, the computer account in AD DS is disabled. When you rejoin the computer to the domain, the same computer account is reused and activated.
Do not rename the computer when you join it to the domain.
You can also reset the secure channel between a domain member and the domain, by using the Active Directory Users and Computers snap-in, DSMod.exe, NetDom.exe, or NLTest.exe. If you reset the account, the computer’s SID remains the same, and it maintains its group memberships.
To reset the secure channel by using the Active Directory Administrative Center:
1. Right-click a computer, and then click Reset Account.
2. Click Yes to confirm your choice.
3. Rejoin the computer to the domain, and then restart the computer.
To reset the secure channel by using DSMod:
1. At a command prompt, type the following command:
dsmod computer “ComputerDN” –reset
2. Rejoin the computer to the domain, and then restart the computer.
To reset the secure channel by using NetDom.exe, type the following command at a command prompt, where the credentials belong to the local Administrators group of the computer:
netdom reset MachineName /domain DomainName /UserO UserName /PasswordO {Password | *}
This command resets the secure channel by attempting to reset the password on both the computer and the domain, so it does not require rejoining or rebooting.
To reset the secure channel by using NLTest.exe, on the computer that has lost its trust, type the following command at a command prompt:
NLTEST /SERVER:SERVERNAME /SC_RESET:DOMAIN\DOMAINCONTROLLER
You also can use Windows PowerShell with Active Directory module to reset a computer account. The following example demonstrates how to reset the secure channel between the local computer and the domain to which it is joined.
You must run this command on the local computer:
Test-ComputerSecureChannel –Repair
Note: You also can reset a remote computer’s password with Windows PowerShell:
invoke-command -computername Workstation1 -scriptblock {reset-computermachinepassword}
Lesson 4: Delegating Administration
Although a single person can manage a small network with a few user and computer accounts, as the network grows, so too does the volume of work that relates to network management. At some point, teams with particular specializations evolve, each with responsibility for some specific aspect of network management. In AD DS environments, it is common practice to create OUs to bring departmental or geographic structure to the networked objects, and to enable configuration of administrative delegation. It is important that you know why and how to create OUs, and how to delegate administrative tasks to users on objects within those OUs.
Lesson Objectives
After completing this lesson, you will be able to:
• Describe AD DS permissions.
• Determine a user’s effective AD DS permissions on an AD DS object.
• Delegate administrative control of an AD DS object to a specified user or group of users.
AD DS Permissions
All AD DS objects, such as users, computers, and groups, can be secured by using a list of permissions. The permissions on an object are called access control entries (ACEs), and they are assigned to users, groups, or computers, which are also known as security principals. ACEs are saved in the object’s discretionary access control list (DACL), which is part of the object’s ACL. The ACL contains the system access control list (SACL) that includes auditing settings.
Each object in AD DS has its own ACL. If you have sufficient permissions, you can modify the permissions to control the level of access on a specific AD DS object. The delegation of administrative control involves assigning permissions that manage access to objects and properties in AD DS. Just as you can give a group the ability to change files in a folder, you can give a group the ability, for example, to reset passwords on user objects.
The DACL of an object also allows you to assign permissions to an object’s specific properties. For example, you can allow (or deny) permission to change phone and email options. This is, in fact, not just one property. It is a property set that includes multiple, specific properties. Using property sets, you can easily manage permissions to commonly used collections of properties.
However, you can also assign more granular permissions and allow or deny permission to change just some of the information, such as the mobile telephone number or the street address.
Assigning the help desk permission to reset passwords for each individual user object is tedious. Even so, in AD DS, it is not a good practice to assign permissions to individual objects. Instead, you should assign permissions at the level of OUs.
The permissions that you assign to an OU are inherited by all objects in the OU. Therefore, if you give the help desk permission to reset passwords for user objects and attach that permission to the OU that contains the users, all user objects within that OU will inherit that permission. In just one step, you have delegated that administrative task.
Child objects inherit the permissions of the parent container or OU. That container or OU in turn inherits its permissions from its parent container OU. If it is a first-level container or OU, it inherits the permissions from the domain itself. The reason child objects inherit permissions from their parents is that, by default, each new object is created with the Include inheritable permissions from this object’s parent option enabled.