Documentation for JIRA 6.4. Not using this? See below:
(JIRA 6.3.x documentation | JIRA Cloud documentation | earlier versions of JIRA)

Skip to end of metadata
Go to start of metadata

 

This page describes how to retrieve the JIRA Administrator. It is broken down by JIRA version, as the process is different depending on what version of JIRA you are on. Please ensure you're referring to the correct process for your version of JIRA. If you are running versions 5.2 and below, please refer to our previous documention.

For JIRA versions above 6.2.1:

Using Single Sign-On (SSO):

  • If JIRA is configured for SSO through Crowd or another third-party service, only users from Crowd or the other service will be able to log in to JIRA.
  • In order to log in as a user from the JIRA Internal Directory, roll back the changes made within Integrating Crowd with Atlassian JIRA or as made by the third-party authenticator.

Scenario A: I don't know which user has the JIRA Administrators or JIRA System Administrators global permission

You first need to find out which group(s) have been granted the global permission.

The JIRA System Administrators global permission was added to JIRA in version 3.12. Anyone granted the JIRA System Administrators global permission can perform all administration tasks in JIRA, whereas anyone granted the JIRA Administrators global permission can perform most but not all administration tasks. Prior to version 3.12, anyone granted the JIRA Administrators global permission can perform all administration tasks.

  1. To find out which group(s) have been granted the JIRA Administrators global permission, run the following database query:

  2. To find out which group(s) have been granted the JIRA System Administrators global permission, run the following database query:

  3. Now that you know which group(s) have the global permission, run the following database query to find out which users are in that group (replace "jira-administrators" with the group returned by the above query):

    (info) If you are having issues with remote directory connectivity, you will need to use an account with a directory_id of 1.

     

    If you don't know the password for the user(s) returned by this query, move on to Scenario B.

If there are no Internal JIRA Administrators

If you're using Crowd or an external user management system, there may be no users with administrator permissions. 
Find the groups in the external management system that you want to grant the administrator permissions and do the following:

  1. Shutdown JIRA.
  2. Use SQL to assign the appropriate group to the administrator permissions similar to this:

  3. (Oracle only): Execute a COMMIT so that the transactions are completed.
  4. Restart JIRA.

If no users or groups exist in JIRA

There may be no users or groups in your Internal Directory. If this is the case, you need to add one:

  1. Add a new 'localadmin' user with the password sphere:

    (warning) If you are using Oracle database use the following:

  2. Add new groups:

    (warning) If you are using Oracle database use the following:

  3. Add groups to the appropriate Global Permissions:

  4. Add the group memberships for the 'localadmin' user:

  5. Enable the JIRA Internal Directory:

  6. (Oracle only): Execute a COMMIT so that the transactions are completed.
  7. Restart JIRA.

Scenario B: I know which user has the JIRA Administrators or JIRA System Administrators global permission, but I have forgotten the password

(warning) Note that this will only work for users in the Internal directory. The following methods will not work with external user directories (eg in an LDAP server), since authentication is performed externally. You can find which directory a user belongs to with the following SQL:

The password can be reset with either of the following:

1. Send it via email

This is the recommended approach.

If you have configured JIRA to send email, just click on the Forgot Password link on the login page, enter your username and click the Send it to me button. You will receive an email which will help you reset your password.

2. Set the password directly in the database

This is a last resort only - try the above recommended approach first.

  1. You can also update the password hash stored for a user in your database. Run the following command to set the user called XXXX's password to the word sphere.

  2. (Oracle only): Execute a COMMIT so that the transactions are completed.
  3. Restart JIRA.

For JIRA versions 6.0 to 6.2.1:

Using Single Sign-On (SSO):

  • If JIRA is configured for SSO through Crowd or another third-party service, only users from Crowd or the other service will be able to log in to JIRA.
  • In order to log in as a user from the JIRA Internal Directory, roll back the changes made within Integrating Crowd with Atlassian JIRA or as made by the third-party authenticator.

Scenario A: I don't know which user has the JIRA Administrators or JIRA System Administrators global permission

You first need to find out which group(s) have been granted the global permission.

