BasesLDAP

Un article de RotomaLUG.

Sommaire

1 Cours : Authentification centralisée avec LDAP

Cours : Authentification centralisée avec LDAP

Avancement : 10%

But de la formation

Cette première partie devrait présenter assez grossièrement l'authentification centralisée et les grands principes de LDAP.

Nous essaierons de voir comment faire pour centraliser les comptes UNIX, Samba, et de mail et utiliser cette base comme carnet d'adresse dans un petit réseau.

Nous verrons également comment gérer ces utilisateurs de façon graphique, très confortable, à partir de GOsa ou de LAM.

L'aspect de ce cours devrait être le moins théorique possible, donc pas de définition des RFCs mais une définition des besoins et une réponse simplifiée.

Pré-requis

Pour suivre ce cours, il serait bon de connaître grossièrement comment fonctionnent :

les bases de données relationnelles (au minimum);
l'authentification Linux moderne (PAM) ;
les services réseau ;
SaMBa - notions ;
Postfix - utilisation d'un serveur de messagerie local

Un mot sur l'authentification locale sur un système Linux

définition des utilisateurs
les groupes
les droits et les systèmes de fichiers
PAM

Quelles autres méthode pour centraliser les comptes ?

Présentation très grossière de la concurrence. Les raccourcis sont volontaires, merci.

NIS

NIS permet de centraliser les informations d'un système UNIX en partageant des fichiers de configuration. Il permet donc de réaliser de la résolution de noms mais aussi de centraliser les comptes utilisateurs et les groupes sous UNIX.

Ses principaux défauts sont la sécurité et le lien trop fort à l'environnement UNIX.

SaMBa / Contrôleur de domaine NT

Le contrôleur de domaine a pour but de centraliser les comptes utilisateurs, groupes et noms de machines dans un environnement Windows. Une implémentation du protocole SMB a été réalisée par la communauté SaMBa, ce qui permet aujourd'hui d'utiliser un contrôleur de domaine (PDC) Linux pour un parc de machines fonctionnant sous Windows, MacOS, Linux et d'autres UNIX.

Bases de données

Grace aux modules d'authentification, il est aujourd'hui possible de créer des bases d'utilisateurs sous des SGBD tels que MySql ou PostgreSQL. Cela demande de dessiner les bases de données et de lien le schéma de la base au système ou aux applications. Cette méthode est efficace mais moins performante que LDAP. Surtout, cette méthode n'est pas standard.

RADIUS

Kerberos

Les OTP (One Time Password)

L'étude de cas

Nous souhaitons donc gérer à partir d'une seule interface nos comptes utilisateurs clients des services SaMBa (postes windows), de messagerie (Postfix et courier-imap), Unix (ssh et shell local), proxy (SQUID), applicatif (bases de données) et profiter de cette base pour leur offrir un carnet d'adresse pour la messagerie mais également un répertoire téléphonique.

Les mots de passe chiffrés seront stockés dans l'arborescence LDAP. Nous n'utiliserons pas d'authentification forte comme avec KERBEROS ou RADIUS.

Tous les flux réseau pour les services faisant circuler les données d'authentification seront chiffrés par SSL : HTTPS, IMAPS, LDAPS. Nous utiliserons une autorité de certification interne, non officielle pour des questions de coûts.

L'arborescence devra être performante : hierarchie le plus à plat possible et les contrôles d'accès limités au maximum.

Le tout devra être facile à maintenir (sauvegardes, etc.) et à mettre à jour, même par un administrateur néophyte. Nous utiliserons donc un schéma standard et les comptes pourrons être gérés par une interface graphique (WEB de préférence). Une interface a été sélectionnée :Gosa.

Des bases sur LDAP

Introduction

