This is the fourth 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.
In this article, we'll touch on the relatively well-known concepts of security identifiers (SIDs) and trust relationships and two lesser-known related features called SID filtering and the authentication firewall. SIDs are fundamental components within the Windows security model; as such, understanding the impact of SID filtering and its affect on resource access across trust relationships is critical.
Introduction to security identifiers (SIDs)
Microsoft's Windows operating systems use a structure known as a security identifier (SID) to express the identity of objects to which the permission to use a resource can be assigned. These objects are collectively known as security principals and consist of users, groups, computers and an industry standard object class that is virtually identical to a user known as an inetOrgPerson.
Note: A user's identity is, among other things, expressed by a collection of SIDs. It comprises the user's own SID, the SIDs of those groups in which the user is a member (either directly or transitively) and any SIDs migrated from domains in which the user or the user's groups previously existed. The resulting construct is referred to as an "access token."
SIDs are system generated, highly complex and considered statistically unique. They are built from a number of distinct components including revision information, issuing authorities, a domain-SID and a relative identifier (or RID). The resulting SID looks something like this:
- S-1-5-21 -2649212323-1185644723-1044911867- 1005
‹revision & issuing authorities -----------------------------------------------------------------›
‹domain component ---------------------------------------›
Note: The techniques used to generate SIDs within Microsoft's Active Directory Application Mode (ADAM) differ from those used by security principals housed within a SAM database and/or Active Directory.
Introduction to trust relationships
Simply stated, a trust relationship consists of two domains and provides the necessary configuration between them to grant security principals on one side of the trust permission to use the resources that exist in the domain on the other. The trust is necessary because, in the world of Windows and other similar technologies, a domain does not unconditionally accept a user's credentials from other domains. Therefore, it is cumbersome or impossible to, for example, grant users from one domain the ability to print to a printer in another.
The two sides of a Windows compatible trust relationship can consist of any of the following collective entities:
- A Windows NT domain
- An Active Directory domain
- An Active Directory forest
- A Kerberos realm
A number of possible combinations of these four collective entities exists; the typical combinations are named and described below:
- Intra-forest trusts
* created automatically between contiguously named Active Directory domains within the same forest
*created automatically between a new Active Directory domain-tree root (a discontiguous namespace) and the forest root within a forest
- Shortcut trusts
* administratively created between discontiguously named Active Directory domains within the same forest
* administratively created between Active Directory domain-tree roots within the same forest (peer root domains)
* administratively created between contiguously named Active Directory domains separated by an intermediary domain (grandparent domain to grandchild domain)
- External trusts
* administratively created between two Active Directory domains either not in the same forest or when one or both of the domains is hosted by Windows NT
- Cross-forest trust
* administratively created between two Active Directory forests
* the trust must be created between the two forest root domains
* the two forests must both be hosted by Windows 2003 or later domain controllers and the forest functional level must be raised to a minimum of two
- Realm trust
* created between a Windows domain and a Kerberos realm
Other components of a trust relationship
In addition to the two halves that make up a trust relationship, three additional properties of a trust must also be understood:
- Trust transitivity ("A" → "B" → "C")
* a trust relationship is considered transitive if it permits trusting domains to, in turn, trust who it trusts. For example, if domain "A" trusts domain "B" and domain "B" trusts domain "C," then the trusts between domains "A & B" and domains "B & C" are deemed transitive only if domain "A" can be said to trust domain "C" without the need for a third explicit trust between "A" and "C"
- Trust directions ( → or ← or ← → )
* a trust relationship can be expressed as uni- or bi-directional
- Supported authentication protocols (NTLM and/or Kerberos)
*a trust relationship is capable of supporting only those authentication protocols for which it was designed
* a modern Windows trust relationship supports either NTLM or both NTLM and Kerberos
* legacy Windows NT trusts supported only NTLM
Enhancing the security of a trust relationship
Two trust-related security enhancement technologies exist: SID filtering and the authentication firewall. SID filtering was introduced in the early days of Windows 2000 while the authentication firewall is available only with Windows 2003.
In the next article, we'll cover the specifics of the authentication process including how SIDs are used and the construction of tickets and access tokens.
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.