nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Issues Logging in After Restore - Can I disable LDAP?

Andrew Wolpers

There are a few questions and answers about them, but I'm looking to do this without involving the DBA.

Trying to move Jira 5.2.7 to 6.2.3, though there is the compatability error when trying to "Restore From Backup" with XML.

So, I decided to spin up a server for staging. Restore From Backup worked fine. However, when I tried to login (on both the local account used during setup and an admin account from the old server) it simply times out and returns no error in the logs, but it has shown me this one:

Sorry, a communication error occurred while trying to contact the remote authentication server.

From the auto logs it hasn't shown anything, tail -f catalina.out will only show me errors involving mail handlers.

So, it appears that the restored backup is trying to reach the LDAP server from before. I'm wondering if there is a way on the Test Machine to modify a file and have it point to the local account I had created, avoid LDAP and make the world a better place all in one fel swoop?

Accepted answers

Andrew Wolpers

Ok, I got on the horn with Support and Ivan was awesome. He gave me this query that really helped clear things up:

SELECT DISTINCT child_name FROM cwd_membership WHERE directory_id = 1 AND child_name IN (SELECT child_name FROM cwd_membership WHERE parent_name IN (SELECT perm_parameter FROM schemepermissions WHERE PERMISSION=44)) ORDER BY child_name;

Instead of the query to list admins, this one listed those with a higher level that could login at its current state. From there I reset the password of the default "adminaccount" user and successfully logged in.

All comments

Diego Zarpelon

Hey Andrew, first thing is to make sure we have a local account. You can do this using this query:

The basic process for this is to change group membership for jira on its database. That is done using the steps on this link . Just remember to stop your jira instance before changing anything on its dabase and make a backup of your DB. If you want further assistance please tell me!

Andrew Wolpers

Diego,

Thanks for getting back to me! I did go through a few of these DB steps, and I did look into these documents/do these as well:

https://confluence.atlassian.com/display/JIRA/Running+SQL+commands+in+a+HSQL+databaseand
https://confluence.atlassian.com/display/JIRA061/Retrieving+the+JIRA+Administrator

Step #3, which identified the Global Permission, reveals that my account does indeed exist. However, when trying to login it still displays the issue.

I did try the final step of modifying/manually resetting the user password: update cwd_user set credential='uQieO/1CGMUIXXftw3ynrsaYLShI+GTcPS4LdUGWbIusFvHPfUzD7CZvms6yMMvA8I7FViHVEqr6Mj4pCLKAFQ==' where user_name='USERNAME';

Sadly this didn't turn out any better. Should I use the ID# rather than the USERNAME?

Diego Zarpelon

Cool let me know if you need any other assistance!

Andrew Wolpers

Ok, I got on the horn with Support and Ivan was awesome. He gave me this query that really helped clear things up:

SELECT DISTINCT child_name FROM cwd_membership WHERE directory_id = 1 AND child_name IN (SELECT child_name FROM cwd_membership WHERE parent_name IN (SELECT perm_parameter FROM schemepermissions WHERE PERMISSION=44)) ORDER BY child_name;

Instead of the query to list admins, this one listed those with a higher level that could login at its current state. From there I reset the password of the default "adminaccount" user and successfully logged in.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

jira-administration