I’m trying to provision to NetIQ eDirectory through the generic LDAP connector (the regular eDirectory connector is not working in our tenant), and am running into the error posted below
["sailpoint.connector.InvalidRequestException: [ InvalidRequestException ] \n [ Possible suggestions ] Ensure that value of \u0027User DN\u0027 is correct. \n [ Error details ] Invalid name: 00009999","sailpoint.connector.InvalidRequestException: [ InvalidRequestException ] \n [ Possible suggestions ] Ensure that value of \u0027User DN\u0027 is correct. \n [ Error details ] Invalid name: 00009999"]
Within the Create Account tab I have tried listing out both User DN and dn as static attribute with the format shown below. CN is being filled with an identity attribute that is found on the accounts, whose value is akin to their employee ID. This matches with accounts already existing in the directory. I have also tried switching the attribute I am using to create the DN, but no matter what attribute I change it to the error does not change values. I did notice that there appears to be a quotation after the employee ID in the error, but again, I don’t know where that is coming from as none of our identity attributes contain quotations.
Welcome to developer community!
Can you get the DN value for any existing users and check the format? Also, the attribute for CN value calculation should be above of DN.
Enable DEBUG level loggings for LDAP connector and check for more logs
In the search tab, searching with a specific user’s ID will display some Account Activity logs. The ‘Account Activity’ tab should contain a log showing the values SailPoint is sending to the attributes. This log will include ‘Account Request’ and ‘Attribute Requests,’ where attribute information can be found in the ‘Attribute Requests’ section. Is the expected value been passed to ‘dn’ in the logs?
The DN for existing users matches the format we are using for the DN. The CN attribute is also defined above.
Within the ccg logs I can see the dn formatted correctly (picture below with some omissions).
From the ‘Account Activity’ tab, this is the error received.
sailpoint.connector.InvalidRequestException: [ InvalidRequestException ]
[ Possible suggestions ] Ensure that value of 'User DN' is correct.
[ Error details ] Invalid name: 02######
The dn value within the ‘Attribute Request’ matches with what I pasted from the VA logs.
Again, even when changing the dn name to User DN or any variation of, the same error returns. I’m not sure where it’s getting the Invalid Name from as I am obviously passing in a complete DN, not just the CN
I think the DN format should be as below. It should be “uid” than “cn”. Not sure if this varies across systems. You can check for any existing user in LDAP system
Can you try using a hardcoded value?
Also, the error you mentioned is for ‘User DN’. Is it the same for ‘dn’? Usually, policy attributes don’t have spaces, and their names should match the schema attributes
Our directory structure uses CN to formulate the DN. For example, my DN may be cn=bvielma,ou=People,ou=Users,o=Org (the difference in CN values between mine and the one I’m using for testing is expected and seen within our directory)
The same error returns when hardcoding the value of their CN and processing them again.
Your comment on the error is also what has prevented me from troubleshooting it on my own any further. I do not know why this error is being thrown with that attribute name as there is no User DN attribute within the schema nor within our directory.
Yes, it’s being defined higher up in the Create Account module, and is being passed over correctly in the ‘Attribute Request’ section of ‘Account Activity’
I would try not passing CN as a separate attribute. The error is about an invalid “name” which normally refers to the CN. To test, remove CN from create profile and hard code your DN.
Hey Bobby,
If you are passing dn do not pass cn. It will be added by the connector. To Test this remove the cn value and just have the dn value. Also can you share the Account Activity how the attribute looks like after you change the setting and let us know if it fixes your issue
I removed the CN attribute from the Create Profile and hardcoded the entire DN, but the error persists. I’d also like to call out that the CN and DN fields both come OOB on the ‘Create Account’ screen when setting up the connector. If there’s documentation that states to not include CN when DN is filled out, I’d appreciate it if someone could link it.
Below is a sample of the Account Activity data when removing CN and hardcoding DN. Other attempts look identical (except for including CN).
ACCOUNT REQUEST
Create account: 02######
ATTRIBUTE REQUESTS
Add groupMembership: cn=Stores,ou=AA,ou=Groups,o=Org
Add password: Unknown
Add givenName: Katie
Add SN: Test
Add afBusinessTitle: Brand Representative
Add afBusinessUnit: S
Add afCompany: Stores, Inc.
Add afCompanyCode: AST
Add afDepartment: Ala Moana
Add afEmployeePayType: H
Add afFirstName: Katie
Add afJobCode: 0023
Add afDepartmentID: #####
Add afJobCodeDescr: Brand Representative
Add afJobFamily: STONON
Add afJobFunction: STO
Add afJobGrouping: 02
Add afLastName: Test
Add afLocation: Ala Moana
Add afLocationCode: #####
Add afLocationDesc: Ala Moana
Add afManagerLevel: Support
Add afManagerLevelCode: S1
Add afObjectActive: TRUE
Add afOfficeType: S
Add afPersonType: EMP
Add afPosition: Representative
Add afPositionNumber: ########
Add afRmsEmployeeTypeCode: None
Add afStartDate: 2025-03-14
Add afTitle: Brand Representative
Add co: USA
Add displayName: Katie Test
Add employeeStatus: A
Add Language: ENG
Add title: Brand Representative
Add uid: 02######
Add objectClass: inetOrgPerson,Person,afPerson,Top,organizationalPerson,afVendor,DirXML-PasswordSyncStatusUser
Add mail: [email protected]
Add dn: cn=02######,ou=People,ou=Users,o=Org
It looks like you are trying to set the “name” attribute in eDir as a DN. The name attribute is an LDAP attribute but not an eDir attribute. Verify in your create account that you are not sending a value for name. LDAP will show the CN as the name attribute when using an LDAP browser, it does not need to be part of the create. I am not sure if eDir sets some other attribute that maps to name in LDAP or how that part is working but it cannot be part of the create as eDir does not recognize that attribute unless you add it to your LDAP group attribute map and have it mapped to some other eDir attribute.
I believe the part you highlighted is part of the connector call. As in it is saying the name of attribute is “dn”, just as the op is “Add” and the value is “cn=02…”
The OOB connector sets uid to be a string. It’s also set as a string in our LDAP schema and other existing accounts have leading zeros as their UID. I did try hardcoding a value without a leading zero (as we don’t have any int or long data types in our schema) but it didn’t work (although I’m sure it was still processing it as a string)
Understood, the only thing I’ve got left (assuming you’ve already checked uniqueness) is case sensitivity on the attribute name - maybe try “DN” vs “dn”?