Le protocole LDAP (LIGHTWEIGHT DIRECTORY ACCESS PROTOCOL c'est à dire protocole léger d'accès à un service d'annuaire) a été développé par l'université du Michigan dans le début des années 90 pour remplacer le protocole DAP utilisé pour accéder au service d'annuaire X500 reposant sur les protocoles OSI. A l'origine, il s'agissait donc d'adapter DAP sur le modèle TCP/IP et de l'alléger de façon à effectuer des requêtes sur les serveurs X500. Au fur et à mesure de son développement, LDAP est devenu un serveur d'annuaire complet et indépendant plus simple d'accès et plus facile à implémenter que X500.

Pour fournir son service d'annuaire LDAP est composé :

d'un modèle qui spécifie la façon dont les données sont organisées logiquement dans l'annuaire, c'est le modèle de données. C'est la partie la plus délicate à concevoir ;
d'un protocole d'accès aux données de l'annuaire, défini dans la partie suivante ;
d'un modèle définissant les opérations possibles sur les données de l'annuaire, c'est le modèle fonctionnel ;
d'un modèle de sécurité présentant les mécanismes d'authentification et les outils de protection des données ;
d'un format pour l'échange des données entre annuaires à travers des fichiers, LDIF ;
d'un modèle de répartition ou de duplication, définissant la façon dont les données peuvent être réparties entre serveurs ;
d'une API permettant le développement d'applications accédant à l'annuaire.

Pour des informations plus précises concernant la définition de LDAP version 3, veuillez vous reporter à la RFC 2251.

Modèle de données

Pour avoir une idée du modèle de données, il faut se représenter la façon dont les données sont organisées à partir, par exemple de ce schéma :

***FAIRE ET INSERER UN SCHEMA ***

Un arbre LDAP est constitué des points suivants :

DIT

Les données d'un annuaire LDAP sont structurées sur une arborescence hiérarchique. Cette structure est représentée par un arbre, appelé Directory Information Tree, le DIT rappelle l'organisation d'un système de fichiers. A noter que l'on peut utiliser plusieurs DIT pour un seul serveur LDAP. Autrement dit, un même serveur LDAP peut accueillir plusieurs arborescences indépendantes (donc ça nous donne plusieurs racines) ; cette solution est déconseillée.

Suffixe

La racine de l'arbre est nommée le suffixe.

Il y a plusieurs façons de nommer le suffixe. L'idée, en général, est de le référencer par rapport à la société et au pays (notation X500) ou à son nom de domaine Internet. La deuxième solution s'impose au fur et à mesure comme standard. Les noms de domaine, pays et organisation sont représentés dans LDAP par des attributs : c pour pays, o pour organisation et dc pour domain component (élément d'un nom de domaine). Ainsi, pour notre domaine faineant, les choix sont :

soit o=faineant, c=fr en notation X500 ;
soit dc=faineant, dc=fr, si l'on se place par rapport au nom de domaine.

C'est la deuxième solution que nous retiendrons ici.

DSE

Chaque noeud et chaque extrémité (feuille) de l'arbre est un objet, ce sont les DSE (Directory Service Entries). Les DSE sont identifiées de façon unique par leur Distinguished Name (DN), suffixe compris, comparable au chemin absolu d'un système de fichiers.

Les DSE sont constituées d'attributs dont certains peuvent avoir différentes valeurs.

Les DSE peuvent aussi être référencées relativement à leur parent par le RDN (Relative Distinguished Name). Le DN d'un objet est donc construit par la concaténation de son RDN et du DN de son père. Le schéma LDAP

Pour pouvoir utiliser des objets, il faut avant les déclarer et déclarer les attributs qui les définissent. C'est le but du schéma LDAP.

Le schéma définit les types d'objets qu'un annuaire peut gérer. Il est généralement défini dans un fichier à part. Les éléments du schéma sont présentés dans les paragraphes suivants. D'autre part, cette vue théorique sera complétée par la présentation de notre schéma dans les chapitres suivants.

OID

Pour assurer la compatibilité entre les logiciels, les attributs et les objets sont référencés dans la RFC2256 par un Object IDentifier (OID). Cela correspond à une suite d'entiers séparés par des points (comme par exemple 1.3.6.1.1), unique pour chaque attribut dont la liste est tenue à jour par l'Internet Assigned Numbers Authority (IANA).

Attributs

Chaque noeud ou feuille est constitué par des associations clé/valeur : les attributs. A chaque attribut correspond un type (binaire, texte, date) décrivant les caractéristiques de l'information qu'il contient. Un attribut peut contenir une valeur (mono-valué) ou plusieurs (multi-valué).

Classes d'objets

Dans LDAP une classe objet correspond à une liste d'attributs pouvant être utilisés pour définir une entrée. Le standard LDAP propose des classes objets définissant des groupes d'utilisateurs de l'annuaire, des utilisateurs, etc.

Chaque classe contient des attributs obligatoires définis par le mot clé MUST et optionnels définis par MAY. Le schéma LDAP est formé par une hiérarchie de classes objets au sommet de laquelle se trouve l'objet TOP. Chaque objet hérite des propriétés de son père.

Extension du schéma

L'extension du schéma se fait en créant de nouveaux objets, fils d'objets standard, contenant les informations qui se rapprochent le plus de l'objet souhaité auquel on ajoute de nouveaux attributs. L'idéal est de déclarer ces objets et attributs à l'IANA pour conserver l'aspect standard de l'annuaire.

Modèle fonctionnel

Le modèle fonctionnel représente le type d'opérations que l'on peut faire sur le serveur d'annuaire. Il en existe neuf dans le standard LDAP avec une possibilité d'extension.

Ces opérations sont les suivantes :

search : recherche dans l'annuaire à partir de critères ;
compare : comparaison du contenu de deux objets ;
add : ajout d'une entrée ;
modify : modification du contenu d'une entrée ;
delete : suppression d'un objet ;
rename : modification du DN d'une entrée ;
bind : connexion et authentification au serveur ;
unbind : fin de session ;
abandon : abandon d'une opération en cours.

Pour la recherche ou la comparaison, on peut envoyer une suite de paramètres dans la requête, dont le plus intéressant est le scope qui permet de préciser si l'on effectue l'opération sur un objet (scope=base), un niveau d'objets (par rapport à la hiérarchie, scope=onelevel search), ou tous les enfants de l'objet (scope=subtree).

Protocole

acteurs

Les communications LDAP passent par un mode client/serveur. Le client (Directory User Agent ou DUA) effectue des requêtes sur le serveur (Directory Service Agent ou DSA) pour accéder à l'information stockée dans la base LDAP (Directory Information Base ou DSI). Les clients peuvent se présenter sous la forme d'un navigateur WEB, d'une application, d'un service système, etc.

Ces informations passent au travers d'une connexion TCP (une version UDP est en cours de développement) sur le port 389 en standard ou 636 pour les connexions cryptées par SSL.

Session

Une session LDAP se présente de la manière suivante :

1. établissement de la connexion TCP
2. envoi d'un message d'authentification (BIND)
3. opérations (recherche, ajout, etc.)
4. possibilité de créer une nouvelle session (nouveau BIND)
5. message de fin de session (UNBIND)
6. Fermeture de la connexion TCP

Ainsi, au cours d'une session, il est possible d'effectuer plusieurs opérations (contrairement à HTTP, par exemple). D'autre part, le bind peut se présenter sous la forme d'une authentification anonyme.

Codage de l'information

Les requêtes et réponses des serveurs LDAP sont encapsulées dans des messages LDAP. Ces messages sont encodés au format ASN.1 (langage de description de syntaxe) par les règles de transfert de syntaxe BER (Basic Encoding Rules). La description du langage utilisé pour la création d'applications LDAP n'est pas le but de ce rapport, pour plus d'informations consultez « International Telecommunication Union : Open Systems Interconnection - Model and Notation - Specification of Abstract Syntax Notation One ITU-T, 1993 ».

modèle de sécurité

LDAP v3 définit les aspects suivants de la protection des données de l'annuaire : le contrôle d'accès par les ACL (Access Control List)

Le but des ACL est de définir qui a accès à quelles données et avec quel droits (lecture et écriture). La syntaxe des ACL n'est pas encore standardisée pour les différents serveurs LDAP. Vous verrez dans la partie pratique la syntaxe se rapportant aux ACL pour OpenLDAP.

l'authentification

L'authentification permet au serveur de connaître l'identité de l'utilisateur. C'est donc à partir de l'authentification que le serveur pourra déterminer les informations auxquelles l'utilisateur a accès et avec quel privilège. Il existe deux principaux types d'authentification :

l'authentification simple : dans ce cas le mot de passe circule en clair sur le réseau (au niveau de la couche application) ce qui signifie qu'un simple sniffer réseau le révélera. Un type particulier de ce mode est l'authentification anonyme où le mot de passe est vide. On peut cependant stocker un mot de passe encrypté (par hachage MD5 ou SHADOW) dans la base et utiliser ce mode.

l'authentification SASL (Simple Authentification And Security Layer) : dans ce cas, l'authentification est déléguée à un processus externe. Cette méthode utilise un mécanisme et stocke les informations d'authentification dans une base externe en utilisant ce mécanisme.

la protection de la communication

Le but de la protection de la communication est de s'assurer de l'intégrité des informations transmises, de garantir la confidentialité de la communication et de s'assurer de l'identité des opérateurs. LDAP v3 confie cette tâche au protocole SSL ou à son successeur TLS présentés en annexe.

le modèle de répartition

A propos du modèle de répartition, deux choses :

pour la réplication, les clients accèdent au serveur contenant la base répliquée en lecture seule. Ainsi, si le client demande un accès en écriture sur la base (modification, ajout ou suppression), le serveur lui envoie l'adresse du serveur maître et l'écriture se fera sur ce dernier ;
la répartition est permise par le principe de referral. Si le client émet une requête concernant une partie de l'annuaire qu'il ne gère pas, le serveur lui envoie l'adresse du serveur qui la gère.

Format d'échange

Toute opération sur l'annuaire (ajout d'une entrée, résultat d'une recherche, import de données d'un autre annuaire, ...) peut être représentée dans un langage compréhensible par l'homme à l'aide du format d'échange LDIF (pour LDAP Data Interchange Format). Un fichier LDIF stocke les informations en utilisant une représentation hiérarchique orientée objet. Une personne dans un annuaire pourrait être représentée de la façon suivante (l'exemple est tiré du LDAP-HOWTO) :

