Projet

Général

Profil

Actions

Feature #8335

fermé

Améliorer la gestion des changements de login dans la synchro avec l'AD

Ajouté par David Lesimple il y a environ 8 ans. Mis à jour il y a presque 6 ans.

Statut:
Closed
Priorité:
Normal
Assigné à:
Catégorie:
Administration
Début:
28/10/2016
Echéance:
% réalisé:

100%

Temps estimé:
Livraison en TEST:
Livraison en PROD:

Description

Lors des synchronisations avec un annuaire LDAP, il arrive qu'une demande de création d'utilisateur échoue si le login de l'utilisateur existe déja (mais sur un autre specificId).
Cela se produit lorsque le login de l'utilisateur déja présent dans SP à été changé dans l'AD et affecté à un autre utilisateur non encore dans SP.

Lors de la synchro, il y a conflit.


Fichiers

removedUsers_00.png (6,64 ko) removedUsers_00.png Yohann Chastagnier, 21/12/2018 15:38
removedUsers_01.png (19,2 ko) removedUsers_01.png Yohann Chastagnier, 21/12/2018 15:38
removedUsers_02.png (26,6 ko) removedUsers_02.png Yohann Chastagnier, 21/12/2018 15:38
removedUsers_03.png (21,5 ko) removedUsers_03.png Yohann Chastagnier, 21/12/2018 15:38
removedUsers_04.png (30,3 ko) removedUsers_04.png Yohann Chastagnier, 21/12/2018 15:38

Mis à jour par Nicolas Eysseric il y a plus de 7 ans

  • Version cible changé de Version 6 à Version 6.1

Mis à jour par David Lesimple il y a plus de 7 ans

Ce point est très pénalisant, car lorsque de nombreux comptes sont bloqués, il faut :
- supprimer chaque compte
- le réimporter unitairement

Est-ce que le problème ne viendrait pas l'ordre dans lequel sont effectuées les actions de synchronisations ?
- add, update, delete
alors qu'il serait plus logique de faire :
- delete, add, update

Mis à jour par Yohann Chastagnier il y a environ 6 ans

  • Statut changé de New à In progress...

Mis à jour par Yohann Chastagnier il y a environ 6 ans

  • Assigné à mis à Yohann Chastagnier

Mis à jour par Yohann Chastagnier il y a presque 6 ans

Des modifications importantes dans la gestion des comptes utilisateur et de la synchronisation de ces derniers avec les gestionnaires d'identité distants (LDAP, Google, etc.) ont été réalisées à l'occasion de ce REDMINE.
Ces changements sont détaillés dans les points suivants.

Nouvel état d'un compte utilisateur : REMOVED

Ce nouvel état à été ajouté notamment pour répondre aux problèmes suivantes :
  • erreurs de manipulation des unités organisationnelles dans un LDAP qui peut engendrer lors d'une synchronisation, si non corrigées, la suppression massive des comptes utilisateurs
  • les comptes supprimés dans les gestionnaires d'identités externes qui peuvent être restaurés, #9546 (Ajout domaine SCIM) et #10284 (Ajout domaine Google)
  • erreur de suppression d'un compte utilisateur dans Silverpeas

Lorsque l'état REMOVED est positionné sur un compte utilisateur, il est considéré comme en attente de suppression définitive et n'est donc pas encore supprimé, mais presque.
Il n'est plus possible à l'utilisateur de se connecter avec son compte, et dans l'administration, il n'apparaît plus dans la gestion des groupes ou des droits, ni même dans la liste des utilisateurs d'un domaine.
Il apparaît cependant dans un nouvel écran Utilisateurs en attente de suppression définitive détaillé plus loin dans cette note.

