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 :

• Chaîne de caractère (IA5DirectoryString)
• Date (timestamp)

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 :

• Les OIDs créés doivent être unique
• Les OIDs doivent s'intégrer dans l'arborescence des OIDs maintenue et gérée par le IANA

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

• Un document décrivant les bonnes pratiques pour construire un DIT
• Des contributions de la société Linagora sur les annuaires LDAP, incluant des formations, des scripts pour OpenLDAP et d'autres ressources
• Scripts d'administration LDAP, extensions monitoring LDAP, packaging OpenLDAP

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 :

• posixAccount
• shadowAccount (optionel, nécessaire si vous désirez utiliser les extensions shadow)
• posixGroup

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.