Inconsistent permissions in Global Catalogue

If you want to use AD groups to assign permissions for ressources, you usually do it this way:

But assigning authorizations like this can have unexpected results… 

Global Catalogue Problem:
Users in same local group – attribute not visible

The following example explains you how inconsistent permissions in the Global Catalogue work and what problems they could cause:

A forest consists of two domains:

• Domain 1 and
• Domain 2

In each domain, there is at least one domain controller running as a Global Catalogue (GC) server.

A local group is set up in Domain1. This group is authorized to read a certain attribute in the AD which, e.g., is not visible for all users. This attribute is replicated into the GC as well.

Member of the group is a universal group with one user from each domain.

The difference is that…

• …when User1 from Domain1 accesses the Global Catalogue, he can read the attribute without problems
• …whereas when User2 from Domain2 tries the same thing from his GC, he cannot see the attribute.

How is that possible when User2 is member of the universal group just like User1 and the GCs in both domains contain the same information? 

Reason: the resource is not in the same domain

The reason for the problem is that we didn’t take care of an essential rule for the above mentioned assignment:

The resource has to be in the same domain as the local authorization-group.

Which is not the case for our local group!

But SIDs of local groups are only included into the user token of the same domain. For this reason, the user from Domain1 has no SID for the local user group in his token when accessing a GC in Domain2. Thus, he doesn’t have authorization on the attribute.

Solution

To avoid the problem in this special case, I would advise to assign the permissions directly on universal security groups.