Re: How to fetch all the groups for a user from Active Directory

[varun mittal <vmittal05 [at] gmail.com>]

Hi Arthur

Thanks for the elaborate write-up and clarifying the 'primary group' thing

Much appreciated.

So, what I understand is that nss-pam-ldap will be able to fetch the secondary groups and nested groups(with that control flag in the config).

The parent groups of the 'primary groups' maybe left out and that is by design/expected.

Regarding the 'member' and 'memberUID' attribute. I need not do any specific config for that, right ?

Just define the group memberships in Active Directory, like we normally do and nss-pam-ldap will pick them up.

No attribute mapping required, correct ?

On Fri, Jan 15, 2021 at 9:22 PM Arthur de Jong <arthur [at] arthurdejong.org> wrote:

On Tue, 2021-01-12 at 09:06 -0600, Mark Hack wrote:
> See
> https://docs.microsoft.com/en-us/windows/win32/adsi/search-filter-syntax
>
> You need to use the LDAP_MATCHING_RULE_IN_CHAIN rule (OID
> 1.2.840.113556.1.4.1941 will cause nested searching on AD
>
> EG
> (memberOf:1.2.840.113556.1.4.1941:=cn=group,cn=users,DC=x)

Currently (nss-pam-ldapd 0.9.11) nslcd does not use the memberOf
attribute on user attributes for searchers to determine group
membership.

The primary group of a user is defined in the user object by the
gidNumber attribute. The secondary groups are determined by searching
for all the groups that the user recorded as being a member of. That
searches for group objects with either the memberUid attribute (which
should hold the username) or the member attribute (which should hold
the user DN).

The nss_nested_groups option can be used to turn on recursive searches
for group membership which means that any groups that are found in the
first search are checked to see if they are members of other groups
(again with the member attribute).

Note that this recursion does not expand "parents" of the primary group
(to add them as secondary groups) because the mechanism of assigned a
primary group and defining group membership are two different things.
It is generally assumed that users with a particular primary group
assigned are also a member of that group but this is not a requirement.
In other words: having a certain primary group assigned does not mean
the user is a member of that group.

This means that the current implementation should answer the question
of whether a specific user is in a group consistently whether you query
it from the perspective of the user or from the perspective of the
group.

In this particular example if the "Domain Users" and "FirstLevelGroup"
can be assigned both as secondary groups both parents of those groups
should be also considered secondary group of that user.

Hope this clarifies things,

--
-- arthur - arthur [at] arthurdejong.org - https://arthurdejong.org/ --