Nous avons présenté le logiciel Service Desk lors de la sortie de la version 0.6 en décembre 2024 dans notre article Active Directory, Audit, Hooks, … Les nouveautés de la version 0.6 de Service Desk.

Le logiciel est conçu pour simplifier l’administration des comptes d’un annuaire LDAP, que ce soit OpenLDAP ou Active Directory.

Initialement limité à la gestion des mots de passe (vérification, réinitialisation, blocage), puis ensuite élargi au statut du compte (expiration, activation, dates de validité), Service Desk permet désormais la gestion complète du cycle de vie des comptes de l’annuaire (création, mise à jour, suppression).

Avec la version 0.7, sortie en septembre 2025, vient également une réécriture complète du chargement des entrées, en particulier le support de la pagination des tableaux. Ce travail notable a permis d’améliorer significativement les performances de l’application.

L’histoire de la vie des comptes, le cycle éternel

Quand on manipule des données, on a besoin de ces opérations de base : rechercher la donnée, la modifier, en créer une nouvelle ou en supprimer.

C’est ce qu’on retrouve derrière l’acronyme CRUD :

  • Create
  • Read
  • Update
  • Delete

Avant la version 0.7 de Service Desk, on pouvait seulement rechercher des entrées (et les lire) et en modifier les attributs liés au statut du compte ou au mot de passe. Bien loin du CRUD donc.

Les utilisateurs de la solution nous ont sollicité afin de faire évoluer le logiciel et de lui permettre de gérer le cycle de vie complet des comptes.

Création des comptes

Créer un compte dans un annuaire nécessite de connaître plusieurs informations. En plus des données de l’entrée (nom, prénom, mail…) il faut :

  • La branche dans laquelle l’entrée va être créée
  • L’attribut (ou les attributs) qui permettront de définir le DN
  • La liste des classes d’objet

Tous ces éléments sont, bien entendu, configurables.

Activation de la fonction de création de compte :

$use_create = true;

Liste des champs disponibles à la création (attention, il s’agit du nom des champs et pas des attributs LDAP) :

$create_items = array('identifier', 'firstname', 'lastname', 'mail');

Liste des classes d’objet :

$create_objectclass = array('top', 'person', 'organizationalPerson', 'inetOrgPerson');

Liste des champs utilisés pour créer le DN :

$create_dn_items = array('identifier');

Branche dans laquelle les entrées sont créées :

$create_base = "ou=users,dc=example,dc=com";

Et enfin, un système de macros a été fourni afin de pouvoir ajouter à la volée d’autres attributs, avec des valeurs statiques ou des valeurs liées à celles saisies dans le formulaire. Par exemple, pour créer le nom complet (attribut LDAP cn, lié au champ fullname), on pourra utiliser cette configuration. pour concaténer le prénom et le nom :

$create_items_macros = array('fullname' => '%firstname% %lastname%');

Suppression

Cette opération est beaucoup plus simple, aucun paramètre n’est nécessaire au-delà de l’activation ou non de cette fonction :

$use_delete = true;

Une invite de confirmation est affichée dans l’interface pour éviter toute mauvaise manipulation. Une entrée supprimée dans un annuaire ne peut, en effet, pas être récupérée.

Modification

Contrairement au processus de création qui affiche un formulaire vide, lors de la modification d’une entrée, on affichera :

  • La liste des champs autorisés en écriture
  • Les autres champs disponibles en lecture, s’ils ont une valeur dans l’annuaire

Il est possible d’indiquer si le champ peut être multi-valué ou non, en ajoutant la propriété multivalued dans sa définition au sein de $attributes_map :

$attributes_map = array(
    ...
    'mail' => array( 'attribute' => 'mail', 'faclass' => 'envelope-o', 'type' => 'mailto', 'multivalued' => true ),
    ...
);

Les autres paramètres de configuration sont semblables à ceux pour la création :

$use_update = true;
$update_items = array('firstname', 'lastname', 'title', 'businesscategory', 'employeenumber', 'employeetype', 'mail', 'mailquota', 'phone', 'mobile', 'fax', 'postaladdress', 'street', 'postalcode', 'l', 'state', 'organizationalunit', 'organization', 'manager', 'secretary');
$update_items_macros = array('fullname' => '%firstname% %lastname%');

Renommage

C’est une opération particulière en LDAP, car il est interdit de modifier directement un attribut qui est utilisé dans le DN (et plus précisément dans le RDN).

Une fonction dédiée est donc présente, activée par :

$use_rename = true;

Indiquer quels sont les attributs concernés (les mêmes que pour la création) :

$rename_items = array('identifier');

Les types d’attributs

