Domain local security groups for cross-forest security

With multi-domain forests there is a chance of access control entries being ignored when querying a Global Catalog if domain local groups for a domain other than that of the current GC are used to secure directory objects. This can include both allowing and denying access, each of which carry risks. This is mitigated somewhat as this is limited to GC read-only operations on secured Active Directory objects, but still needs to be carefully assessed before using in multi-domain forests. There are no known issues with single-domain forests.

These issues arose in the scenario of a cross-forest administration domain, where there is little choice but to use domain local groups to secure directory objects in managed domains, thereby enabling access to be granted to global/universal groups across-forests.

This goes against general Microsoft recommendation, and some research has been completed to further understand the limitations.

Scenario:

1. Connecting with a cross-forest account to administer a trusting domain.
2. The cross-forest account is a member of a global or universal group in the trusted domain
3. The cross-forest group is a member of a trusting domain local group
4. ACLs are applied on directory objects to the domain local group.
5. The trusting domain is one of several domains in a forest
6. There is an external one-way NTLM trust, with each domain in the forest being accessed (but I don't believe a forest trust would change the result)
7. ACLs are set on a local group in the trusting domain denying access to the read a security group object.
8. The user is a member of this cross-forest domain global group that is a member of the domain local group to deny access

The cross-forest user tries to query the secured object:

• dsquery * "CN=SecurityGroupName,CN=Users,%domainDN%" -attr * -gc
  

As access is denied on this object, Dsquery reports:

• dsquery failed:The specified directory service attribute or value does not exist.

However, to bypass the security applied to the ACE, you could target the GC query at the other trustin domain in the forest:

• dsquery * "CN=SecurityGroupName,CN=Users,%domainDN%" -attr * -gc -s DC.other.domain.in.trusting.forest
  

Object is successfully enumerated as the trusting domain local ACE is ignored.

The same occurs in the scenario of granting specific access to an object that would otherwise be denied or not implicity granted.

What this does not affect:

1. Single-domain forests. The scope of domain local is not an issue as there is only one domain.
2. LDAP 389 operations to a domain partition on a DC, rather than a read-only GC type query.
3. Samr/netlogon operations to a Domain Controller in the trusting domain
   Replication issues. Originally it was thought that this could cause issues with replication consistency, this is not the case and only affects security on the GC.

What this could affect:

1. Security on automated GC usage, such as Universal group enumeration (during logon or otherwise), forest-wide searches, Exchange address-book lookups and UPN logons
2. Security on any manually initiated GC query (such as used in the testing).

Unknown:

1. Application directory partitions with a forest-wide replication scope, such as forest dns zones. It seems the 'Security descriptor reference domain' of an application partition partially solves this issue, in addition to GC not containing replicas of any application partitions and an application directory partition can't contain security principals.
   

Notes:

1. The user token contains universal, global and domain local groups for the user domain (cross-forest), not domain local groups in the DC domain. An impersonation token is created for the GC access, containing the forest-wide universal, domain global and domain local scope of the domain that the GC is in.
2. The same can be seen through the GUI when connecting with ldp.exe to the a GC instance of one domain over 3268, and then browsing to the other domain tree
3. Groups of scope domain local are partially replicated to the Global Catalog in the forest, so when viewing the security descriptor of an object that contains a domain local reference from another domain than the domain of the connected GC, the SID is easily resolved to a name. However, the token used to authenticate the GC query contains only the domain local groups in the GC's domain, not the intended trusting domain, causing the ACE to be ineffective.
4. Exchange 2007 has some capability to automate the configuration of cross-forest Exchange administration. I assume it won't be too long before a Windows AD administration equivalent is available. There is reference to parallel groups and then using the ForeignForestFQDN Exchange setup option, I'm unsure of the outcome, but I assume it is universal->local->ACE (see Step 7 in 'How to Configure Cross-Forest Administration')
   

Excerpt from 'Global catalog replication' below:

A global catalog stores a replicated, read-only copy of all objects in the forest and a partial set of each object's attributes, including the security descriptor for each object. The security descriptor contains a discretionary access control list (DACL), which specifies permissions on the object. When a user connects to a global catalog and tries to access an object, an access check is performed based on the user's token and the object's DACL. Any permissions specified in the object's DACL for domain local groups that are not from the domain that the domain controller hosting the global catalog (to which the user has connected) belongs to, will be ineffective because only domain local groups from the global catalog's domain of which the user is a member are represented in the user's access token. As a result, a user may be denied access when access should have been granted, or allowed access when access should have been denied.

As a best practice, you should avoid using domain local groups when assigning permissions on Active Directory objects, or be aware of the implications if you do use them. To prevent unauthorized access to global catalog data, use global groups or universal groups instead. For information about global and universal groups, see Group scope.

References:

Global catalog replication
http://technet2.microsoft.com/windowsserver/en/library/8ac658b0-199c-47df-ac2b-ef9cb56fa7f01033.mspx?mfr=true

DNS zone replication in Active Directory
http://technet2.microsoft.com/windowsserver/en/library/6c0515cf-1719-4bf4-a3c0-7e3514cef6581033.mspx?mfr=true

Application directory partitions
http://technet2.microsoft.com/windowsserver/en/library/ed363e83-c043-4a50-9233-763e6f4af1f21033.mspx?mfr=true

What Is the Global Catalog?
http://technet2.microsoft.com/windowsserver/en/library/24311c41-d2a1-4e72-a54f-150483fa885a1033.mspx?mfr=true

What's New in Active Directory
http://www.microsoft.com/windowsserver2003/evaluation/overview/technologies/activedirectory.mspx

How to Configure Cross-Forest Administration (Exchange 2007)
http://technet.microsoft.com/en-us/library/bb232078.aspx

Exchange 2007 Permission Considerations
http://technet.microsoft.com/en-us/library/aa996881.aspx

Multiple Forest Considerations in Windows 2000 and Windows Server 2003
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/directory/activedirectory/mtfstwp.mspx

Group Scope (2003):
http://technet2.microsoft.com/WindowsServer/en/library/79d93e46-ecab-4165-8001-7adc3c9f804e1033.mspx?mfr=true

Group Type and Scope Usage in Windows
http://support.microsoft.com/kb/231273

Accessing resources across-forests
http://technet2.microsoft.com/WindowsServer/en/library/517b4fa4-5266-419c-9791-6fb56fabb85e1033.mspx

Accessing resources across domains
http://technet2.microsoft.com/WindowsServer/en/library/e36ceae6-ff36-4a1b-9895-75f0eacfe94c1033.mspx


Wayne's World of IT (WWoIT), Copyright 2008 Wayne Martin.