This is the last of six articles by contributor Dean Wells that dissect the Active Directory architecture. Dean is Director of Technology Solutions at MSEtechnology, a consulting organization that provides services such as solution analysis, solution design and implementation and technology seminars as well as customized training.
SID filtering scenarios
In Dissecting the AD architecture: Tickets, tokens and the authentication process, we talked about the authentication process and the resulting constructs used to express a user's identity in Windows. Ultimately, we use these identity constructs, specifically the session ticket and the embedded access token, to identify the user requesting access to a specific resource. In turn, we provide that resource with the information necessary to decide whether to grant or deny access, i.e., perform the process of authorization.
When both a user and a resource exist in the same domain or the same forest, an assumed level of trust exists between them. Upon joining the domain, both of them implicitly consent to trust a number of potentially sensitive elements including physical security, logical security, policy set by administrative staff and even administrative practices. Once decrypted, the content of an access token is therefore trusted, virtually without question and without consideration for any form of identity spoofing or other maliciously intended act. It is, however, worth noting that certain sensitive portions of a ticket are encrypted and/or signed in order to ensure their confidentiality and integrity.
Note: Identity spoofing is a means of elevating one's privilege beyond what it should naturally be. In the scenario outlined above, identity spoofing is achieved by falsifying security IDs (SIDs) within an access token (often referred to as SID injection).
There are a number of scenarios in which SID filtering is used. The most common situation is when a user and resource exist in separate forests connected via either a cross-forest or an external trust relationship. Unlike the implied trust between a user and a resource in the same domain or forest, SID filtering provides for an additional validity check on the SIDs within the foreign user's ticket before considering them trustworthy.
SID filtering behaviors and configuration
In order to understand the specifics of the criteria used to determine whether or not a SID should be filtered, we must also understand the following related facts:
The configuration of a trust relationship is primarily maintained using an object known as a trusted domain object or TDO. Along with a number of other configuration components, the domain SID of the trusting and/or trusted domain is maintained on the TDO specific to each trust.
A number of the elements that comprise a security principal's SID are derived from the SID of the domain in which it was created. For example:
CORPUser SID: S-1-5-21-2649212323-1185644723-1044911867-
Domain name: corp.msetechnology.com
Domain SID/component: 2649212323-1185644723-1044911867
With this in mind, a mechanism becomes apparent that permits a Domain Controller (DC) to decide for itself which SIDs are trustworthy and which should be filtered. The key aspects of that decision-making process are outlined below.
- The CORP domain receives a ticket from domain OTHER.
- The OTHER domain is identified as trusted.
- The trust relationship configuration indicates that SID filtering is enabled.
- The Access token is extracted from ticket's PAC attribute.
- The domain component of each SID within the access token is isolated and compared against OTHER's domain SID (i.e., the SID of the domain from which the ticket originated).
- Any SID whose domain component (the middle piece) does not match that of the domain SID of the ticket's origin (the OTHER domain) is considered untrusted and is filtered.
OTHERDWells : S-1-5-21-200-11097 → TRUSTED
OTHERAppUsers : S-1-5-21-200-10183 → TRUSTED
<unrecognized SID> : S-1-5-21-999-10183 → FILTERED!
<unrecognized SID> : S-1-5-21-100-10183 → FILTERED!
Configuring SID filtering
You can configure SID filtering using a number of tools since its configuration is maintained on trusted domain objects (TDOs) within Active Directory as one or more bits. Microsoft has, however, provided a command line interface in an attempt to simplify the process of turning SID filtering on or off. In the example provided earlier, SID filtering would have been configured using either of the following syntaxes:
netdom trust CORP /domain:OTHER /quarantine:YES
netdom trust CORP /domain:OTHER /enableSIDhistory:NO
Note the variation in the switches and, more specifically, their opposing values. Although the two values appear to be functionally opposite, they are in fact both turning SID filtering ON. The switches merely alter a specific aspect of SID filtering behavior. The first switch uses language that addresses the SID filtering feature itself allowing an administrator to switch it ON or OFF. The second, and more confusing switch, uses language that references a resulting behavior, i.e., SID history is not enabled because SID filtering is turned ON.
The "/enableSIDhistory" switch is applied to cross-forest trusts and, when set to "NO," filters any SID whose domain component does not match the domain SID of any of the domains found within the trusted forest. The "/quarantine" switch is typically applied to external trusts and causes SID filtering to consider only those SIDs from the single, directly trusted domain as valid. Unwanted behaviors may result from using the "/quarantine" switch against a cross-forest trust.
Dean Wells has been in the information technology industry since 1987 providing consulting and training services on the leading platforms. Originally from the U.K., he is now the Director of Technology Solutions and a co-founder of MSEtechnology, a consulting/training organization. Dean is a Microsoft Directory Services and Security MVP and delivers internal-only classes to Microsoft Product Support Services on Windows Infrastructure technologies.