dn: o=TUDelft, c=NL
o: TUDelft
objectclass: organization
dn: cn=Luiz Malere, o=TUDelft, c=NL
cn: Luiz Malere
sn: Malere
mail: malere@yahoo.com objectclass: person

Note : LDIF permet également de représenter des modifications sur l'arbre. Vous trouverez plus d'informations sur cette possibilité dans l'annexe 1.

Liste de RFCs traitant de LDAP

RFC 2251 : Lightweight Directory Access Protocol (v3)
RFC 2252 : Lightweight Directory Access Protocol (v3): Attribute Syntax
RFC 2253 : Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names
RFC 2254 : The String Representation of LDAP Search Filters
RFC 2255 : The LDAP URL Format
RFC 2256 : A Summary of the X.500(96) User Schema for use with LDAPv3
RFC 2829 : Authentication Methods for LDAP
RFC 2830 : Lightweight Directory Access Protocol (v3): Extension for Transport Layer Security
RFC 3377 : Lightweight Directory Access Protocol (v3): Technical Specification

Autour de LDAP :

RFC 2247 : Using Domains in LDAP/X.500 Distinguished Names
RFC 2307 : An Approach for Using LDAP as a Network Information Service
RFC 2377 : Naming Plan for Internet Directory-Enabled Applications
RFC 2589 : Lightweight Directory Access Protocol (v3): Extensions for Dynamic Directory Services
RFC 2596 : Use of Language Codes in LDAP
RFC 2891 : LDAP Control Extension for Server Side Sorting of Search Results
RFC 3062 : LDAP Password Modify Extended Operation
RFC 3112 : LDAP Authentication Password Schema
RFC 2044 : UTF-8, a transformation format of Unicode and ISO 10646
RFC 2849 : The LDAP Data Interchange Format (LDIF) - Technical Specification
RFC 3384 : LDAPv3 Replication Requirements

