Lesson 3: Supporting Computer Objects and Accounts in .NET framework

Encode ANSI/AIM Code 128 in .NET framework Lesson 3: Supporting Computer Objects and Accounts

between any containers, including the Computers container, the Domain Controllers OU, and any other OUs. There is no way to delegate the specific task of moving an object in Active Directory. Instead, your ability to move a computer is derived from your ability to delete an object in the source container and create an object in the destination container. When you move the object, you are not actually deleting and re-creating it; those are just the permissions that are evaluated to allow you to perform a move. The Dsmove command allows you to move a computer object or any other object. The syntax of Dsmove is:

dsmove ObjectDN [-newname NewName] [-newparent ParentDN]

The newname parameter enables you to rename an object. The newparent parameter enables you to move an object. To move a computer named DESKTOP153 from the Computers container to the Clients OU, you would type the following:

dsmove "CN=DESKTOP153,CN=Computers,DC=contoso,DC=com" -newparent "OU=Clients,DC=contoso,DC=com"

To move a computer in Windows PowerShell, you must use the psbase.MoveTo method. The following two lines of code will move a computer:

$objUser=[ADSI]"LDAP://ComputerDN " $objUser.psbase.MoveTo("LDAP://TargetOUDN")

With VBScript, you connect to the source container and use the container s MoveHere method:

Before you move a computer, consider the implications to delegation and configuration. The target OU might have different permissions than the originating OU, in which case, the object will inherit new permissions affecting who is able to manage the object further. The target OU might also be within the scope of different GPOs, which would change the configuration of settings on the system itself.

One of the beneficial but lesser used features of the Active Directory Users and Computers snap-in is the Manage command. Select a computer in the Active Directory Users and Computers snap-in, right-click it, and choose Manage. The Computer Management console opens, focused on the selected computer, giving you instant access to the computer s event logs, local users and groups, shared folder configuration, and other management extensions. The tool is launched with the credentials used to run the Active Directory Users and Computers snap-in, so you must be running the Active Directory Users and Computers snap-in as a member of the

5

remote computer s Administrators group to gain the maximum functionality from the Computer Management console.

Every member computer in an Active Directory 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 with the domain every 30 days or so. The Netlogon service uses the credentials to log on to the domain, which establishes the secure channel with a domain controller.

Computer accounts and the secure relationships between computers and their domain are robust. However, certain scenarios might arise in which a computer is no longer able to authenticate with the domain. Examples of such scenarios include:

After reinstalling the operating system on a workstation, the workstation is unable to authenticate even though the technician used the same computer name. Because the new installation generated a new SID and because the new computer does not know the computer account password in the domain, it does not belong to the domain and cannot authenticate to the domain. A computer is completely restored from backup and is unable to authenticate. It is likely that the computer changed its password with the domain after the backup operation. Computers change their passwords every 30 days, and Active Directory remembers the current and previous password. If the restore operation restored the computer with a significantly outdated password, the computer will not be able to authenticate. A computer s LSA secret gets out of synch with the password known by the domain. 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.

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 (another way of saying the secure relationship ) between the computer and the domain has been lost. An example is shown in Figure 5-7.