Development #6379
sync-ldap-users do not remove deleted accounts
0%
Description
If the external_id cannot be resolved in the LDAP, accounts should be removed. It should be customizable with an option like 'sync_delete': True
,
The method LDAPBackend.external_id_to_filter
can be used for this.
Files
Related issues
History
Updated by Paul Marillonnet about 2 years ago
- File 0001-WIP-ldap_backend-deactivate-accounts-if-ldap-entry-m.patch 0001-WIP-ldap_backend-deactivate-accounts-if-ldap-entry-m.patch added
- Status changed from Nouveau to Information nécessaire
- Patch proposed changed from No to Yes
Up car discuté ce matin sur le salon.
Pas eu le temps de réfléchir au côté CLI (une nouvelle option pour la commande de synchronisation ? une nouvelle commande à part ?)
Mais, dans l'idée, si on se contentait de désactiver les LDAPUsers dont le nom d'utilisateur n'a pas pu être retrouvé dans le LDAP, on est bon ?
Updated by Frédéric Péters about 2 years ago
Mais, dans l'idée, si on se contentait de désactiver les LDAPUsers dont le nom d'utilisateur n'a pas pu être retrouvé dans le LDAP, on est bon ?
Les utilisateurs désactivés apparaissent dans le tableau des usagers.
Updated by Paul Marillonnet about 2 years ago
- File 0001-WIP-ldap_backend-deactivate-accounts-if-ldap-entry-m.patch 0001-WIP-ldap_backend-deactivate-accounts-if-ldap-entry-m.patch added
Et donc on les supprime, c'est ça (voir le nouveau patch WIP) ?
Est-ce que le comportement le plus souhaitable n'est pas de changer l'affichage des usagers désactivés dans le tableau des usagers ?
Updated by Benjamin Dauvergne about 2 years ago
Les utilisateurs supprimés vont disparaître des historiques w.c.s sans #24430, j'aimerai vraiment que tous les aspects cycle de vie des comptes soit reliés et discutés sur #26907 qu'on garde toujours un objectif global et qu'on ne traite chaque petit bout sans voir les conséquences.
Ensuite si c'est un problème temporaires (genre l'annuaire a été branché sur une copie vide, les ACLS sont foirées et ldapsearch ne renvoie plus rien) pim pam poum on vide tout, on perd toutes les affectations de rôle, je serai plutôt pour désactiver le compte, et dès qu'on a un compte disparu du LDAP, déjà désactivé et modifié il y a plus de 3 mois, on supprime.
Updated by Paul Marillonnet about 2 years ago
- Related to Development #26907: Cycle de vie des comptes added
Updated by Paul Marillonnet about 2 years ago
- File 0001-WIP-ldap_backend-process-orphan-accounts-6379.patch 0001-WIP-ldap_backend-process-orphan-accounts-6379.patch added
Ok d'ac. Est-ce que dans l'idée le code convient ?
(Si oui, j'écris les tests et soumet un patch pour relecture.)
Updated by Paul Marillonnet about 2 years ago
Paul Marillonnet a écrit :
(Si oui, j'écris les tests et soumet un patch pour relecture.)
(Et l'ajout de logs sur la désactivation et la suppression).
Updated by Benjamin Dauvergne about 2 years ago
_deactivated_on ne va pas persister d'un run sur l'autre, c'est pour cela que j'ai proposé de se servir du champ modified qui existe déjà.
Updated by Benjamin Dauvergne about 2 years ago
Mais dans l'idée c'est pas ça du tout, il faut accumuler une liste des external_id_tuples
(faut les reconstruire à la volée), extraire celle en base, extraire la première à la deuxième, et les comptes qui reste sont ceux qui sont orphelins; c'est vraiment pas un ticket évident en fait...
Updated by Paul Marillonnet about 2 years ago
Ah bein oui zut, j'avais pas pensé à la persistance d'une exécution à l'autre.
Un ticket faussement facile donc (et je ne me l'assigne pas, pour l'instant au moins).
Updated by Frédéric Péters 10 months ago
- Status changed from Information nécessaire to Nouveau
- Patch proposed changed from Yes to No
Ça serait bien utile, notamment parce qu'on se trouve à continuer à envoyer des mails à des agents dont le compte n'existe plus, et ça peut participer à la mauvaise réputation.
Updated by Benjamin Dauvergne 10 months ago
- Related to Development #42388: Ne pas envoyer de mail aux comptes désactivés added
Updated by Benjamin Dauvergne 10 months ago
Updated by Frédéric Péters about 1 month ago
- Related to Development #50751: Ajout d'une fonctionnalité de suppression automatique des comptes LDAP après disparition dans l'annuaire added
Updated by Benjamin Dauvergne about 1 month ago
- rechercher les comptes par source/exteral_id_tuple
- pour un compte qui n'existe plus, le marquer désactivé ainsi que la date de la désactivation (donc il faudrait un ticket pour introduire cette date)
- si un compte est désactivé depuis plus de n jours on supprime
- vérifier au passage que les comptes LDAP sont bien exclus du système de nettoyage, ce n'est pas fait pour l'instant parce qu'on suppose qu'à un annuaire LDAP correspondant une OU particulière où ce nettoyage ne doit pas être actif
Updated by Serghei Mihai 24 days ago
- Related to Bug #50966: ajouter la date de desactivation du compte dans les attributs de User added
Updated by Loïc Dachary 8 days ago
Bonjour,
Je souhaite participer à cet effort et je suis tenté de travailler sur un point proposé dans idée en l'état. Par exemple "rechercher les comptes par source/exteral_id_tuple pour un compte qui n'existe plus, le marquer désactivé ainsi que la date de la désactivation". Est-ce que ça vous semble pertinent ou bien est-ce que quelqu'un est déjà en train de le faire ?
En attendant votre réponse j'étudie le code, ce sera toujours ça de pris :-)
A++
Updated by Loïc Dachary 7 days ago
@Serghei je vois que tu es lancé dessus donc je vais observer et apprendre. Une question (peut-être naïve): quand tu fais:
+ for eid in UserExternalId.objects.filter(user__is_active=True,
+ source=block['realm']):
+ inactive = True
+ for external_id_tuple in map_text(block['external_id_tuples']):
+ ldap_filter = cls.external_id_to_filter(eid.external_id, external_id_tuple)
+ results = conn.search_s(block['basedn'],
+ ldap.SCOPE_SUBTREE, ldap_filter)
Ca fait une recherche LDAP par utilisateur ce qui peut stresser le serveur LDAP. Une autre option serait d'utiliser paged_search pour les prendre 100 par 100 et faire une liste en mémoire. Ce qui peut poser problème de RAM s'il y en a vraiment beaucoup...
Qu'en dis-tu ?
Updated by Benjamin Dauvergne 7 days ago
- Assignee set to Serghei Mihai
- Status changed from Nouveau to Information nécessaire
Updated by Loïc Dachary 1 day ago
@Serghei si tu souhaite que j'avance sur une partie ou une autre, n'hésite pas à me solliciter, je suis disponible pour cela :-)