Integrating pwm with apacheDs which does not support memberOf attribute

[mkashwin]

It seems that pwm , group feature does not work with directories which do no have virtual attribute like memberOf

My suggestion to support groups with such a LDAP ( e.g. Apache DS) would be the following In configuration we add 3 parameters to be specified

1. Name of Group Object Class : e.g. e.g. groupOfNames, groupOfUniqueNames, group.
2. LDAP Group Entry Attribute Holding User's DN, CN, etc. : e.g. member, uniquemember, memberUid
3. LDAP Group Entry Attribute specifying the group / role : e.g. CN, OU

These can be provided as an alternative / in addtion to to the "ldap.user.group.attribute"

The LDAP query to get the groups then would be ( replace $xx with appropriate variable) (&(objectClass=$Group_Object_Class)($GROUP_ATTRIBUTE=$USER_DN))

On the return list at attribute filter for $GROUP_NAME_ATTRIBUTE can be applied to get all the groups

I searched through the project code but could not understand how and where can we fix this or atleast which class can this be fixed in?

[dcacklam]

Also useful for any LDAP implementation that stores group membership in a not-LDAP-DN-based format (eg, a 'Groups' CN, with each entry having a list of 'MemberUID' entries that correspond to user-record uid fields.

[jrivard]

PWM doesn't ever search for groups, it searches for users who are members of groups. The group data itself (membership, etc,) is irrelevent to PWM. The reason the search is done in this direction is because searching for the groups and then evalulating membership is inefficient on both the client and LDAP server side, especially with groups with large memberships (long time for searching) and large number of groups (one query for each group). Thus we need an attribute on the user to indicate group membership.

[dcacklam]

The problem is that, at least for many non-Microsoft LDAP implementations, the memberOf attribute is near useless.

LDAP is often configured as follows (with multiple applications depending on it):

cn=AdminGroup,ou=Group,dc=mycorp,dc=com GroupOfNames (Structural) PosixGroup (Auxilliary)

.... memberUID=user1login memberUID=user2login memberUID=user3login ....

alongside a users OU that looks like

ou=People,dc=mycorp,dc=com inetOrgPerson (Structural) posixAccount (Auxilliary)

uid=user1login uidNumber=<Unix UID Number> userPassword= ...other-attributes...

(repeat the above for each user)

In this structure, DNs are never actually used outside of the LDAP internal structure - users log-in with uids, and groups are referenced/resolved by memberUID matching the user UID, rather than MemberOf matching a DN.

To support this structure you don't have to do any sort of extensive query, you just have to implement the ability to compare the user's entered login-name to the 'memberUID' entries of the group or groups in question.

So rather than checking to see if a user is the 'memberOf' a group DN... You check the group DN to see if it has a 'memberUID' matching the user's entered login-name.

Various other LDAP reading products have an option to switch between the two modes.

On Fri, May 21, 2021 at 11:55 AM Jason Rivard @.***> wrote:

PWM doesn't ever search for groups, it searches for users who are members of groups. The group data itself (membership, etc,) is irrelevent to PWM. The reason the search is done in this direction is because searching for the groups and then evalulating membership is inefficient on both the client and LDAP server side, especially with groups with large memberships (long time for searching) and large number of groups (one query for each group). Thus we need an attribute on the user to indicate group membership.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/pwm-project/pwm/issues/272#issuecomment-846171909, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHAS6ZUZCD754TJ3ZBU6CLTTO2UALANCNFSM4EOS6T7Q .

[jrivard]

So.. my experience is different. The LDAP implementations I have dealt with extensively such as SunONE, eDirectory & Directory386, and AD (though I'd never suggest AD as a good example of anything) all have approaches of reciprocal attributes between users and groups. I don't have any experience with ApacheDS, I've been meaning to look into it forever. And again in my experience LDAP applications that checked groups for users have all run into scale problems when memeberships or groups become large. No matter what there will never be an LDAP query faster and more flexible than a filter applied to a user with a scope of base (which is what PWM uses for permission evaluation today). And authentication performance is very critical in PWM since it is often invoked multiple times per user during a web authentication sequence.

In fact, I recommend an alternative to groups in general for any LDAP design - use String values on a user attribute instead, using application side logic to force value consistency. In almost all cases this is better than trying to use a group and dn pointers with referential integrity. But this is beyond the point of this issue.

I understand the idea of checking group user-membership attributes for userDNs. I've implemented this in the past when I was naive to the performance impact. Nonetheless, I'm not against making an optional group policy permission that checks membership against the group an option in PWM. Id be open to a PR that had such an implementation, though I doubt I'll do it myself. This would have to be implemented as a per-permission option, ideally with a way to do filter value substitution to make it more generally useful to experts, but simple enough for non-ldap experts to use as well.