{
	"id": "34618ea2-e8ac-4eed-9308-42db8b83efd2",
	"created_at": "2026-04-06T00:09:04.903524Z",
	"updated_at": "2026-04-10T03:21:01.81253Z",
	"deleted_at": null,
	"sha1_hash": "4bd052ec35e534bfa9a436a9e7986b54f5d6513f",
	"title": "Security Considerations for Trusts: 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": 103984,
	"plain_text": "Security Considerations for Trusts: Domain and Forest Trusts\r\nBy Archiveddocs\r\nArchived: 2026-04-05 18:31:24 UTC\r\nApplies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with\r\nSP2, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2\r\nIn this section\r\nPotential Threats to Interforest Trusts\r\nSecurity Settings for Interforest Trusts\r\nMinimum Administrative Credentials for Securing Trusts\r\nTrust Security and Other Windows Technologies\r\nRelated Information\r\nThe threat scenarios outlined in this section apply only to trusts made between two forests (also known as interforest trusts),\r\nincluding external and forest trusts. All other trusts made within a forest (also known as intraforest trusts), including parent-child, tree-root, and shortcut trusts, are optimally secured by default and do not require further planning to mitigate any\r\nknown threat. As with intraforest trusts, there are no known threats to realm trusts that require mitigation.\r\nYou should be familiar with these threats before you deploy or configure a Windows Server 2003 network environment.\r\nPotential Threats to Interforest Trusts\r\nThere are two potential threats to interforest trust relationships in Windows Server 2003. These threats can disrupt or\r\nundermine the integrity of interforest trusts.\r\nAttack on trusting forest by malicious user in a trusted forest. A malicious user with administrative credentials\r\nwho is located in a trusted forest could monitor network authentication requests from the trusting forest to obtain the\r\nsecurity ID (SID) information of a user who has full access to resources in the trusting forest, such as a Domain or\r\nEnterprise Administrator. SID filtering is set on all trusts by default to help prevent malicious users from succeeding\r\nwith this form of attack. For more information about how SID filtering works, see “Security Settings for Interforest\r\nTrusts.”\r\nAttack on shared resources in a trusting forest by malicious users in another organization’s forest. Creating an\r\nexternal or forest trust between two forests essentially provides a pathway for authentications to travel from the\r\ntrusted forest to the trusting forest. While this action by itself does not necessarily create a threat to either forest,\r\nbecause it allows all secured communications to occur over the pathway, it creates a larger surface of attack for any\r\nmalicious user located in a trusted forest. Selective authentication can be set on interforest trusts to help minimize\r\nthis attack surface area. For more information about how to mitigate this threat, see “Security Settings for Interforest\r\nTrusts.”\r\nSecurity Settings for Interforest Trusts\r\nThere are two security settings in Windows Server 2003 that can be used to enhance the integrity of communications made\r\nover interforest trusts. SID filtering helps prevent malicious users with administrative credentials in a trusted forest from\r\ntaking control of a trusting forest. Selective authentication lessens the attack surface by restricting the quantity of\r\nauthentication requests that can pass through an interforest trust.\r\nSID Filtering\r\nhttps://technet.microsoft.com/library/cc755321.aspx\r\nPage 1 of 12\n\nSID filtering is set on all trusts to prevent malicious users who have domain or enterprise administrator level access in a\r\ntrusted forest from granting (to themselves or other user accounts in their forest) elevated user rights to a trusting forest. It\r\ndoes this by preventing misuse of the attributes containing SIDs on security principals (including inetOrgPerson) in the\r\ntrusted forest. One common example of an attribute that contains a SID is the SID history attribute (sIDHistory) on a user\r\naccount object. The SID history attribute is typically used by domain administrators to seamlessly migrate the user and\r\ngroup accounts that are held by a security principal from one domain to another.\r\nWhen security principals are created in a domain, the domain SID is included in the SID of the principal to identify the\r\ndomain in which it was created. The domain SID is important because the Windows security subsystem uses it to verify the\r\nidentity of the security principal, which in turn determines what resources in the domain the principal can access.\r\nHow SID History is used to migrate accounts\r\nDomain administrators can simplify account migration by using the SID history attribute to migrate permissions, either\r\nautomatically by using the Active Directory Migration Tool (ADMT) or manually by adding SIDs from an old user or group\r\naccount to the SID history attribute of the new, migrated account. With either method, the new account retains the same level\r\nof permissions or access to resources as the old account. If domain administrators could not use the SID history attribute in\r\nthis way, they would have to determine and reapply permissions on each network resource to which the old account had\r\naccess. For more information about the SID history attribute, see “Trust Security and Other Windows Technologies.”\r\nHow SID History can be used to elevate privileges\r\nAlthough SID history has legitimate and important uses, it can also pose a security threat when used to exploit an\r\nunprotected trust. A malicious user with administrative credentials who is located in a trusted forest could monitor network\r\nauthentication requests from the trusting forest to obtain the SID information of a user, such as a domain or enterprise\r\nadministrator, who has full access to resources in the trusting forest. After obtaining the SID of an administrator from the\r\ntrusting forest, a malicious user with administrative credentials can add that SID to the SID history attribute of a security\r\nprincipal in the trusted forest and attempt to gain full access to the trusting forest and the resources within it.\r\nThis method of gaining access by granting unauthorized user rights to a user is known as an elevation of privilege attack. In\r\nan elevation of privilege attack, an attacker might apply the SID of a domain administrator located in a trusting forest to the\r\nSID history attribute of the attacker’s own account located in a trusted forest, get a ticket that would automatically include\r\nthe new SID, and then use the ticket to access resources in the trusting forest. When the attacker requests the use of a\r\nresource, the access control mechanism considers all SIDs in the authorization data to determine if the principal has the\r\nrights to complete the requested action.\r\nIn an external trust scenario, a malicious user who has domain administrator credentials in the trusted domain is a threat to\r\nthe entire trusting forest. In a forest trust scenario, a malicious user who has domain or enterprise administrator credentials\r\nin the forest root domain of the trusted forest is a threat to the entire trusting forest. Although the concept of elevating\r\nprivileges by modifying SIDs is relatively easy to understand, it is quite difficult to implement. Attackers can use various\r\ntechnologies together with SID history to accomplish an elevation of privilege attack.\r\nApplication Programming Interfaces (APIs)\r\nWindows includes APIs that facilitate account migration. These APIs are not exposed and can only be accessed on a system\r\nthat has been patched to allow access to them. In this case, the APIs could be misused to add SIDs for a user from one\r\ndomain to the SID history of a user in another domain. This is unlikely because these APIs require domain administrative\r\ncredentials for both domains, including the domain being attacked. In order to overcome that security measure, malicious\r\nusers would need to get the password of an account with domain administrative credentials before adding the SID. Attackers\r\nwith access to such an account could more easily use it to accomplish their ultimate goal, rather than having to carry out an\r\nelevation of privilege attack to achieve the goal.\r\nDisk Editors\r\nA disk editor, such as the DiskProbe utility included in the Windows Server 2003 support tools, could also be used to mount\r\nan attack. A malicious user could boot into another operating system and use a disk editor to modify an offline Active\r\nhttps://technet.microsoft.com/library/cc755321.aspx\r\nPage 2 of 12\n\nDirectory database. With a disk editor, the user could modify the SID history attribute, modify replication attributes so the\r\nchange would be replicated, and calculate a new directory checksum so as to prevent Active Directory from detecting that\r\nthe directory was improperly modified. This attack is difficult not only because it requires physical access to a domain\r\ncontroller, but all of the tasks are technically complex.\r\nDebuggers\r\nDebuggers can also be used maliciously. A user could attach a debugger to a domain controller and use it to modify the copy\r\nof the directory loaded in memory. This method is also technically sophisticated. It requires the attacker to have unrestricted\r\nphysical access, be a domain administrator, and be able to use system APIs to modify system-level code that is not publicly\r\navailable.\r\nHow interforest trusts use SID Filtering\r\nEven though a sophisticated attacker might be able to exploit the SID history attribute to gain unauthorized access to\r\nresources, SID filtering can provide an effective countermeasure. An outgoing external or forest trust created from a trusting\r\ndomain can use SID filtering to verify that incoming authentication requests made by security principals in the trusted\r\ndomain contain only SIDs of security principals in the trusted domain.\r\nThe trust compares the SIDs of the requesting security principal to the domain SID of the trusted domain. Any SIDs from\r\ndomains other than the trusted domain are removed, or filtered. When this happens the request for authentication will fail\r\nand the resource will not be accessed.\r\nA stricter form of SID filtering is SID filter quarantining. When a SID filter quarantine is applied to a trusted domain (using\r\nthe trust relationship between the two domains), only SIDs from the trusted domain are allowed to traverse the trust\r\nrelationship. This prevents inbound communications (across the trust relationship) from the trusted domain to claim an\r\nidentity that belongs to any other domain.\r\nSID filter quarantining was designed to be applied to external trust relationships. It should not be applied to forest trust\r\nrelationships, trusts within a domain, or trusts within a forest that has a forest functional level of Windows 2000.\r\nExternal trusts created from domain controllers running Windows 2000 Service Pack 3 (or earlier) do not enforce SID filter\r\nquarantining by default. To improve the security of Active Directory forests, domain controllers running Windows\r\nServer 2003 and Windows 2000 Service Pack 4 or later enable SID filter quarantining on all new outgoing interforest trusts\r\nby default.\r\nNote\r\nThe following restrictions and recommendations apply to using SID filtering to mitigate security threats to external\r\nand forest trusts:\r\nYou cannot turn off the default behavior that enables SID filter quarantining for newly created external trusts.\r\nTo further secure your forest, you should consider enabling SID filter quarantining on all existing external trusts that\r\nwere created by domain controllers running Windows 2000 Service Pack 3 (or earlier). You can do this by using\r\nNetdom.exe to enable SID filter quarantining on existing external trusts, or by recreating these external trusts from a\r\ndomain controller running Windows Server 2003 or Windows 2000 Service Pack 4 (or later). Domain controllers\r\nrunning Windows NT Server 4.0 do not take part in the trust creation process when existing domain controllers in the\r\nsame domain are running Windows 2000 or Windows Server 2003.\r\nHow SID filtering impacts operations\r\nSID filtering can affect your existing Active Directory infrastructure in the following two ways:\r\nUsers who use SID history data for authorization to resources in the trusting domain no longer have access to those\r\nresources.\r\nhttps://technet.microsoft.com/library/cc755321.aspx\r\nPage 3 of 12\n\nBecause SID history that contains SIDs from any domain other than the trusted domain is removed from\r\nauthentication requests made from the trusted domain, the user is denied access to resources that reference the old\r\nSID.\r\nUniversal group access control strategy between forests will require changes.\r\nIf you typically assign universal groups from a trusted forest to access control lists (ACLs) on shared resources in the\r\ntrusting domain, SID filtering will have a significant impact on your access control strategy.\r\nBecause universal groups must adhere to the same SID filtering guidelines as other security principal objects (that is,\r\nthe universal group object SID must also contain the originating domain SID), you should verify that any universal\r\ngroups that are assigned to shared resources in the trusting domain were created in the trusted domain.\r\nIf the universal group in the trusted forest was not created in the trusted domain, even though it might contain users\r\nfrom the trusted domain as members, authentication requests made by members of that universal group will be\r\nfiltered and discarded. Therefore, before assigning access to resources in the trusting domain for users in the trusted\r\ndomain, you should confirm that the universal group containing the trusted domain users was created in the trusted\r\ndomain.\r\nNote\r\nThe default SID filtering on forest trusts does not prevent migrations to domains within the same forest\r\n(intraforest migration) from using SID history, and it will not affect your intraforest universal group access\r\ncontrol strategy. You should not apply SID filter quarantining on trusts between forests (that is, forest trusts or\r\ninterforest trusts).\r\nDisabling SID Filter Quarantining on External Trusts\r\nAlthough it reduces the security of your forest (and is therefore not recommended), you can disable SID filter quarantining\r\nfor an external trust by using the Netdom.exe tool. You should consider disabling SID filter quarantining only in the\r\nfollowing situations:\r\nYou have an equally high level of confidence in the administrators who have physical access to domain controllers in\r\nthe trusted domain and the administrators with such access in the trusting domain.\r\nYou have a strict requirement to assign universal groups to resources in the trusting domain, even when those groups\r\nwere not created in the trusted domain.\r\nUsers have been migrated to the trusted domain with their SID histories preserved, and you want to grant them access\r\nto resources in the trusting domain based on the SID history attribute.\r\nOnly domain administrators or enterprise administrators can modify SID filtering settings. To disable SID filter quarantining\r\nfor the trusting domain, type a command using the following syntax at a command-prompt:\r\nNetdom\r\ntrustTrustingDomainName**/domain:TrustedDomainName/quarantine:No/usero:domainadministratorAcct/passwordo:**domainadminp\r\nTo re-enable SID filtering, set the /quarantine: command-line option to Yes. For more information about Netdom, see\r\n“Domain and Forest Trust Tools and Settings.”\r\nAllowing SID History to Traverse Forest Trusts\r\nIf users are migrated from one domain to another in different forests, you may want to allow the migrated users to access\r\nresources in their original forest using their migrated (SID history) credentials. The default SID filtering applied to forest\r\ntrusts prevents user resource access requests from traversing the trusts with the credentials of the original domain. If you\r\nwant to enable users to use the credentials that were migrated from their original domain, you can allow SID history to\r\ntraverse forest trusts by using the Netdom command.\r\nhttps://technet.microsoft.com/library/cc755321.aspx\r\nPage 4 of 12\n\nOnly domain administrators or enterprise administrators can modify SID filtering settings. To allow SID history credentials\r\nto traverse a trust relationship between two forests, type a command using the following syntax at a command-prompt:\r\nNetdom\r\ntrustTrustingDomainName**/domain:TrustedDomainName/enablesidhistory:Yes/usero:domainadministratorAcct/passwordo:**domaina\r\nTo re-enable the default SID filtering setting across forest trusts, set the /enablesidhistory: command-line option to No. For\r\nmore information about Netdom, see “Domain and Forest Trust Tools and Settings.”\r\nNote\r\nThe same security considerations for removing SID filter quarantining from external trusts apply to allowing SID\r\nhistory to traverse forest trusts.\r\nSelective Authentication\r\nSelective authentication is a security setting that can be set on interforest trusts. It provides Active Directory administrators\r\nwho manage a trusting forest more control over which groups of users in a trusted forest can access shared resources in a\r\ntrusting forest. This increased control is especially important when administrators need to grant access to shared resources in\r\ntheir organization’s forest to a limited set of users located in another organization’s forest, because creating an external or\r\nforest trust provides a pathway for all authentication requests to travel between forests.\r\nWhile this action by itself does not necessarily cause a threat to either forest, because all secured communications occur over\r\nthe pathway, an external or forest trust exposes a larger surface to attack by any malicious user located in a trusted forest.\r\nSelective authentication helps to minimize this exposed area by enabling Active Directory administrators to grant a new\r\nauthentication permission — to computer objects in the resource domain — for specific user accounts located in another\r\norganization’s forest.\r\nThis new authentication permission is set on the security descriptor of the computer object located in Active Directory, not\r\non the security descriptor physically located on the resource computer in the trusting forest. Controlling authentication in\r\nthis way provides an extra layer of protection to shared resources by preventing them from being randomly accessed by any\r\nauthenticated user working in a different organization, unless the user has been granted this permission explicitly by\r\nsomeone with write access to the computer object in Active Directory.\r\nNote\r\nTo enable selective authentication on forest trusts, the trusting forest in which shared resources are located must have\r\nthe forest functional level set to Windows Server 2003. To enable selective authentication on external trusts, the\r\ntrusting domain in which shared resources are located must have the domain functional level set to Windows 2000\r\nnative.\r\nAuthentication Settings for Interforest Trusts\r\nWhen the forest functional level is set to Windows Server 2003, Active Directory Domains and Trusts recognizes three\r\nauthentication settings that can be set on interforest trusts: Domain-wide Authentication, Forest-wide Authentication, and\r\nSelective Authentication. The following table describes these authentication settings in more detail.\r\nAuthentication Settings Used on Interforest Trusts\r\nAuthentication\r\nSetting\r\nInterforest\r\nTrust Type\r\nDescription\r\nDomain-wide\r\nAuthentication\r\nExternal\r\nPermits unrestricted access by any users in the trusted domain to all available\r\nshared resources located in the trusting domain. This is the default\r\nauthentication setting for external trusts.\r\nhttps://technet.microsoft.com/library/cc755321.aspx\r\nPage 5 of 12\n\nAuthentication\r\nSetting\r\nInterforest\r\nTrust Type\r\nDescription\r\nForest-wide\r\nAuthentication\r\nForest\r\nPermits unrestricted access by any users in the trusted forest to all available\r\nshared resources located in any of the domains in the trusting forest. This is the\r\ndefault authentication setting for forest trusts.\r\nSelective\r\nAuthentication\r\nExternal and\r\nForest\r\nRestricts access over an external or forest trust to only those users in a trusted\r\ndomain or forest who have been explicitly given authentication permissions to\r\ncomputer objects (resource computers) residing in the trusting domain or forest.\r\nThis authentication setting must be manually enabled.\r\nDomain- and forest-wide authentication settings\r\nDomain and forest-wide authentication provide an unrestricted pathway in which all authentication requests made by users\r\nin a trusted forest will be successfully authenticated by a domain controller in the trusting forest where the shared resource is\r\nlocated. The following illustration shows how the domain controller in the trusting forest authenticates and routes\r\nauthentication requests made by users in the trusted forest.\r\nAuthentication Requests Are Authenticated and Routed\r\nAuthentication Request is Authenticated and Routed\r\nWhen domain or forest-wide authentication is enabled, users who are authenticated over an interforest trust are\r\nautomatically provided the Authenticated Users SID of the trusting forest in their authorization data. The Authenticated\r\nUsers SID is used to grant many of the default rights for users in a forest.\r\nBecause the Authenticated Users group is a computed group, and its SID is added on the server to which the user\r\nauthenticates, you cannot change the membership of the group. Because of this, after you set up a interforest trust, users\r\nfrom the other forest receive some default rights to all of the resources in the trusting forest that are accessible by the\r\nAuthenticated Users group. Consequently, you might not want to use the domain-wide or forest-wide authentication setting\r\nif the trust is set up only to allow access to a small subset of users who are in the trusted forest.\r\nOnce an authentication request made to a resource in a trusting forest is validated by the trusted forest, it is routed to the\r\ntargeted resource computer, which determines, based on its access control configuration, whether to authorize the specific\r\nrequest made by the user, service, or computer in the trusted forest. In this way, interforest trusts provide the mechanism by\r\nwhich validated authentication requests are passed to a trusting forest, while access control mechanisms on the resource\r\ncomputer determine the final level of access granted to the requestor in the trusted forest.\r\nOnce the authentication request reaches the resource computer, that computer must determine whether the user who initiated\r\nthe authentication request is authorized to access the shared resource it is hosting. It does this by comparing the SIDs\r\nprovided in the access token of the authentication request with the SIDs in the security descriptor that has been granted\r\naccess to the shared resource.\r\nSelective authentication setting\r\nUnlike domain and forest-wide authentication, selective authentication provides a more restrictive pathway in which only\r\nauthentication requests made from users in a trusted forest, who have been granted access to the Active Directory objects\r\nhosting the resources in a trusting forest, can be authenticated by the domain controller in the resource domain. The\r\nfollowing illustration shows how the domain controller in the trusting forest can restrict the flow of authentication requests\r\nmade by users in the trusted forest to shared resources in the trusting forest when those users have not been granted the\r\nappropriate permissions.\r\nAuthentication Requests Are Not Authenticated or Routed\r\nhttps://technet.microsoft.com/library/cc755321.aspx\r\nPage 6 of 12\n\nAuthentication Request Not Authenticated or Routed\r\nHow selective authentication affects domain controller behavior\r\nWhen selective authentication is enabled, all authentication requests made over a trust to the trusting forest are tagged with\r\nan identifier that subjects the request to closer scrutiny by the domain controllers in the domain where the target resource is\r\nlocated. This is important because the mere presence of this identifier triggers the domain controller in the resource domain\r\nto first check whether the user requesting the access has been given explicit permissions to the Active Directory object\r\nwhere the resource is hosted. The appropriate permission to the resource object in Active Directory is verified before the\r\ndomain controller sends a service ticket back to the requesting workstation in the trusted forest. The following illustration\r\nsummarizes how domain controllers in the trusting forest are affected when selective authentication is enabled.\r\nEffect of Selective Authentication on Domain Controllers in the Trusting Forest\r\nForest\r\nThe steps by which domain controllers process authentication requests when selective authentication is enabled are as\r\nfollows:\r\n1. All domain controllers in the domain where the trust is established detect authentication requests made from\r\nthe other organization.\r\nWhen selective authentication is enabled all domain controllers in the forest root domain of a trusting forest (with a\r\nforest trust) or all domain controllers in a resource domain in the trusting forest (with an external trust) are aware that\r\nall authentication requests coming in over that trust are coming from a different organization. This means that when a\r\nuser from a different organization authenticates across a trust with the selective authentication option enabled, the\r\ndomain controller that receives the request in the trusting domain recognizes this user as other than an authenticated\r\nuser located in the trusting forest.\r\n2. Receiving DC in the domain where trust is established tags an identifier to the authorization data of the\r\ntrusted user.\r\nOnce a domain controller receives the request it adds an identifier to the authorization data of the trusted user. This\r\nidentifier is known as the Other Organization SID. The Other Organization SID is used to identify users making\r\nrequests across a trust with selective authentication enabled.\r\n3. All domain controllers in the resource domain detect requests originating from the other organization, and the\r\nreceiving domain controller in the resource domain performs an access check.\r\nWhen a domain controller in a resource domain detects an Other Organization SID in the authorization for the trusted\r\nuser, the domain controller is alerted to first check whether the requesting user has been granted explicit permissions\r\nto the Active Directory object where the resource is hosted. The appropriate permission to the resource object in\r\nActive Directory must be verified before the domain controller can authenticate the access request and send a service\r\nticket back to the requesting workstation in the trusted forest.\r\nThis verification process works by checking the access permissions set on the Allowed to Authenticate permission on\r\nthe discretionary access control list (DACL) on the computer object in Active Directory. When you set selective\r\nauthentication on an outgoing interforest trust, you need to manually assign access to the Allowed to Authenticate\r\npermission on each computer object, which physically represents a member server to which you want users in the\r\ntrusted forest to authenticate.\r\nYou must grant access to this permission in order for users located in a trusted forest to authenticate to the shared\r\nresources hosted by the server computer. If this permission has not been granted to a user whose authorization data\r\ncontains the Other Organization SID, the service ticket to the server hosting the shared resource is not granted and the\r\nauthentication process fails.\r\nNote\r\nhttps://technet.microsoft.com/library/cc755321.aspx\r\nPage 7 of 12\n\nThe following restrictions apply to the Allowed to Authenticate authorization permission:\r\nBy default, only members of the Account Operators, Administrators, Domain Administrators, Enterprise\r\nAdministrators, and SYSTEM security groups located in the trusting domain can modify the Allowed to\r\nAuthenticate authorization permission.\r\nWhen Kerberos is used for authentication, the Allowed to Authenticate permission should be enabled on\r\ncomputer accounts when the service that hosts the resource is running as Local System or Network Service. If\r\nthe service that hosts the resource is running as a Domain Service account, the permission should be\r\nconfigured on that account. For example, if the SQL service is running under the account SQLServer, the\r\nSQL Server account has to have the Allowed to Authenticate permission enabled for users to be able to\r\nauthenticate to that account across trusts that have selective authentication enabled.\r\nWhen NTLM is used for authentication, the Allowed to Authenticate permission should be granted to the\r\ncomputer account, even if the service that you want to connect to is using a domain user account.\r\nWhen a Windows NT 4.0, Windows 2000 Server, or Windows Server 2003 member server receives an authentication\r\nrequest from a user, regardless of whether that user is identified with the Other Organization SID, the member server\r\nautomatically adds the Authenticated Users SID for the trusting forest to the authorization data for that user.\r\nHow selective authentication affects Windows Server 2003 member server authentication\r\nWhen users who are located in a domain within the trusting forest (or in a trusted domain that does not have selective\r\nauthentication enabled) authenticate to local Windows Server 2003 member servers, the Authenticated Users SID and a new\r\nidentifier indicating that they belong to the same organization are placed in their authorization data. This new identifier is\r\nknown as the This Organization SID. Only the Other Organization SID or the This Organization SID can be present in the\r\nauthorization data of an authenticated user along with the Authenticated Users SID. The following table describes the SIDs\r\nthat can be added to the authorization data of a user throughout the entire selective authentication process and shows when\r\nthey are added.\r\nSIDs Added to Authorization Data During the Selective Authentication Process\r\nSID Purpose When Added to User Authorization Data\r\nAuthenticated\r\nUsers\r\nAdds default access rights to\r\nresources in the trusting forest.\r\nBecause this SID is mandatory for\r\nall incoming authentication requests,\r\nit prevents all anonymous access to\r\nresources in the trusting forest.\r\nAdded when any incoming authentication request to a\r\nmember server is made from a user who has been identified\r\nwith the Other Organization SID. This SID is always applied\r\nby the member server to the authorization data of an\r\nincoming user, in addition to one of the other SIDs in this\r\ntable.\r\nThis\r\nOrganization\r\nIdentifies users who access\r\nresources locally within a trusting\r\nforest or across a trust that is not\r\nmarked for selective authentication.\r\nAdded when users who are located in any of the domains\r\nwithin a trusting forest authenticate to a local Windows\r\nServer 2003 member server. This SID and the Authenticated\r\nUsers SID are added by the member server. The Other\r\nOrganization SID cannot be added to this authorization data\r\nof this user.\r\nOther\r\nOrganization\r\nIdentifies users coming across a\r\ntrust that is marked for selective\r\nauthentication.\r\nAdded when any incoming authentication request is made\r\nfrom a user located in a trusted forest to a domain controller\r\nin the domain in the trusting forest where the trust is\r\nestablished. This SID is added by the domain controller that\r\ninitially receives the authentication request. The\r\nhttps://technet.microsoft.com/library/cc755321.aspx\r\nPage 8 of 12\n\nSID Purpose When Added to User Authorization Data\r\nAuthenticated Users SID is not added to the authorization\r\ndata of the user until the member server has authenticated the\r\nuser.\r\nNote\r\nThe Allowed to Authenticate permission can be set on computer objects that represent member servers running\r\nWindows NT Server 4.0, Windows 2000 Server, and Windows Server 2003. However, only member servers running\r\nWindows Server 2003 can provide the This Organization SID to the authorization data of a user.\r\nProcessing authentication requests made over forest trusts with selective authentication enabled\r\nBefore an authentication request made with the Kerberos version 5 authentication protocol can follow the forest trust path,\r\nthe service principal name (SPN) of the resource computer must be resolved to a location in the other forest. A SPN is a\r\nmulticomponent name that is used to identify a service that is associated with a computer account. When a workstation in\r\none forest attempts to access data on a resource computer in another forest, the Kerberos authentication process contacts the\r\ndomain controller for a service ticket to the SPN of the resource computer. Once the domain controller queries the global\r\ncatalog and determines that the SPN is not in the same forest as the domain controller, the domain controller sends a referral\r\nback to the workstation for its parent domain. The workstation queries its parent domain for the service ticket and continues\r\nto follow the referral chain until it reaches the domain where the resource is located.\r\nOnce the workstation reaches a domain controller in the root domain of the resource forest where selective authentication is\r\nenabled, the domain controller adds the Other Organization SID to the authorization data for the user. After the Other\r\nOrganization SID is added, the domain controller in the resource domain checks the Allowed to Authenticate permission on\r\nthe computer object (located in Active Directory) that is hosting the resource. If the user has been granted access the domain\r\ncontroller issues a service ticket back to the workstation. This is an important part of the selective authentication process,\r\nbecause if the user does not have permission to authenticate to the computer object, a service ticket will not be granted and\r\naccess to the target resource computer fails. In this way, the selective authentication setting restricts what authentication\r\nrequests can pass through a trust and obtain a ticket for a target resource computer.\r\nThe following figure and corresponding steps provide a detailed description of the Kerberos authentication process that is\r\nused when computers running Windows 2000 Professional, Windows XP Professional, Windows 2000 Server, or Windows\r\nServer 2003 attempt to access resources from a computer located in another forest when selective authentication is enabled.\r\nKerberos authentication process over a forest trust with selective authentication enabled\r\nKerberos authentication over a forest trust\r\nThis illustration incorporates images from Active Directory Users and Computers in the Microsoft Management Console to\r\nhelp you better understand at what point during the authentication process a domain controller queries the Allowed to\r\nAuthenticate permission for the resource object.\r\n1. Acctuser1 logs on to Workstation1 using credentials from the Sales.tailspintoys.com domain. The user then attempts\r\nto access a shared resource on FileServer1 located in the WingtipToys forest. Acctuser1 is also a member of the\r\nAccounting global group in the Sales.tailspintoys.com domain.\r\n2. Workstation1 contacts the Key Distribution Center (KDC) on a domain controller in its domain (TailspinDC1) and\r\nrequests a service ticket for the FileServer1 SPN. FileServer1 is located in the Mktg.wingtiptoys.com domain and is a\r\nmember server.\r\n3. TailspinDC1 does not find the SPN in its domain database and queries the global catalog to see if any domains in the\r\nTailspinToys forest contain this SPN. Because a global catalog is limited to its own forest, the SPN is not found. The\r\nglobal catalog then checks its database for information about any forest trusts that are established with its forest, and,\r\nif any are found, it compares the name suffixes listed in the forest trust trusted domain object (TDO) to the suffix of\r\nhttps://technet.microsoft.com/library/cc755321.aspx\r\nPage 9 of 12\n\nthe target SPN to find a match. Once a match is found, the global catalog provides a routing hint back to\r\nTailspinDC1.\r\n4. Using the information in the routing hint, TailspinDC1 sends a referral for a domain controller located in the forest\r\nroot domain of the WingtipToys forest back to Workstation1.\r\n5. Workstation1 contacts a domain controller in the forest root domain (WingtipDC1) of the Corp.wingtiptoys.com\r\nforest and requests a service ticket to the Fileserver1 resource computer.\r\n6. WingtipDC1 contacts its global catalog to find the SPN, and the global catalog finds a match for the SPN and sends it\r\nback to WingtipDC1.\r\n7. Because the authentication request originated from the TailspinToys forest and selective authentication is enabled\r\nWingtipDC1 applies the Other Organization SID to the user’s authorization data and then sends a referral for the\r\nmktg.wingtiptoys.com domain back to Workstation1.\r\n8. Workstation1 contacts the KDC on WingtipDC2 and attempts to negotiate a ticket for Acctuser1 to gain access to\r\nFileServer1.\r\n9. WingtipDC2 detects the Other Organization SID in the authorization data of Acctuser1, which requires the domain\r\ncontroller to first locate the computer object of the resource computer (Fileserver1) before providing a ticket back to\r\nthe requesting computer.\r\n10. Once the computer object is located, the domain controller must check whether the user requesting access to the\r\nresource computer has been explicitly granted the Allowed to Authenticate permission on the Fileserver1 computer\r\nobject located in the Mktg.wingtiptoys.com domain. This process must complete successfully before WingtipDC1\r\ncan provide a ticket back to the requesting computer.\r\nNote\r\nIn this example, Acctuser1 is a member of the Accounting group in the TailspinToys forest and that group has\r\nbeen explicitly granted the Allowed to Authenticate permission to this computer object residing in Active\r\nDirectory.\r\n11. After WingtipDC1 determines that Acctuser1 has the required permission to Filerserver1, it sends a service ticket\r\nback to Workstation1 permitting it to gain access to FileServer1.\r\n12. Now that Workstation1 has a service ticket, it sends the server service ticket to FileServer1, which reads the security\r\ncredentials for Acctuser1 and constructs an access token accordingly.\r\nImpact of Selective Authentication\r\nBecause all verification of incoming interforest authentication requests is done locally on the receiving domain controller in\r\nthe trusting forest, access to resources in the trusting forest is likely to be extremely limited for a broad set of users on the\r\nnetwork (which is the purpose of this security setting). Consequently, implementing selective authentication might require\r\nuser education, particularly due to the following reasons:\r\nUsers browsing network resources through My Network Places to resources located in a trusting forest might get\r\naccess denied messages when attempting to access those resources.\r\nResources in the trusting forest that were once available to users in a trusted forest might no longer be available.\r\nNote\r\nAs a security best practice it is recommended that resource administrators in a trusting forest remove the default\r\naccess rights granted to the Authenticated Users group in all of the shared resources in the trusting forest. This\r\npractice will help to further minimize the possibility of authenticated users inside and outside of a forest from\r\naccessing protected resources.\r\nhttps://technet.microsoft.com/library/cc755321.aspx\r\nPage 10 of 12\n\nEnabling and Disabling Selective Authentication\r\nSelective authentication must be manually enabled or disabled by using Active Directory Domains and Trusts or the\r\nNetdom.exe tool. To enable selective authentication for the trusting domain, type a command using the following syntax at a\r\ncommand-prompt:\r\nNetdom\r\ntrustTrustingDomainName**/domain:TrustedDomainName/SelectiveAuth:Yes/usero:domainadministratorAcct/passwordo:**domainadm\r\nTo disable selective authentication, set the /SelectiveAuth: command-line option to No. For more information about the\r\nNetdom tool, see “Domain and Forest Trust Tools and Settings.”\r\nYou can enable or disable selective authentication only from the trusting side of a trust. If the trust is a two-way trust, you\r\ncan also enable or disable selective authentication in the trusted domain by using the credentials of the domain administrator\r\nfor the trusted domain and reversing the values of TrustingDomainName and TrustedDomainName in the command.\r\nNote\r\nYou can further increase security in a forest by enabling selective authentication on all external and forest trusts used\r\nto connect forests that are not managed by the IT department in your organization.\r\nMinimum Administrative Credentials for Securing Trusts\r\nThe following table lists the minimum administrative credentials necessary to enable or disable the SID filtering and\r\nselective authentication security settings in Active Directory.\r\nMinimum Administrative Credentials Necessary To Secure Trusts\r\nSID Filter Quarantining -\r\nExternal Trusts\r\nAllowing SID History\r\n- Forest Trusts\r\nSelective Authentication -\r\nExternal Trusts\r\nSelective Authentication -\r\nForest Trusts\r\nYou must be a member of\r\nthe Domain Admins group\r\nin the trusting domain or\r\nthe Enterprise Admins\r\ngroup in the trusting forest.\r\nYou must be a member\r\nof the Domain Admins\r\ngroup in the forest root\r\ndomain or the\r\nEnterprise Admins\r\ngroup in the trusting\r\nforest\r\nYou must be a member of\r\nthe Domain Admins group\r\nin the trusting domain or the\r\nEnterprise Admins group in\r\nthe trusting forest.\r\nYou must be a member of\r\nthe Domain Admins group\r\nin the forest root domain or\r\nthe Enterprise Admins group\r\nin the trusting forest\r\nTrust Security and Other Windows Technologies\r\nTrust security can be affected or enhanced by other technologies built into the Windows operating system. These include\r\nSID history and the Lightweight Directory Access Protocol (LDAP).\r\nSID History\r\nSID History is used to store the former SIDs of moved objects such as users and security groups. Prior to Windows 2000,\r\nrestructuring a domain generally meant the creation of new accounts that needed to be placed in the same groups the old\r\naccounts were placed in. Since Windows 2000, domain restructuring is considerably easier because of SIDHistory, which is\r\nan attribute of Active Directory security principals.\r\nAs part of the move operation for the user or group, Application Programming Interfaces (APIs), or tools and support\r\nutilities built from these APIs, update the SIDHistory attribute of the object, representing it in Active Directory with its\r\nformer SID. When the user next logs on to the system, not only the new SID, but also the old SID retrieved from the\r\nSIDHistory attribute is added to the user’s access token and serves to determine the user’s group memberships. The SIDs of\r\nhttps://technet.microsoft.com/library/cc755321.aspx\r\nPage 11 of 12\n\nthe groups of which the user is a member (through either the new SID or the old SID) are also added to the access token,\r\ntogether with any SIDHistory those groups might have.\r\nGroups have a SIDHistory attribute because they also can be moved. The system retrieves the SIDHistory attributes of all\r\nthe groups of which the user is a member and adds these attributes to the user’s access token. Because these SIDHistory\r\nentries in the token look to the operating system like normal group memberships during authorization checks, the token can\r\ngrant appropriate access even on earlier versions of the operating system.\r\nBecause old SIDs can be stored in SIDHistory, the user can continue to access resources after a move without requiring\r\nadministrators to modify ACLs. Once a migration is complete, if all needed resources are in the new domain, use of\r\nSIDHistory can be phased out if desired.\r\nNote\r\nThe SIDHistory attribute can be updated only in native mode Windows 2000 or Windows Server 2003 domains,\r\nwhich requires all migration operations relying on SIDHistory to have a native mode target.\r\nFor more information about the security threat that exploits SID history, see “Security Settings for Interforest Trusts.”\r\nLDAP Sign and Encrypt\r\nWhen using Windows Server 2003, secure LDAP traffic is enabled so that Active Directory administrative tools sign and\r\nencrypt all LDAP traffic by default. In this way, secured LDAP traffic enhances the security of communications that can\r\noccur between trusts.\r\nActive Directory Domains and Trusts signs and encrypts all LDAP traffic by default. Signing LDAP traffic guarantees that\r\nthe packaged data comes from a known source and that it has not been tampered with. Active Directory administrative tools\r\nin Windows 2000 do not sign and encrypt all LDAP traffic by default. In order to maintain a secure network, it is strongly\r\nrecommended that you upgrade all domain controllers running Windows 2000 to Service Pack 3 or later.\r\nYou can use the corresponding Active Directory administrative tools in Windows 2000 to manage Windows 2000 domain\r\ncontrollers that do not have the Windows 2000 Server Service Pack 3 or later installed. However, traffic is not signed and\r\nencrypted by LDAP on domain controllers running Windows 2000.\r\nThe following resources contain additional information that is relevant to this section.\r\nDomains and Forests Technical Reference\r\nKerberos Authentication Technical Reference\r\nSecurity Identifiers Technical Reference\r\nSecurity Principals Technical Reference\r\nSource: https://technet.microsoft.com/library/cc755321.aspx\r\nhttps://technet.microsoft.com/library/cc755321.aspx\r\nPage 12 of 12",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://technet.microsoft.com/library/cc755321.aspx"
	],
	"report_names": [
		"cc755321.aspx"
	],
	"threat_actors": [],
	"ts_created_at": 1775434144,
	"ts_updated_at": 1775791261,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/4bd052ec35e534bfa9a436a9e7986b54f5d6513f.pdf",
		"text": "https://archive.orkl.eu/4bd052ec35e534bfa9a436a9e7986b54f5d6513f.txt",
		"img": "https://archive.orkl.eu/4bd052ec35e534bfa9a436a9e7986b54f5d6513f.jpg"
	}
}