The JIRA System Administrators global permission was added to JIRA in version 3.12. Anyone granted the JIRA System Administrators global permission can perform all administration tasks in JIRA, whereas anyone granted the JIRA Administrators global permission can perform most but not all administration tasks. Prior to version 3.12, anyone granted the JIRA Administrators global permission can perform all administration tasks.

  1. To find out which group(s) have been granted the JIRA Administrators global permission, run the following database query:

  2. To find out which group(s) have been granted the JIRA System Administrators global permission, run the following database query:

  3. Now that you know which group(s) have the global permission, run the following database query to find out which users are in that group (replace "jira-administrators" with the group returned by the above query):

    (info) If you are having issues with remote directory connectivity, you will need to use an account with a directory_id of 1.

     

    If you don't know the password for the user(s) returned by this query, move on to Scenario B.

If there are no Internal JIRA Administrators

If you're using Crowd or an external user management system, there may be no users with administrator permissions.
Find the groups in the external management system that you want to grant the administrator permissions and do the following:

  1. Shutdown JIRA.
  2. Use SQL to assign the appropriate group to the administrator permissions similar to this:

  3. (Oracle only): Execute a COMMIT so that the transactions are completed.
  4. Restart JIRA.

If no users or groups exist in JIRA

There may be no users or groups in your Internal Directory. If this is the case, you need to add one:

  1. Add a new 'localadmin' user with the password sphere:

    (warning) If you are using Oracle database use the following:

  2. Add new groups:

    (warning) If you are using Oracle database use the following:

  3. Add groups to the appropriate Global Permissions:

  4. Add the group memberships for the 'localadmin' user:

  5. Enable the JIRA Internal Directory:

  6. (Oracle only): Execute a COMMIT so that the transactions are completed.
  7. Restart JIRA.

Scenario B: I know which user has the JIRA Administrators or JIRA System Administrators global permission, but I have forgotten the password

(warning) Note that this will only work for users in the Internal directory. The following methods will not work with external user directories (eg in an LDAP server), since authentication is performed externally. You can find which directory a user belongs to with the following SQL:

The password can be reset with either of the following:

1. Send it via email

This is the recommended approach.

If you have configured JIRA to send email, just click on the Forgot Password link on the login page, enter your username and click the Send it to me button. You will receive an email which will help you reset your password.

2. Set the password directly in the database

This is a last resort only - try the above recommended approach first.

  1. You can also update the password hash stored for a user in your database. Run the following command to set the user called XXXX's password to the word sphere.

  2. (Oracle only): Execute a COMMIT so that the transactions are completed.
  3. Restart JIRA.

