Ldap connector entitlement provisioning

Which IIQ version are you inquiring about?

Version 8.3

Please share any images or screenshots, if relevant.








Share all details related to your problem, including any error messages you may have received.

Hello everyone!!!

I am currently integrating an LDAP type application into SailpointIQ 8.3 and am managing the provisioning of groups (poxisGroups) for identities. The provisioning process is working correctly, however, group membership is associated using the DN of the identity instead of the UID, which is the unique identifier used throughout LDAP so far.

Although the DN is considered the recommended practice, I would need to configure the system so that the poxisGroup LDAP membership is based on the UID of the identity instead of the DN.

Is it possible to do this configuration?

Hello,

I had the same issue, in Identity Security Cloud however, and solved pretty easily by creating a new group schema for posixGroup.

I’m not entirely sure how to configure the same in IIQ, but I know that the connectors are basically identical.

image

My inital wrongdoing was that I was trying to alter the “group” schema and change the identifiers in there, however it kept provisioning with DN instead of UID. This is because regular LDAP groups natively use DN as identifier. posixGroups however, use UID. IdentityNow seemed to understand this when I added a separate schema for posixgroup.

Check your entitlements, are they being aggregated as groups or posixGroups?

1 Like

Hi Sebastian,

Thank you for your timely response! I tried to apply what you did in IDN for IQ, but during account provisioning with attached entitlement request I get the error:

2024-04-16T17:23:08,238 ERROR QuartzScheduler_Worker-2 sailpoint.connector.LDAPConnector:9948 - 1475309080 Failed to create object [uid=a.longo,o50E Attribute posixgroup was not found in the schema definition.
]
sailpoint.connector.ConnectorException: [LDAP: error code 65 - GLPRDB050E Attribute posixgroup was not found in the schema definition.
]
entitlements were imported as you suggested:

What changes have you made in the schema account to allow provisioning?
Currently my schema looks like this:

Thanks again!
Damiano

Hello once again,

try “posixgroup” without camelCase in the account schemas, I realised now that It failed for me when I had camelcase, and now I have all lower case.

Also, in IDN there is a checkbox in the source configuration that you have to switch on in order to use posixgroups:

Is there anything similar that needs to be switched on in IIQ?

1 Like

Hi @dpuccina

In case to set UID attribute based on group membership, please add the following lines in your schema of posixgroup type

<Schema aggregationType="group" displayAttribute="cn" featuresString="PROVISIONING"  identityAttribute="dn" " nativeObjectType="posixGroup" objectType="posixgroup">
.....
<Attributes>
     <Map>
        <entry key="groupMemberAttribute" value="memberUid"/>
        <entry key="memberAttribute">
            <value>
                 <List>
                      <String>uid</String>
              </List>
            </value>
          </entry>
        </Map>
      </Attributes>
<Schema>
1 Like

Thanks to both of you, I was able to solve it!

Basically seeing Sebastian’s (@Swegmann ) settings I reconfigured the connector, not LDAP type but OpenLDAP which has by default all the settings to handle “posixGroups”.

Then adding the line that Ismael (@ismaelmoreno1 ) suggested I can now do the group assignment with the uid instead of the dn!

Thanks to both of you!
Damiano.

1 Like

Hello!
I will add a point, maybe you know how you can help me.
Basically through this OpenLDAP connector I should be able to manage the “secPwdValid” attribute.
I can write the value “true” or “false”, the problem is that the connector keeps writing me the value in upper case but I need it in lower case.
I have tried either passing it as a value or as a script but the result is always uppercase.

Do you happen to know if it is possible to change this behavior?

Thanks!
Damiano

Hey @dpuccina

In my case I have not managed “secPwdValid” attribute, but I would like to know more details about the issue, what kind of script are you using to transform de value, and when you are using this attribute.

If you want, you can open a new Question, providing these details and mayber other expert could solve this issue.

Thanks!