Symbiose des référentiels utilisateur avec 389 Directory Server et Active Directory dans un contexte de fédération d'identités
Nicolas Carel
Service Commun Informatique
INRP – 19 allée de Fontenay – BP 17424 – 69347 Lyon Cedex 07
Hugo Étiévant
Service Commun Informatique
INRP – 19 allée de Fontenay – BP 17424 – 69347 Lyon Cedex 07
Résumé
Cet article résume le projet de refonte de la gestion des identités de l'INRP dans le cadre de la mutualisation du système d'information documentaire de trois établissements partenaires. Ce projet organisationnel autant que technique a été l'occasion de mettre en œuvre des logiciels libres innovants autour de la problématique de la gestion des identités et de mettre en place de nouvelles procédures métiers transversales. Dans les éléments phares, la mise en œuvre de « 389 Directory Server » (ex. Fedora Directory Server) en mode multi-maître, la synchronisation bilatérale avec Active Directory, le tout en SSL, apportent de réels plus en termes de disponibilité et de souplesse par rapport à une solution OpenLDAP. Le retour d'expérience que nous apportons pourra donc permettre à d'autres établissements de résoudre de manière élégante deux épineux problèmes : la haute disponibilité de leur annuaire LDAP et la cohabitation avec le monde Microsoft Windows.
Mots clefs
annuaire, LDAP, AD, 389 DS, 389 Directory Server, FDS, Fedora Directory Server, authentification, SSO, CAS, fournisseur d'identités, IdP, Shibboleth, haute disponibilité, services innovants, sécurité, SSL, réplication multi maître, mot de passe
Dès 2004, l'INRP a défini dans son schéma directeur informatique la mise en œuvre d'un annuaire LDAP et son périmètre d'application. Il s'agissait de centraliser l'authentification des utilisateurs et de mettre en place un serveur Radius pour les accès modem et le Wifi. Il n'était pas encore question de domaine Active Directory et notre expérience était limitée. Pour exemple, un serveur OpenLDAP a été utilisé pour identifier les utilisateurs d'un important site web, mais les concepteurs du site web se sont servis de l'annuaire comme d'une table de référence applicative, avec des accès beaucoup trop fréquents (10 balayages par seconde sur 20000 entrées).
En 2006, il a été fait le choix de 389 Directory Server pour mettre en place l'annuaire destiné à Radius et eduroam. L'ingénieur ayant débuté ces travaux nous ayant quitté peu après, l'infrastructure est restée en l'état : un seul nœud, un import manuel des utilisateurs et un réseau Wifi opérationnel sur eduroam mais pas tout a fait terminé. Ce mode de fonctionnement a perduré jusqu'à fin 2008.
En 2007, un nouvel axe de modernisation a été défini : SSO CAS avec annuaire LDAP et entrée dans la fédération d'identités de RENATER avec l'IdP Shibboleth. Le périmètre de l'annuaire LDAP a été étendu et un gros effort sur son alimentation a été réalisé. L'objectif était d'automatiser l'import à partir des applications de gestion : base RH, base des enseignants-associés, base bibliothèque, base des participants aux formations, séminaires et colloques.
Parallèlement à ces travaux internes, nous devions renouveler notre système de gestion de bibliothèque (SIGB) acquis en 1996. Profitant de notre nouvelle implantation géographique sur le site de l'ENS-LSH, les 3 bibliothèques (ENS-LSH, BIU Lyon 2 Lyon 3, INRP) ont travaillé d'un commun accord sur un projet mutualisé visant non seulement à renouveler les SIGB, mais également à se doter d'un outil fort : un système d'information documentaire (SID1).
Ce projet de SID, entré en phase de réalisation en février 2009 est novateur. Il permettra de fédérer l'ensemble des ressources électroniques des établissements partenaires (catalogue bibliothèque, abonnements numériques payants aux revues, bases de ressources internes, catalogues de partenaires internationaux dans le domaine des lettres et sciences humaines) afin de dépasser l'utilisation même du SuDoc et de déporter l'utilisation des ressources quelque soit la localisation géographique de l'usager.
Pour fonctionner, ce SID s'appuie d'une part sur les technologies de proxy, de gestion de droits électroniques, de fédération d'identité (LDAP, CAS, Shibboleth) et d'autre part sur des compétences informatiques fortes partagées entre l'INRP et l'ENS-LSH.
Le choix d'architecture et des outils techniques se sont faits avec un niveau fonctionnel souhaité tout en tenant compte de l'infrastructure existante. Il convient tout d'abord de se placer au niveau de l'utilisateur, et ensuite de se placer à un niveau d'organisation et d'architecture.
L'utilisateur actuel de l'INRP possède un compte d'accès par système que nous citons ici par volumétrie décroissante : Courrier électronique, Wifi, site web intranet statique, Bureautique, Agenda partagé, Bibliothèque (lecteur), Accès à distance (VPN), site web collaboratif, Gestion comptable, Gestion RH, Gestion bibliothèque (professionnel) et en projet un portail RH pour tous les agents et un système d'information documentaire. L'utilisateur doit mémoriser une dizaine de mots de passe, il est donc demandeur de simplification.
Ce dernier est de surcroit confronté à de mauvaises habitudes, sous couvert de continuité de service : transmission du mot de passe aux collègues ; mot de passe transmit par mail ou écrit dans le cahier de procédures posé sur le bureau ; collecte de tous les mots de passe par le chef de service... Arrêtons là le musée des horreurs.
Nous voyons donc deux axes forts qui poussent à un changement : un niveau fonctionnel à atteindre pour évoluer vers de nouveaux usages et une rationalisation de la pratique actuelle de gestion des comptes.
Au niveau du DSI, il est nécessaire d'augmenter le niveau de sécurité et le niveau fonctionnel de son système d'information afin de concourir aux objectifs présents et futurs de son établissement. A ce niveau organisationnel, la direction de l'établissement se trouve impliquée avec un certain nombre de ses cadres afin de fixer les contraintes organisationnelles et techniques.
Parmi les contraintes organisationnelles, se pose la question de la transition. La direction souhaite fortement un passage en douceur ne perturbant ni le fonctionnement du courrier électronique, ni de la bureautique. Il n'est donc pas possible de casser le système bureautique pour passer sur un nouveau domaine (Samba ou Active Directory). La contrainte organisationnelle devient technique : unifier le monde Active Directory avec le monde Unix et conserver les mots de passe existants au moment de la migration.
Pour l'architecte des systèmes d'information, se pose la question de la sécurité (disponibilité, confidentialité, intégrité). Un système d'authentification unique est un élément critique. Son indisponibilité occasionne du chômage technique, sa corruption occasionne une perte de confiance, sa divulgation des fuites d'informations confidentielles. C'est aussi l'occasion de remettre à plat des éléments de la politique de sécurité, comme nous le verrons dans le paragraphe 6.4. Pour atteindre un niveau raisonnable de sécurité, les contraintes techniques sont exprimées : non circulation du mot de passe en clair, traçabilité, redondance des systèmes, sauvegarde et dispersion multi-site.
Au niveau financier, nous souhaitions limiter les coûts au maximum. L'utilisation de logiciel libre est donc souhaitée à condition de ne pas perdre l'économie réalisée en temps d'ingénierie car liberté n'est pas synonyme de gratuité.
Au départ, nous avions pensé à un serveur OpenLDAP avec un réplicat plus un contrôleur de domaine Samba. Cette première idée induit une perte de fonctionnalités au niveau de la gestion des droits d'accès bureautique et en particulier sur les groupes imbriqués que nous utilisons.
Nous avons ensuite pensé à une solution « Full AD » avec des contrôleurs sur chaque site. Cela nous pose un problème de périmètre d'utilisateurs avec une partie de la population qui n'a pas de session bureautique. Pour l'intégration avec Postfix et plus globalement avec le monde Unix, cette solution pose de gros problèmes d'intégration.
Nous avons étudié aussi la solution OpenLDAP avec Active Directory, mais cela fonctionne sans synchronisation de mot de passe. Une application doit piloter le changement de mot de passe dans les deux mondes.
Ayant découvert 386 DS, nous avons effectué un comparatif fonctionnel et revu nos scénarii :
|
Fonctionnalité |
OpenLDAP |
389 DS |
|---|---|---|
|
Réplication |
Un seul répliquat. Problèmes de fiabilité. |
4 nœuds en mode maître-maître. |
|
Interface graphique de configuration |
Aucune, produits tiers |
Console Java multi-plateforme. |
|
Cryptographie |
Librairies OpenSSL. |
Librairies Netscape SSL. |
|
Dialogue avec Active Directory |
Produit tiers nécessaire ou développement maison. |
Création, synchronisation et suppression bilatérale des entrées et des mots de passe. |
|
Gestion des schémas |
Fichiers .schema et redémarrage |
Fichiers LDIF. Modification à chaud, y compris indexation. |
|
Gestion des ACL / ACI |
Modification du fichier de configuration principal et redémarrage. |
Modification à chaud via la console graphique. |
|
Tenue en charge avec ACL |
Plusieurs crash de base. |
Meilleure. |
|
Coût |
Libre. Développement à prévoir. |
Libre. |
|
Support communautaire |
Large expérience universitaire françaises. |
Liste de diffusion internationale en prise directe avec les développeurs, très réactive. |
|
Sauvegarde |
Dump LDIF (slapcat). |
Procédure de sauvegarde et restauration à chaud. Dump LDIF possible. |
|
Traçabilité |
Niveaux de log paramétrable manuellement. Fichiers de log standard. |
Journaux de logs précis sur connexions , recherches, modifications, erreurs. Niveaux de log paramétrable. Configuration fine et affichage des logs via GUI. |
|
Temps mort |
Arrêt et redémarrage après toute modification de la configuration, des schémas, des ACI... |
Mise à jour de la configuration à chaud, sans redémarrage. |
|
Politique de mot de passe et verrouillage de compte |
Nécessite un module additionnel. |
Natif, configuration graphique. |
389 Directory Server est la version de développement de Red Hat Directory Server : la solution d'annuaire LDAP pour entreprise de l'éditeur Red Hat qui dérive lui-même de Netscape Directory Server. 389 DS est donc plus avancé au niveau fonctionnel que RHDS, mais est cependant moins stable et possède un cycle de vie plus rapide hérité du projet Fedora sponsorisé par Red Hat. Fedora ne propose pas de support pour ses produits (d'où la gratuité), nous pouvons cependant compter sur une communauté de plus en plus active, notamment visible sur les listes de diffusion de 389 DS.
Figure 1: Schéma
d'architecture de 389 DS
389 DS est composé d'un serveur
d'annuaire conforme à la norme LDAP et supportant la version
3 du protocole. Sur ce serveur, se greffent des plugins assurant des
fonctionnalités supplémentaires comme le contrôle
d'accès et la réplication, les fonctionnalités
de 389 DS peuvent donc être étendues grâce à
des greffons. Les données de l'annuaire sont organisées
dans un arbre DIT2
et une base de données sous-jacente (Berkeley DB de Sleepcat
Software) stocke ces données. A noter que chaque branche du
DIT peut être stockée sur une base différente et
même répartie sur plusieurs bases différentes.
Comme le montre la figure 1, en parallèle à 389 DS, un serveur de configuration (Administration Server) permet un accès distant aux données et à la configuration de 389 DS. AS utilise en frontal un serveur HTTP communiquant en XML avec une console cliente, en java, multi-plateformes (IDM Console). La IDM Console permet de réaliser la quasi totalité des opérations de configuration en mode graphique ce qui réduit considérablement les efforts de paramétrage. Les opérations de configuration peuvent être également réalisées en ligne de commande via des requêtes LDAP sur 389 DS grâce à un DIT virtuel recevant les éléments de paramétrage mais aussi des ordres d'action (redémarrage, sauvegarde...). Par ailleurs, les configurations des serveurs 389 DS et AS sont elles-mêmes sauvegardées dans des exports LDIF. Afin d'offrir un seul point d'entrée aux administrateurs, plusieurs 389 DS peuvent s'enregistrer auprès d'un unique AS afin de simplifier le paramétrage via la console.
Les opérations standard de sauvegarde de la configuration et d'import/export de données sont réalisables aisément via la console ou en ligne de commande.
La haute disponibilité du service d'annuaire peut être assurée par la mise en place d'une architecture répliquée en mode maître/esclave ou multi-maître. Il est aisé de mettre en place une architecture à N nœuds multi-maîtres : chaque nœud répliquant de façon bidirectionnelle des données avec les N-1 autres serveurs.
Le périmètre de la réplication ne se limite pas aux données métiers de l'annuaire mais s'étend aussi à la configuration même de 389 DS, qui puisqu'elle est stockée dans un suffixe à part entière du DIT, peut être répliquée comme n'importe quel autre suffixe. Ainsi les nœuds d'une architecture répliquée partagent les données mais aussi la configuration du serveur LDAP. Chaque nœud est donc équipé d'un 389 DS et d'un AS capable de gérer tous les 389 DS de l'architecture, la perte d'un AS ne limite pas la capacité de paramétrage en mode graphique. Toute opération de remise en service d'un nœud défaillant s'en trouve alors facilitée. L'équipe d'administration système gagne beaucoup en efficacité grâce à cette réplication.
Outre le besoin de proposer une haute disponibilité des données et du service d'annuaire, celui-ci se doit d'être interopérable avec d'autres technologies et produits du système d'information. Beaucoup d'organismes disposent d'un parc de postes de travail sous Windows et gérés par un domaine Active Directory. Le souci de proposer aux utilisateurs un service d'authentification unifié et de simplifier les opérations de gestion des comptes impose de faire communiquer les mondes Linux et Windows. Pour cela, 389 DS propose un module de synchronisation avec l'AD. Ainsi les comptes, groupes et mots de passe sont maintenus en temps réel en cohérence entre 389 DS et l'AD. Toute création, suppression et modification dans l'un des deux annuaires et synchronisé dans l'autre. Ceci est particulièrement intéressant pour le mot de passe que les utilisateurs peuvent modifier sans intervention d'un administrateur, Ce mot de passe s'applique à toutes leurs applications, que celles-ci reposent sur une authentification pam_ldap ou Kerberos.
Les échanges entre composants au sein d'une architecture d'annuaires avec 389 DS offrent potentiellement un point de vulnérabilité par la criticité des informations échangées (mot de passe). C'est pourquoi tout le trafic réseau peut être sécurisé avec un tunnel crypté par SSL. Ceci concerne les communications entre 389 DS (serveur LDAP) et AS (serveur HTTP de configuration), entre répliquas 389 DS, entre 389 DS et AD (synchronisation des comptes et mots de passe), entre console cliente et AS et enfin, entre tout client LDAP et 389 DS. Par ailleurs, 389 DS offre de nombreux algorithmes de hashage (SSHA-1, Crypt, MD5...) pour le stockage des mots de passe dans les entrées LDAP, ainsi que la possibilité de chiffrement d'autres attributs.
Pour assurer la robustesse des mots de passe des utilisateurs de l'annuaire, 389 DS implémente le mécanisme de politique de mot de passe (RFC du 18 janvier 2006 de Sermersheim & Poitou3) et de verrouillage de comptes à des fins de protection contre les attaques. On paramétrera judicieusement cette politique sous 389 DS pour la rendre compatible avec les contraintes de complexité de mot de passe sous Windows.
Enfin, 389 DS supporte le protocole SNMP afin de permettre la supervision de l'annuaire et d'en surveiller l'utilisation quotidienne.
L'INRP dispose d'un existant composé de nombreuses sources d'informations sur ses personnels et utilisateurs de l'outil informatique. Pour des raisons historiques et comme beaucoup d'autres organismes, le service informatique a longtemps eu une certaine autonomie dans la gestion de la population possédant un compte informatique. Ces comptes étaient gérés de façon déconnectée de la base administration de gestion des personnels pour des raisons de praticité, mais avec les risques juridiques et de sécurité que cela implique.
Il a donc été décidé de faire « le ménage » et de considérer les bases de données de gestion comme seules sources fiables de référence. Ainsi un méta annuaire (application Access/MSSQL) a été mis sur pied afin de mettre toutes les autres bases de données (annuaire téléphonique de l'Intranet, annuaire 389 DS, comptes Windows...) en conformité avec les données administratives.
Ainsi le méta annuaire met à jour l'annuaire 389 DS en conformité avec la base de la DRH. 389 DS sert de référence pour les comptes informatiques. Il est synchronisé avec l'AD (comptes Windows) et est utilisé par l'annuaire téléphonique de l'Intranet, le serveur Radius pour WiFi eduroam, le firewall pour les VPN, le serveur de messagerie électronique Postfix, le serveur SSO CAS utilisé par les applications web, notre IdP4 qui est dans la fédération RENATER, l'intranet RH, etc.
Le couple 389 DS/AD est la pierre angulaire de la gestion des comptes informatiques, sous le contrôle du méta annuaire.
La figure 2 montre la circulation des flux de données du SI permettant au méta annuaire d'alimenter 389 DS.
Figure 2: Schéma de circulation des flux dans le SI de l'INRP
En interne, les services impliqués sont avant tout situés en amont de l'annuaire. Ils sont les gérants des bases nominatives suivantes : personnels, enseignants-associés, participants aux séminaires, formations, colloques, lecteurs de la bibliothèque, intervenants extérieurs divers. Le service communication, pour des raisons historiques de gestion de l'annuaire téléphonique, est aussi associé. Le service commun informatique pilote le projet sous la houlette du secrétaire général. En externe, les partenaires du système d'information documentaire : l'ENS-LSH, la BIU Lyon 2 et Lyon 3 pour la gestion de l'interopérabilité.
La méthode retenue a été d'avancer en intégrant progressivement les bases de données une par une en commençant par les personnels, puis la bibliothèque, et en septembre 2009 les enseignants associés. La partie séminaire, formations, colloques n'est pas encore entamée.
Avec l'aide du service communication, un plan de communication a été établi pour l'opération de changement de mot de passe liée à la mise en œuvre opérationnelle de la synchronisation entre AD et FDS instituant le mot de passe unique.
Un tour de table lyonnais des pratiques des politiques de mots de passe a permis de mettre sur pied notre propre politique. Une application web de changement de mot de passe a été développée pour les populations qui n'ont pas accès au domaine Active Directory.
Figure 3: Schéma d'une réplication à 2 maîtres
La réplication 389 DS permet à un serveur « consommateur » de répliquer les données d’un serveur « fournisseur ». L’initiative de la réplication est toujours du côté fournisseur (mode push5) : le fournisseur envoie de lui-même les données à son ou ses consommateur(s). L’unité la plus petite pouvant être répliquée est la « base de données ». Un suffixe peut être stocké dans une base de données dédiée, une base de données partagée entre plusieurs suffixe ou répartie entre plusieurs bases de données ; il convient alors d'organiser son DIT convenablement pour la réplication.
Les données que le fournisseur doit envoyer sont stockées dans un « journal » qui recense toutes les mises à jour qui seront rejouées par le consommateur. Le fournisseur se connecte sur le consommateur avec un compte d'accès devant avoir les droits adéquats pour y jouer les données du journal.
Comme le montre la figure 3, un « accord de réplication » est créé sur le fournisseur pour chacun des consommateurs, il permet de paramétrer finement le comportement de la réplication pour chacun d’eux et de spécifier le DN6 de l’utilisateur sous l’identité duquel le fournisseur va alimenter le consommateur. Une telle relation entre consommateur et fournisseur est donc binaire, et doit être renseignée autant de fois que nécessaire dans une architecture à N nœuds, soit N*(N-1) fois.
Une réplication est toujours réalisée en temps réel mais peut être active en permanence ou bien uniquement certains jours de semaine et dans une période horaire de la journée déterminée. Ainsi, les week-end et en dehors de heures d'ouvertures des bureaux, la synchronisation peut être interrompue afin de limiter la charge sur les réseaux et permettre des opérations de maintenance sur les annuaires.
Dans une architecture multi-maîtres, tout serveur est fournisseur de données mais aussi consommateur.
Figure 4: Schéma d'une réplication avec un Active Directory
L'annuaire 389 DS peut être nativement synchronisé avec un annuaire AD. Ce qui permet de maintenir la cohérence de deux annuaires hétérogènes sans développer d'outillages maison lourds à maintenir, ni d'outil payant.
Toute création/modification/suppression de compte utilisateur (y compris les changements de mot de passe utilisateur) et/ou de groupe est synchronisée de façon bidirectionnelle entre deux annuaires 389 DS et AD. La synchronisation concerne toutes les entités utilisateurs et groupes des sous-arbres (de façon récursive) d’une branche pour chacun des deux annuaires à faire correspondre.
La figure 4 montre une architecture de réplication entre un 389 DS et un AD.
Tout compte utilisateur Windows (de type Utilisateur ou inetOrgperson) créé dans l’AD est dupliqué sur 389 DS si cette option est spécifiée dans l’accord de synchronisation.
Tout compte utilisateur créé dans 389 DS est dupliqué vers l’AD s’il possède les informations suivantes :
La valeur « ntUser » dans le champ multivalué « objectClass »
L’identifiant Windows du compte (samAccountName) comme valeur du champ « ntDomainUser »
L’attribut « ntUserCreateNewAccount » à « yes »
De façon similaire, tout groupe présent dans la branche synchronisée sera reproduit sur 389 DS si cette option est spécifiée dans l’accord de synchronisation.
Tout groupe créé dans 389 DS est dupliqué vers l’AD uniquement s’il possède les informations additionnelles suivantes :
La valeur « ntGroup » dans le champ multivalué « objectClass »
L’attribut « ntGroupCreateNewAccount » valué à « yes »
Les informations d’appartenance d’utilisateurs à des groupes sont aussi synchronisées uniquement dans le cas où le groupe et l’utilisateur sont dans le périmètre de l’accord de synchronisation.
Les changements de mots de passe sont répercutés de façon bidirectionnelle, c’est le comportement par défaut de la synchronisation.
Cette action doit être réalisée par l’utilisateur via les commandes ldappasswd ou Ctrl+Alt+Suppr de Windows. Cette action ne peut pas être réalisée par simple modification de l’attribut userPasswd (crypté) de l’entrée LDAP de l’utilisateur (sauf à le stocker en clair dans l'annuaire, ce qui n'est pas recommandé), car 389 DS et l'AD utilisant des algorithmes de chiffrement différents pour le stockage du mot de passe, toute synchronisation doit se faire sous la forme « texte en clair » du mot de passe (d'où le tunnel SSL). Il peut aussi être réinitialisé par un administrateur via la IDM Console ou la MMC Windows pour Active Directory.
Côté 389 DS, un accord de synchronisation doit être créé, sur le même principe que les accords de réplication entre nœuds 389 DS. Côté AD, un service nommé PassSync doit être installé via un MSI fourni sur le site officiel de 389 DS, sa configuration est simple et permet de synchroniser une branche de l'AD avec une branche d'annuaire 389 DS.
Si elle est mise en œuvre, il faut bien penser à mettre en place la même politique de complexité du mot de passe côté Windows et côté 389 DS, sinon un mot de passe accepté d'un côté pourrait être refusé de l'autre.
Le pré-requis pour un serveur AD est l'installation des composants suivants : contrôleur de domaine, Active Directory, DNS, services de certificats et la création d'une autorité racine d'entreprise.
La figure 4 illustre l'architecture de synchronisation entre un AD et un 389 DS via un tunnel chiffré.
La synchronisation des mots de passe doit impérativement se faire sous un tunnel chiffré par SSL, il est donc nécessaire de réaliser un échange de clés entre serveurs (elles peuvent être auto-signées).
Les applications clientes sont configurées de manière à interroger l'ensemble des nœuds de l'architecture LDAP de l'INRP avec un timeout assez faible pour assurer une bascule rapide en cas de défaillance.
Dans l'exemple du fichier de configuration ldap.conf7 d'un système Linux utilisé pour le pam_ldap8, plusieurs URI sont spécifiées dans le champs URI afin de pointer vers tous les nœuds LDAP. Dans le cas du SSO CAS, il en va de même.
Pour ce qui est des applications web dynamiques développées en interne (PHP & MySQL), une fonction de connexion vers le premier nœud disponible de notre architecture LDAP parmi une liste fermée a été créée. Ainsi nos applications trouvent toujours un annuaire disponible même en cas de défaillance d'un nœud.
Une répartition de charge peut aussi être assurée grâce au DNS Round Robin9 et aux certificats « wildcard10 » ou à CN multi valués11.
Exemple de fichier de configuration ldap.conf :
uri
ldaps://ldap1.inrp.fr:636
ldaps://ldap2.inrp.fr:636
base
ou=People,dc=inrp,dc=fr
ldap_version
3
scope
one
timelimit
5
bind_timelimit
5
idle_timelimit
3600
TLS_REQCERT
always
TLS_CACERTDIR
/etc/pki/certs
Il y a deux stratégies possibles pour sécuriser les communications réseaux :
utiliser un tunnel de transport chiffré par SSL à partir des certificats serveurs et réaliser une authentification simple par couple DN / mot de passe
utiliser en plus du tunnel chiffré une authentification des clients à base de certificats clients signés par une autorité de certification dont le certificat racine devra être déposé dans le magasin de certificats de 389 DS
L'INRP a fait le choix de chiffrer toute communication entre répliquats (nœuds 389 DS), annuaires synchronisés (AD/389 DS), serveurs d'administration (389 DS/AS) et consoles d'administration (IDM Console/AS). Cependant, pour des raisons de performances, les daemons de messagerie (popd et imapd) et autres services systèmes (sshd, radiusd) interrogent les nœuds 389 DS sans tunnel chiffré car les communications restent dans un VLAN interne. Les autres clients qui accèdent en mode anonyme à certaines données non sensibles de l'annuaire le font en clair.
La discrimination des accès des utilisateurs aux données de l'annuaire est à base d'ACI (Access Control Instruction). Une ACI définit des permissions (lecture, modification, ajout...) sur une cible (entrée LDAP, attributs, filtre...). Une ACI s’applique à des utilisateurs en fonction de leur DN, de leur groupe, de leur rôle, de leurs attributs utilisateurs, de leur IP, de leur nom d’hôte DNS, de la plage horaire, du jour de la semaine et de la méthode d’authentification. Les ACIs sont stockés directement dans les entrées, elles sont donc répliquées. Les ACIs sont évaluées selon leur signification sémantique et non leur position hiérarchique dans le DIT : les interdictions prévalent sur les autorisations et les autorisations sont cumulatives.
La syntaxe des ACIs sur 389 DS est très différente des ACL sur OpenLDAP, cependant la syntaxe n'est pas particulièrement compliquée. D'autant que la console offre un assistant graphique permettant de gérer les ACIs.
La refonte des systèmes de gestion d'identités de l'INRP a été l'occasion d'aplanir les procédures administratives de gestion des comptes informatiques et de ne fournir aux utilisateurs qu'un seul et unique compte, simplifiant d'autant leur expérience utilisateur. Notre objectif majeur est la sécurité du système d’information. Cependant, la confidentialité du mot de passe de l’utilisateur devient d’autant plus critique qu’un mot de passe unique permet l’accès à toutes les ressources protégées de l’établissement. Le mot de passe de l’utilisateur devient donc un maillon essentiel de la chaîne de sécurité. Or l’utilisateur est seul maître de la constitution de son mot de passe, qui est une donnée personnelle secrète. Et l’expérience montre que les mots de passe choisis sont souvent faciles à deviner. Il convient donc de forcer les utilisateurs à choisir un mot de passe robuste et à en changer régulièrement. L’ensemble des contraintes que l'on peut imposer aux utilisateurs pour la gestion de leur mot de passe est constitutive d’une « politique de mots de passe ». 389 DS permet de mettre en place une telle politique sur le DIT, un sous arbre ou une entrée particulière.
Comme toute version de développement, quelques bogues résiduels ont été découverts mais ne sont pas de nature à remettre en cause le choix de 389 DS. Par exemple : la synchronisation vers l'AD de comptes crées dans 389 DS les positionne dans l'AD dans l'état inactif. Ceci impose une intervention humaine dans l'AD, intervention de toute façon nécessaire pour positionner les groupes Windows (que nous ne synchronisons pas).
La réplication vers l'AD peut-être problématique dans le cas d'architectures complexes où plusieurs 389 DS multi-maître sont répliqués vers des AD eux-même répliqués en mode multi-maître. Les croisements peuvent provoquer des doublons dans les comptes synchronisés. Il convient de ne synchroniser la création d'objet que dans le cadre d'un accord unique entre le monde Linux et Windows, même si cela introduit un élément vulnérable aux pannes.
L'AD utilise un format d'encodage du mot de passe (Unicode) différent de 389 DS (ASCII 7 bits). Dans certains cas, cela peut faire échec à la synchronisation du mot de passe car 389 DS refuse alors certains caractères acceptés par l'AD. Même s'il est possible de modifier l'encodage sous 389 DS (plugin « 7-bit check »), certains clients (deamon imap) Linux refusent l'Unicode. Il s'est avéré nécessaire de demander aux utilisateurs de ne pas employer de caractères accentués dans leur mot de passe. L'utilisation d'une application web (développée en interne et hébergée par l'intranet) de changement de mot passe très ergonomique12 permet de contourner le problème.
Certaines ACIs complexes peuvent ne pas être gérées par le GUI et nécessitent une écriture manuelle (cependant accessible dans un champs texte dans le GUI).
L'historique des mots de passe (attribut opérationnel multi-valué) reste sur le maître en environnement répliqué (seuls les attributs utilisateurs sont répliqués13).
Nous avons expérimenté les problèmes suivants qui seront détaillés dans la présentation orale :
Diagnostic plus difficile à établir lors de la survenue d'un problème affectant les comptes informatiques.
Filtrage de l'attibut Common Name « cn » qui est utilisé par AD dans le Distinguished Name « dn »,
Débordement des journaux de log.
Création de comptes en double dans certaines configurations de réplications croisées.
Gestion des exceptions et dérogations aux anciennes règles de gestion.
Formation et niveau d'information des collègues du service.
Le méta annuaire contrôlant la cohérence de la gestion des comptes utilisateurs du SI alimente un annuaire LDAP référentiel utilisateur pour l'authentification des applications du SI. Cet annuaire LDAP est lui-même utilisé par un SSO CAS auquel les applications web délèguent l'authentification des utilisateurs de l'INRP.
Dans le cadre de nos partenariats institutionnels et notamment le projet SID, il a été nécessaire de rejoindre la fédération RENATER et de mettre en place un fournisseur d'identités avec Shibboleth. Ce fournisseur délègue l'authentification de notre population interne au SSO et propage des attributs stockés dans l'annuaire LDAP.
Ce fournisseur d'identités est utilisé en interne par un reverse proxy pour l'accès à des ressources électroniques documentaires et en externe par le portail documentaire du SID et certains autres éditeurs de ressources électroniques.
389 DS est une brique essentielle de notre architecture et doit être hautement disponible. L'IdP est quant à lui actuellement redondé selon une architecture actif/passif grâce à des machines virtuelles14 réparties sur plusieurs hyperviseurs.
Le SSO et l'IdP sont configurés de manière à pouvoir interroger n'importe lequel des nœuds LDAP de notre architecture pour une disponibilité optimale du service d'authentification.
Voilà donc l'état actuel de notre travail, en cours d'achèvement. Cependant la course continue : les applications et les spécifications évoluent sans cesse. Notre installation actuelle basée sur Supann v1 et sur 389 DS version 1.1 sur Fedora Core 8 est caduque ; il nous faut maintenant mettre à jour les plateformes et migrer vers le schéma Supann 2008. La révision de nos déclarations CNIL fait aussi parti du chantier : le partage d'informations nominatives entre briques du SI et entre nos établissements nous amène à repenser d'une part la déclaration à la CNIL et d'autre part la communication institutionnelle interne.
La symbiose est une relation intime et durable entre deux organismes d'espèce différente. Nos symbiotes, ici 389 DS et AD, sont associés pour créer un bénéfice global, d'abord aux utilisateurs, et aux équipes du service informatique. Ce dispositif ouvre la porte de l'interopérabilité de notre système d'information. Des applications qui auraient été développées pour fonctionner avec soit le monde Microsoft, soit le monde Unix trouvent un socle d'authentification où la technique s'efface.
Bien conscients que la solution présentée n'est pas la panacée nous avons repéré d'autre avancées techniques prometteuses. Nous pouvons citer entre autres un module d'interopérabilité ADFS15 entre Active Directory et une fédération d'identités. A suivre...
1 Système d'Information Documentaire de la Bibliothèque Denis Diderot à Lyon (regroupement des bibliothèques de l'ENS-LSH, de l'INRP et de la BIU LSH) : http://www.ens-lsh.fr/64901484/0/fiche___pagelibre/&RH=INFOS?RF=BIBLI
2 « Directory Information Tree » : structure logique hiérarchique d'organisation arborescente des données d'un annuaire LDAP
4Identity Provider : fournisseur d'identités fournit par la solution logicielle Shibboleth supportée par le consortium Internet 2, http://shibboleth.internet2.edu/
5 Mode de communication client/serveur où l'information est transmise à l'utilisateur sous forme d'alerte automatique, sans qu'il n'ait besoin d'en effectuer la requête, contrairement au mode pull
6 « Distinguished Name » : identifiant unique d'un objet dans la norme LDAP
7 Fichier de configuration par défaut des outils LDAP client de la machine.
8 Module du système d'authentification PAM des OS Linux, utilisant un annuaire LDAP comme référentiel utilisateur.
9 Technique de répartition de charge basée sur une rotation circulaire de la résolution d'un nom DNS associé à plusieurs adresses IP différentes.
10 Certificat générique lié à un domaine « *.mon-domaine.fr », utilisable par de multiples serveurs de ce domaine et de ses sous-domaines.
11 Nous utilisions jusqu'à fin 2009 les certificats SCS délivrés par le CRU « Comité Réseau des Universités », nous utilisons dorénavant les certificats TCS (Terena Certificate Service) : http://www.cru.fr/services/tcs/index
12 Pour des raisons d'ergonomie pour un public novice en informatique, cette application réalise également tous les contrôles que fait l'annuaire LDAP (conformité du mot de passe avec la politique de complexité, vérification de l'historique des mots de passe, etc.). Le cas échéant, des messages d'explication clairs sont présentés à l'utilisateur, ainsi qu'une jauge graphique de complexité du mot de passe.
13 L'attribut opérationnel « aci » (stockant les ACIs) fait exception à la règle.
14 C'est la solution open source Xen qui a été retenue pour la virtualisation.
15 Active Directory Federation Services : https://spaces.internet2.edu/display/SHIB/MsADFSIntegration
Nicolas
Carel, Hugo Étiévant (INRP) JRES 2009