Comment migrer des utilisateurs entre répertoires Atlassian

Jusqu’a présent, votre instance Jira utilise son propre répertoire interne d’utilisateurs pour l’identification. Votre Confluence utilise également ce même repertoire pour gérer les droits de son côté.
Le choix du répertoire cible pour un compte donné se fait à la création de ce dernier. Il n’existe ensuite aucune procédure pour déplacer ce repertoire après cette action. Et pourtant, cela serait très utile dans de nombreux cas, comme par exemple :

• La mise en place d’un serveur Crowd pour la gestion des utilisateurs afin de profiter de son module de SSO
• La remise à plat de la politique de gestion des utilisateurs
• Le raccordement au LDAP entreprise. (Toutefois, il est déjà possible lors de la déclaration du LDAP, de choisir de fusionner nativement les comptes qui portent le même nom. Le périmètre est alors moins couvert qu’avec cette procédure)

Cette procédure de migration est compatible avec n’importe quel cas de migration d’un repertoire à un autre (Crowd et/ou Jira).

Etude de cas

Dans le cas étudié, nous utilisons Crowd depuis un moment avec deux répertoires : un interne et un LDAP délégué. Le répertoire LDAP est prioritaire sur l’interne. Crowd est utilisé par Jira et Confluence pour l’authentification des utilisateurs.

Pour certaines raisons techniques, certains utilisateurs n’étaient pas créés dans le repertoire LDAP délégué, mais dans le répertoire interne.
Par ailleurs, d’autres utilisateurs possédaient un compte dans les 2 repertoires.

L’objectif est alors de basculer l’ensemble des comptes sur le LDAP délégué. Pour cela, nous allons distinguer les différents cas d’utilisateurs rencontrés :

• Utilisateur ayant seulement un compte dans le répertoire Crowd interne. « CRÉER LE COMPTE DANS LE RÉPERTOIRE CIBLE » puis « FUSIONER LES COMPTES »
• Utilisateur ayant seulement un compte dans le répertoire LDAP délégué. « PAS D’ACTIONS À PRENDRE »
• Utilisateur ayant un compte avec un login différent dans le répertoire Crowd interne et dans le le répertoire LDAP délégué. « FUSIONER LES COMPTES »
• Utilisateur ayant un compte avec le même login dans le répertoire Crowd interne et dans le le répertoire LDAP délégué. « FUSIONER LES COMPTES »

L’opération doit conserver l’historique des actions faites via les comptes actuels.

La procédure

Prérequis

• Les utilisateurs dont le contenu est à migrer doivent déjà être créés dans répertoire LDAP de Crowd.
• Les comptes d’utilisateurs à migrer qui sont dans le répertoire interne Crowd doivent posséder un nom différent de ceux du répertoire LDAP (on pourra par exemple suffixer le nom par “_old”)
• Les affectations de groupes doivent être identiques entre les répertoires pour les utilisateurs migrés.
• Les répertoires doivent avoir été synchronisés au préalable (Dans Jira/Confluence, partie administration > Gestion des utilisateurs > Répertoires, forcez la synchronisation du répertoire Crowd)

Exécution

Nous allons aller en base et prendre toutes les contributions et abonnements de l’ancien utilisateur pour aller l’affecter au nouveau. Il s’agit donc d’un fusion entre deux comptes.

1- Migration

Pour cette dernière étape, nous allons effectuer des modifications en base de données sur les outils Jira et Confluence.

L’idée est d’aller changer en base les clés qui font le lien vers les anciens utilisateurs et de les rebrancher vers les nouveaux.
Il faut procéder à 24 requêtes SQL pour Jira et 15 pour Confluence, par utilisateur. L’utilisation du script donné plus bas n’est pas obligatoire, mais aidera vraiment si vous avez plusieurs utilisateurs à migrer durant cette opération.

L’utilisation du script est assez simple. Il faut l’appeler et passer en paramètre :

• l’ancien login
• le nouveau login (ce dernier doit être différent car, comme expliqué plus haut, on ne pourra distinguer la provenance du répertoire Crowd depuis Jira et Confluence)

2- Opérations post-migration

Après relance des outils, il faudra lancer une ré-indexation de Jira et Confluence. Cela peut être plus ou moins long selon les instances.

L’accès aux utilisateurs qui viennent d’être migrés est instantané. En revanche, l’affectation des contributions et abonnements dépendra de la ré-indexation. Cela s’effectuera donc progressivement.

Scripts de références

Migrate.bat

Rôle et déroulement

Le but de ce script est d’aller collecter dans Jira et Confluence les contributions de l’utilisateur actuel. Le script va générer automatiquement un fichier SQL pour aller faire la mise à jour de l’ancien vers le nouvel utilisateur.

Ce dernier se charge pour chaque utilisateur d’aller chercher en base les identifiants utilisateurs pour les deux comptes, afin de limiter la fourniture des arguments. En cas de mauvaise saisie ou si l’utilisateur n’est pas trouvé, le script se met en erreur. Aucune modification en base ne sera faite dans ce cas là.

Le résultat de la sauvegarde ainsi que les modifications effectuées sont conservés pour chaque utilisateur migré, dans un dossier à son nom.

On fournit simplement le login de l’ancien utilisateur et le nouveau comme paramètres d’entrée,

Vous devez remplacer USER/PASSWORD par les identifiants de votre user pour la base de données.

La vérification

• Si ce n’est pas déjà fait, en cas d’utilisation du CAPCHA, vous devez désactiver la fonction en attendant que les utilisateurs impactés se connectent une première fois après la migration.
• Vérifiez que les utilisateurs migrés peuvent bien se connecter : via le panel d’administration de Jira > Gestion des utilisateurs, faîtes une recherche sur les utilisateurs correspondants et vérifiez la date de dernière connexion.
• Depuis Jira et Confluence, allez sur les profils d’utilisateurs d’origine et cible, et constatez que le flux d’activité a bien été transféré.

Pour aller plus loin

Maintenant que vous savez tout sur la migration des utilisateurs entre répertoires Atlassian, votre gestion des utilisateurs devrait s’en trouver simplifiée. Pour bénéficier de nombreux autres conseils avisés de nos consultants sur Jira, Confluence, Jira Service Desk ou encore des apps de la Marketplace Atlassian, inscrivez-vous à notre newsletter.