You are not logged in.
Pages: 1
Bonjour,
J'ai le paramètre suivant activé:
Action lorsqu'un utilisateur est supprimé de l'annuaire LDAP: Mettre à la poubelle
Sauf que dans les faits, mon utilisateur GLPI est mis à la poubelle lorsqu'il est désactivé de l'annuaire LDAP.
Je suppose que cela est du au filtre de connection par défaut (userAccountControl:1.2.840.113556.1.4.803:=2) qui ne renverra pas les utilisateurs AD désactivé à GLPI et donc GLPI supprimera l'utilisateur.
Et si l'utilisateur est ré-activé dans LDAP, il n'est pas possible de le restaurer automatiquement dans GLPI: l'import automatique n'affichera pas de nouveau cet utilisateur, la synchronisation de tous les utilisateurs ne l’inclura pas, et il n'est pas possible de synchroniser les utilisateurs supprimés.
Je vois donc deux solutions:
1) Changer le filtre par défaut (mais si par défaut on ne requête pas les utilisateurs désactivés, il doit surement y avoir une raison ?)
2) Ajouter la possibilité de synchroniser les utilisateurs supprimés (via l'interface web, et via ldap_mass_sync.php).
Avis des développeurs ?
Prod: Windows 2008 R2 - Apache 2.4.26 (Win64) - OpenSSL 1.1.0f - PHP 7.1.6 - MySQL 5.7.23 - GLPI 9.3.1 (600+ users authenticated with AD in 20+ entities)
Offline
Un utilisateur supprimé de GLPI est en réalité mis dans la corbeille de l'entité racine.
La synchronisation va lui remettre ses droits. Il suffit donc de restaurer cet utilisateur
CentOS 6.5 - CentOS 7.x
PHP 5.6 - PHP 7.x - MySQL 5.6 - MariaDB 10.2 + APC + oOPcache
GLPI from 0.72 to dev version
Certifiée ITIL (ITV2F, ITILF, ITILOSA)
Offline
Bonjour Yllen,
Ce que vous dites est tout à fait exact, mais ne résout pas le problème qui est de pouvoir restaurer automatiquement cet utilisateur à partir du moment où il a été ré-activé dans LDAP.
Prod: Windows 2008 R2 - Apache 2.4.26 (Win64) - OpenSSL 1.1.0f - PHP 7.1.6 - MySQL 5.7.23 - GLPI 9.3.1 (600+ users authenticated with AD in 20+ entities)
Offline
Il n'y a pas de restauration automatique pour un utilisateur mis à la corbeille.
CentOS 6.5 - CentOS 7.x
PHP 5.6 - PHP 7.x - MySQL 5.6 - MariaDB 10.2 + APC + oOPcache
GLPI from 0.72 to dev version
Certifiée ITIL (ITV2F, ITILF, ITILOSA)
Offline
Et oui, nous sommes d'accord, c'est bien le problème...
Prod: Windows 2008 R2 - Apache 2.4.26 (Win64) - OpenSSL 1.1.0f - PHP 7.1.6 - MySQL 5.7.23 - GLPI 9.3.1 (600+ users authenticated with AD in 20+ entities)
Offline
C'est le comportement voulu par le paramètre que vous avez choisi.
Dans votre cas, il faudrait plutot choisir de supprimer les habilitations dans GLPI plutot que de mettre à la corbeille. De cette manière votre utilisateur réapparaitra lorsque les habilitations lui seront réattribuées lors de la synchro.
Je précise qu'un utilisateur sans droit ne peut pas se connecté dans GLPI et n'est visible que depuis la liste des utilisateurs, dont uniquement du super-admin (à charge pour lui de purger périodiquement les utilisateurs qui n'ont pas eu de synchro depuis plusieurs années)
CentOS 6.5 - CentOS 7.x
PHP 5.6 - PHP 7.x - MySQL 5.6 - MariaDB 10.2 + APC + oOPcache
GLPI from 0.72 to dev version
Certifiée ITIL (ITV2F, ITILF, ITILOSA)
Offline
Bonjour Yllen,
D'abord, merci de votre réponse !
C'est le comportement voulu par le paramètre que vous avez choisi
Permettez-moi de ne pas être d'accord... Comme souligné dans mon premier post, et sans vouloir jouer sur les mots, le paramètre s'appelle "Action lorsqu'un utilisateur est supprimé de l'annuaire LDAP "et non pas "désactivé de l'annuaire LDAP".
supprimer les habilitations dans GLPI plutot que de mettre à la corbeille
Je vais tester cette option qui posera sans doute moins de problème qu'actuellement, mais ce n'est pas non plus l'idéal (nettoyage manuel à faire + ne supprime que les droits dynamiques donc il y a toujours un risque).
Autres références sur ce sujet:
Forum GLPI anglais qui propose un workaround directement sur la base SQL
Prod: Windows 2008 R2 - Apache 2.4.26 (Win64) - OpenSSL 1.1.0f - PHP 7.1.6 - MySQL 5.7.23 - GLPI 9.3.1 (600+ users authenticated with AD in 20+ entities)
Offline
Pages: 1