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

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.

3 answers

1 accepted

This widget could not be displayed.

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'.

This widget could not be displayed.

Hi Glenn, by right if the delegated LDAP is on top, you should be able to login against LDAPO directory. There's some possibility that the user is inactive. Please try to run the following query.

SELECT * FROM cwd_user WHERE user_name = '<username>'

Please do change <username> to relevant user name, and check active field whethe rit's set to T or F.

This widget could not be displayed.

Evidently the problem is that the users already exist in the internal directory from the N years before we attempted to enable Delegated LDAP. From what I'm learning, this means that only new users will be LDAP authenticated but all existing users will be internal directory authenticated. Not exactly what you'd expect by putting LDAP at the top of the list.

Suggest an answer

Log in or Sign up to answer
Community showcase
Posted Thursday in United States

Local Atlassian Research Workshop opportunity on Sep. 28th

We're looking for participants for another workshop at Atlassian! We need Jira admins who have interesting custom workflows, issue views, or boards. Think you have a story to sh...

65 views 0 0
View post

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you