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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.