We have two Confluence Data Center instances. A production instance (confluence.my-company.com) and a test instance (confluence-test.my-company.com) for testing.
The production instance uses Microsoft Active Directory and the Confluence Internal Directory as the user directory. The test instance uses only the Confluence Internal Directory.
The production and test instances each have their own Oracle database, which in turn run separately on an Oracle test database server and on a production database server.
Now I have made a mistake. I have created a site backup in the Confluence production instance. Then I restored the Confluence production site backup in the Confluence test instance. I did this because I wanted to bring the test instance up to date. Many spaces and apps that were created over time in the production instance were missing in the test instance.
Since restoring the site, I can no longer log in to the test instance. When I enter the URL “confluence-test.my-company.com” in the web browser, it immediately redirects me to “confluence-test.my-company.com/login.action?os_destination=%2Findex.action&permissionViolation=true”. When I then try to log in, I get the error message “The following error(s) occurred: Sorry, your username and/or password are incorrect. Please try again.” although the data is correct.
I have already activated the confluence recovery admin. Unfortunately, I can't log in with the recovery admin either. In addition, I did a full VM restore from the Confluence test server using Veeam to get back to the old state before the site restore. I also restored the entire tablesapce from a backup in Orcale for the Concluence test database. None of this has helped. I still get the same error and still can't log in.
Does anyone have any ideas what else I could try?
Can anyone tell me where Confluence stores the internal directory?
Hi and Welcome to the Community!
This happens a lot and is indeed a result of the restore. With the restore you have also restored the User directories to your test instance + the order they are in to authenticate. I'm going to guess that on PRD your AD directory is higher in the list than the Internal directory.
If this is the case authenticating on test with a test user and credentials will try authentication against the PRD AD first. If the user is found there, it wil authenticate with those credentials (or try to do so) and the Internal directory won't be used.
What you could do:
Another solution would be to make the test instance access the PRD AD, that way you can authenticate with the same user.
Jeroen
Hi @Jeroen Poismans
indeed in our PRD instance the AD directory is higher in the list than the internal directory.
What you could do:
- Create an internal user on PRD in the Internal directory
- This user can not be in AD
There is an admin user in the Internal Directory of the PRD instance. Unfortunately, I can't log into Confluence Test with this user from PRD.
- Redo the restore
I can't redo the restore because I can no longer log in to Confluence. I can only access the server via SSH.
I thought that if I restore the Veeam backup of the Confluence Test Server with the state before PRD Site restore and additionally restore the tablespace of the external Oracle database from Confluence Test, then everything will work as before. However, this is not the case.
I have looked in the atlassian-confluence.log file. It shows me the following error: [Caesium-1-1] [troubleshooting.healthcheck.concurrent.SupportHealthCheckProcess] lambda$getCompletedStatuses$0 Health check 'Internal Administrator User' failed with severity 'major': 'Confluence has an enabled internal user directory, however its administrator account does not exist or is disabled'
Do you know where Cofluence stores the internal directory?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Users are in the cwd_user table but you don't actually need access to the test instance:
Jeroen
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I was able to get the Confluence test instance running again using a different method.
The problem was that I restored the wrong tablespace in orcale all the time. It was the table from a very old Confluence test server that no longer exists. Now I have restored the correct tablespace from the current Confluence Test Server.
@Jeroen Poismans I'm still very grateful for your support.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.