It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

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

Glenn Engel Dec 13, 2012

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

2 votes
Answer accepted
Glenn Engel Dec 16, 2012

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
          JOIN cwd_group cg ON
       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 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'.

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.

0 votes
Glenn Engel Dec 13, 2012

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
This widget could not be displayed.
This widget could not be displayed.
Community showcase
Posted in Off-topic

Disney Live Action Reboots: Are you for or against?

Happy Friday Everyone! Today marks the international release of Disney's live action version of the animated classic Aladdin. I know that this movie was met with some controversy of over cast...

139 views 19 8
Join discussion

Community Events

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

Find an event

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

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you