Grouper Users - Open Discussion List

[Dominique Petitpierre <>]

Hello,

while poring over the logs for other  problems related to a PSPNG provisioner provisioning to Active Directory,  I noticed that target user entries were retrieved with the attribute memberOf in addition to those in listed in the PSPNG property userSearchAttributes. E.g.:

DEBUG LdapProvisionerConfiguration.readConfiguration(126) -  - Ldap Provisioner activedirectory_student - Setting isActiveDirectory to true
...
DEBUG LdapProvisionerConfiguration.readConfiguration(146) -  - Ldap Attribute Provisioner activedirectory - Setting userSearchAttributes to [dn, employeeNumber]
...
DEBUG LdapGroupProvisionerConfiguration.readConfiguration(151) -  - Ldap Group Provisioner activedirectory_employee - Setting groupAttributeName to memberof
...
DEBUG LdapSystem.performLdapSearchRequest(730) -  - Doing ldap search: [org.ldaptive.SearchFilter@181456024::filter=(|(employeeNumber=647008)(employeeNumber=706863)(employeeNumber=22626)(employeeNumber=26520)(employeeNumber=23242)), parameters={}] / OU=UsersUnige,OU=_UNIGE,DC=isis-klif,DC=unige,DC=ch / [dn, employeeNumber, memberof]
TRACE LdapObject.<init>(92) -  - Allocating java LdapObject #10: [dn=CN=bello,OU=PA-PAT,OU=LETTRES,OU=FCI,OU=UsersUnige,OU=_UNIGE,DC=isis-klif,DC=unige,DC=ch[[employeeNumber[645150]], [memberOf[CN=bpmpoc1,OU=workflow1,OU=bpm-bonita,OU=bpm-poc,OU=application,OU=Grouper,OU=Groups,OU=_UNIGE,DC=isis-klif,DC=unige,DC=ch, CN=testgroup_all,OU=workflow1,OU=bpm-oracle,OU=bpm-poc,OU=application,OU=Grouper,OU=Groups,OU=_UNIGE,DC=isis-klif,DC=unige,DC=ch, ...

(Note the memberof in "[dn, employeeNumber, memberof]")

It is documented that for a LdapGroupProvisioner if the property isActiveDirectory is true then the default value for the property groupAttributeName is memberOf (empty otherwise). (cf https://spaces.at.internet2.edu/display/Grouper/Grouper+Provisioning%3A+PSPNG#GrouperProvisioning:PSPNG-Configuration)
But I fail to see what is the purpose of fetching all the memberOf values of a user entry. I looked at the code of PSPNG and saw no sign that these values are used once fetched (caveat: I am not a Java programmer).

This looks pretty wasteful both for data hauling over the network and caching in memory, especially if, like in our case, users are member of many groups (not all synchronized to Grouper). Moreover, in Active Directory the attribute memberOf is a computed attribute and the real reference is the member attribute in the corresponding group: since that group is known by the provisioner (it is the one being synchronized) there is no point of cross checking with memberOf. And I cannot think of a use case for using membeOf in a Jexl _expression_, and even if there was, it seems that it should not be the default that memberOf values are fetched.

When groupAttributeName  is configured explicitly to be empty (e.g. changeLog.consumer.activedirectory_employee.groupAttributeName =) the provisioner does not fetch the memberOf values anymore, and, after wuite a few checks, this does not seem to cause  ill effects. A side benefit was that, for one provisioner, it became faster (lasted 13% less time, probably because there is less data hauling, I did not check the memory footprint gain).

Hence my question:

- what is the purpose to fetch memberOf attribute values of users when provisioning to Active Directory?

If there is no purpose, then, by default the property groupAttributeName should not be set even if isActiveDirectory is true or there should be another mechanism to prevent to fetch memberOf values by default.

Thanks in advance for your answer!

Regards.

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