-
Improvement
-
Resolution: Unresolved
-
Minor
-
None
-
Windows Server 2008 R2 (x64),
Active Directory plugin 1.48
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
Hello, what bindName are you using? Is it in format CN="", ... or you are using the displayedName?