Fisheye users get disabled after username change in LDAP

Still need help?

The Atlassian Community is here for you.

Ask the community

Platform Notice: Server and Data Center Only - This article only applies to Atlassian products on the server and data center platforms.

This workaround was tested by Atlassian on Fisheye versions 3.7.0, 3.8.0, and 3.8.1 only. We cannot provide support if the scripts are executed on other versions.

This page does not apply to Fisheye 4.0+.

Problem

Fisheye users get disabled after their username changes within LDAP, once one of the involved users logs in with the new username, Fisheye/Crucible creates a new account for it and the old one appears as deleted.

Diagnosis

Environment:

  • Fisheye/ Crucible uses JIRA for user authentication and LDAP to synchronise users.
  • Automatic synchronisation is active in Fisheye/Crucible

Diagnostic Steps:

Change the username in LDAP for one or more users (eg. username from uppercase to lowercase).

Cause

Auto-add users into Fisheye is set to 'true' so, when the user connects for the first time with the new LDAP username Fisheye creates a new user for him. 

Workaround

The script provided modifies the Fisheye database content and is not intended as a best practice but only as a last resort. Please be aware that repeated use may prevent the correct behaviour of your instance.

One possible workaround is that you fix the situation directly in the Database following this procedure:

Always back up your data before performing any modifications to the database. If possible, test any alter, insert, update, or delete SQL commands on a staging server first.

    1. Stop Fisheye/Crucible instance
    2. Locate the ID of both the old user and new user in the database:

      select
      new_user.cru_user_id,
      old_user.cru_user_id
      from cru_user old_user
      cross join cru_user new_user
      where old_user.cru_user_name = 'OLD_USER_NAME - to be modified'
      and new_user.cru_user_name = 'NEW_USER_NAME - to be removed'
    3. Follow the procedure corresponding to the database you are using

      MySQL procedure

      The script provided is to be considered as a guideline and must be adapted to your environment by changing user IDs and database name accordingly.

      1. Download the script mysql_merge_users.sql.
      2. Open the file with your preferred editor
      3. Replace the values in the script on the following lines:

        USE crucible;
        SET @old_user_id = XXXX;
        SET @new_user_id = XXXX;
      4. Execute the script.
      PostgreSQL procedure

      The script provided is to be considered as a guideline and must be adapted to your environment by changing user IDs and database name accordingly.

      1. Download the script psql_merge_users.sql.
      2. Open the file with your preferred editor
      3. Replace the values in the script on the following lines:

        \set old_user_id OLD_USER_ID
        \set new_user_id NEW_USER_ID
      4. Execute the script.
      Oracle procedure

      The script provided is to be considered as a guideline and must be adapted to your environment by changing user IDs accordingly and must be executed against the correct schema.

      1.  Download the script oracle_merge_users.sql.
      2. Open the file with your preferred editor
      3. Replace all the instances of old_user_id with the old user ID you get previously.

      4. Replace all the instances of new_user_id with the new user ID you get previously.

      5. Execute the script.
    4. Start Fisheye/Crucible instance
    5. Reindex Crucible 

      Administration > Crucible > Re-index

Resolution

To prevent the problem the best practice is to follow some basic guidelines when it comes to renaming users in LDAP.

Renaming users when FishEye/Crucible is using external authentication

Last modified on Jul 31, 2018

Was this helpful?

Yes
No
Provide feedback about this article
Powered by Confluence and Scroll Viewport.