Windows Server for beginners. Part 21: How do multiple domains and forests work?
All parts of the series “Windows Server for beginners”Part 3 set a rule: one forest, one domain. Eighteen parts later it still holds, but it has exceptions, and to recognize them you need to understand what exactly the domains of one forest share, what they don't, and where the boundary lies beyond which a second domain doesn't help and a second forest is needed. This part is about how a forest of several domains is built, when it's needed and how it's created; the next two are about trusts between forests, that is, about how life works beyond that boundary.
What the domains of a forest share
The forest corp.example.com with the child domain eu.corp.example.com and a second tree shop.example.net:
Forest corp.example.com
┌─────────────────────────────────────────────────────────────────────────┐
│ Schema ─────────── one for all: a class added for Exchange in corp │
│ exists in eu and in shop too │
│ Configuration ──── one: sites, subnets, site links, partitions, │
│ certificate templates, authorized DHCP servers │
│ Global catalog shared: a GC of any domain knows names, SIDs and │
│ the partial attribute set of all three domains │
│ Trust ──────────── automatic, two-way, transitive: │
│ corp ↔ eu (parent-child), corp ↔ shop (tree root); │
│ eu trusts shop through corp │
│ Enterprise Admins a group of the root domain with rights to everything │
│ Schema Admins ──── the same for the schema │
│ UPN suffixes ───── a forest-wide list: the suffix example.com works in │
│ any domain, and a UPN is unique across the forest │
│ DNS partitions ─── ForestDnsZones and the root's _msdcs zone holding │
│ records of GCs and controllers of all domains │
│ Forest functional level, AD Recycle Bin, KDS root key for gMSA │
└─────────────────────────────────────────────────────────────────────────┘
Domain corp.example.com Domain eu.corp.example.com Domain shop.example.net
┌──────────────────────┐ ┌──────────────────────┐ ┌──────────────────────┐
│ own users, │ │ own │ │ own │
│ computers, groups │ │ │ │ │
│ own domain SID │ │ own │ │ own │
│ own krbtgt │ │ own │ │ own │
│ own Domain Admins │ │ own │ │ own │
│ own GPOs │ │ own │ │ own │
│ own password │ │ own │ │ own │
│ policy │ │ │ │ │
│ own controllers, │ │ own │ │ own │
│ at least two │ │ │ │ │
│ DomainDnsZones │ │ own │ │ own │
└──────────────────────┘ └──────────────────────┘ └──────────────────────┘
The forest's directory is divided into partitions (naming contexts), and each one replicates by its own rules. The schema and the configuration go to every controller of the forest. The domain partition DC=eu,DC=corp,… goes in full only to the controllers of eu, and to the global catalogs of the other domains as a partial copy: the objects with all attributes marked isMemberOfPartialAttributeSet in the schema (name, SID, UPN, mail, phone, department and a few hundred more), and the membership of universal groups only — global and domain local groups are in the GC as objects, but without their members. The application partitions DomainDnsZones (one per domain) and ForestDnsZones (one per forest) hold the DNS zones and replicate only to the controllers with a DNS server listed in their crossRef; they don't go into the global catalog.
A domain is a unit of data replication: the users of the European division are stored in full only on the eu controllers. A domain is a unit of administration: it has its own Domain Admins, its own policies, its own password policy. A domain is a unit of naming: EU\alice and CORP\alice are different people.
But the controllers of all domains sit in the same sites, obey the same configuration, and all of them have one list of administrators who can do anything: the Enterprise Admins of the root domain.
Why child domains used to be needed
Four reasons from the year 2000, and what became of them:
Replication over slow links. In Windows 2000 the smallest unit of replication was a whole attribute: adding one member to a group sent the whole member attribute, so groups over 5,000 members were not supported, and a large domain behind a slow link was expensive. A separate domain in a branch kept its data at home. With the Windows Server 2003 forest functional level the values of linked attributes replicate separately (linked-value replication), replication between sites goes compressed and on a schedule (part 10), and a branch gets an RODC (part 11). The reason is gone.
Different password policies. Before 2008 there was one password policy per domain: you need a strict one for administrators and a lenient one for the shop floor — two domains. Since Windows Server 2008 there are fine-grained policies (part 13). The reason is gone.
Administrative separation. A division wants its own administrators who can't touch anything else. Delegation on OUs gives the same inside a domain, and a separate domain gives it only on paper, as shown below. The reason is gone.
Legal requirements on data residency. Personal data of a European company's employees must not be stored on servers outside the EU. The eu domain partition replicates in full only to the eu controllers, and this is the only mechanism in the directory that gives such a guarantee — with a caveat: the partial copy (name, mail, phone, department — everything in the partial attribute set) goes to every global catalog of the forest. This reason remains, and it's the main reason child domains are created today.
The price of a child domain: at least two controllers per domain (fault tolerance isn't shared between domains), global catalogs with partial copies of all domains, the group scope rules (part 3), a separate set of policies, separate Domain Admins who also need watching, and a Kerberos path through two or three KDCs on every access to another domain.
Why a domain is not a security boundary
The administrator of the child domain eu is not supposed to have rights in corp. And he doesn't — by the access lists. But he has a domain controller, and the controller holds writable copies of the schema and configuration partitions, which are shared by the whole forest. Running as SYSTEM, the controller can change anything in them, and the change replicates to the root domain's controllers like any other: every controller of the forest trusts every other controller of the forest.
He has the krbtgt key of his domain. With it he can issue himself a ticket whose PAC carries, besides his own groups, the SID of the root domain's Enterprise Admins group. Inside a forest such SIDs are not filtered: the PAC specification drops "foreign" privileged SIDs only on a trust to another forest, on an external trust and on a trust marked as quarantined (SID filtering is in the next part). The root domain accepts that ticket just like a ticket of a real forest administrator. Writing that SID into the sIDHistory of an object on his own controller gives the same.
None of these paths needs anything beyond the Domain Admins rights in the child domain and the will to do it. Microsoft puts it this way: each forest is a separate instance of the directory and a security boundary, and a domain is an administrative boundary. The administrator of any domain in the forest is technically able to become a forest administrator, and the only protection is trust in that person and auditing. If that trust isn't there — a division, a contractor, an acquired company with its own administrators — a second domain gives nothing. You need a second forest.
When a second forest is needed
- A separate administration that isn't trusted unconditionally. An acquired company before integration, a contractor, a joint venture.
- The schema. Two products with incompatible schema extensions, two Exchange organizations (one forest — one Exchange organization), an application that needs a schema you don't want in the main forest.
- A test forest for schema extensions and changes that can't be undone (part 5): a copy of the structure where an LDIF file is tested before it's loaded into production.
- Perimeter. A forest for DMZ servers with a one-way trust to the internal one, so that a compromised web server gives nothing inside.
- An administrative forest. A separate forest for the administrator accounts of the main forest (the ESAE model, the "red forest"): the tier 0 workstations and accounts from part 15 live there, and the main forest trusts it one way. Microsoft no longer recommends this model by default and treats it as a custom configuration for exceptional cases — isolated environments without cloud services; existing administrative forests that work as designed don't have to be retired.
The price of a second forest: no shared global catalog (Outlook won't find a recipient from the other forest without separate setup), no automatic trust, applications built for one forest don't work across two, synchronization with Entra ID gets more complex, and every pair of forests is a trust that has to be set up, maintained and protected.
Kerberos between domains
The user alice@eu.corp.example.com opens \\fs1.corp.example.com\share. Her KDC in eu doesn't have the FS1$ key — it's in another domain. The eu KDC doesn't find the SPN cifs/fs1.corp.example.com in its partition, asks the global catalog which domain of the forest it's registered in, and issues a referral ticket: a TGT for the realm CORP.EXAMPLE.COM, encrypted with the trust key between the domains. She takes it to the corp KDC:
ws-eu (alice@EU) KDC eu KDC corp fs1 (corp)
│ │ │ │
├─ TGS-REQ cifs/fs1.corp ─►│ │ │
│ │ not my realm → │ │
│◄─ TGS-REP: TGT for CORP, │ │ │
│ {…}K_trust(eu→corp) ───┤ │ │
├─ TGS-REQ cifs/fs1.corp with TGT ───────────────────►│ │
│ │ │ decrypts with the │
│ │ │ trust key; alice from │
│ │ │ EU, groups from PAC + │
│ │ │ her corp groups │
│◄─ TGS-REP: ticket for fs1 {…}K_fs1$ ────────────────┤ │
├─ AP-REQ ─────────────────────────────────────────────────────────────────────►│
The trust key is a password shared by the two domains. It's stored in the trusted domain object (TDO) in CN=System and in the trust account — the user EU$ with the INTERDOMAIN_TRUST_ACCOUNT flag in CN=Users of the corp domain (and CORP$ in eu). The password changes automatically every 30 days, like a computer password: the PDC emulator of the trusting domain starts the change, and a two-way trust is two one-way trusts, so the password of each direction changes separately. At each hop the realm is added to the ticket's transited field, and the final service sees which domains the authentication went through. The path between domains of different trees (us.eu.corp.example.com → shop.example.net) goes along parent-child trusts up to the forest root and down from it, through three or four KDCs; a shortcut trust between two distant domains straightens it.
The groups are collected into the PAC along the way. The global groups of eu and the universal groups of the forest were written by the eu controller at logon (the universal ones after learning the membership from the GC). The corp domain local groups that alice belongs to are added by the corp KDC when it issues the ticket for fs1. The scope rules from part 3 follow from this mechanism.
Creating a child domain
The controller dc-eu1 is prepared as in part 1, its DNS client points to a corp controller. Promotion into a new domain is the third cmdlet of the ADDSDeployment module, one we haven't used yet; as in part 4, it runs on the server's own console:
PS C:\> Install-WindowsFeature AD-Domain-Services -IncludeManagementTools
PS C:\> Install-ADDSDomain -NewDomainName eu -ParentDomainName corp.example.com -DomainType ChildDomain -NewDomainNetbiosName EU -DomainMode WinThreshold -Credential (Get-Credential CORP\alice.admin) -InstallDns -CreateDnsDelegation -SiteName Office -SafeModeAdministratorPassword (Read-Host -AsSecureString) -Force
For a child domain -NewDomainName is a single label (eu), and the full name is formed with -ParentDomainName. The account has to be in Enterprise Admins: creating a domain is a forest-level operation, and it goes through the owner of the Domain Naming Master role (part 17). -DomainMode can't be lower than the forest level, but it can be higher. -CreateDnsDelegation creates a delegation of eu to the new controller in the corp.example.com zone. What happens beyond a regular promotion:
- a
crossRefobject forDC=eu,DC=corp,DC=example,DC=comappears inCN=Partitions, named after the domain's NetBIOS name (EU), withdnsRoot,nETBIOSNameand its own functional level inmsDS-Behavior-Version; - a domain partition is created with a new SID, its own
krbtgt, Administrator, Domain Admins and the other built-in objects, plus the application partitionDomainDnsZonesof theeudomain for its DNS zone; trustedDomainobjects pointing at each other are created inCN=Systemof both domains, and the trust accountsEU$andCORP$inCN=Users: a two-way transitive parent-child trust with a generated password;- the
eucontroller registers its forest-level records — its CNAME<GUID>._msdcs, the record_ldap._tcp.<domain GUID>.domainsand, if it's a GC, thegcrecords — in the_msdcs.corp.example.comzone of the forest root, and the records of its own domain (_ldap._tcp.dc._msdcs.eu.corp.example.comand others) in theeu.corp.example.comzone; - the first controller becomes a global catalog by default (
-NoGlobalCatalogturns that off), and all GCs of the forest start holding a partial copy of the new domain.
A new tree is the same cmdlet with -DomainType TreeDomain -NewDomainName shop.example.net -ParentDomainName corp.example.com: here -NewDomainName is a full name that is not a descendant of an existing one, and the trust is a tree-root trust with the forest root instead of parent-child. The shop.example.net zone has to resolve from the whole forest — it's placed in the ForestDnsZones partition.
In the output of familiar cmdlets, Get-ADForest then shows both domains in Domains and dc-eu1 among GlobalCatalogs; Get-ADDomain corp.example.com gets eu.corp.example.com in ChildDomains and the partition DC=eu,… in SubordinateReferences; Get-ADTrust -Filter * on the corp side shows the trust eu.corp.example.com with Direction BiDirectional, IntraForest True and TrustAttributes 32 (the WITHIN_FOREST bit).
The three domain-wide FSMO roles of the new domain are on its first controller; the two forest-wide ones stay in corp. The second controller for eu is Install-ADDSDomainController -DomainName eu.corp.example.com, as in part 10, and without it eu is a domain with a single copy of its data.
Living with several domains
Searching. Get-ADUser -Server eu.corp.example.com searches in eu; -Server corp.example.com:3268 searches the whole forest through the global catalog, but only on attributes of the partial set. At logon by UPN a controller looks for it first in its own domain, then in the GC, because the domain doesn't follow from the UPN: alice@example.com can be in any domain. The suffix example.com itself is not the name of a domain in the forest, so it's first added to the forest's list of alternative suffixes (uPNSuffixes of the CN=Partitions container, the cmdlet Set-ADForest -UPNSuffixes @{Add='example.com'}); without that a UPN can end only in the name of one of the forest's domains.
Groups. A global group of eu can be a member of a domain local group of corp, and that's the main way to give eu users access to corp resources. Universal groups with members from both domains are stored in the GC together with their membership, and their changes replicate across the whole forest — convenient for mailing lists, expensive for groups with thousands of members that change often.
Moving objects. A user can be moved from eu to corp within the forest: Move-ADObject -Identity $dn -TargetPath 'OU=Sales,OU=Departments,DC=corp,DC=example,DC=com' -Server dc-eu1.eu.corp.example.com -TargetServer dc1.corp.example.com. Both servers have to be the RID Master role owners of their domains (-TargetServer by its full name), otherwise the cmdlet answers "The requested operation could not be performed because the directory service is not the master for that type of operation". The password moves with the object, the object gets a new SID in the new domain, the old one is written to sIDHistory, and permissions granted to the old SID keep working. Moving between forests works differently — with separate migration tools — and isn't covered in this series.
Policies and delegation are per domain, each has its own. A policy that has to be the same in both is copied: Copy-GPO -SourceName 'Workstations Baseline' -SourceDomain eu.corp.example.com -TargetName 'Workstations Baseline' -TargetDomain corp.example.com (with -MigrationTable if it contains SIDs and paths of the source domain).
Administrators. When a machine joins the domain, the eu Domain Admins get into its local Administrators group — on eu machines, and only there. Enterprise Admins are members of the built-in Administrators group of every domain in the forest, that is, administrators of all controllers. By default Enterprise Admins contains only the Administrator of the root domain; the group is kept empty and filled for the duration of the operations that need it: creating a domain, authorizing DHCP, extending the schema.
Renaming. A domain inside a forest can be renamed with the rendom tool and even moved to a different place in the tree (given a new parent); after that every member of the renamed domain is restarted twice. You can't move a domain to another forest or merge forests this way, and in a forest with Exchange 2007 or 2010 renaming isn't supported. It's a "once in the lifetime of a forest" operation, and it's usually simpler to create a new domain and move the objects into it.
A hands-on look
Our forest has a single domain so far, and it shows well everything that will multiply later. The commands run on the workstation ws1 in PowerShell 7. The forest and the domain:
PS C:\> Get-ADForest | Select-Object Name, RootDomain, Domains, ApplicationPartitions, GlobalCatalogs, UPNSuffixes, Sites
Name : corp.example.com
RootDomain : corp.example.com
Domains : {corp.example.com}
ApplicationPartitions : {DC=DomainDnsZones,DC=corp,DC=example,DC=com, DC=ForestDnsZones,DC=corp,DC=example,DC=com}
GlobalCatalogs : {dc2.corp.example.com, dc1.corp.example.com, dc3.corp.example.com, dc4.corp.example.com}
UPNSuffixes : {}
Sites : {Office, Branch}
PS C:\> Get-ADDomain | Select-Object DNSRoot, NetBIOSName, ParentDomain, ChildDomains, DomainMode, SubordinateReferences
DNSRoot : corp.example.com
NetBIOSName : CORP
ParentDomain :
ChildDomains : {}
DomainMode : Windows2016Domain
SubordinateReferences : {DC=DomainDnsZones,DC=corp,DC=example,DC=com, DC=ForestDnsZones,DC=corp,DC=example,DC=com, CN=Configuration,DC=corp,DC=example,DC=com}
UPNSuffixes is empty: there are no alternative suffixes, and users' UPNs end in corp.example.com. SubordinateReferences lists the partitions that sit "under" the domain partition in the name tree: both DNS partitions and the configuration; at a forest root with a child domain, DC=eu,… would be here too.
The partitions a controller holds are in the namingContexts of its RootDSE:
PS C:\> (Get-ADRootDSE).namingContexts
DC=corp,DC=example,DC=com
CN=Configuration,DC=corp,DC=example,DC=com
CN=Schema,CN=Configuration,DC=corp,DC=example,DC=com
DC=ForestDnsZones,DC=corp,DC=example,DC=com
DC=DomainDnsZones,DC=corp,DC=example,DC=com
Five partitions: the domain, the configuration, the schema and two DNS application partitions. On a global catalog in a forest of several domains, the partitions of the other domains — partial copies — would be added here.
Each partition is described by a crossRef object in CN=Partitions of the configuration:
PS C:\> Get-ADObject -SearchBase (Get-ADForest).PartitionsContainer -LDAPFilter '(objectClass=crossRef)' -Properties nCName, nETBIOSName, systemFlags, msDS-Behavior-Version, msDS-NC-Replica-Locations | Format-Table nCName, nETBIOSName, systemFlags, msDS-Behavior-Version, @{n='Replicas'; e={$_.'msDS-NC-Replica-Locations'.Count}} -AutoSize
nCName nETBIOSName systemFlags msDS-Behavior-Version Replicas
------ ----------- ----------- --------------------- --------
CN=Configuration,DC=corp,DC=example,DC=com 1 0
CN=Schema,CN=Configuration,DC=corp,DC=example,DC=com 1 0
DC=ForestDnsZones,DC=corp,DC=example,DC=com 5 4
DC=DomainDnsZones,DC=corp,DC=example,DC=com 5 4
DC=corp,DC=example,DC=com CORP 3 7 0
systemFlags are bits from the specification: 1 — a partition of this forest (not an external one), 2 — a domain partition, 4 — the partition isn't replicated to the global catalog. The configuration and the schema are 1, the domain is 3 (1 + 2), the DNS partitions are 5 (1 + 4), that is, application partitions. A list of controllers holding a copy (msDS-NC-Replica-Locations) exists only for application partitions — four controllers with DNS; the domain, schema and configuration are on all controllers of their domain and forest by definition. The functional level (msDS-Behavior-Version) is recorded only on the domain: 7 is Windows Server 2016. Domain levels are independent, but none can be lower than the forest level. The names of the crossRef objects aren't in the table: for the domain it's the NetBIOS name CORP, for the DNS partitions a GUID, for the schema and configuration Enterprise Schema and Enterprise Configuration.
Replication partners — separately for each partition:
PS C:\> repadmin /showrepl dc1 | Select-String '^(DC|CN)=|via RPC'
DC=corp,DC=example,DC=com
Branch\DC3 via RPC
Office\DC2 via RPC
CN=Configuration,DC=corp,DC=example,DC=com
Office\DC2 via RPC
Branch\DC3 via RPC
CN=Schema,CN=Configuration,DC=corp,DC=example,DC=com
Office\DC2 via RPC
Branch\DC3 via RPC
DC=ForestDnsZones,DC=corp,DC=example,DC=com
Branch\DC3 via RPC
Office\DC2 via RPC
DC=DomainDnsZones,DC=corp,DC=example,DC=com
Office\DC2 via RPC
Branch\DC3 via RPC
The application partitions show up here; Get-ADReplicationPartnerMetadata -Partition * doesn't show them — only the domain, the configuration and the schema.
The partial attribute set is the schema attributes with isMemberOfPartialAttributeSet:
PS C:\> $schema = (Get-ADRootDSE).schemaNamingContext
PS C:\> (Get-ADObject -SearchBase $schema -LDAPFilter '(objectClass=attributeSchema)').Count
3952
PS C:\> (Get-ADObject -SearchBase $schema -LDAPFilter '(&(objectClass=attributeSchema)(isMemberOfPartialAttributeSet=TRUE))').Count
697
PS C:\> (Get-ADObject -SearchBase $schema -LDAPFilter '(&(objectClass=attributeSchema)(isMemberOfPartialAttributeSet=TRUE)(!(lDAPDisplayName=msExch*)))').Count
310
This forest's schema is extended for Exchange, and more than half of the attributes in the partial set are Exchange's (msExch*). What it means in practice shows when you read one object through the GC port 3268 and through regular LDAP:
PS C:\> $dn = (Get-ADUser Administrator).DistinguishedName
PS C:\> $gc = Get-ADObject $dn -Server dc1:3268 -Properties *
PS C:\> $dc = Get-ADObject $dn -Server dc1 -Properties *
PS C:\> $gc.PropertyNames.Count; $dc.PropertyNames.Count
39
53
PS C:\> $dc.PropertyNames | Where-Object { $_ -notin $gc.PropertyNames }
accountExpires
adminCount
badPasswordTime
badPwdCount
codePage
countryCode
isCriticalSystemObject
lastLogoff
lastLogon
lockoutTime
logonCount
logonHours
msDS-SupportedEncryptionTypes
msExchPreviousRecipientTypeDetails
Through port 3268 even a controller of the object's own domain returns only the partial set: logon counters, lockout, account expiration aren't for forest-wide search.
The scopes of the built-in groups:
PS C:\> Get-ADGroup -Filter "Name -eq 'Administrators' -or Name -eq 'Domain Admins' -or Name -eq 'Enterprise Admins' -or Name -eq 'Schema Admins' -or Name -eq 'Domain Users'" | Sort-Object Name | Format-Table Name, GroupScope, DistinguishedName -AutoSize
Name GroupScope DistinguishedName
---- ---------- -----------------
Administrators DomainLocal CN=Administrators,CN=Builtin,DC=corp,DC=example,DC=com
Domain Admins Global CN=Domain Admins,CN=Users,DC=corp,DC=example,DC=com
Domain Users Global CN=Domain Users,CN=Users,DC=corp,DC=example,DC=com
Enterprise Admins Universal CN=Enterprise Admins,CN=Users,DC=corp,DC=example,DC=com
Schema Admins Universal CN=Schema Admins,CN=Users,DC=corp,DC=example,DC=com
PS C:\> Get-ADGroupMember Administrators | Where-Object objectClass -eq 'group' | Select-Object Name
Name
----
Domain Admins
Enterprise Admins
Enterprise Admins and Schema Admins are universal: they exist only in the root domain but have to work across the whole forest. Domain Admins is a global group of its domain. Administrators is a built-in domain local group; Enterprise Admins is a member of it in every domain of the forest, hence their rights on all controllers.
The _msdcs zone of the forest root and the global catalog records in it:
PS C:\> Get-DnsServerZone -ComputerName dc1 -Name _msdcs.corp.example.com | Format-Table ZoneName, ReplicationScope, DirectoryPartitionName -AutoSize
ZoneName ReplicationScope DirectoryPartitionName
-------- ---------------- ----------------------
_msdcs.corp.example.com Forest ForestDnsZones.corp.example.com
PS C:\> Get-DnsServerResourceRecord -ComputerName dc1 -ZoneName _msdcs.corp.example.com -RRType Srv | Where-Object HostName -like '*gc' | Format-Table HostName, @{n='Target'; e={$_.RecordData.DomainName}}, @{n='Port'; e={$_.RecordData.Port}} -AutoSize
HostName Target Port
-------- ------ ----
_ldap._tcp.Branch._sites.gc dc4.corp.example.com. 3268
_ldap._tcp.Branch._sites.gc dc3.corp.example.com. 3268
_ldap._tcp.Office._sites.gc dc1.corp.example.com. 3268
_ldap._tcp.Office._sites.gc dc2.corp.example.com. 3268
_ldap._tcp.gc dc3.corp.example.com. 3268
_ldap._tcp.gc dc2.corp.example.com. 3268
_ldap._tcp.gc dc1.corp.example.com. 3268
_ldap._tcp.gc dc4.corp.example.com. 3268
The zone lives in ForestDnsZones, that is, on the DNS servers of all domains of the forest. dc-eu1 would register here too if it's a GC — and corp clients would find a global catalog in eu when there's none closer.
Finally, the domains of the forest as nltest sees them:
PS C:\> nltest /domain_trusts /forest
List of domain trusts:
0: CORP corp.example.com (NT 5) (Forest Tree Root) (Primary Domain) (Native)
The command completed successfully
/forest limits the list to the domains of the machine's own forest. The line is our domain: a tree root (Forest Tree Root), the domain of this machine (Primary Domain), NT 5 meaning an Active Directory domain. With a child domain the list would get a second line, EU eu.corp.example.com, with the flags Direct Outbound and Direct Inbound (a direct trust in both directions) and the attribute withinforest. The trustedDomain object of such a trust has trustDirection 3 — two-way, trustType 2 — Active Directory, trustAttributes 32 — the WITHIN_FOREST bit; a trust to another forest has the FOREST_TRANSITIVE bit (8) instead. And alice's ticket cache after accessing fs1 (klist) holds three tickets: her own TGT krbtgt/EU.CORP.EXAMPLE.COM @ EU.CORP.EXAMPLE.COM, the referral krbtgt/CORP.EXAMPLE.COM @ EU.CORP.EXAMPLE.COM issued by the eu KDC (the realm after @ is the issuer), and the service ticket cifs/fs1.corp.example.com @ CORP.EXAMPLE.COM issued by the corp KDC.
Sources
- Understanding the Active Directory Logical Model and Appendix A: Reviewing Key AD DS Terms — the forest, the domain as a partition and an administrative unit, the forest as a security boundary;
- Determining the Number of Forests Required — when a separate forest is needed and why one forest is cheaper;
- Enhanced Security Admin Environment (ESAE) architecture mainstream retirement — the administrative forest as a custom configuration;
- How Domain and Forest Trusts Work — TDOs, the trust password change every 30 days, parent-child and tree-root trusts, shortcut trusts, referral processing;
- [MS-PAC]: SID Filtering and Claims Transformation — which SIDs are filtered on which trusts, no filtering inside a forest, quarantine;
- [MS-ADTS]: trustAttributes — the
WITHIN_FOREST,FOREST_TRANSITIVEand other bits; - [MS-ADTS]: Cross-Ref Objects and [MS-ADTS]: System Flags —
crossRefobjects and thesystemFlagsbits of partitions; - Global catalog replication — the partial attribute set and group membership in the GC;
- How the Active Directory Replication Model Works — whole-attribute replication in Windows 2000, the 5,000-member limit, linked-value replication;
- Active Directory security groups — group scopes, Enterprise Admins and Schema Admins;
- User Naming Attributes — the UPN, its uniqueness in the forest,
upnSuffixes, the GC lookup,sIDHistoryon a move between domains; - Active Directory Domain Services Functional Levels — the domain level is not lower than the forest level;
- Install-ADDSDomain — parameters for creating a child domain and a new tree;
- Get-ADForest, Get-ADDomain, Get-ADTrust and Set-ADForest — properties of the forest, the domain and trusts, UPN suffixes;
- Move-ADObject — moving between domains of a forest through the RID Master owners;
- Copy-GPO — copying a policy between domains of a forest;
- Get-ADReplicationPartnerMetadata — replication partners from PowerShell;
- Administering Active Directory Domain Rename and Restart Member Computers — what domain rename can do, Exchange restrictions, restarting domain members twice;
- Verify SRV DNS records have been created — a controller's records in
_msdcs; - Nltest —
/domain_trustsand its switches.
Inside a forest a trust appears by itself and works without any setup. Between forests it has to be created, and it has parameters that decide what exactly the other forest will be able to do in yours.
Next — part 22: trusts between forests. Trust types — external, forest, shortcut, realm; direction and transitivity; what each forest's DNS needs to know about the other; netdom trust and .NET classes in place of the missing trust creation cmdlet, and verification; SID filtering and selective authentication; name suffix routing and what happens when two forests have the same UPN suffix.
Only registered users can leave a comment.
Sign in or register to leave a comment.