After upgrading NSD from v6.5.4 to v7.0, users cannot be added from an LDAP source.

  • 7011494
  • 12-Dec-2012
  • 28-Jan-2013

Environment

Novell Service Desk

Situation

After upgrading NSD from v6.5.4 to v7.0, users cannot be added from an LDAP source.

Scenario when the issue occurs:
- This issue will occur only if a customer has imported users from an LDAP source in NSD v6.5.4 and upgrades to NSD 7.0. Subsequent upgrade from v7.0 won't fix the issue automatically and will need to execute commands on the database manually.
Scenarios when the issue does not occur:
- Fresh installation of NSD v7.0.
- Upgrading NSD from v6.5.4 to v7.0 without any users imported from an LDAP source.
- Upgrading NSD from v6.5.4 directly to v7.0.1 (irrespective of users imported from an LDAP source or not).

Resolution

- Automatic:
- Applicable if a customer upgrades NSD v6.5.4 directly to v7.0.1.

- Manual:
- Applicable if a customer has upgraded NSD v6.5.4 to v7.0.
- Applicable if a customer has upgraded NSD v6.5.4 to v7.0 and subsequently to later versions.
- Involves running a script that corrects a record in the NSD database. Can be run when the system is in v7.0 or new versions.

Cause

As part of NSD v7.0, a new feature was introduced to support multiple LDAP sources. This added a new table LDAP_CLIENT by denormalizing CLIENT table. As part of upgrade, data is copied from CLIENT to LDAP_CLIENT table. NSD uses its own counter for primary keys. After copying the data to LDAP_CLIENT table, the counter is not set properly for LDAP_CLIENT table and left with the default value of 1. As part of LDAP sync if any new user object is added, insertion fails as NSD tries to update the record with ID 1 and database throws primary key constraint violation.

Additional Information

- Documentation of database commands that will rectify the counter value for LDAP_CLIENT table so that the subsequent updates will happen to the first unused index. These commands will be run by the administrator manually.

Connect to NSD DB and execute the following queries
a. SELECT MAX(ID) / 10 + 1 FROM LDAP_SOURCE;
b. SELECT MAX(ID) / 10 + 1 FROM LDAP_CLIENT;
c. SELECT MAX(ID) / 10 + 1 FROM LDAP_CLIENT_ROLE;
d. SELECT NAME, PK FROM EO_PK_TABLE WHERE NAME = 'LDAP_SOURCE';
e. SELECT NAME, PK FROM EO_PK_TABLE WHERE NAME = 'LDAP_CLIENT';
f. SELECT NAME, PK FROM EO_PK_TABLE WHERE NAME = 'LDAP_CLIENT_ROLE';

a-c show what the values in the EO_PK_TABLE should be.
d-f show what the values currently are.

Note that if any of the queries above error, because fields do not exist, etc, this would suggest an error in the upgrade process itself, or that they are not on version 7, so in such cases, please refer back to us for the next course of action.
If any of these values do not match, this should be where the error lies. To get them to match, first backup the NSD database, and if possible run these queries in a testing environment first. Then, run the following, replacing a,b and c with the numbers returned in queries a,b and c above:

UPDATE EO_PK_TABLE SET PK = a WHERE NAME LIKE 'LDAP_SOURCE';
UPDATE EO_PK_TABLE SET PK = b WHERE NAME LIKE 'LDAP_CLIENT';
UPDATE EO_PK_TABLE SET PK = c WHERE NAME LIKE 'LDAP_CLIENT_ROLE';

LiveTime/Tomcat/etc would need restarting and the users should import just fine.