Un compte à l'état REMOVED peut être restauré, et dans un tel cas, il redevient lié aux groupes et possède à nouveau les mêmes droits qu'au moment de sa suppression temporaire (à l'exception des groupes et des droits qui ont été supprimés ou ajoutés entretemps).
Evidemment, il peut aussi être supprimé définitivement manuellement ou automatiquement.

Petit récapitulatifs des différents états possibles pour un compte utilisateur :
  • VALID : le compte est valide
  • BLOCKED : le compte est bloqué (cf. #4149)
  • EXPIRED : le compte est expiré (se comporte comme l'état bloqué pour le moment)
  • DEACTIVATED : le compte est désactivé (cf. #6170)
  • REMOVED : le compte est en attente de suppression définitive
  • DELETED : le compte est supprimé

Gestion des comptes utilisateurs

Supprimer un utilisateur

La suppression d'un utilisateur demande maintenant à l'utilisateur si la suppression est définitive ou pas :

Si la case définitivement ? n'est pas cochée lors de la confirmation, le compte utilisateur est alors mis en attente de suppression définitive (cas par défaut).
Autrement, le compte est supprimé définitivement, comme cela était le cas avant cette évolution.

Suppression automatique des comptes en attente de suppression

Si activée, les utilisateurs dont la date de mise en attente de suppression définitive est dépassée d'un nombre de jours définis sont définitivement supprimés.
Le moment de l'exécution du traitement et le délai avant suppression définitive sont paramétrables depuis le fichier de propriétés $SILVERPEAS_HOME/properties/org/silverpeas/admin/admin.properties :
  • DeleteRemovedUsersDelay : délai en nombre de jour après lequel un compte est supprimé définitivement, par défaut défini à 30 jours.
    Si défini à zéro, le traitement est désactivé, quelle que soit la valeur du paramètre DeleteRemovedUsersCron
  • DeleteRemovedUsersCron : permet de définir un CRON pour déterminer le moment de l'exécution du traitement, par défaut défini pour être invoqué tous les jours à 22h45.
    Si vide, le traitement est désactivé, quelle que soit la valeur du paramètre DeleteRemovedUsersDelay

Gestion manuelle des comptes en attente de suppression définitive

Un nouvel écran Utilisateurs en attente de suppression définitive est accessible depuis la liste des utilisateurs d'un domaine via le menu Que voulez-vous faire ?
Ce dernier liste tous les utilisateurs en attente de suppression définitive :

Si le traitement de suppression automatique est activé (le cas par défaut), il y a une colonne supplémentaire qui indique la date (et le délai) après laquelle la suppression définitive sera effectuée automatiquement :

A partir de cet écran, via le menu Que voulez-vous faire ?, il est possible de restaurer ou supprimer les comptes utilisateurs sélectionnés.
Si la liste comporte plusieurs page, les comptes sélectionnés ne sont pas gardés lors d'un changement de page.

Synchronisation des comptes utilisateurs

La synchronisation des comptes utilisateurs a été revue afin de prendre en charge le nouvel état REMOVED d'un compte utilisateur et aussi pour répondre à la problématique initiale de ce REDMINE.

Enchaînement des opérations

L'enchaînement des opérations est le suivant :
  • Détection des comptes utilisateurs supprimés dans le gestionnaire distant des comptes, pour chacun de ces comptes, le correspondant dans Silverpeas est passé à l'état REMOVED s'il ne l'est pas encore
  • Pour chacun des autres comptes dans le gestionnaire distant :
    • s'il n'existe pas de compte Silverpeas correspondant :
      • s'il existe un compte dans Silverpeas à l'état REMOVED avec le même login que le compte distant, c'est le cas de la problématique initiale de ce REDMINE. C'est à dire qu'un compte a été supprimé et un autre créé dans le gestionnaire distant où le nouveau utilise le même login que celui supprimé. Dans cette situation, du fait de son caractère délibéré, le compte à l'état REMOVED dans Silverpeas est supprimé définitivement
      • un nouveau compte est créé dans Silverpeas
    • s'il existe un compte Silverpeas correspondant :
      • dans le cas où le compte Silverpeas est à l'état REMOVED, donc en attente de suppression définitive, ce dernier est restauré et les informations du compte sont mises à jour si necessaire
      • dans le cas où le compte Silverpeas n'est pas en attente de suppression et si les données du compte diffèrent entre Silverpeas et le gestionnaire distant, le compte est mis à jour avec les nouvelles données

Aministrateurs avertis en cas de synchronisation en échec

Lorsqu'une synchronisation automatique (par batch donc) se termine en erreur pour un domaine, c'est à dire qu'aucune synchronisation n'a pu aboutir pour un domaine, les administrateurs de la plate-forme et ceux du domaine, en sont notifiés.

Optimisation de la durée du traitement de synchronisation

Afin de pénaliser le moins possible l'administrateur lors d'une synchronisation manuelle, ou le traitement automatique de nuit, des optimisations ont été apportées de manière à ce que le temps de traitement soit sensiblement écourté.

Gestion des indexes

Les indexes des utilisateurs sont maintenant créés, modifiés ou supprimés après le traitement de synchronisation, dans une tâche exécutée en arrière plan.
Durant les développements, notamment avec un domaine Google, un traitement de synchronisation qui durait 20 minutes (2000 utilisateurs) avant ce changement est passé à 30 secondes ensuite.

Suppression de la gestion de l'indice de dernière synchronisation d'un domaine LDAP

Cet indice était utilisé pour détecter les comptes utilisateurs mis à jour dans un LDAP après la date de la dernière synchronisation.
Comme la mise à jour d'un compte dans Silverpeas est maintenant réalisée uniquement si ses données distantes sont différentes de celles dans Silverpeas, cet indice n'avait plus vraiment d'intérêt. D'autant plus que tous les comptes distants étaient de toute manière recherchés dans l'étape de détection des comptes distants supprimés.

De fait, la gestion de l'indice de dernière synchronisation a été supprimée.
L'indice n'est plus présenté à la création ou à la modification d'un domaine LDAP.


PR : https://github.com/Silverpeas/Silverpeas-Core/pull/948 (commit https://github.com/Silverpeas/Silverpeas-Core/pull/948/commits/7bce46d37c61dc3e8ad0e940170cfa10177b019a)

Mis à jour par Nicolas Eysseric il y a presque 6 ans

  • Statut changé de Resolved à Integration in progress...

Mis à jour par Nicolas Eysseric il y a presque 6 ans

  • Statut changé de Integration in progress... à Closed

Validé et intégré...

Lors d'une erreur durant la synchronisation périodique, l'envoi de la notification aux administrateurs ne fonctionnait pas à cause d'une exception sur l'émetteur (non renseigné). Correctif : https://github.com/Silverpeas/Silverpeas-Core/commit/f4a45fb79dff84c521bee788f074664c755b944d

Actions

Formats disponibles : Atom PDF