Grouper Users - Open Discussion List

["Bee-Lindgren, Bert" <>]

Hello,

I'm trying to start a discussion and get to a decision about how PSPNG should handle LDAP groups where the schema requires a value for the membership attribute. This will eventually lead to a solution for GRP-1376.

TL;DR: We would like to extend PSPNG's existing group-provisioning process to support group schemas that require members. However, we believe that this will require a pspng-configuration option that will enable persistent maintenance of a faux group member.

I don't know if any background is needed, but let's summarize by saying there are three flavors of group schemas in how they require or don't require memberships:

1) Standard LDAP Group objectclasses (rfc 2256) that require at least one member

2) Directory servers that have redefined the "standard" LDAP Group objectclasses in their default schemas. They don't require members

3) Directory servers (Active Directory) that have their own schemas that don't require members.

This thread is about how Grouper should support provisioning to (1).

In general, here are some observations:

- It's very good if all these (1)-(3) situations can be provisioned by PSPNG in a single implementation

- It's nice when groups go from new --> empty --> populated --> empty --> populated --> empty --> deleted in a nice, step-wise way. This means seeing the group in LDAP every step along the way.

- When removing the last member from a (1) group, the group needs to be deleted. It will likely slow down PSPNG noticeably if it has to read additional group information to avoid deletion-not-allowed errors or will create logging noise and modest slowness if the extra information is read in response to ldap errors to see if the group actually needs to be deleted.

- Sometimes, groups that are deleted and recreated aren't exactly the same. For example, a recreated Active Directory group would have a different SID. Therefore, we cannot standardize our handling of groups by implementing things as if they all require members.

- Type (1) groups today are created in (at least) some universities with an initial or persistent Faux member -- an account or dn that doesn't represent a real user. Pspng can be set up to do that today (by adding the Faux member to the group-creation template), but that member would be deleted during full-sync, resulting in errors when that is the last member or when another last member is eventually removed from a group.

My conclusions:

a) A single group-provisioning system can handle all the ldap group types, if we take the a Faux-member approach.

b) If Faux-members are too kludgy, then we'll need a separate, noisier and slower implementation that handles provisioning of groups that require members.

What do you all think about this?

Sincerely,

  Bert Bee-Lindgren