Grouper Users - Open Discussion List

[Dominique Petitpierre <>]

Hello,

On 17.09.20 21:34, Jeffrey Williams wrote:

It sounds like you have 2 things to check:

1) Your subject.properties to be sure your student and employee members will uniquely identify when specified.

2) How to get 2 members for the price of 1 membership add?

Talking about 1, first:

ERROR LdapProvisioner.fetchTargetSystemUsers(262) -  - activedirectory-full: User data from ldap server was not matched with a grouper subject (perhaps attributes are used in userSearchFilter (employeeNumber=${subject.id.replaceFirst("@unige.ch","")}) that are not included in userSearchAttributes ([dn, employeeNumber, employeeType, memberof])?): cn=bello6,ou=lettres,ou=etu,ou=usersunige,ou=_unige,dc=isis-klif,dc=unige,dc=ch

  Is your subject.properties( https://spaces.at.internet2.edu/pages/viewpage.action?pageId=14517958#APIBuilding&Configuration-ChoosingIdentifiersforSubjects) configured to resolve members in both ETU and FCI?

Subjects are not resolved in that directory.

There are two directories:
subjects in Grouper are taken from a directory that has employeeNumber has a unique identifier (and rdn). There is one entry per person in that directory.
But the target directory has two entries for persons that are both staff and student, and the unique identifier (and rdn) is a login name (aka uid).
These login names are available as attributes in the subject directory (unigechstudentuid and unigechemployeeuid).
E.g. the distinguished names that you see in the cited pspng logs

CN=bello,OU=PA-PAT,OU=LETTRES,OU=FCI,OU=UsersUnige,OU=_UNIGE,DC=isis-klif,DC=unige,DC=ch
CN=bello6,OU=LETTRES,OU=ETU,OU=UsersUnige,OU=_UNIGE,DC=isis-klif,DC=unige,DC=ch

correspond to the person with employeeNumber=645150 whose dn in the subject directory is

employeeNumber=645150,ou=people,dc=unige,dc=ch

  The error message seems to indicate that bello6 couldn't be resolved into a subject.  If Grouper can't resolve it back to a subject, it'll treat it as an unknown.

It is 645150 that was resolved as a subject. There is no mechanism and no need to resolve back to a subject the members found in the the target directories (i.e. mapping is not bi-directional).
I suspect that PSPNG assumes there is a one to one (or one to zero) correspondence and does not know what to do with an extra corresponding target group member returned by the target members search.

- Is it possible to configure a PSPNG provisioner to synchronize one Grouper group member to two target directory group members?  

I think the short answer is not likely.  At least for the reason when it came to full-syncs, PSPNG would delete the member account in the target group that was not a bona fide member of the Grouper group.

I came to the same conclusion :-( .

But it seems to me that, with distinct directories as described above, for both full and incremental synchronization, it is conceivable for a provisioner to maintain a one to many correspondence as well. It just has to trust what the target members search returns as correspondence for one subject.

Talking about 2, next. At UNCG, I have a similar situation where I have 2 sets of groups whose membership represent the same individuals:

*DepartmentalTechnicalSupport(DTS) - group of techs represented by their administrative account

*DepartmentalTechnicalSupport-Primary - same group of techs, represented by their primary account.

The DTS group is manually maintained.  I have a GSH script that periodically will loop through these DTS groups, find the tech's primary account by searching through an eligibleEmployee-Primary group, and create an array of administrative -to- primary translation records with the two subjects and the  employeeNumber they share.  The script then adds any new users to the corresponding -Primary group, followed by removing any that no longer have a member in the original DTS group.

You could take a similar script to take the members of your "employee" group, search in a suitable student group for any student accounts with the same employeeNumber, then add that member to a "student" group and keep those synced.  You'd then take the employee and student group and make them members of the group you'd ultimately want them to be in.

The end result would be that your employee group is still driving the membership of the final group, but is also influencing which student accounts would get added as well.

The upside is that your provisioners don't have to be manipulated to get this desired behavior.  

The downside is that it's not instant, which may or may not matter depending on your situation.  Also, since you're also on 2.4, there isn't a great way to cron gsh scripts except for getting the host to do it via docker commands on it's own scheduler.  2.5 has a loader script option that you can schedule within the app, but I haven't had a chance to play with it yet.

Let me know if you're interested in the script or if you have more questions/comments.

    Thanks for the offer! I had envisaged of a non scripted approach
    too.
    In the mean time I took another route, in particular in order to
    benefit from the incremental synchronization of PSPNG.
    The purpose of these groups, privileges in applications, allows for
    splitting groups into two: one with only staff members and one with
    only student members, with the same name but in different branches.
    The lookup of the privileges for one authenticated user in the
    target directory will find the right groups, even for users with two
    logins.
    It works because these applications and groups are designed to
    consider the person and not the login name/user entry (e.g. a user
    authenticating with his/her staff login will benefit from the same
    privileges for students as when he/she logs with his/hers student
    login).

So now I configured two PSPNG provisioner, one synchronizing the staff members of a Grouper group to a target group in a staff branch and one synchronizing the student members to a target group in a student branch.

The relevant configuration in grouper-loader.properties look like this

changeLog.consumer.activedirectory_employee.memberAttributeValueFormat = ${ldapUser.getDn()}
changeLog.consumer.activedirectory_employee.userSearchFilter = (cn=${empty(subject.attributes["unigeChEmployeeUid"])?"inexistant":subject.attributes["unigeChEmployeeUid"].iterator().next()})
changeLog.consumer.activedirectory_employee.userSearchAttributes = dn,cn
    and
changeLog.consumer.activedirectory_student.memberAttributeValueFormat = ${ldapUser.getDn()}
changeLog.consumer.activedirectory_student.userSearchFilter = (cn=${empty(subject.attributes["unigeChStudentUid"])?"inexistant":subject.attributes["unigeChStudentUid"].iterator().next()})
changeLog.consumer.activedirectory_student.userSearchAttributes = dn,cn
    Thus the Grouper group with members employeeNumber=645150 (both
    staff and student), 645151 (staff only), 645152 (student only)
application:bpm-poc:bpm-oracle:workflow1:testgroup
    is mapped to two target directory groups:
dn: CN=testgroup,OU=workflow1,OU=bpm-oracle,OU=bpm-poc,OU=application,OU=employee,OU=Grouper,OU=Groups,OU=_UNIGE,DC=isis-klif,DC=unige,DC=ch
member: CN=bello,OU=PA-PAT,OU=LETTRES,OU=FCI,OU=UsersUnige,OU=_UNIGE,DC=isis-klif,DC=unige,DC=ch
member: CN=iamstaffonly,OU=PA-PAT,OU=LETTRES,OU=FCI,OU=UsersUnige,OU=_UNIGE,DC=isis-klif,DC=unige,DC=ch


dn: CN=testgroup,OU=workflow1,OU=bpm-oracle,OU=bpm-poc,OU=application,OU=student,OU=Grouper,OU=Groups,OU=_UNIGE,DC=isis-klif,DC=unige,DC=ch
member: CN=bello6,OU=LETTRES,OU=ETU,OU=UsersUnige,OU=_UNIGE,DC=isis-klif,DC=unige,DC=ch
member: CN=iamstudentonly,OU=LETTRES,OU=ETU,OU=UsersUnige,OU=_UNIGE,DC=isis-klif,DC=unige,DC=ch

The upside is that it is workable with PSPNG only and will benefit from the incremental synchronization.

The downsides are
 - there are, well, two groups : this might cause problems with other applications, in particular if one needs Active Directory security groups.

 - there are, well, two provisioners: all members are synchronized twice, and there are lots of warnings because there are lots of one to zero correspondences (i.e. the majority of persons are not both staff and student).
   I also suspect that the cache mechanism does not handle one to zero correspondences very well (it seems that absence is not cached) and slows down the operation further (especially for full sync where clearly PSPNG is not as efficient as PSP was).

Yet I would have preferred PSPNG to handle one to many correspondences!
With such an enhancement, maybe you could use a PSPNG provisioner to handle the case you described!

So I hereby propose a Request For Enhancement  to improve PSPNG with one to many correspondences.

Thanks for your comments and offer!

    Regards,
-- 
Mr Dominique Petitpierre, user=Dominique.Petitpierre domain=unige.ch
IT Division, University of Geneva, Switzerland