Provision Multi Valued attribute in OpenLDAP from Identity Attribute

Hi folks,
We need to provision the departmentNumber in OpenLDAP as a multi-valued attribute.

Below is the current setup :

  • An identity attribute named “openldapDepartmentNumber”, which contains the expected format "Option 1, Option 2,Option 3
  • A source OpenLDAP on which the attribute “departmentNumber” has been set to “Multi-Valued” in Account Schema
  • A provisioning policy with the below JSON for attribute “departmentNumber” :
{
    "name": "departmentNumber",
    "transform": {
        "type": "identityAttribute",
        "attributes": {
            "name": "openldapDepartmentNumber"
        }
    },
    "attributes": {
    	"cloudDelimiter": ","
    },
    "isRequired": false,
    "type": "string",
    "isMultiValued": true
}
  • Attribute sync for “departmentNumber” is enabled and update is performed when identity data gets updated.

Current output is the attribute being provisioned as one string with separated valued, instead of being sent as multiple lines.

Anyhelp is much appreciated !

It should work.

Are you facing this issue while creating account or updating account or both ?

Hi Adrien,
Have you check the below link. Please let me know after following the below link you are not able to provision multivalued attribute in target.

https://community.sailpoint.com/t5/IdentityNow-Articles/Best-Practices-Provisioning-Multi-Valued-Attributes/ta-p/153748

Hello Krishna,
It works on Account Creation.
I am trying on update now and will revert to you.

Hi Rakesh,

It seems my implementation is working fine on Create, but sends a String on Update.
EDIT : I have read the provided document but there is no additional indication for managing the same during the Update.

1 Like

@acosson : Can you please check this link. We can achieve this using a cloud rule

Such a fragmented approach to do essentially the same thing (attribute lands on the target object, regardless of create or update). …and…it’s been 18months+ since that post.

Agreed @IIQUserOnCompass, I think the best option here to use a before Provisioning rule and make changes before provisioning

Yeah, agree. Unfortunately so.