By default, trust relationship and computer account passwords are negotiated every thirty days, except for computer accounts that can be disabled by the administrator.
When you authoritatively restore Active Directory on a domain controller, an earlier password for the Active Directory objects that maintain trust relationships and computer accounts might be restored. In trust relationships, this change may disable communication with other domain controllers from other domains. For a computer account password, this change could disable communication between the member workstation or server and a domain controller of its domain.
By default, computer accounts are kept in the following Active Directory container:
This default container and the computer accounts can be moved to organizational units in Active Directory.
By default, trust accounts are kept in the following Active Directory container:
The trust accounts are named after the NETBIOS domain name of the trusting domain with a dollar sign ($) appended and special flags set. They are hidden by Active Directory Users and Computers, but they are visible when you use ADSI Editor or the LDP tool.
For more information, click the following article number to view the article in the Microsoft Knowledge Base:
Redirecting the users and computers containers in Windows Server 2003 domains
The trusted domain objects that represent the trusting side of trusts are located in the following Active Directory container:
This location cannot be moved. Do not authoritatively restore this container and its immediate child leaf objects unless you must. To recover the replication topology of a DFS volume, you may restore subcontainers, such as the FRS container.Note
Windows 2000 keeps a history of two passwords on the trusted domain component of a trust relationship.For more information, click the following article number to view the article in the Microsoft Knowledge Base:
How to disable automatic machine account password changes
Nonauthoritatively restoring a domain controller
When a domain controller is replaced or must be recovered from hardware failure, only a restore from the most recent backup of a domain controller is necessary if the data on other domain controllers is known to be good.
After the restore process, Active Directory replication automatically starts propagating any changes from other domain controllers that occurred after the time of the backup.
Authoritatively restoring a domain controller
When other domain controllers exist, but you must recover data, use caution when you perform an authoritative restore of data in the domain naming context. Trust relationship data resides in the domain naming context for both parent-child relationships to Windows 2000 domains in the forest, and for NTLM/Kerberos trusts to pre-Active Directory domains.
If data restoration is required, authoritatively restore only those parts of the naming context. If you restore the complete naming context, all computer passwords and trust relationship passwords are restored. When these passwords are restored, they may become invalid because passwords may have been renegotiated after the backup occurred. Therefore, the passwords may no longer be synchronized and must be reset.
To reset NTLM trust relationships to Windows Active Directory or pre-Active Directory domains, you must remove and re-create the trust. If you must do this for multiple domains, you can use the Netdom utility that is provided with the Windows 2000 Resource Kit to do this by using a batch process.When other domain controllers exist and an authoritative restore is performed, any objects that were created in the naming context after the backup will remain in Active Directory.
For example, one possible scenario is as follows:
- On day 1, the administrator performs a backup of the system.
- On day 2, the administrator creates a user named "User Two" and this data replicates to other domain controllers in the domain.
- On day 3, the user named "User One" is unintentionally deleted.
- On day 4, an authoritative restore of the domain controller is performed with the backup created on day 1.
Therefore, both User One and User Two exist within the domain.
Authoritatively restoring a domain controller when no other domain controllers exist
When no other domain controllers exist to replicate recent changes to a restored system, or when an authoritative restore is necessary to bring domain controllers back to a known state, you should perform an authoritative restore of the whole naming context.
This process creates the same scenario as previously mentioned. If trust relationships or computer account passwords are effected, you will have to reset them.