21 Comments

  1. The steps listed in this doc do not allow for changing the System Administrator password. I guess with the steps listed in the doc, you can bypass the authentication scheme but not the authorization. Instead, I resolved the issue by doing this:

    1. Edited the latest backup XML file to add a user for which I had the password to the System Administrator group.
    2. Uninstalled JIRA and deleted the JIRA folder
    3. Removed the JIRA windows registry entries
    4. Reinstalled JIRA and chose to import from the edited backup file.
    5. Logged in with the new System Admin user and changed the password for original System Admin
    6. Logged out and logged back in with the original System Admin and revoked the System Admin privileges from the other user.

    A bit more involved, but worked. Keep in mind to backup any changes you made to the jira-application.properties file as uninstalling JIRA will delete that file.

    1. Thanks Huzaifa.

      I've updated the instructions so that they do explicitly cover the JIRA System Administrators global permission.

      1. Anonymous

        thanks.

        but i want to ask something.

        while i m doing following instructions it says no database selected.

        can you help about this problem...

        1. Anonymous

          Run this command first:

          USE db1;

          Where db1 is the name of your JIRA database.

           

          Kyle L.

  2. Anonymous

    Hi!

    Is there any way to decode the password which has a value like "{PKCS5S2}DQIXJU038u4P7FdsuFTY/+35bm41kfjZa57UrdxHp2Mu3qF2uy+ooD+jF5t1tb8J" ?

    How to do it?

    Thanks!

    1. No. The password uses one-way encryption.

      If you need to re-gain access to an account, then you can replace the value with a known encrypted value.
      See section in the page above named "Set the password directly in the database"

      Pro Tip: Always have at least two admin accounts on your server. If one forgets their password or dies of a mysterious gardening accident, then the other still has access.

  3. Hi - sorry if this is the wrong place, but I have a very basic question. I've been tasked with setting up our JIRA structure, and I'm pretty familiar with JIRA from an end user (not admin) perspective. We have a google apps account, and my boss set up our JIRA 'on demand' instance to be tied into google apps, making him an administrator. Unfortunately, he doesn't know how to add me as an administrator, and I'm in another country so cannot go into his admin interface to investigate. Could you provide a brief step-by-step guide for an admin to change a user's role to admin in JIRA if on demand instance uses Google Apps? Sorry, no backend / database speak helps me. How can this be configured on the front end?

    1. Hi Nicole,

      The easiest way for an administrator to find his or her way around JIRA is to use the "." shortcut. Pressing "." and typing "users" will take him directly to the user management page. From there, all he will need to do is fine your username, and hit "Groups" to the right of it, and add the "administrators" group to your set of groups.

      Feel free to reach out if you're still struggling: cbang (at) atlassian (dot) com.

  4. This didn't work when I upgraded to 5.2.11 (fortunately on a duplicated server) – despite setting the password hash in the DB it still didn't want to log me in. I'm a bit suspicious about the hash in the documentation at it doesn't look like any of the other credentials in the DB, which all start with {PKCS5S2} – does this still definitely work?

     

    1. I just tested this on JIRA 5.2.11 and it works without issue. Have you considered asking a question on our public forum: https://answers.atlassian.com/ The community there can help you get through this kind of issue.

      1. As this was on a duped server I just restored it from a backup and created a local admin account before retrying the upgrade, which then worked. So I've got it working now, thanks (smile)

  5. Scenario C: I added Internal LDAP Authentication and moved it before the JIRA Internal Directory - thus losing the jira-administrators group permissions

    1. You are running with only JIRA Internal Directory (default from install).
    2. You then  add the "Internal with LDAP Authentication" User Directory.
    3. You reorder directories so that the Internal LDAP Authentication comes before JIRA Internal Directory
    4. You log off your admin account to test the new login (or - at some stage you have to verification your admin-rights).
    5. Disaster strikes!
      When authenticated (the LDAP Authentication itself is working fine) you find that JIRA hasn't merged the LDAP information with your existing internal account - and instead gives you a normal user account (at least I was able to login - since I added the option to add jira-users and jira-developers on first login via LDAP). In other words, the jira-administrators group is not one of the groups for your (newly created) user. (I wish JIRA could handle the different users in the different directories with more intelligence... (sad)). There were  no-longer anyone able to log in with admin rights!

    At this stage JIRA is a brick in terms of nobody being able to change it's operating parameters!

    Some suggestions I found online included reinstalling JIRA from scratch. Well, scratch that! I was in no mood for doing that. So, with some help of the instructions on this page (and - since our JIRA was still on HSQL also here: Running SQL commands in a HSQL database). Note: Thank you for having spent time on adding the information I needed to fix this (smile).

    An additional difficulty was that we are running JIRA on a Windows server and the HSQL instructions in the link above are meant for Linux-type installations. One small issue was that the Java used by JIRA is installed within it's own application and the PATH doesn't include that location. I didn't want to change anything on the system so I went down the easy route and made sure I included the path to java in the command to start the HSQL DB Manager. The second problem was that the database itself was located in a folder with a space in it. I tried a lot of different ways to get this working, without luck, so instead of having to specify the path in the commandline I rather CDed to the data-folder before starting the HSQL DB Mgr.

    Then the information on this page about adding the localadmin user came into play. But, some of the queries listed did not work (either bad number of params, numberformatting issues or dependency problems). I was in the end able to add just what I needed to get it working though via some tweaking.

    Creating the "localadmin" user with admin rights via the HSQL Database Manager:

    1. Make sure that you have shut down JIRA, as the database cannot be opened otherwise.
    2. Open command-prompt
    3. Change directory to the data folder:
      CD C:\Program Files\Atlassian\Application Data\JIRA
    4. Run the HSQL Database Manager:
      ..\..\JIRA\jre\bin\java -cp ..\..\JIRA\lib\hsqldb-1.8.0.5.jar org.hsqldb.util.DatabaseManager -user sa -url jdbc:hsqldb:database/jiradb
    5. Run the following queries:
      1. insert into cwd_user (id, directory_id, user_name, lower_user_name, active, created_date, updated_date, first_name, lower_first_name, last_name, lower_last_name, display_name, lower_display_name, email_address, lower_email_address, credential) values (999999,1,'localadmin','localadmin',1,'2013-05-27 09:56:06.816000000','2013-05-27 09:56:06.816000000','local','local','admin','admin','local admin','local admin','localadmin@localadmin.com','localadmin@localadmin.com','uQieO/1CGMUIXXftw3ynrsaYLShI+GTcPS4LdUGWbIusFvHPfUzD7CZvms6yMMvA8I7FViHVEqr6Mj4pCLKAFQ==');
      2. insert into cwd_membership values (666666,10000,999999,'GROUP_USER','','jira-administrators','jira-administrators','localadmin','localadmin',1);
      3. insert into cwd_membership values (555555,10002,999999,'GROUP_USER','','jira-users','jira-users','localadmin','localadmin',1);
    6. Exit the HSQL Database Manager
    7. Start JIRA
    8. Login using user: localadmin and password: sphere
    9. Goto User Directories. 
    10. Locate your "normal" user, which you originally had admin-rights for. 
    11. Add the jira-administrators user to the user.
    12. Finally: I suggest changing the password for the localadmin user...

    At this stage you should again be able to login using your normal user, this time with jira-administrators permissions. Yeehaa!!! (big grin)

  6. I followed the instructions at the top and now I cannot log in at all. What am I missing?

     

    If there are no Internal JIRA Administrators

    If you're using Crowd or an external user management system, there may be no users with administrator permissions. 
    Find the groups in the external management system that you want to grant the administrator permissions and do the following:

    1. Shutdown JIRA.
    2. Use SQL to assign the appropriate group to the administrator permissions similar to this:

       

      update schemepermissions set perm_parameter='jira-system-administrators' where permission=44;
      update schemepermissions set perm_parameter='jira-administrators' where permission=0;
      update schemepermissions set perm_parameter='jira-users' where permission=1;
    3. (Oracle only): Execute a COMMIT so that the transactions are completed.
    4. Restart JIRA.

    1. Hi John,

      I'm not sure what's going wrong. Can you raise a ticket with our support team?

      Kind regards,
      Andrew

  7. I have JIRA configured with CROWD and my userid in CROWD is in the jira-administrators group.  I can log into JIRA and my user profile shows me belonging to the jira-administrator's group.  When I try to administer something and I get redirected to the "Administrator Access" screen, it rejects my password.  And YES I'M ENTERING THE SAME PASSWORD!!!!!

    This problem was precipitated when I changed the order of user directories and placed a JIRA local directory above the Crowd directory.  But my userid is NOT IN the local JIRA directory.

    I have other admins and MAYBE I'll be able to have them fix this.

    But I assume the fasted fix is to reorder the directories to what they were.  How do I do that?

    1. Hi there, can you please put in a ticket with Support so they can help you? Cheers, Christine

      1. Not necessary cuz I solved the problem...

        First: to change directory order whack the last field of the cwd_directory table so the directories are in the order you want.  Probably with the internal directory position == 0.

        Second, this is an interesting problem.  The ultimate cause was that years ago when I was a carefree and foolish admin, I had the same username in two directories with different passwords.  As is reported elsewhere, if you enable Crowd SSO then JIRA ignores all other directories.  As a result when I first authenticated with JIRA it used the first directory (an LDAP delegated auth directory).  But apparently when it does the admin challenge JIRA ignores SSO and so it was using the other directory (an internal one).  Since I didn't know the password anymore for that username in that directory I was stuck.

        Personally, I think the "ignore all other directories when SSO is configured" is a mistake.

  8. You may run into errors if trying to insert the localadmin user into the cwd_user table using the instructions above.  (I ran into an incorrect datatype error). 

    To get around this,  strip the '-08' from the timestamp fields.

    Modified SQL statement below;

     

    Corrected localadmin user insert statement
  9. In JIRA 6.3.12 you need to add 2 additional parameters for cwd_user.

    1. Have you any ideas what to pass to these fields? It looks like EXTERNAL_ID should be generated somewhere.

      1. Hi Alpesh and Andrey,

        The fields 'deleted_externally' and 'EXTERNAL_ID' are both relevant for users coming from the External User Directory (LDAP/AD etc). In case of internal directory users, you can leave both these fields as null. I have just updated the queries above to reflect this.