I have tested the tokengroups group-lookup strategy of the (newest) Active Directory Plugin in our AD-environment. Our AD is setup as forest, were some users are located in the root-domain (e.g., root.local), but most user-accounts, security-groups and computers are located in the second resource-domain (e.g., subx.local).

Therefore, the plugin is currently configured with

• Domain Name = "subx.local,root.local",
• Domain controller = "dc1.subx.local:3268,dc2.subx.local:3268"
• Group Membership Lookup Strategy = "RECURSIVE"

With this configuration, login "against" a local group of subx.local by using an account of root.local (which is member of the local group) is permitted.

If I change the the group-lookup strategy to "TOKENGROUPS", the login fails *) ...
... and after some tests (with logging 'FINE'), I've determined (or assume), that:

• Searching for the user-object and login (with credentials) is successful,
• also getting the tokengroups-list (SIDs) will contain local, universal groups of the subx.local (which DC was asked),
• But the the name-translation of the tokengroups-SIDs afterwards, is limited to the domain (by Bind-DN) of the user-object. Therefore, the security-groups of our resource-domain (subx.local) were not found!

*) More concrete:
Login with an account of the resource-domain (subx.local) is still successful; an much faster.
The failure/problem occurs only with accounts of the "extra" root-domain.

Assuming, that my findings/assumptions are correct: It is possible to change the implementation, that groups of "different" (but also configured/permitted domain), are permitted?

Best regards from Salzburg,
Markus