This isn't a question, rather it is just some information, in case you ever want to update a Confluence instance that is using Internal Authentication only to now use LDAP Authentication (local users, ldap authentication). This is my learning experience. Note, the commands are NOT supported by Atlassian, use at your own risk. Do a backup first.
I followed the directions in the document, [Connecting to an Internal Directory with LDAP Authentication|https://confluence.atlassian.com/x/fg6zDQ]. Initially I did NOT set the "Copy Users on Login". I tested my settings and everything was good, so I saved them.
Then under the settings User Directory, I moved my new configuration to the top of the list. When I tried to log in, it was ignoring my LDAP password, and was still using the internal password. After doing some research I saw that some people had success with "Copy at first login", so I did that and saved my settings. Now when I tried to login the system created a new account, and wiped out all my permissions (like all good sys admins I had a backup administrator account configured). I tried to uncheck this option. However, when I tried to save the configuration after this, it gave me the classic "Oops" error. I was stuck. No one could log in without wiping out their permissions, and I could not undo the change. What I eventually found was that I could disable and then delete it.
The problem was that the users existed in the internal directory and therefore would not authenticate with LDAP. In order to do this I would need to add the users to the LDAP directory. Officially, I would have to add the users manually. Unofficially, I could follow the steps in [Migrate Local Group Memberships Between Directory|https://confluence.atlassian.com/x/oQc_EQ]. When I did this, it duplicated all the users, and therefore used up all of my user licenses.
The suggestion from Atlassian was to retrieve a list of users and then use the CLI plugin (which has become my best friend through this) to create the new users, after that to rerun the group membership file created above.
This is the command used to create the user list:
SELECT lower_user_name, 'password', email_address, display_name FROM cwd_user
and the import command:
./confluence.sh --action addUserWithFile --file "users.csv"
this did not work as it detected that the users already existed in the database.
Bottom line I got to the point where I was stuck. The only suggestion left was to manually create the 400 users. Not something that I was willing to do.
What I ended up doing was something that I really don't like to do. I manipulated the database directory. *WARNING* - Take a backup, run in Test before doing in Production. We found the ID for our LDAP configuration, and for the Internal configuration. Made a note of the ID. In the tables, CWD_User, CWD_User_attribute, and CWD_group, we updated the id from the existing internal id, to the new ldap id. Restarted the system. Testing confirmed that this worked. Or so we thought. We found though that none of the the 'service accounts', that is accounts that existed in Confluence, but didn't exist in the LDAP would work. We tried moving them back to the old ID (basically undid the database change), and still it didn't help.
Through trial and error we found that the root cause was that new users were always being created as an "LDAP Authentication" account, we were never allowed to enter a user as an "Internal Authentication" account. So I went back to the Users directory, I moved internal authentication, above the LDAP authentication. Then I could create a new user, it creates with type Internal Authentication. I then go back to the User Directories and move LDAP above Internal I can get it to work. This step will need to be repeated whenever a new service (internal only) account is created. Seeing as this is not done a lot, it is a small price to pay to get Confluence to work with Local Users, and LDAP authentication.
This method is not supported by Atlassian, but they are aware of the steps that I did to resolve this problem. There may be other methods to solve this issue, but neither me, nor Atlassian were able to have success in finding something that worked.
This is my story. Hopefully it will save some people a bit of stress and frustration in case they ever try to do this.
Again, I can't stress enough, backup, backup, backup. We ended up restoring our backup several times during this investigation.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.