After adding Delegated LDAP Authentication, users are still authenticated against internal directory

Glenn Engel1

We have a system with 500+ users using the Confluence Internal Directory. After adding a Delegated LDAP authentication directory method we find that users are still authenticated against the internal directory. This occurs regardless of the position of the directories in the list.

Please advise on how to force existing users to be LDAP authenticated.

Glenn Engel1

I was able to successfully migrate from Internal Directory to Delegated LDAP with the following procedure. This may very well work for moving users between other directory methods but I was only interested in this case.

1. Create or make note of an admin capable user in the internal directory that will not be involved in the conversion and then create your Delegated LDAP directory.
2. Stop confluence. I had some odd errors a few times during test that seemed to go away if confluece was stopped before doing the sql manipulations.
3. Fix any usernames that do not match LDAP user names via instructions in this article. You'll of course have to identify the usernames that need conversion yourself. This step can be done later or omitted.
4. Change the directory_id for all users in the cwd_user table to refer to the Delegated LDAP directory_id rather than the internal directory. This was done with the following bit of sql.
   

   update cwd_user  set directory_id = (select id from cwd_directory where directory_name = 'Delegated LDAP Authentication') ,credential=NULL
       where directory_id = (select id from cwd_directory where directory_name = 'Confluence Internal Directory')
             and not user_name like '%admin%' and not user_name like '%remote%' and not user_name like '%test%';

   This sql omits conversion of usernames containing 'admin', 'remote', or 'test'. It is important that at least one username still reside in the internal directory so you can still log in after this step. You can see the names of the directory_name options with this sql:
   

   select id,directory_name from cwd_directory;

5. Start Confluence. The next step requires confluence to be running.
6. After changing directory_id users can log in with LDAP authentication but will be unable to access any pages because their group membership still resides with the internal directory. One more step is required to copy their group membership from the internal directory to the Delegated LDAP directory. This conversion process is described in Migrate Local Group Memberships Between Directories article. This article worked for me but I tweaked the sql to use the following expression for obtaining the internal directory id so I could reuse the script without hand editing.
   

   SELECT cu.lower_user_name, cg.lower_group_name
     FROM cwd_user cu
         JOIN cwd_membership cm ON cu.id=cm.child_user_id
         JOIN cwd_group cg ON cm.parent_id=cg.id
      WHERE cu.directory_id= (select id from cwd_directory where directory_name = 'Confluence Internal Directory') AND cg.directory_id= (select id from cwd_directory where directory_name = 'Confluence Internal Directory')
         INTO OUTFILE '/tmp/groups.csv'
            FIELDS TERMINATED BY ','
            ENCLOSED BY ''
            LINES TERMINATED BY '\n';

   Note that you do not need to install the CLI plugin in confluence but you do need to unzip it to access the confluence.sh script.
7. Rebuild Indexes.

The above worked for me. Hopefully it can help someone else. Step 4 seems to be what is missing from the documentation anywere. Someone from Atlassian suggested this approach with 'no guarantees'.