La façon dont les attributs sont affichés et modifiés dépend de leur paramétrage dans $attributes_map. Pour chaque champ, on définit les propriétés suivantes :

  • attribute : Nom de l’attribut LDAP, en minuscules
  • faclass : Classe CSS Font Awesome pour l’icône
  • type : Type d’attribut (texte, liste, etc.)
  • dtorder : Mettre à disabled pour que la colonne soit non triable dans les tableaux de résultats
  • multivalued : Booléen pour permettre d’avoir plusieurs valeurs pour le même attribut
  • sort : tri croissant ou décroissant à afficher par défaut pour les attributs multi-valués

Il existe de nombreux types d’attribut, documentés sur la page suivante : https://service-desk.readthedocs.io/en/stable/attributes.html.

Certains nécessitent des paramètres complémentaires, comme l’utilisation de listes de valeurs ou la recherche d’un DN dans l’annuaire.

Listes de valeurs

L’objectif est de pouvoir se baser sur une nomenclature et éviter de laisser un champ texte libre. Ces listes fonctionnent sur un système de clé/valeur : la clé est ce qui est réellement stocké dans l’attribut LDAP, la valeur est ce qui est affiché dans l’interface.

Il y a deux possibilités pour définir les valeurs autorisées :

  • Une liste statique dans la configuration
  • Une liste dynamique liée à une recherche dans l’annuaire

Dans le premier cas, on utilisera le type static_list et pour le champ en question il faudra configurer la liste de valeurs :

$attributes_static_list['title'] = array(
    'Mme' => 'Madame',
    'Mr' => 'Monsieur'
);

Dans le second cas, ce sera un type list et il faudra définir tous les paramètres de la recherche LDAP :

$attributes_list['organizationalunit'] = array(
    'base'=>'ou=services,dc=example,dc=com',
    'filter'=>'(objectClass=organizationalUnit)',
    'key'=>'ou',
    'value'=>'description'
);

Cette recherche va, par exemple, remonter toutes les entrées de la branche “services” de type “organizationalUnit” et créer une liste dont les clés seront les valeurs de l’attribut “ou” et les valeurs de l’attribut “description”. Si on ne définit pas value alors l’attribut indiqué dans key servira de clé et de valeur.

Lien DN

Il s’agit ici du type dn_link qui permet de transformer un DN en un lien menant à la fiche de l’entrée en question. Il est, par exemple, utilisé pour l’attribut manager (responsable hiérarchique).

Avec l’apparition de la fonctionnalité de modification des valeurs, ce type d’attribut se transforme en mode édition en un champ de recherche dynamique.

Le comportement de ce composant est paramétrable :

  • Attribut LDAP contenant la valeur à afficher au lieu du DN :
    $dn_link_label_attributes = array("cn");
    
  • Le nombre minimum de caractères à taper pour déclencher la recherche :
    $dn_link_search_min_chars = 3;
    
  • Le nombre maximum de résultats à renvoyer dans les suggestions :
    $dn_link_search_size_limit = 10;
    
  • La possibilité d’afficher une valeur composite au lieu du label simple, ce qui est utile pour les annuaires volumineux possédant de nombreux homonymes :
    $dn_link_search_display_macro = "%fullname% (%mail%)";
    

Amélioration des performances

Avant cette nouvelle version, lors d’une recherche, tous les résultats étaient renvoyés dans le navigateur et passés à la bibliothèque javascript DataTables, ce qui pouvait entraîner un traitement assez long dans le navigateur dès qu’il y avait beaucoup d’entrées.

Pour pallier ce problème, il était possible de limiter le nombre de résultats renvoyés par l’annuaire LDAP ($ldap_size_limit), cependant cela faussait les tableaux de bord, puisque, dans ce cas, toutes les entrées de l’annuaire n’étaient pas analysées.

Depuis la version 0.7, toute cette partie du code a été réécrite. Une API est désormais utilisée pour retourner les données au navigateur, qui sont ensuite mises en forme par du code javascript. Cette API se conforme à la pagination des tableaux de résultats, et ne sont donc renvoyées au navigateur que les entrées à afficher au lieu de l’ensemble des entrées.

Un logiciel libre plébiscité et soutenu par nos clients

Le travail sur la version 0.7 a démarré début 2025, encouragé par certains de nos clients qui souhaitaient voir s’étendre le périmètre fonctionnel de cet outil.

Nous remercions en particulier la Ville d’Échirolles, le SITIV et le Ministère de l’Agriculture qui ont permis de financer une partie du temps passé sur le développement de cette nouvelle version.

Rendez-vous lors de notre deuxième édition du Worteks Identity Club pour découvrir les dernières nouveautés des différents logiciels IAM auxquels nous contribuons !