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 foo.com attempted to access resources in bar.com. If the foo.com user could inject an entry into his SIDHistory that corresponded to the Domain Admins group in bar.com, SIDHistory would lead bar.com to grant the foo.com user all permissions associated with the bar.com\Domain Admins group, thereby elevating this user's privileges in bar.com.

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 bar.com evaluates access attempts from users in the foo.com and child.foo.com domains, bar.com will drop (ignore) any SIDHistory entries that do not have a domain SID corresponding to either foo.com or child.foo.com. (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 child.foo.com to its foo.com parent domain, then bar.com would still recognize the SIDHistory entry from child.foo.com, since that is in the list of "acceptable" domain SIDs.

Figure A

But, if we migrated a user from bar.com to foo.com, that user's bar.com 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 bar.com to point to the migrated user's foo.com 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 bar.com and foo.com, only SIDs that contain the foo.com domain SID will be processed by bar.com; any requests from the child.foo.com 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 child.foo.com to the foo.com parent domain, then bar.com would not recognize the SIDHistory entry from child.foo.com. In addition, it would ignore the SIDHistory entry for a user that was migrated from bar.com to foo.com. In this case, you would need to "re-ACL" resources in bar.com 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 laurahcomputing@gmail.com.
This was first published in August 2006

Dig deeper on Microsoft Active Directory Security

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

-ADS BY GOOGLE

SearchServerVirtualization

SearchCloudComputing

SearchExchange

SearchSQLServer

SearchWinIT

SearchEnterpriseDesktop

SearchVirtualDesktop

Close