What's in a name? Active Directory security under the covers

Laura Hunter delves a bit deeper into ways to manage Active Directory security when the need arises to create trust relationships beyond those that are created by default.

In our last article, we took an introductory look at trust relationships between different domains and forests

under Windows 2000 and Windows Server 2003. This week, we'll start to delve a bit deeper into ways to manage Active Directory security when you need to create trust relationships beyond those that are created by default. In addition to the default trust relationships that exist within an Active Directory forest, you can also configure trusts with external domains and forests using either an external or a forest trust. I'll discuss in this article the issues related to Active Directory forest trusts and security.

What's a forest trust anyway?

An external trust is one that you'll create with a Windows NT 4 domain or a Windows 2000 domain in a separate Active Directory forest. External trusts are non-transitive, and can be one-way or two-way in direction. Forest trusts are new to Windows Server 2003, and can only be enabled between two forests that are operating at the Windows Server 2003 forest functionality level. Forest trusts can be one-way or two-way, and will create a transitive trust relationship between each domain in Forest A and each domain in Forest B.

Keeping your forest secure

So what does this mean for the security of an environment that has one or more of these trust relationships configured? To answer that, we first need to develop at least a basic understanding of how permissions are applied within a Windows domain. Each Windows security principal (a user, group or computer object) is assigned a numeric security identifier, or SID. This SID is unique within the domain and does not change even if the security principal is renamed or moved to another container within the same domain. (The SID is not retained if an object is deleted and re-created with the same display name; the re-created object would be a brand-new object with a completely different SID.) All access control lists (ACLs) on files, folders or Active Directory objects use this SID to determine whether a particular user or computer should be granted or denied access.

Security identifiers key to migration

The notion of SIDs became a bit problematic, though, when people began migrating from Windows NT domains into new Active Directory environments. If you migrated a number of user objects from a legacy NT domain into a new Active Directory domain, a new SID was created for the migrated user, corresponding to the new domain. If this migrated user still required access to resources in the old NT domain, however, an issue cropped up in which their new Active Directory SID would not match their old NT4 SID. To combat this, Windows 2000 introduced a feature called SID History, which allowed migrated user objects to retain records of any old SIDs they had once possessed. This would allow a migrated user to continue to access a resource that used his or her old SID in its access control list. If the user attempted to access the resource with their current SID and was denied, Windows would check the SID History attribute to see if any previous SIDs would fit the bill and allow access.

Be paranoid about security

The paranoid among us shouldn't need to look too hard to find a way in which SID History has the potential to be a really bad idea from a security perspective. All an attacker would need to do would be to find the SID of an administrative account from the domain on the other side of the trust, and then inject that SID into their own SID History attribute. (In network security parlance, this is known as an elevation of privilege attack.)

Do a sanity check

So unless the trusting domain has some way to perform a "sanity check" on the contents of the SIDHistory attribute, this convenient feature of Active Directory could be exploited for malicious purposes. Enter: SID Filtering. The SID Filtering function will take major steps to mitigate the security risks presented by SID History. This function has become a default security measure on all trust relationships created on Windows 2000 Service Pack 4 and Windows Server 2003. If you have trust relationships that were created on pre-Service Pack 4 domain controllers, you can enable SID Filtering by either breaking and re-creating the trust, or by using the netdom command-line utility to enable SID Filtering.

In our next article, we'll examine some more specifics of SID Filtering and SID History, and examine some common scenarios that you might encounter when deploying manually-created Active Directory trust relationships.

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 Group Policy Management

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:

SearchServerVirtualization

SearchCloudComputing

SearchExchange

SearchSQLServer

SearchWinIT

SearchEnterpriseDesktop

SearchVirtualDesktop

Close