Attributs et schéma nécessaires

La brève définition des besoins nous permet d'identifier grosso-modo les attributs nécessaires et de commencer à envisager l'arborescence.

liste des attributs

Attention : cette liste est outrageusement copiée à partir du SMBLDAP-HOWTO de Idealx

- - A INSERER ET METTRE EN FORME, PFFFFFFFFFF ***

drois d'accès aux attributs

objets utilisés

le schéma de notre annuaire

hierarchisation de notre modèle

D'après notre étude de besoins, voici les objets que nous définissons :

Les utilisateurs : contient tous les attributs nécessaires à l'authentification des services SAMBA, SMTP et UNIX.

Les groupes : correspondent aux groupes utilisateurs pour SAMBA, la messagerie, et Unix (attention, ça part moyen mon truc, à éclaircir ***)

Les machines : comptes machines samba (??? pas sûr), ou hôtes au sens DNS, je voudrais voir aussi si on peut relier ça à OCSInventory Manager.

domaines : les domaines SAMBA (un seul chez moi)

Suffixe (ou racine de l'annuaire) :

                                   dc=monentreprise,dc=fr
                                                |
                                                |
                   --------------------------------------------------------------
                   |               |                            |               |
                   |               |                            |               |
              Utilisateurs      Groupes                       Machines       Domaines
              ou = People     ou = Groups                    ou = hosts    ou = domains

Récupérée de « http://wiki.rotomalug.org/index.php/BasesLDAP »