LDAP sync does not create new users and repeats same actions on every run

  • Document ID:7017448
  • Creation Date:01-Apr-2016
  • Modified Date:07-Apr-2016
    • Micro Focus Products:
      Filr

Environment

Novell Filr 2.0

Situation

When running the LDAP sync, it appears that none of the newly added users on the LDAP server are registered in Filr. When looking through the appserver.log it appears that the same set of actions are repeated every time the LDAP sync task is run. For example, the same set of users are shown as being disabled on every run which should not happen if those users were disabled in the first run.

The following series of events will appear and repeat in the appserver.log on every LDAP sync run:

2016-02-29 18:35:28,117 WARN  [Sitescape_Worker-7] [org.hibernate.util.JDBCExceptionReporter] - SQL Error: 2601, SQLState: 23000
2016-02-29 18:35:28,117 ERROR [Sitescape_Worker-7] [org.hibernate.util.JDBCExceptionReporter] - Cannot insert duplicate key row in object 'dbo.SS_Principals' with unique index 'name_Principal'. The duplicate key value is (1, hbosma).
2016-02-29 18:35:28,118 ERROR [Sitescape_Worker-7] [org.kablink.teaming.module.ldap.impl.LdapModuleImpl] - An error occurred attempting to create a batch of users:
org.springframework.dao.DataIntegrityViolationException: could not insert
...
...
2016-02-29 18:35:28,119 INFO  [Sitescape_Worker-7] [org.kablink.teaming.module.ldap.impl.LdapModuleImpl] - 2nd attempt to create the user: hbosma
2016-02-29 18:35:28,131 WARN  [Sitescape_Worker-7] [org.hibernate.util.JDBCExceptionReporter] - SQL Error: 2601, SQLState: 23000
2016-02-29 18:35:28,131 ERROR [Sitescape_Worker-7] [org.hibernate.util.JDBCExceptionReporter] - Cannot insert duplicate key row in object 'dbo.SS_Principals' with unique index 'name_Principal'. The duplicate key value is (1, hbosma).
2016-02-29 18:35:28,132 ERROR [Sitescape_Worker-7] [org.kablink.teaming.module.ldap.impl.LdapModuleImpl] - An error occurred trying to create the user the 2nd time: hbosma
2016-02-29 18:35:29,516 INFO  [Sitescape_Worker-7] [org.kablink.teaming.module.ldap.impl.LdapModuleImpl] - Disabled user: jjmtimmerman
2016-02-29 18:35:29,547 INFO  [Sitescape_Worker-7] [org.kablink.teaming.module.ldap.impl.LdapModuleImpl] - Disabled user: rvermeer
2016-02-29 18:35:29,577 INFO  [Sitescape_Worker-7] [org.kablink.teaming.module.ldap.impl.LdapModuleImpl] - Disabled user: mnijenhuis
...
...

Resolution

A fix for this issue is available in the Filr 2.0 Hot Patch 1, available via the Novell Patch Finder.

This fix requires manual intervention by the Filr administrator to correct the user records in the Filr database as follows:
  1. The fix will make it easy to identify the problematic user when reading the appserver.log file
    For example, the appserver.log should include the following information for problematic users after applying this patch:
    2016-03-05 23:42:40,050 WARN  [http-bio-8080-exec-6] [org.kablink.teaming.module.ldap.impl.LdapModuleImpl] - Cannot create user 'hbosma' with dn='cn=hbosma,ou=users,o=acme' and ldapGuid='b2c7699fc123de4f5e92b456699fc2a9' because a user with the same name already exists in the database
    -
  2. For all such users, administrator will have to reset the user's GUID value in the Filr database and run another LDAP Sync
    For example, the following query will set the user's GUID value in Filr to NULL:
    UPDATE SS_Principals set ldapGuid=NULL where name='hbosma' and ldapGuid='b2c7699fc123de4f5e92b456699fc2a9' and type='user';
    -
  3. After running another sync, you can verify that your user now has the new GUID value
    SELECT name, ldapGuid from SS_Principals where name='hbosma' and type='user';


Important Note: Take a backup of your Filr database (for example using mysqldump for MySQL) before attempting to make any changes directly to the database. If you are unsure about what changes need to be made, please contact Novell Technical Support with reference to this TID and ask for assistance.

Cause

The problem arises when the user's unique GUID changes between the Filr system and the LDAP Server; typically because the user was deleted and re-created in the LDAP Server. When this happens Filr is not able to automatically update the user's GUID but rather disable the user in Filr (because his GUID is no longer found in the LDAP Server). But any attempts to register the user with the new GUID will fail because Filr database will still have the same username. The easiest workaround is to delete the old user from Filr and allow the next LDAP sync to create a new user for the user with the new GUID. However, in most cases deleting and re-creating the user is not desirable.