Problem solve Get help with specific problems with your technologies, process and projects.

SIDs help tighten AD security

Laura Hunter continues her advice on how to manage Active Directory security through the use of Security Identifiers.

In a previous article within this series on Windows 2000 and Windows Server 2003, What's in a name? Active Directory...

security under the covers, Windows server MVP Laura Hunter talked about Active Directory trust relationships and how Windows uses security identifiers (SIDs) to secure resources. She also discussed the SIDHistory attribute, which is a convenient feature for Active directory migrations but can weaken the security of a trust relationship when it's not managed correctly. This week, Hunter puts all of these elements together and examines ways to tighten the security of Active Directory trust relationships.

SIDs keep malicious users out

Each SID contains a number of elements, including what's called a domain SID, which identifies the Windows domain that the user or group belongs to. Likewise, the SIDs in a user's SIDHistory attribute include the domain SID corresponding to all domains that the user previously belonged to.

Prior to Windows 2000 Service Pack 4, when a user attempted to access a resource in a trusting domain, the trusting domain would process all entries in the user's SIDHistory attribute looking for one that granted or denied access to the resource. This became problematic when a malicious user in attempted to access resources in If the user could inject an entry into his SIDHistory that corresponded to the Domain Admins group in, SIDHistory would lead to grant the user all permissions associated with the\Domain Admins group, thereby elevating this user's privileges in

A wall goes up: SID filtering

To help combat this, Windows 2000 Service Pack 4 introduced SID filtering, and this feature remains in place in Windows Server 2003. With SID filtering in place, when evaluates access attempts from users in the and domains, will drop (ignore) any SIDHistory entries that do not have a domain SID corresponding to either or (See Figure A for a graphical representation of this domain structure.) In this way, SID filtering and SIDHistory are predominately (though not entirely) mutually exclusive. For example, if we migrated a user from to its parent domain, then would still recognize the SIDHistory entry from, since that is in the list of "acceptable" domain SIDs.

Figure A

But, if we migrated a user from to, that user's SIDHistory entry would be ignored as long as SID filtering was in place. You would need to update the Access Control Lists (ACLs) on resources in to point to the migrated user's SID, which would allow the user to access them.

SID filtering is enabled automatically on any trust relationships created by domain controllers running Windows 2000 Service Pack 4 or Windows Server 2003. Or, you can manually enable it by using the Netdom trust command line utility with the /EnableSIDHistory:no command line switch. To disable SID filtering (and thus enable SIDHistory), use the /EnableSIDHistory:yes switch.

Quarantine what you can

If even this level of SIDHistory accessibility is too much, you can impose even stricter limits on your trust relationships by enabling the Quarantine feature. (In this context, the Quarantine feature controls SID processing over trust relationships and shouldn't be confused with the Network Access Protection or Network Access Quarantine Control technologies that are used to control local and remote access connections.)

By enabling Quarantine for a trust relationship, you are specifying that only SIDs from the exact domain on the other side of the trust are to be honored. So in our previous example where you configured a trust relationship between and, only SIDs that contain the domain SID will be processed by; any requests from the domain (or SIDHistory entries from that domain) will be ignored. In effect, enabling Quarantine on a trust relationship will break the transitivity of that trust, so that only the specific domains on either side of the trust are considered participants in the trust. In this case, if we migrated a user from to the parent domain, then would not recognize the SIDHistory entry from In addition, it would ignore the SIDHistory entry for a user that was migrated from to In this case, you would need to "re-ACL" resources in to allow both migrated users to access them.

Quarantine is disabled by default on all trust relationships; you can manually enable it by using the Netdom trust command line utility with the /quarantine:yes command line switch. Use the /quarantine:no switch to disable Quarantine on a trust relationship where it has already been enabled.

Laura E. Hunter (CISSP, MCSE: Security, MCDBA, Microsoft MVP) is a senior IT specialist with the University of Pennsylvania, where she provides network planning, implementation and troubleshooting services for business units and schools within the university. Hunter is a two-time recipient of the prestigious Microsoft "Most Valuable Professional" award in the area of Windows Server-Networking. She is the author of the Active Directory Field Guide (APress Publishing). You can contact her at
This was last published in August 2006

Dig Deeper on Microsoft Active Directory Security



Find more PRO+ content and other member only offers, here.

Start the conversation

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.