How trusts are stored in AD

Hey — I’ve been away for a while tanning in the sun and slurping cool drinks. As my vacation is over now, I’m going to write a few words on how Trusts are stored in AD.

AD knows “trust objects” that are stored as “trustedDomain” objects in Active Directory in every domain’s System container:

You can see in that picture that I have three Trusts in my intern.frickelsoft.net domain. From the name-attribute, we can guess that two of them, us.intern.frickelsoft.net and asia.intern.frickelsoft.net are subdomains. These trustedDomain objects have attributes that describe the type of Trust and its scope. See:

The picture shows the trustedDomain object’s attributes of my us.intern.frickelsoft.net subdomain. Some important attributes are:

  • trustDirection: specifies the direction of the trust. 0=disabled; 1=incoming; 2=outgoing; 3=both directions.
  • trustPartner: this is the DNS name of the trust partner (Windows NT will use the NetBIOS name here, I guess).
  • trustType: the type of the trust, obviously :-) 1=”Windows NT”; 2=”Active Directory” (parent-child, forest trust, external, shortcut), 3=MIT/KRB realm trust
  • Â trustAttributes: this is a bitmask for Server 2003 and above and has the following values:
    • 1 – trust is not transitive
    • 2 – only Windows 2000 and above clients can use the trust
    • 4 – SID filtering enabled
    • 8 – the trust is a forest trust
    • 16 – this is a “cross-org” trust with selective authentication enabled
    • 32 – the trust is forest-internal
    • 64 – this is a forest trust with SIDHistory enabled (only valid if “4″, SID filtering is enabled, too)
  • flatName: NetBIOS name

As a contrast, let’s check the object attributes for a different trustedDomain object, let’s say for contoso.com a Forest-Trust:

Contoso is a domain in a different forest the intern.frickelsoft.net forest has a Forest Trust with. Contoso.com trusts intern.frickelsoft.net so that users from frickelsoft can access resources in contoso.com – but not vice versa.

That is the configuration part. Now — if you previously had the honor to mess with (broken) trusts, you may already have resetted a trust password. Every trust has a secure channel through which trust participants communicate. They use a trust passwords to secure their communication. If the secure channel between them is broken, you need to reset it/reset the trust password. Now — where’s that password stored?

Pretty similar to computer accounts that have a computer account in AD to maintain the secure channel to the domain, Trusts have a user account in Active Directory. You cannot see them with Active Directory Users and Computers but with ADSIEdit. The user account for the Trust is stored in the builtin “Users” container under the domain root, CN=Users,DC=intern,DC=frickelsoft,DC=net and CN=Users,DC=yourdomain,DC=tld for you.Â

This is one of the reasons why you shouldn’t remove the Users container from your domain. You break Trusts!

The user has a dollar sign $ attached to the NETBIOS name, ‘CONSOTO$’ for me. Whenever you reset a Trust with netdom or nltest, you reset the Trust user’s password and ultimately break things. Use nltest to reset your secure channels!

1 Comment so far

  1. Mike Kline on August 21st, 2009

    Welcome back from vacation Florian, sounds like you had a great time.

    Another good entry, and it sort of goes along with joe’s entry on his blog today…perfect timing.

    Talk to you later

    Mike