Does PDS have READ access to all LDAP user record data fields?

• Article Type: General
• Product: MetaLib
• Product Version: 4

Description:
If a Metalib site configures PDS to use a campus LDAP server, the LDAP server may not always allow READ access to certain patron attributes for specific user record in the LDAP patron data.
When READ permissions are not granted, the resulting Metalib Z312 record will not only contain blank name and email fields, but the MetaLib-PDS-LDAP interaction may default to the first alphabetic portal name/code (even if that is NOT the desired portal assignment).
NOTE: This is relevant for sites using multiple user-access portals AND those using one portal together with a TEST portal for staff.

Resolution:
Be sure to ask the customer if MetaLib’s PDS has READ rights to all expected and desired patron attribute data fields.

For the following example, the example institution code = UNIV and the two portal codes are UNIV and TEST (UNIV portal for patron use and TEST portal for staff testing use with no patron access).

In this example, a Metalib v4 site was successfully authenticating Metalib users who were STAFF users (in the LDAP Organizational Unit/OU), as well as assigning the correct default INSTITUTION and PORTAL code. While the STUDENT authentication attempts looked successful, STUDENT users were not authenticating successfully in the same way. Only the STUDENT users were having the incorrect portal (Z312_PORTAL_NAME = TEST) assigned.

The PDS to LDAP configuration file = pds/conf_table/ldap_univ.conf confirmed that the PORTAL_NAME = UNIV should be confirmed as the default PORTAL value in any new UNIV Metalib patron record. (It was assumed that only STAFF users might manually create a Z312 user account that would use the TEST portal.)

The resolution was to request that PDS attempts for BOR_AUTH and BOR_INFO would be allowed READ permissions to the STUIDENT user patron attributes. Once READ permissions was granted, the resulting STUDENT authentication requests successfully created new Z312 accounts without blank names and emails, as well as assigning the correct default Z312_PORTAL_NAME.

Note: One other option may have been to remove the TEST portal and test if the correct default Z312_PORTAL_NAME gets assigned even though new UNIV Z312 accounts would still contain blank name and email fields.