AD DS: SID filtering is not enabled for an external trust
Applies To: Windows Server 2008 R2, Windows Server 2012
This topic is intended to address a specific issue identified by a Best Practices Analyzer scan. You should apply the information in this topic only to computers that have had the Active Directory Domain Services Best Practices Analyzer run against them and are experiencing the issue addressed by this topic. For more information about best practices and scans, see Best Practices Analyzer.
Windows Server 2008 R2
Windows Server 2012
Active Directory Domain Services (AD DS)
SID filtering is not enabled for an external trust established with a domain.
If authentication occurs across an external trust boundary (where the user and the computer hosting the resource are in different domains), a vulnerability exists because this domain (the trusting domain) does not verify that the trusted domain is actually authoritative for all the SIDs in the authorization data (that is, the access token). It is possible for an attacker or rogue administrator to insert SIDs into the authorization data presented to this trusting domain.
By inserting SIDs into the authorization data, an attacker can elevate the privileges of an account and then access all data and resources for the domain and, potentially, the forest.
Enable SID filtering for the external trust by using the netdom trust /quarantine:yes command. Enabling SID filtering may prevent users from accessing resources in your environment. Before enabling SID filtering for the trust, you should review the detailed resolution procedures for this BPA rule.
Care should be taken when enabling SID filtering for external trusts because the action will cause all SIDs that do not belong to the trusted domain to be filtered out. SID filtering can also prevent the ability for universal groups to access resources because universal groups that are not in the trusted domain will be filtered out.
If you are migrating user accounts from this domain to an external domain and you want the migrated users to take advantage of SID history so that they can continue to access resources in this domain, you might have deliberately disabled SID filtering. But after resource access using SID history is no longer required, you should enable SID filtering again.
Disabling SID filtering for the long term is not recommended because of the inherent security risks. To mitigate the problem, you can reassign permissions to the resources to the migrated user’s new account—a process typically known as “re-ACLing.” Reassigning permissions to resources can be a complex and lengthy task, and if resources are missed during the process, users may be denied access to them.
Reassigning permissions is achieved by:
Determining the SIDs of the accounts (users, groups, and computers) in the source domain.
Determining the SIDs of the accounts in the new target domain.
Identifying any resources throughout the organization that grant permissions to the old SID of each account.
Adding an equivalent access control entry (ACE) with the same permission and characteristics (inherited, target object-scope, and others) to the SID of the newly migrated account in the new target domain.
You can use a tool, such as the Active Directory Migration Tool (ADMT), to migrate accounts from a source domain to a target domain, and you can use the Security Translation Wizard to maintain permissions to resources during the migration. For more information about using ADMT, see ADMT v3.1 Guide: Migrating and Restructuring Active Directory Domains (http://go.microsoft.com/fwlink/?LinkId=93678).
Membership in Domain Admins group or the Enterprise Admins, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at Local and Domain Default Groups (http://go.microsoft.com/fwlink/?LinkId=83477).
You can enable SID filtering of a trusted domain only from the trusting side of the external trust.
To enable SID filtering on an external trust
Log on to an administrative workstation that has Active Directory Domain Services Tools installed, and then open an elevated command prompt. To open an elevated Command Prompt window, click Start, point to All Programs, click Accessories, right-click Command Prompt, and then click Run as administrator.
At the command prompt, type the following command, and then press ENTER:
netdom trust <TrustingDomainName> /domain: <TrustedDomainName> /quarantine:Yes /userD: <domainadministratorAcct> /passwordD: <domainadminpwd>
The Domain Name System (DNS) name (or NetBIOS name) of the trusting domain in the trust that is being created.
The DNS name (or NetBIOS name) of the domain that will be trusted in the trust that is being created.
The user account name with the appropriate administrator credentials to modify the trust.
The password of the user account in <domainadministratorAcct>.