Par défaut, le serveur PlaniPSY utilise uniquement sa propre base de données pour gérer les utilisateurs. Il est toutefois possible de configurer une ou plusieurs connexions à des annuaires LDAP externes afin de centraliser la gestion des utilisateurs au sein de l’établissement.
Afin de configurer cette connexion, il vous faudra :
- Un serveur LDAP joignable par le serveur PlaniPSY,
- Un utilisateur pouvant accéder en lecture à l’annuaire,
- Un accès à l’application Superviseur,
- Une connaissance de la structure de votre annuaire LDAP.
Le lien entre l’annuaire LDAP et le compte utilisateur dans cette application se fait sur la base d’un login identique (champ Nom Utilisateur). Il est donc important de nommer correctement les comptes dans cette application pour que le lien avec les comptes LDAP se fasse correctement.
Pour commencer, accédez à l’application Superviseur : https://IP du serveur/superviseur/
Accédez ensuite dans l’annuaire LDAP pour configurer la connexion à l’annuaire LDAP : Superviseur > Onglet “Utilisateur” > Annuaire LDAP
Vous trouverez ci-dessous les différents champs à compléter.
PARAMÈTRES | DESCRIPTION |
Nom | Nom de la connexion à l’annuaire LDAP. Ce nom permet d’identifier l’annuaire dans la plateforme BI PILOT. Exemple: AD – CH Terniac – OU RH |
Hôte | Adresse IP ou nom d’hôte du serveur hébergeant l’annuaire. Si un nom d’hôte est utilisé, il faut s’assurer que le serveur BI PILOT est capable de joindre la machine via une résolution de nom. |
Connexion sécurisée | Si votre serveur LDAP prend en charge LDAP over SSL (LDAPS) |
Port | Par défaut, les serveurs qui implémentent le protocole LDAP écoutent les connexions non-sécurisées (LDAP) sur la port 389 et les connexions sécurisées (LDAPS) sur le port 636. |
Version du protocole | Version du protocole à utiliser lors des échanges avec l’annuaire LDAP. Les versions 2 et 3 sont supportées. |
Timeout de connexion (en secondes) | Temps de réponse maximum entre la plateforme BI et le LDAP (généralement 10 secondes) |
Bind DN | Le champ Bind DN correspond au DN complet de l’utilisateur pour lire en lecture seule l’annuaire LDAP. Ce compte est généralement un compte technique, soit qui existe déjà, soit créé spécialement pour cette application et cette utilisation bien spécifique. Exemple : « CN=LecteurAD,OU=Services,OU=CH Terniac,DC=local,DC=ch-terniac,DC=fr » |
Mot de passe | Mot de passe qui sera utilisé pour se connecter à l’annuaire pour toutes les opérations de lecture. |
Confirmer le mot de passe | Confirmer le mot de passe ci-dessus |
Search DN | Le champ Search DN est peut être l’un des champs les plus importants car il permet de préciser le « répertoire », plus précisément l’OU, dans laquelle les comptes utilisateurs doivent être rangés pour que leur authentification fonctionne. Le fonctionnement est en fait le suivant :
|
MAPPINGS | DESCRIPTION |
Champs « Nom d’utilisateur » | Nom de l’attribut dans l’annuaire qui sera utilisé comme nom d’utilisateur sur la plateforme BI PILOT. Exemple : uid |
Champs « Prénom » | Nom de l’attribut dans l’annuaire qui sera utilisé comme prénom pour les utilisateurs sur la plateforme BI PILOT. Exemple : givenName |
Champs « Nom » | Nom de l’attribut dans l’annuaire qui sera utilisé comme nom pour les utilisateurs sur la plateforme BI PILOT. Exemple : sn |
Champs « Adresse email » | Nom de l’attribut dans l’annuaire qui sera utilisé comme adresse email pour les utilisateurs sur la plateforme BI PILOT. Exemple : Mail |
Champs « Actif » | Le champ « actif » est optionnel. Tout compte LDAP qui n’aurait pas ce paramètre à « vrai » ne pourrait pas se connecter (compte désactivé). Lors de la mise en place de la configuration LDAP, nous vous conseillons de laisser ce champ vide pour déjà tester que tout fonctionne. Une fois que la liaison avec l’annuaire LDAP est opérationnelle, ce champ peut être ajouté pour activer le filtrage supplémentaire. Exemple : enabled |
FILTRES PERSONNALISE | DESCRIPTION |
Requête LDAP | Par défaut, tous les comptes présents dans le Search DN, et ayant le champ « actif » du dessus à vrai, ont le droit de s’authentifier et donc d’obtenir les droits fonctionnels cochés ci-dessous (rubrique « Groupes »). Mais il est possible d’ajouter un dernier filtre personnalisé supplémentaire. Cela permet par exemple d’indiquer au serveur BI : « les comptes du répertoire « OU=DIM,OU=CH Terniac,DC=local,DC=ch- Ce filtre supplémentaire doit s’écrire avec le langage de requête LDAP (symbole & pour les ET, | pour les OU, etc.). Exemple : « (memberOf=CN=MédecinDIM,OU= |
- Connexion à la base LDAP
Grâce à l’adresse définie dans le paramètre Hôte , à l’utilisateur et au mot de passe d’accès à l’annuaire, respectivement définis dans Bind DN et Mot de passe , le serveur BI pourra se connecter à votre annuaire LDAP.
- Recherche d’un utilisateur dans la base LDAP
La recherche d’utilisateur se fait dans un arbre, constitué de conteneurs ou de feuilles. Pour cela, il faut configurer le noeud de l’arbre (ou conteneur), correspondant à la base de la recherche grâce au paramètre Search DN.
Pour un domaine mondomaine.local, il s’agit en général de :OU=UserRecherches,OU=MyBusiness,DC=mondomaine,DC=local
Pour rechercher un utilisateur précis, il est nécessaire de filtrer les feuilles et noeuds situés sous Search DN avec une contrainte qui sera automatiquement construite à l’aide des paramètres de mappings des attributs LDAP.
Voici la requête LDAP qui sera construite avec les paramètres utilisés en exemple dans le tableau précédent : (&(uid={nom d’utilisateur})(mail=*)(givenName=*)(sn=*)) qui indique que l’on souhaite retourner un objet pour lequel l’attribut uid est égal au nom d’utilisateur fourni lors de l’identification et ayant les champs mail, givenName, et sn renseignés dans l’annuaire.
- Authentification d’un utilisateur
Une fois l’utilisateur trouvé l’authentification se fait grâce à une tentative de connexion à l’annuaire LDAP avec ses identifiants et le paramètre Hôte.
Pour cela, il est nécessaire de connaître l’adresse de l’objet feuille représentant l’utilisateur. L’adresse est constituée des informations provenant de la recherche et avec Search DN qui représente le reste du chemin pour l’accès à la feuille.
1- Suite à la mise en place du « binding LDAP« , l’utilisateur se connecte avec son login et mot de passe Windows pour la première fois.
2- Comme cela ne correspond à aucun compte dans la base de données locale, et comme le « binding AD » est opérationnel, le système essaie d’authentifier l’utilisateur avec son compte Windows.
3- Une nouvelle entrée est créée dans la BDD locale, en lui associant aucuns droits dans un premier temps.
Note : le mot de passe de l’Active Directory n’est bien sûr jamais stockés localement sur le serveur.
4- Une personne ayant l’autorisation d’accéder au module Superviseur doit ensuite attribuer les bons droits au compte qui vient d’être créer.
5- L’utilisateur peut à présent se connecter avec ses identifiants Windows habituel.
REMARQUES ET CAS PARTICULIERS
1- Une fois le binding LDAP effectué, il reste donc possible de s’authentifier avec ses anciens identifiants créés localement.
2- Une fois le binding LDAP effectué, il sera impossible pour les utilisateurs de modifier leur mot de passe AD depuis l’application (un message d’erreur apparaîtra si un utilisateur essaie). Le changement ne pourra se faire que sous Windows ou via les outils de l’établissement.
3- Dans le cas où le LoginA (LDAP) est égal à Login1 (BDD locale BI), l’utilsiateur pourra tout de suite se connecter, au choix, avec ses identifiants Login1 et/ou LoginA. Dans les deux cas, cela utilisera les « droits1 » déjà créés localement pour Login1. Dans le Superviseur, il n’y aura pas de nouvelle entrée. L’authentification LoginA de l’AD sera simplement possible à présent. L’utilisateur ne pourra par contre plus modifier son mot de passe à travers l’application (cf. remarque précédente).
Il est désormais possible de retirer un annuaire directement depuis la liste.
Suite au retrait d’un annuaire, il n’est plus possible de se connecter depuis celui-ci, les utilisateurs qui se sont déjà connectés depuis cet annuaire sont désactivés.
● Réactivation des utilisateurs possible hors LDAP
● Réactivation automatique à la première connexion si ré-import de l’annuaire
N.B. : les différents niveaux de permissions des utilisateurs ne sont pas impactés par ces opérations.