Saviynt unveils its cutting-edge Intelligence Suite products to revolutionize Identity Security!
Click HERE to see how Saviynt Intelligence is transforming the industry.
Saviynt Copilot Icon

Deleting multi-valued attributes in OpenLDAP

Caesrob
Regular Contributor
Regular Contributor
We have an OpenLDAP connector which reads and provisions student data from and to the OpenLDAP server at Uhasselt.
Uhasselt has 2 multi-valued attributes on account level, groupMemberShip and member. These attributes are provisioned with the full names and abbreviated names of the groups which they are members of. 
 
We have created the groupMemberShip and member attributes for new accounts using the Saviynt4Saviynt connector and analytics. This analytic will give us results of which account is a member of which group and will fill this in on a users customproperty61 & customproperty62.
Caesrob_6-1697545813314.png
This will result in one of 2 things being added in the customproperties of the user.
 
  1. The user is not a member of any groups so the customproperties are provisioned with [] Caesrob_0-1697545129472.png

     

  2.  The user is a member of 1 or multiple groups so the customproperties are provisioned with ["group1","group2",..]

Caesrob_3-1697545320593.png

 
When customproperty61 or customproperty62 of a user is updated, this will automatically generate an updateAccount task.
In our updateAccountJSON we have added 2 new lines:
"groupMemberShip": ${user.customproperty61},
"member": ${user.customproperty62},
When the updateAccount task is provisioned, the 2 attributes are provisioned correctly.
Caesrob_4-1697545467165.png

 

The problem occurs when a user is no longer part of any group, so the groupMemberShip and member attributes need to be emptied/deleted. This does not work when there is more than 1 entry in either of these attributes.
 
Example 1:
In above screenshot, we see that this student has 2 groups (so 2 entries in both groupMemberShip and member)
When the student is removed from these 2 groups, customProperty61 & customProperty62 are updated to []
This creates an updateAccount task.
we provision customProperty61 to groupMemberShip attribute and customProperty62 to member attribute using the updateAccountJSON.
No changes have been made. Both groupMemberShip and member still have 2 entries each and are not deleted.
 
Example 2:
Here we see that this student has 1 group (so 1 entry in both groupMemberShip and member)
Caesrob_5-1697545614943.png
When the student is removed from this group, customProperty61 & customProperty62 are updated to []
This creates an updateAccount task.
we provision customProperty61 to groupMemberShip attribute and customProperty62 to member attribute using the updateAccountJSON.
In this example, both the groupMemberShip and member attribute are deleted which is correct.
 
We think this is a bug related to Saviynt as it works just fine with 1 entry, but not with multiple. 
Changing groups, adding groups or deleting all but 1 group functions correctly.
2 REPLIES 2

nimitdave
Saviynt Employee
Saviynt Employee

@Caesrob , so if you want to remove a group for a user then you remove the user from group and then update these 2 attributes explicitly or ldap takes care of this on its own.

I am asking because generally we just remove and add the user to groups and then these attribute at account level memberOf,groupmembership is handled by LDAP automatically.

Also in your implementation do you have an entitlement type for groups which gets populated on import. 

And in EIC on addition/removal of group only AddAccess/Remove Access task is generated no update account unless any attribute at account level/form is updated. Can you confirm on this?

Caesrob
Regular Contributor
Regular Contributor

We have to update these 2 attributes explicitly, this is not a standard OpenLDAP implementation. It is something custom for the customer.

Yes, although the entitlement type is "member" and not groups. This is because the customer's OpenLDAP is a bit more complicated.

We run a report to see which accounts are in which groups on OpenLDAP. Then we fill in customproperty61 & customproperty62 using the results of this report. If customproperty61 or customproperty62 is updated, an update account task is triggered to update the values in OpenLDAP.