Feature #8335
ferméAméliorer la gestion des changements de login dans la synchro avec l'AD
100%
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
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
- Fichier removedUsers_00.png removedUsers_00.png ajouté
- Fichier removedUsers_01.png removedUsers_01.png ajouté
- Fichier removedUsers_02.png removedUsers_02.png ajouté
- Fichier removedUsers_03.png removedUsers_03.png ajouté
- Fichier removedUsers_04.png removedUsers_04.png ajouté
- Statut changé de In progress... à Resolved
- % réalisé changé de 0 à 100
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.
VALID
: le compte est valideBLOCKED
: 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éfinitiveDELETED
: 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ètreDeleteRemovedUsersCron
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ètreDeleteRemovedUsersDelay
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
- s'il n'existe pas de compte Silverpeas correspondant :
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