{
	"id": "3c1026b6-72df-4c0c-ac14-32fe17b043b9",
	"created_at": "2026-04-06T00:20:05.657941Z",
	"updated_at": "2026-04-10T13:12:24.797157Z",
	"deleted_at": null,
	"sha1_hash": "19b45aa58266cc0fa2b48bc67565ae6052aea7b5",
	"title": "Trust Technologies: Domain and Forest Trusts",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 76018,
	"plain_text": "Trust Technologies: Domain and Forest Trusts\r\nBy Archiveddocs\r\nArchived: 2026-04-05 19:54:28 UTC\r\nApplies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server\r\n2003 with SP2\r\nTrust Technologies\r\nBy default, all users in a specific Windows domain can be authenticated to resources contained within that\r\ndomain. In this way, a domain can provide its users with secured access to all resources in that domain. To expand\r\nthat access to include resources beyond the boundaries of a single domain, you need to use trust relationships.\r\nTrust relationships provide a mechanism for one domain to allow access to resources based on the logon\r\nauthentications of another domain.\r\nTrust Concepts\r\nTrusts in Microsoft Windows NT version 4.0 differ from trusts in the Microsoft Windows 2000 and Windows\r\nServer 2003 operating systems. In domains that have domain controllers running Windows NT 4.0 Server and\r\nearlier, trusts are limited to two domains, and the trust relationship is one-way (only one of the two domains trusts\r\nthe other domain) and nontransitive (does not extend to any other domains trusted by the two domains). With\r\ndomains that have domain controllers running Windows Server 2003 or Windows 2000 Server, all trusts created\r\nwithin a forest are two-way (both domains trust each other) and transitive (extends to all domains in the forest).\r\nDomains that have domain controllers running Windows 2000 Server or Windows Server 2003 (domains that use\r\nthe Active Directory directory service) are also referred to as Active Directory domains.\r\nTo understand trust technology, you should be familiar with basic trust concepts including the nature and purpose\r\nof trust relationships, the role of trusted authorities, the variety of trust paths, and trust transitivity.\r\nTrust Relationships\r\nA trust relationship (also called a trust) is a logical relationship established between domains to allow\r\nauthentication and authorization to shared resources. The authentication process verifies the identity of the user,\r\nand the authorization process determines what the user is permitted to do on a computer system or network. Once\r\na user requesting access to a resource computer in another domain has been authenticated by the resource domain,\r\nthe resource computer compares the user’s credentials to the permissions assigned within its security descriptor to\r\nhelp determine the user’s level of authorization to that resource. A security descriptor contains access control lists\r\n(ACLs) that identify the users and groups that are assigned or denied access permissions on a resource.\r\nIn its simplest form, a trust acts as a technological drawbridge, by either allowing or disallowing authentication\r\ntraffic to flow between two or more domains. When a trust relationship is created between two domains, traffic is\r\nhttps://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc759554(v=ws.10)\r\nPage 1 of 7\n\nallowed over the bridge, permitting the sharing of resources between them, as shown in the following illustration.\r\nSimple Trust Relationship\r\nThe domain where the user account requesting access is located is referred to as the trusted domain. The domain\r\nthat contains a shared resource that a user account is trying to access is referred to as the trusting domain.\r\nSevering a trust removes the bridge through which authentication traffic flows, and removes all relationships to\r\nany trusted authorities located in the other domain. When this occurs, no authentication traffic originating from a\r\nuser in the formerly trusted domain can cross over to the formerly trusting domain; it is no longer possible to share\r\ninformation across domain boundaries, as is shown in the following figure.\r\nSevered Trust Relationship\r\nActive Directory domains do not unconditionally accept credentials coming from other domains; they accept\r\ncredentials only from trusted authorities. In Active Directory, domain controllers act as trusted authorities for all\r\nsecurity principals located in their domain and all security principals located within trusted domains, as long as a\r\nvalid trust is present between those domains.\r\nA trusted authority, in Active Directory, is analogous to a certificate granting agency that distributes certificates by\r\nwhich a sub agency can verify its authenticity. For example, when a passport is issued by a passport authority in\r\none country (a domain controller in a trusted domain), customs officials physically located in another country\r\n(domain controllers in a trusting domain), trust the authority that issued the passport, therefore they trust the\r\nvalidity of the passport.\r\nhttps://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc759554(v=ws.10)\r\nPage 2 of 7\n\nConversely, a company might create a specific means by which to identify employees, such as employee badges\r\nissued by its various departments (domains). The manufacturing department (domain controllers in a trusting\r\ndomain) might trust identification badges issued by the sales department (domain controllers in a trusted domain)\r\nfor important transactions, but other companies (domains or forests that do not have a trust relationship with that\r\ncompany or its departments) would not trust them because they do not inherently trust the authority that issued\r\nthem.\r\nIn Windows NT 4.0 or Active Directory domains, domain administrators act as the chief executive officer of the\r\ncertificate granting agency by defining the policy regarding what external authorities (domains) are trusted in their\r\ndomain. For example, a domain administrator in a trusting domain first identifies which other domains should be\r\ntrusted to access shared resources in the domain. The administrator then establishes the trust relationships that\r\nprovide a path by which authentication requests from trusted domains can travel and be verified. In this way, trusts\r\ndefine for each domain which authentication requests are valid. For more information about trust paths, see “Trust\r\nPaths” later in this overview.\r\nTrust Paths\r\nThe direction that a trust is assigned determines the trust path used for authentication. A trust path is defined by\r\nthe series of trust relationships that authentication requests must follow between domains. Before a user can\r\naccess a resource in another domain, the security system on domain controllers running Windows NT 4.0,\r\nWindows 2000 Server, and Windows Server 2003 must determine whether the trusting domain (the domain\r\ncontaining the resource the user is trying to access) has a trust relationship with the trusted domain (the user’s\r\nlogon domain). To determine this, the security system computes the trust path between a domain controller in the\r\ntrusting domain and a domain controller in the trusted domain. All domain trust relationships have only two\r\ndomains: the trusting domain and the trusted domain. In the following figure, the trust path is indicated by arrows\r\nshowing a one-way direction of trust and the direction of access:\r\nTrust Path in a One-Way Trust\r\nOne-Way Trust\r\nA one-way trust is a unidirectional authentication path created between two domains (trust flows in one direction,\r\nand access flows in the other). This means that in a one-way trust between a trusted domain and a trusting domain,\r\nusers or computers in the trusted domain can access resources in the trusting domain. However, users in the\r\ntrusting domain cannot access resources in the trusted domain. Some one-way trusts can be either nontransitive or\r\ntransitive, depending on the type of trust being created.\r\nhttps://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc759554(v=ws.10)\r\nPage 3 of 7\n\nTwo-Way Trust\r\nA two-way trust can be thought of as a combination of two, opposite-facing one-way trusts, so that, the trusting\r\nand trusted domains both trust each other (trust and access flow in both directions). This means that authentication\r\nrequests can be passed between the two domains in both directions. Some two-way relationships can be either\r\nnontransitive or transitive depending on the type of trust being created. All domain trusts in an Active Directory\r\nforest are two-way, transitive trusts. When a new child domain is created, a two-way, transitive trust is\r\nautomatically created between the new child domain and the parent domain.\r\nTrust Transitivity\r\nTransitivity determines whether a trust can be extended beyond the two domains between which it was formed. A\r\ntransitive trust extends trust relationships to other domains; a nontransitive trust does not extend trust relationships\r\nto other domains. Each time you create a new domain in a forest, a two-way, transitive trust relationship is\r\nautomatically created between the new domain and its parent domain. If child domains are added to the new\r\ndomain, the trust path flows upward through the domain hierarchy, extending the initial trust path created between\r\nthe new domain and its parent.\r\nTransitive trust relationships thus flow upward through a domain tree as it is formed, creating transitive trusts\r\nbetween all domains in the domain tree. A domain tree can therefore be defined as a hierarchical structure of one\r\nor more domains, connected by transitive, bidirectional trusts, that forms a contiguous namespace. Multiple\r\ndomain trees can belong to a single forest.\r\nAuthentication requests follow these extended trust paths, so accounts from any domain in the forest can be\r\nauthenticated by any other domain in the forest. Consequently, with a single logon process, accounts with the\r\nproper permissions can access resources in any domain in the forest.\r\nWith a nontransitive trust, the flow is restricted to the two domains in the trust relationship and does not extend to\r\nany other domains in the forest. A nontransitive trust can be either a two-way trust or a one-way trust.\r\nTrust Architecture\r\nThe architecture of trusts includes various interdependent technologies and processes that, when implemented\r\ntogether, provide cross domain resource sharing. These technologies include authentication, authorization, the Net\r\nLogon service and Active Directory, which all rely on DNS or Windows Internet Name Service (WINS) to locate\r\ndomain service records. The following figure shows the various technologies that make up the trust architecture.\r\nTrust Architecture\r\nhttps://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc759554(v=ws.10)\r\nPage 4 of 7\n\nActive Directory provides the foundation for trust relationships by supplying a central management system\r\nthrough which domain administrators can grant access to trusted authorities in other domains. Trusts then provide\r\nthe mechanism through which authentication traffic between domains or forests must travel to obtain authorization\r\nfor a given shared resource. Authentication and authorization are the security enforcement mechanisms within this\r\nresource access management environment.\r\nThe authentication process and the Net Logon service provide pass-through validation of credentials for users or\r\ndistributed applications located in other domains, and rely on either the NTLM or Kerberos version 5\r\nauthentication protocol to transport all trust related traffic. Applications can use these protocols to securely and\r\nseamlessly integrate with the Active Directory user store for authentication, and can also use these protocols to\r\nsecure application data.\r\nTrust Components\r\nThe various components of trust technologies and the related components that are an important part of the\r\nWindows Server 2003 security architecture determine how trusts function. The following table provides a\r\nsummary view of these components.\r\nTrust Technologies and Related Components\r\nRelated\r\ncomponents\r\nDescription\r\nSecurity\r\nIdentifiers\r\n(SIDs)\r\nThe Windows security model identifies account objects such as users, groups, computers,\r\nand domains by SIDs. SIDs are domain-unique values, built when the user or group is\r\ncreated, or when the computer or trust is registered with the domain. The components of\r\na SID follow a hierarchical convention: A SID contains parts that identify the revision\r\nnumber, the authority — such as the domain — that issued the SID, and a variable\r\nnumber of sub authority or relative identifier (RID) values that uniquely identify the\r\nsecurity principal relative to the issuing authority.\r\nAccess Tokens\r\nand\r\nAuthentication\r\nAn essential component of the Windows-based trust model is authentication, which\r\ninvolves identifying the user to the local or trusted domain by presenting credentials,\r\nusually in the form of a user name and password. Assuming these credentials are\r\nacceptable, the system creates an access token for the user that contains the SID of the\r\nuser (the primary SID), and the SIDs of all the local and domain groups of which the user\r\nis a member. Every process the user creates, for example by running an application,\r\ncarries the user’s access token.\r\nhttps://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc759554(v=ws.10)\r\nPage 5 of 7\n\nSecurity\r\nDescriptors and\r\nAuthorization\r\nOnce authenticated, the user can attempt to gain access to resources from any domain in\r\nthe forest by using the Active Directory authorization process. This process determines\r\nwhat a user is permitted to do on a resource by using the access token to determine\r\nwhether and at what level to grant the user access to system resources. The counterpart of\r\nthe user’s access token is the security descriptor attached to resources such as files or\r\nprinters. A security descriptor contains a discretionary access control list (DACL), which\r\nconsists of a list of access control entries (ACEs). Each ACE consists of a SID that\r\nidentifies a security principal, together with an indicator of the specific access on that\r\nresource that is granted or denied to that security principal.\r\nSIDHistory\r\nIn Active Directory, domain migration or restructuring across trusts is made considerably\r\neasier by an attribute on Active Directory security principals called SIDHistory.\r\nSIDHistory stores the former SIDs of moved objects such as users and security groups.\r\nWhen a user is moved, the SIDHistory attribute of the user object is updated with the\r\nformer SID. When the user then logs on to the system, the system retrieves the entries in\r\nthe user object and the user’s SIDHistory and adds them to the user access token. In this\r\nway SIDHistory ensures that migrated users can continue to access resources located in a\r\ntrusting (resource) domain, even though the user’s new domain does not have a trust\r\nrelationship with the resource domain.\r\nSID Filtering\r\nSID filtering prevents domains from accepting SIDs with domain SIDs from outside the\r\nsender’s domain. Applying SID filtering to trusts can prevent malicious users who have\r\ndomain administrator level access in the trusted domain from granting, to themselves or\r\nother user accounts in their domain, elevated user rights in the trusting domain.\r\nTrust Deployment Scenarios\r\nThere are three scenarios in Active Directory in which specific types of trusts can be used to help accommodate\r\ndifferent resource sharing needs of an organization. These include using trusts within a forest (intra-forest trusts),\r\nusing trusts across forests (inter-forest trusts), and using trusts to collaborate with Kerberos realms.\r\nIntra-Forest Trusts\r\nIntra-forest trusts are transitive trusts that can be used only within a single forest, and include tree-root, parent-child, and shortcut trusts.\r\nTree-root trusts\r\nBy default, two-way, transitive trusts are automatically created when a new domain is added to a domain tree or\r\nforest root domain by using the Active Directory Installation Wizard. When a new domain tree is created in an\r\nhttps://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc759554(v=ws.10)\r\nPage 6 of 7\n\nexisting forest, a new tree-root trust is established.\r\nParent-child trusts\r\nWhen a new child domain is added to an existing domain tree, a new parent and child trust is established.\r\nAuthentication requests made from subordinate domains flow upward through their parent to the trusting domain.\r\nShortcut trusts\r\nYou can use shortcut trusts to improve user logon times between two domains that are located in two separate\r\ndomain trees within the same forest. Authentication requests must first travel a trust path between domain trees,\r\nand in a complex forest this can take time. Using shortcut trusts helps to speed up authentication in this situation.\r\nInter-Forest Trusts\r\nInter-forest trusts can be nontransitive or transitive, depending on the type of inter-forest trust used, and can only\r\nbe created between domains located in different forests or realms. Inter-forest trust types include external trusts\r\nand forest trusts; both of these trust types must be manually created.\r\nExternal trusts\r\nExternal trusts are nontransitive and can be created between Active Directory domains in different forests or\r\nbetween an Active Directory domain and a Windows NT 4.0 domain.\r\nForest trusts\r\nWith Windows Server 2003 forests, you can link two different forests to create a one-way or two-way transitive\r\ntrust relationship. A two-way forest trust is used to form a transitive trust relationship between every domain in\r\nboth forests. Forest trusts can be created only between two Windows Server 2003 forests and cannot be implicitly\r\nextended to a third forest.\r\nKerberos Realm Trusts\r\nA realm trust can be established between any non-Windows-based operating system Kerberos version 5 realm and\r\na Windows 2000 Server or Windows Server 2003 domain. This trust relationship allows cross-platform\r\ninteroperability with security services based on other Kerberos version 5 implementations, such as that from the\r\nMassachusetts Institute of Technology. Realm trusts can be manually switched back and forth between\r\nnontransitive and transitive by using the Netdom.exe tool. Realm trusts can be either one-way or two-way.\r\nSource: https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc759554(v=ws.10)\r\nhttps://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc759554(v=ws.10)\r\nPage 7 of 7",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc759554(v=ws.10)"
	],
	"report_names": [
		"cc759554(v=ws.10)"
	],
	"threat_actors": [],
	"ts_created_at": 1775434805,
	"ts_updated_at": 1775826744,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/19b45aa58266cc0fa2b48bc67565ae6052aea7b5.pdf",
		"text": "https://archive.orkl.eu/19b45aa58266cc0fa2b48bc67565ae6052aea7b5.txt",
		"img": "https://archive.orkl.eu/19b45aa58266cc0fa2b48bc67565ae6052aea7b5.jpg"
	}
}