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

Provisioning Accounts to redhatIDM

ARCrosthwaite
New Contributor II
New Contributor II

We are trying to configure provisioning of accounts into redhatIDM using the LDAP connector however when we run the provisioning job we get and LDAP error code 32 both in the logs and in the provisioning comments.

We've had confirmation from the application team that we have the correct permissions and are trying to create the account in the correct location. However we continue to get this error whenever we attempt to provision the test account.  They below is an extract from the log file 

account in AD - [LDAP: error code 32 - No Such Object]"
"2024-08-20T12:08:36.146+00:00","ecm-worker","","null-9zkf6","","javax.naming.NameNotFoundException: [LDAP: error code 32 - No Such Object]; remaining name 'uid=XXX,cn=XXX,cn=XXX,dc=XXXdc=XXX,dc=XXX,dc=XXX' at com.sun.jndi.ldap.LdapCtx.mapErrorCode(LdapCtx.java:3286) at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:3207) at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2998) at com.sun.jndi.ldap.LdapCtx.c_createSubcontext(LdapCtx.java:840) at com.sun.jndi.toolkit.ctx.ComponentDirContext.p_createSubcontext(ComponentDirContext.java:341) at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.createSubcontext(PartialCompositeDirContext.java:268) at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.createSubcontext(PartialCompositeDirContext.java:256) at javax.naming.directory.InitialDirContext.createSubcontext(InitialDirContext.java:197) at com.saviynt.ldap.SaviyntGroovyLdapService$_createAccountGLDAP_closure2.doCall(SaviyntGroovyLdapService.groovy:839) at com.saviynt.ldap.SaviyntGroovyLdapService.createAccountGLDAP(SaviyntGroovyLdapService.groovy:250) at com.saviynt.ecm.services.ArsTaskService.createAccountTarget(ArsTaskService.groovy:11816) at com.saviynt.ecm.services.ArsTaskHelperService$_whenTaskTypeIsThreeNewAccountAccess_closure50.doCall(ArsTaskHelperService.groovy:3078) at com.saviynt.ecm.services.ArsTaskHelperService.whenTaskTypeIsThreeNewAccountAccess(ArsTaskHelperService.groovy:3069) at com.saviynt.ecm.services.ArsTaskHelperService$_completeAutoProvTasksUpgraded_closure1.doCall(ArsTaskHelperService.groovy:175) at com.saviynt.ecm.services.ArsTaskHelperService.completeAutoProvTasksUpgraded(ArsTaskHelperService.groovy:160) at MultipleProvisioningJob.execute(MultipleProvisioningJob.groovy:222) at org.quartz.core.JobRunShell.run(JobRunShell.java:199) at org.quartz.simpl.SimpleThreadPool$WorkerThread.run(SimpleThreadPool.java:546)"

4 REPLIES 4

rushikeshvartak
All-Star
All-Star
  • You have issue with json on objects defined
  • share  json 

Regards,
Rushikesh Vartak
If this helped you move forward, click 'Kudos'. If it solved your query, select 'Accept As Solution'.

CREATEACCOUNTJSON

{
"givenName": "${user.firstname}",
"sn": "${user.lastname}",
"title": "${user.title}",
"employeenumber": "${user.username}",
"mail": "${user.email}",
"homeDirectory": "/home/<XXX>"
}

ACCOUNTNAMERULE

uid=XXX,cn=XXX,cn=XXX,dc=XXX,dc=XXX,dc=XXX,dc=XXX

 

This error can arise from several issues. Here are some steps to troubleshoot:

  1. Verify the DN (Distinguished Name): Double-check that the DN for the account you're trying to create or modify is correct. Ensure that the DN components (like uid=XXX, cn=XXX, etc.) are valid and exist in the LDAP directory.

  2. Check Base DN Configuration: Ensure that your LDAP connector's base DN configuration is correctly set. The base DN must be correctly specified to the portion of the directory where the objects are located or created.

  3. Confirm Object Location: Confirm with your LDAP directory or application team that the target DN where you're trying to create the account actually exists and is accessible. You might need to create any necessary parent objects or update the configuration to point to the correct location.

  4. Permissions and Access: Even if you've confirmed permissions, verify that the account used for LDAP operations has sufficient permissions to create objects at the specified location.


Regards,
Rushikesh Vartak
If this helped you move forward, click 'Kudos'. If it solved your query, select 'Accept As Solution'.

Just to update and explain the solution turns out with regard to redhatIDM there is a primary storage directory as well as what is being called the compat tree (compatability layer).  The DN for the account should be set as the primary storage and not the compatibility (compat) DN.