Tout savoir sur LDAP

Cette série d'article vous propose de découvrir LDAP, aussi bien d'une manière générale (description des concepts, du protocole) que de son utilisateur. En effet, vous trouverez ci-dessous un certain nombres d'articles décrivant l'utilisation de LDAP dans un environnement UNIX.

Les concepts

Les concepts

Introduction et historique

Le protocole

Un objet LDAP

Le modèle d'information LDAP est orienté objet, on y retrouve donc des objets et des classes exactement comme dans un langage de programmation objet (C++ ou Java par exemple) à la différence près qu'un objet LDAP ne dispose pas de méthodes spécifiques. Fondamentalement, donc, un objet LDAP est une instance d'une classe d'objet LDAP (objectClass).

On dit par ailleurs que les informations stockées dans LDAP sont tri-dimensionnels. Cette notion est l'une des principales différences avec le modèle bi-dimensionnel d'une base de données relationnelle.

  1. La première dimension est la classe d'objet (objectClass) - par exemple person
  2. La deuxième dimension est le type d'attribut - par exemple mail
  3. La troisième dimension est le nombre de valeurs de l'attribut - par exemple elilly@enterprise.com et evangeline@gmail.com

Les types d'objectClass

Les types d'attributs

Un attribut est toujours défini par un nom, un OID, une syntaxe, et une méthode de recherche. La syntaxe définit le type de contenu de cet attribut, on trouvera par exemple les traditionnels :

Les opérations

La RFC LDAPv3 définie un certain nombres d'opérations pour manipuler les objets LDAP, on peut y trouver :

bind

C'est l'opération qui permet de s'authentifier sur un annuaire

search

delete

modify

Le DIT

Comment obtenir un PEN

Comme vu précédemment, dès que l'on souhaite créer un objectClass ou un attribut dans un schéma LDAP il faut définir un OID unique. Pour une application bien précise et spécifique, on peut souhaiter vouloir créer son propre schéma LDAP et par conséquent définir ses propres OIDs.

La question à se poser lors de la création de son schéma est donc : Quels sont les OIDs que l'on peut utiliser ?

Pour rappel, chaque OID est un identifiant universel composé d'une suite d'entiers sous une forme hiérarchique. Cette hiérarchie est définie sous la forme d'une arborescence gérée par l'IANA. On rattache chaque nœud de l'arborescence à un organisme ou entité qui aura l'entière responsabilité de gérer le sous-arbre d'OIDs correspondant.

Les OIDs définis par l'organisme en question pourront être utilisés pour définir un schéma LDAP mais aussi pour décrire d'autres objets tels que des OIDs SNMP.

Lorsque l'on créé donc son schéma LDAP, il faut donc déterminer ou se placer dans cette arborescence pour définir ces OIDs sachant qu'il faut respecter certaines conditions :

La meilleure solution est de faire une demande auprès du IANA pour obtenir pour son organisation / entité / entreprise un numéro d'identification dans l'arborescence des OIDs. On appelle cela un PEN (Private Enterprise Number).

Le IANA a réservé en effet le préfixe 1.3.6.1.4.1 de l'arborescence des OIDs pour les entreprises et entités privés. Ainsi, lorsque le IANA attribue un PEN à une entité, son préfixe pour ses OIDs sera 1.3.6.1.4.1.PEN. L'organisation à qui le PEN a été attribué aura toute autorité sur le sous-arbre des OIDs dont le préfixe est 1.3.6.1.4.1.PEN.

Par exemple, CISCO à obtenu le PEN numéro 9, par conséquent son prefixe pour définir ses OIDs est 1.3.6.1.4.1.9.

Pour obtenir un PEN, rien de plus simple, il suffit de se rendre sur le site du IANA à l'adresse http://pen.iana.org/pen/PenApplication.page

Il vous sera demandé de remplir un formulaire qui une fois rempli sera soumis à validation. Le processus de validation prend entre 2 et 3 semaines. Durant ce processus de validation, le IANA peut revenir vers le demandeur pour des compléments d'informations sur les informations postées dans le formulaire. Ce n'est donc pas juste une procédure automatique. Il vaut mieux donc remplir correctement toutes les informations demandées.

