Active Directory Domain Trusts & Trust Password Management

Recently a customer asked me about Active Directory Domain Trusts and how the passwords were managed. I replied with some educated guesses based on how AD manages a variety of passwords. After stating how I thought it worked (and mentioned that I wasn’t sure), I decided to look it up. I was mostly correct.

Every trust a domain maintains is represented by a Trusted Domain Object (TDO) in the Domain partition’s System container. The TDO contains the following attributes for a domain trust:

  • DNS domain name
  • Domain SID
  • Trust type
  • Trust transitivity
  • Reciprocal domain name

Forest trusts store the following attributes:

  • DNS domain name
  • Domain SID
  • Trust type
  • Trust transitivity
  • Reciprocal domain name
  • Domain tree names
  • User Principal Name (UPN) suffixes
  • Service Principal Name (SPN) suffixes
  • Security ID (SID) namespaces

Since trust information is stored in Active Directory, all domains in the forest know about all of the trusts in place with all forest domains. External NT 4 trusts are not stored as TDOs and therefore are not in Active Directory.

In a one-way trust, there is a TrustED and TrustING domain.
The TrustING domain has the resources that the account in the TrustED domain needs to access. Since a two-way trust is only 2 one-way trusts, there are actually 2 trust passwords involved.

Here’s how trust passwords are managed:

  1. After the trust is created, the password is stored in the associated TDO object.
  2. After 30 days the PDC emulator in the trustING domain changes the password by creating a new one. The trustED DC never attempts to change the password.
  3. The TrustING DC updates the associated TDO OldPassword attribute to the value of the prior password.
  4. The TrustING DC updates the associated TDO NewPassword attribute to the value of the new password.
  5. This way there are always 2 trust passwords associated with the trust, the old password and the new (current) one. This ensures that even if there is an issue with the password change on the TrustED side, the trust remains active since both sides still have a useful password (OldPassword).
  6. The TrustING domain DC connects to a TrustED domain controller via RPC to provide the updated password.
  7. The TrustED DC receives the new password and updates its existing trust password.
  8. Since the trust password is stored in the Domain container in the associated TDO, all the DCs in the domain receive the updated trust password via regular AD replication.
  9. Until the TrustING DC authenticates to a TrustED DC using the new password, the new password is not valid. The old password is used over secure channel until the new password is updated in the TrustED domain and validated.
  10. If authentication fails with the new password, it falls back to the old password and the the password change resumes within 15 minutes.
  11. It is expected that trust passwords are updated among all domain DCs within a day and have a default lifetime of 30 days (same as domain computer accounts). Obviously, trusts can get out of sync if both sides of the trust don’t update and store the new password properly.

Trust Limitations:

  • More than 2400 Trusted Domain Objects (TDOs) incurs noticeable delays specifically related to inter-domain authentication.
  • There is a maximum of 10 trust links Kerberos clients (Windows 2003) can traverse to locate a requested resource in another domain. If the trust path starts approaching 10, it is better to create external trusts to bypass this issue.

Realm Trust:

A realm trust is a trust between a non-Windows Kerberos realm and a Windows 2000/2003/2008 domain which enables cross-platform Kerberos (v5) interoperability.

  • Only supports Kerberos v5 authentication (not NTLM).
  • One-way & nontransitive by default, but can be switched to transitive. configure 2 one-way trusts to enable a two-way trust relationship.

NOTE:
Windows Server 2003 administrative tools sign and encrypt all LDAP traffic by default.

Command Line Tools for managing trusts:

  • NLTest
    “You can use the NLTest command-line tool to perform trust-related network administrative tasks such as testing the trust relationship between a Windows–based computer that is a member of a domain and the domain controller on which its computer account is located. In domains where an external trust is defined, NLTest can be used to test the trust relationship between all domain controllers in the trusting domain and a domain controller in the trusted domain. Nltest can also be used to verify any secured channel.
  • NetDom
    Netdom is a command-line tool that allows you to create and manage Active Directory trust relationships (except forest trusts) and can help reduce the number of steps needed to create a trust by using Active Directory Domains and Trusts. You can also use the Netdom command line tool to complete batch management of trusts, join computers to domains, verify trusts (including forest trusts) and secured channels, and obtain information about the status of trusts.
    Netdom can be targeted at all Active Directory domain controllers and can verify all Active Directory trust types. Verification is accomplished between two domains by enumerating the domain controllers in each domain. If you choose to have Netdom create both sides of the trust at once the trust password is automatically generated.

WMI Classes Associated with Trusts

Class Name Namespace Version Compatibility
Microsoft_TrustProvider root\microsoftactivedirectory Windows 2000 Server and Windows Server 2003
Microsoft_DomainTrustStatus root\microsoftactivedirectory Windows 2000 Server and Windows Server 2003
Microsoft_LocalDomainInfo root\microsoftactivedirectory Windows 2000 Server and Windows Server 2003

Ports Required for Trusts

Task Outbound Ports Inbound Ports From–To
Set up trusts on both sides from the internal forest LDAP (389 UDP and TCP)Microsoft SMB (445 TCP)Kerberos (88 UDP)

Endpoint resolution — portmapper (135 TCP) Net Logon fixed port

 N/A Internal domain domain controllers–External domain domain controllers (all ports)
Trust validation from the internal forest domain controller to the external forest domain controller (outgoing trust only) LDAP (389 UDP)Microsoft SMB (445 TCP)Endpoint resolution — portmapper (135 TCP) Net Logon fixed port  N/A Internal domain domain controllers–External domain domain controllers (all ports)
Use Object picker on the external forest to add objects that are in an internal forest to groups and DACLs  N/A LDAP (389 UDP and TCP)Windows NT Server 4.0 directory service fixed portNet Logon fixed port

Kerberos (88 UDP)

Endpoint resolution portmapper (135 TCP)

External server–Internal domain PDCs (Kerberos)External domain domain controllers–Internal domain domain controllers (Net Logon)
Set up trust on the external forest from the external forest  N/A LDAP (389 UDP and TCP)Microsoft SMB (445 TCP)Kerberos (88 UDP) External domain domain controllers–Internal domain domain controllers (all ports)
Use Kerberos authentication (internal forest client to external forest) Kerberos (88 UDP)  N/A Internal client–External domain domain controllers (all ports)
Use NTLM authentication (internal forest client to external forest)  N/A Endpoint resolution – portmapper (135 TCP) Net Logon fixed port External domain domain controllers–Internal domain domain controllers (all ports)
Join a domain from a computer in the internal network to an external domain LDAP (389 UDP and TCP)Microsoft SMB (445 TCP)Kerberos (88 UDP)

Endpoint resolution — portmapper (135 TCP) Net Logon fixed port

Windows NT Server 4.0 directory service fixed port

 N/A Internal client–External domain domain controllers (all ports)

To specify the services that you want to run on a fixed port, you must appropriately configure the registry for that port.

References:

(Visited 29,051 times, 2 visits today)