FusionDirectory considère le rôle d’un serveur LDAP c’est d’être un stockage organisé.
FusionDirectory peut être utilisé avec tout type de serveur LDAP à condition qu’il sait communiquer à LDAP V3 comme :

ApacheDirectory from the apache Foundation
eDirectory from Novell
389-Directory From Fedora project
Sun Directory from Sun Microsystem

La protection du contenu de l’arborescence LDAP

FusionDirectory ajoute des entrées dans l’Annuaire, un attribut pour limiter l’accès à un enregistrement LDAP, ou même les attributs aux utilisateurs de l’interface web.

Ces ACLs ne sont utilisés que par FusionDirectory et ne sont pas intrusifs aux autres applications utilisant le serveur d’annuaire.

Ces ACLs permettent le contrôle avec une bonne granularité qui peut utiliser FusionDirectory.

Ces ACLs peuvent être affectés à des rôles. Nous pouvons avoir un rôle :

  • Administrateur global : ce rôle a le droit de tout faire
  • Administrateur local : ce rôle sera en mesure de gérer les utilisateurs et les groupes et aussi une branche
  • Ressources humaines : ce rôle ne peut créer des utilisateurs à partir du modèle afin d’optimiser le flux d’arrivée de nouvelles personnes
  • Utilisateur : il peut se connecter à FusionDirectory avec son login / mot de passe pour changer sont des données seulement lorsque autorisé par l’administrateur.

L’accès à plusieurs arbres LDAP

FusionDirectory est une interface web gérer par des profils.
Il est donc possible d’avoir une seule instance FusionDirectory et accéder à plusieurs serveurs LDAP avec des profils différents.
Dans le cas d’un système d’information dans de multiples endroits avec des répertoires distincts, d’une interface unique sera les gérer tous.

Actions FusionDirectory

FusionDirectory intègre une série de déclencheurs qui peuvent lancer une action spécifique sur la base d’une tâche FusionDirectory doit exécuter.
Ces déclencheurs sont associés à un type de contenu (utilisateur LDAP, groupe, serveur, mot de passe, le service (etc ..) et l’action de déclenchement (créer, modifier, supprimer, changer le mot de passe …)
Ce système est très utile lorsque certaines actions doivent être suivies à l’arrivée ou le départ d’une personne dans l’entreprise, par exemple, lors de la création d’un utilisateur, une forme de génération de script peut être exécuté automatiquement avec les informations du serveur LDAP. Cela peut être utile pour générer des badges avec photo, une forme d’accès à la cantine ou en envoyant un e-mail pour avertir de l’arrivée effective de la personne.
Ce système est également pratique lorsque l’on veut déployer le compte de cette personne sur une application ne prend pas en charge LDAP (FusionDirectory peut également transmettre le mot de passe) est un autre exemple lorsqu’un utilisateur quitte, vous devez:

  • archive et supprimer sa boîte aux lettres
  • archive et supprimer son espace réseau
  • lui supprimer des applications tierces non connectés à LDAP.

Tout cela peut être facilement fait par des scripts shell (au moins dans un environnement UNIX) et exécuter automatiquement après la suppression de la personne par l’administrateur dans FusionDirectory

L’interaction avec les applications non LDAP

FusionDirectory stocke des informations d’un service ou d’un serveur sur un serveur LDAP.
Comment faire lorsque ce service n’a pas la possibilité d’interagir avec LDAP? Cette question peut être résolu en créant :

  • Un schéma LDAP approprié pour une application sur le serveur LDAP
  • Un plugin pour sa gestion dans FusionDirectory
  • Un module Argonaut pour le client installé sur le serveur