Windows domains before Active Directory: NT domains, master domains, and the trust maze
Part 1from the Windows domains series · 6 parts in all
Fifteen years after Active Directory shipped, the shape of its design still only makes sense once you understand what it replaced. This series starts where Microsoft's enterprise identity story actually started: the NT domain, and the elaborate topologies engineers built when one domain stopped being enough.
The NT domain was a flat file wearing a suit
An NT domain was one Security Account Manager (SAM) database on one machine — the PDC. Domain controllers were strictly tiered: the PDC held the one writable copy of accounts, and the BDCs held read-only copies synced by a single-master replication model. Administrators who wanted to edit a user on a BDC got an error. Password changes rippled one way, from the PDC outward. It was simple, predictable — and it topped out at roughly 40,000 accounts before the SAM database became painful, which was a real problem for enterprises that had 50,000 employees.
The master domain model: org charts drawn in trusts
The official scaling answer was to link several domains with NTLM trusts. These trusts were one-way and non-transitive — if ACCOUNTS trusted SALES, that proved nothing about MARKETING. So the same two shapes appeared at every big shop:
- Single master domain — one account domain, many resource domains (print/file servers, SQL boxes) that trusted it. Fine below ~20,000 users.
- Multiple master domain — a small cluster of account domains (typically split by geography or division), all trusted by a wide base of resource domains. Users' SIDs accumulated across domains; every group membership across a trust was another hand-maintained path.
The result was an org chart drawn in one-way arrows. Moving a department between domains meant rebuilding SIDs and ACLs. Nobody had a global catalog; "find every group this user is in across the company" was a day of scripting.
What a trust actually authenticated
Underneath, everything was NTLM: the workstation proved the user's password knowledge to the domain, and the domain proved the user's identity across a trust using an inter-domain NTLM handshake backed by a shared inter-domain trust password. Name resolution leaned on NetBIOS and WINS. There was no Kerberos, no policy objects, no schema — identity lived in the SAM and access lived in ACLs, full stop.
# what a legacy NT4-era box still confesses about itself today
net config server # server name, domain, Windows version
nltest /trusted_domains # the trust list this machine sees
netdom query trust /domain:SALES # direction matters: read it like an arrow
# NT trusts are one-way and non-transitive: ACCOUNTS trusts SALES does NOT
# imply ACCOUNTS trusts MARKETING. Every path was drawn and paid for by hand.
Why the pain mattered
By the late 1990s the model was buckling under three pressures: growth (the 40k account ceiling), change (M&A and reorgs meant trust surgery), and delegation (the only administrative boundary was the domain, so helpdesk delegation forced either new domains or dangerously broad rights). Windows 2000's Active Directory — the subject of part 2 — was designed around precisely those three complaints: a hierarchical database instead of a flat one, transitive trusts instead of hand-drawn paths, and OUs plus Group Policy instead of "another domain for the helpdesk".
Next: how the forest, the tree, and the transitive trust changed the geometry overnight — and why the forest is still the security boundary a quarter-century later.