Une fois le processus de validation achevé, un mail sera envoyé avec le PEN attribué à votre entité. Dans l'heure, il sera visible sur le site du IANA dans la liste de tous les PEN attribués (http://www.iana.org/assignments/enterprise-numbers)

Félicitations, vous pouvez maintenant définir vos propres OIDs.

Liens utiles

Les serveurs LDAP

Historique

L'implémentation de référence d'un serveur LDAP est née à l'université du Michigan : le projet slapd (c'est le nom du démon LDAP de la majorité des serveurs), au début des années 90.

Cette base de code, à travers une succession de forks, de rachats et de lois de propriété intellectuelle, constitue la base de la majorité des serveurs LDAP qui existent aujourd'hui : OpenLDAP, 389 DS, Sun DSEE...

Les serveurs libres

OpenLDAP

OpenLDAP a commencé en tant que fork du projet slapd de l'Université du Michigan. Le logiciel est distribué sous une licence proche de la BSD (l'OpenLDAP public license).

La dernière version majeure, la 2.4, supporte, entre autres :

OpenDS

OpenDS est un projet né de l'envie de Sun Microsystems de libérer le code de Directory Enterprise Edition néanmoins pour diverses raisons (notamment la difficulté de savoir qui est le détenteur de la propriété intellectuelle de tout le code) Sun à décider de commencer la réécriture complète de l'annuaire. Ce nouveau projet (sous licence CDDL) est entièrement écrit en Java, et dispose de fonctionnalités très intéressante, notamment en terme de performances (aussi bien lecture qu'écritures !).

ApacheDS

ApacheDS est le projet d'annuaire par la fondation Apache. À la différence des autres annuaires libres, il ne se contente pas de fournir une interface LDAP, mais d'autres services associés, comme Kerberos. Cela à le gros avantage de faciliter l'intégration entre les deux services.

389 (ex-Fedora/RedHat) directory server

En 1996, Netscape a embauché les développeurs du projet slapd de l'Université du Michigan, donnant naissance au produit Netscape Directory Server (NDS), sur la même base de code. Suite au rachat de Netscape par AOL, ce dernier a revendu le contrôle des droits sur ce code à RedHat. Le 1er juin 2005, les sources de ce qui est devenu aujourd'hui 389 DS ont été placées sous GPL.

Les autres

Sun Directory Server Entreprise Edition

Suite au rachat de Netscape, qui développait son Netscape Directory Server (NDS) sur la base du code et des développeurs de l'Université du Michigan, par AOL, Sun a acquis la propriété intellectuelle de ce code source. Sun DS dérive de ce même code source.

Microsoft Active Directory

La solution de Microsoft est batie autour d'un annuaire, qui implémente une bonne partie de la norme LDAPv3. Attention cependant, car l'implémentation bafoue la norme en plusieurs endroits, et n'est vraiment pas prévue pour stocker d'autres objets que ceux prévus dans le cadre d'Active Directory : utilisateurs, groupes et comptes machines.

Néanmoins, l'interface LDAP d'Active Directory est souvent bien pratique pour intégrer une application avec ce système omniprésent.

Liens utiles

Apache et LDAP

L'authentification

Il existe de nombreux modules Apache permettant d'authentifier les utilisateurs, vous l'aurez compris, l'un d'eux permet d'utiliser un annuaire LDAP.

La gestion des hôtes virtuels

mod_vhs

Les services de messageries

Introduction

Sendmail

Postfix

Les services de nommages (NSS)

Introduction à NSS

NSS, pour NameServiceSwitch est une couche d'abstraction présente sur la plupart des systèmes d'exploitation UNIX. Vous l'utilisez probablement même sans le savoir, notamment pour résoudre un nom en adresse IP. En effet, à l'origine, cette traduction était effectuée via le fichier /etc/hosts, ce qui devient bien évidemment impossible à gérer lors de grands réseaux (par exemple Internet). Est apparu alors un service réseau, le DNS, permettant d'interroger un serveur pour lui demander de traiter la traduction.

Un autre exemple, celui qui nous intéresse particulièrement dans cet article, de traduction entre nom et numéro est la gestion des utilisateurs. En effet, sous UNIX, un utilisateur est défini par un nom, mais aussi et surtout un UID (User Id) et un GID (Group ID). Lors que vous créer un fichier, le système de fichier va enregistrer dans les méta données l'UID et le GID du propriétaire de ce fichier. Cependant, lorsque vous faites un ls sur ce fichier, c'est le nom (et non les valeurs numériques) de l'utilisateur et du groupe qui sont affichés. Cette traduction est traditionnellement effectuée en utilisant les fichiers /etc/passwd et /etc/group. Vous l'aurez compris, un serveur LDAP est très bien adapté pour remplacer ces fichiers. En pratique, les fichiers sont utilisés pour les comptes systèmes (notamment le root) et les comptes de services, tandis que LDAP est utilisé pour les utilisateurs (au sens humain du terme).

LDAP et NSS

Pour utiliser un serveur LDAP comme source pour les utilisateurs, il convient de créer des objets qui disposent d'un certain nombre d'objectClass, à savoir :

Stocker votre configuration sudo dans LDAP

Introduction

Vous connaissez déjà sans doute sudo, un outil permettant d'autoriser des utilisateurs à exécuter des commandes sous un autre utilisateur (par exemple root) sans connaître le mot de passe ce celui-ci. Nous vos proposons à travers cet article d'utiliser un annuaire LDAP pour stocker votre configuration sudo. Cela à le gros avantage de centraliser la configuration, et donc une administration simplifiée.

La configuration standard

Voici un fichier de configuration classique de sudo :

root ALL=(ALL) ALL
%operator ALL=(ALL) ALL

Ce fichier de configuration est volontairement très simple pour une première approche. Il autorise l'utilisateur root et les membres du groupe operator à exécuter des commandes sous n'importe quel utilisateur. Un appel à la commande sudo -l permet d'obtenir la liste des règles autorisées par l'utilisateur appelant :

% id -a
uid=1000(asyd) gid=1000(asyd) groupes=4(adm),37(operator),1000(asyd)
% sudo -l
User asyd may run the following commands on this host:
(ALL) ALL

Installation

Avant tout, vous devez vérifier que le sudo que vous utilisez est compilé avec le support ldap, pour cela vérifier que votre binaire sudo est linké sur la libldap 

% ldd sudo | grep ldap
libldap.so.5 => /usr/lib/libldap.so.5

Si vous n'obtenez aucun résultat, vous devez recompiler sudo avec l'option --with-ldap

Configuration

Vous disposez donc maintenant d'un sudo compilé avec le support LDAP, la première opération consiste à rajouter le schéma dans votre annulaire LDAP

Installation du schéma LDAP

IPlanet, Sun Directory Server Entreprise Edition, OpenDS

Pour rajouter le schéma, exécuter simplement la commande suivante (depuis le répertoire sources de sudo) :

% cp schema.iPlanet $INSTANCE_ROOT/config/schema/98-sudo.ldif

(Rajouter les options -Wx si vous utilisez un ldapmodify d'OpenLDAP.)

OpenLDAP

Pour un annuaire OpenLDAP, copier le fichier schema.OpenLDAP dans le répertoire des schémas sous le nom sudo.schema, puis rajouter la ligne de configuration suivante dans le fichier slapd.conf :

schema sudo.schema

Fichier de configuration

Le fichier sudoers n'est plus nécessaire, les informations nécessaires sur le serveur LDAP sont stockés dans le fichier de configuration ldap.conf. Attention l'emplacement de ce fichier est spécifique à chaque distribution et système d'exploitation !

Voici un exemple très simple des directives nécessaires pour sudo :

host ldap.domain.tld
port 389
sudoers_base ou=sudo,ou=Apps,dc=asyd,dc=net

Les objets LDAP

Il nous reste maintenant à configurer les différents objets LDAP. Avant tout, il convient de préciser que l'approche de configuration LDAP est différente par rapport à l'utilisation de fichiers.

Utilisation du 802.1x

Cet article va présenter une utilisation de la norme 802.1x au sein d'un réseau d'utilisateurs. L'objectif est d'authentifier l'utilisateur aussi bien au niveau réseau (d'où le 802.1x) qu'au niveau système, en une authentification unique, et gérée d'une manière centralisée (dans notre exemple, un annuaire LDAP).

Présentation des technologies

Archicture

802.1x

Le protocole 802.1x est un protocole d'authentification au niveau ethernet, cela permet l'autorisation d'une machine auprès du commutateur, avant même de disposer d'une adresse IP. Dans la plupart des cas (pour ne pas dire tous), cette authentification est assurée par une communication entre le commutateur (qui peut être également un Access Point Wifi) et un serveur radius, mais il peut être également réalisé par une base de données internes aux équipements.

Radius

Radius est un protocole d'AAA (Authorization, Authentication, Accounting) permettant l'authentification des utilisateurs. Il fut créé notamment pour l'authentication pour des services d'accès distants (RTC, DialUP).

LDAP

LDAP est un protocole de communication et d'interrogation vers un annuaire. Le sujet est tellement vaste qu'il fera sujet d'articles dédiés.

Un mot sur les commutateurs

Certains commutateurs permettent l'application de différentes politiques d'accès (des ACL) en fonction de l'état 802.1x d'un port, c'est à dire si la machine est authentifiée ou non. Cela permet par exemple d'autoriser les flux DHCP, DNS pour tout les utilisateurs (qu'ils soient authentifié ou non), et de donner un accès full IP aux utilisateurs authentifiés.

Réalisation

Authentification unique et mode déconnecté

Afin d'assurer une authentification unique pour l'utilisateur (du moins pour se connecter au réseau et au système), nous avons développé un module pam_supplicant qui permet non seulement de rejouter le couple identifiant / mot de passe au daemon wpa_supplictant mais il procède également à la mise à jour du fichier /etc/shadow. Cette dernière opération permet une synchronisation du mot de passe local à partir de celui du serveur LDAP, qui est utilisé par les autres applications de l'Intranet.

Cette synchronisation permet donc l'authentification sur le poste lorsque que celui ci est déconnecté du réseau.

Configuration radius et la problématique des mots de passe

Problématique : une authentification radius s'effectue à l'aide d'un login et d'un mot de passe fourni par l'utilisateur, cependant le mot de passe est généralement condensé (hashé) à l'aide d'algorithme comme MS-CHAPv2, le serveur radius ne recevant donc pas en clair le mot de passe de l'utilisateur.

Le serveur freeradius permet deux types d'authentification sur un annuaire LDAP, l'une vérifie via une opération bind avec les identifiants utilisateurs, l'autre permet de spécifier l'attribut LDAP utilisé pour stocker le mot de passe, et vérifie les identifiants par une recherche sur le login, puis une comparaison du mot de passe (avec application de hash le cas échéant).

Plusieurs solutions (du moins deux) s'offrent à nous :

Utilisation de deux attributs LDAP

On stocke dans l'annuaire LDAP le mot de passe hashé via la même méthode que celle utilisée par les clients radius. Néamnoins, si les administrateurs du système d'information souhaitent (à juste titre) que les utilisateurs ne disposent que d'un, et d'un seul mot de passe, cela oblige à synchroniser le champ userPassword et celui utilisé par le serveur radius (par exemple radiusTunnelPassword). De plus, cela pose un problème de sécurité, en effet, si le même mot de passe est utilisé pour les attributs userPassword et radiusTunnelPassword, l'un sera stocké de façon forte (généralement le champ userPassword utilise l'algorithme SSHA SHA1 avec génération de sel), et l'autre de façon faible (le MS-CHAPv2 se casse en quelques secondes). Ce problème peut être résolu par l'utilisation d'ACL au niveau du serveur d'annuaire, en autorisant que les serveurs légitimes à lire/écrire le champ radiusTunnelPassword).

Utilisation d'EAP TTLS PAP

L'autre solution est de forcer l'utilisation de mot de passe en clair lors de l'échange radius. Bien évidemment, cela peut sembler dangereux, c'est pourquoi il conviens d'utiliser les méthodes TTLS (Tunnel TLS) dans radius, qui permettent l'authentification Radius sur un tunnel chiffré (nécessite donc un certificat coté serveur). On parle donc d'EAP-TTLS-PAP. Cette solution à le gros avantage de pouvoir configurer le serveur Radius à effectuer une recherche, puis un bind auprès de l'annuaire, afin de vérifier l'identité de l'utilisateur. Plus de problèmatique de méthode de hash différentes, plus de problèmatique de synchro de mot de passe !