Use case: to be used whenever “Nesting support” is Disabled OR if the the directory is an eDirectory

First call to retrieve user

(&
(objectClass=user)
(|
(cn=TEST USER)
(sAMAccountName=TEST USER)
(userPrincipalName=TEST USER)
)
)

Second call to verify if user is enabled to a chain, it should look for groups with a member

(&
(objectClass=group)
(member=cn=TEST USER,ou=users)
(|
(
(cn=chainGroup1)
…
(cn=chainGroupN)
)
)
)


Case 2) Use case with Nesting support for one-level-nesting (for eDirectory Nested is already supported on backend so it should be treated like case 1)

First call to retrieve user and its groupMembership

(&
(objectClass=user)
(|
(cn=TEST USER)
(sAMAccountName=TEST USER)
(userPrincipalName=TEST USER)
)
)

Second call to verify if user is enabled to a chain, it should look for groups on the specified chain retrieving member

(&
(objectClass=group)
(|
(
(cn=chainGroup1)
…
(cn=chainGroupN)
)
)
)


Check which user groupMemberships are equal to group member to understand the first nesting level

Doing a check of nested groups for multiple levels should never be done at every login, it should be the LDAP repo full scan doing the map to understand if a user belong to a nested group of second level


For sure It does make any sense doing a full scan of the groups when a customer does not chose to support nesting. We tested that even with nesting support off, the query looks for all the groups where the user is member…. Despite the list specified on the chains.

Moreover eDirectory has its own support for nested groups internally, so the nesting support should never be specified via NAA when using eDir repo

by: Natan S. | over a year ago | Integrations