1196 lines
43 KiB
TeX
1196 lines
43 KiB
TeX
\chapter{Les annuaires}
|
|
~\\
|
|
\section{Les services d'annuaire en général}
|
|
~\\
|
|
|
|
\subsection{Définitions}
|
|
|
|
\begin{itemize}
|
|
\item{\textbf{Annuaire}} :Définition (Larousse) : \textsc{Annuaire n.m. (lat. annuus, annuel). Ouvrage publié chaque année, donnant la liste des membres
|
|
d'une profession, des abonnés à un service, etc. Annuaire du téléphone.}\\
|
|
Exemples : Annuaire téléphonique (pages jaunes, pages blanches), Guide Michelin (guide rouge, etc.),
|
|
|
|
\item{\textbf{Annuaire électronique}}: Définition : \textsc{ Possibilité de mise-à-jour directement pour la consultation en ligne.}\\
|
|
Exemples : pagesjaunes.fr, DMOZ (Open Directory Project), Listes des utilisateurs sur un ordinateur (fichier /etc/passwd sous Unix)
|
|
|
|
\item{\textbf{Service d'annuaire}}: Définition : \textsc{ Service réseau, Architecture client/serveur}\\
|
|
Exemples : Annuaire des développeurs Debian, Annuaires dans les universités françaises,
|
|
\end{itemize}
|
|
|
|
~\\
|
|
Note : en anglais, annuaire se dit "directory".
|
|
|
|
|
|
%\subsection{Annuaires distribués}
|
|
|
|
%Dans les cas où l'on doit stocker une grande quantité d'informations, une base centralisée est non raisonable.
|
|
%TODO
|
|
%éviter la duplication des données
|
|
%Répartition en fonction du temps de réponse => accès simple et rapide
|
|
|
|
%\textit{Exemples : état civil, Annuaire distribué des adresses de l'Internet (DNS)}
|
|
|
|
|
|
\subsection{Exemples}
|
|
|
|
%Mettre des schémas DNS (voir Oreilly Bind) :
|
|
%Déléguation d'autorité
|
|
|
|
\subsubsection{DNS}
|
|
|
|
Le service DNS (Domain Name System) permet la conversion de noms de domaine en adresses IP (et inversement). On parlera de "nom pleinement qualifié" pour désigner un nom de domaine complet (typiquement sousdomaine.domaine.tld).\\
|
|
Il est plus facile pour l'être humain de retenir des noms que des numéros : il a donc été décidé d'associer des noms de domaine aux adresses IP. Au départ, un simple fichier HOSTS.TXT rassemblait les correspondances entre les adresses IP et les noms. Mais rapidement, ce système est devenu ingérable et il fut décidé d'opter pour une base de données distribuées en arbre (similaire au système de fichier UNIX) : la racine est gérée par l'ICANN\footnote{\url{http://www.icann.org/}} et les sous-domaines de la racine (TLD) sont délégués à des organismes : par exemple, chaque pays se voit confier un TLD (fr pour la France, us pour les États-Unis, uk pour la Grande-Bretagne, etc.). Ces organismes permettent ensuite à certaines sociétés, sous certaines conditions, de revendre des sous-domaines. À chaque sous-domaine acheté est associé un ou plusieurs serveurs DNS maître. Il est conseillé d'utiliser un serveur maître primaire et un serveur maître secondaire (ou serveur esclave) qui se synchronise sur le serveur primaire.\\
|
|
|
|
\textbf{Serveur DNS}\\
|
|
Un serveur DNS est (souvent) maître pour un certain nombre de noms de domaines, c'est-à-dire qu'il a autorité sur plusieurs zones. Il peut ainsi résoudre un certains nombres de demandes (il contient les informations grâce à des fichiers) ou déléguer des sous-zones à d'autres serveurs de domaine. Le serveur répond donc aux requêtes où il a autorité (en répondant directement ou en redirigeant vers le serveur ayant autorité) ou bien se redirige vers un serveur "racine" capable lui-même de rediriger vers les serveurs appropriés.\\
|
|
Au niveau réseau, un serveur DNS écoute sur le port 53 en TCP et UDP.\\
|
|
|
|
\textbf{Resolvers DNS}\\
|
|
Un résolver, ou client DNS, peut formuler deux types de demandes à un serveur DNS~:
|
|
|
|
\begin{itemize}
|
|
\item{les demandes en mode récursif} qui demandent une résolution complète au serveur DNS, l'obligeant à faire lui-même les requêtes pour apporter la réponse
|
|
\item{les demandes en mode itératif} qui demandent une réponse sans générer de requête de la part du serveur (sera donc sovent redirigé vers un serveur racine ou délégué)
|
|
\end{itemize}
|
|
|
|
\textit{Exemple de résolution "classique"}\\
|
|
Le résolveur adresse une requête en mode récursif : le serveur local envoie une requête en mode itératif à un serveur de nom faisant autorité sur la demande. Il essaiera le serveur le plus à même de répondre. Dans le pire des cas il contactera un serveur "racine" et suivra les références jusqu'à obtenir une réponse complète (généralement par le serveur de nom s'occupant du réseau où se trouve la machine).\\
|
|
Une fois la réponse trouvée, le serveur local envoie la réponse au résolveur.\\
|
|
Attention, il faut noter que les applications ou les systèmes ont souvent leur propre cache DNS.\\
|
|
~\\
|
|
\textit{Types d'enregistrement}\\
|
|
Bien que le principal but soit de convertir un nom de domaine en adresse IP, il existe différents types d'enregistrement au niveau d'un serveur DNS. L'enregistrement principal est l'enregistrement A qui associe directement un nom de domaine à une adresse IP mais il enexiste d'autres : l'enregistrement CNAME (qui lie un nom de domaine vers un autre nom de domaine), MX (qui permet de spécifier plusieurs serveurs SMTP avec différentes priorités), NS (qui spécifie les serveurs de noms), TXT (qui permet d'avoir un champ texte), PTR (pour les enregistrements invers), etc. Il existe également des enregistrements pour IPv6 où il faut à priori utiliser les enregistrements AAAA (il peut exister également des enregistrements A6).\\
|
|
~\\
|
|
\textit{Résolution inverse}\\
|
|
La résolution d'une adresse en nom n'est pas triviale car le processus de résolution devrait connaître à peu près toutes les branches de l'arbre pour pouvoir répondre, (sans compter que plusieurs noms pointent souvent vers la même adresse). L'idée a donc été de développée un sous-domaine pour les adresses. Ce sous-domaine est in-addr.arpa et peut contenir toutes les adresse IP existantes (elles sont inversées afin de partir des feuilles jusqu'à la racine). Ainsi, pour qu'une adresse IP fasse l'objet d'une résolution inverse, elle doit avoir un enregistrement dans ce sous-domaine.\\
|
|
~\\
|
|
\textbf{Mémoire cache et durée de vie}\\
|
|
En plus des différents mécanismes de résolution, l'utilisation d'une mémoire-cache accélère efficacement ces résolutions. En effet, lorsqu'un serveur de nom effectue une requête récursive il obtient de nombreuses informations (résolutions complètes, serveurs faisant autorité, etc.). Il va donc stocker ces informations afin de pouvoir répondre plus rapidement à de prochaines requêtes utilisant ces informations, et ainsi éviter d'interroger de nouveau les serveurs concernés. Il conserve en fait ces données pendant un temps fixé par le serveur DNS où il a été cherché ses données. Les serveurs DNS ayant des données qui varient fréquemment adapteront donc cette durée appelée TTL (Time To Live).\\
|
|
~\\
|
|
|
|
\textit{Les outils}\\
|
|
L'outil "historique" pour provoquer une résolution DNS est \textit{nsloookup}.
|
|
Sous Unix, on trouvera les outils \textit{host} et \textit{dig}.\\
|
|
~\\
|
|
Exemple d'une requête avec dig~:\\
|
|
|
|
\begin{verbatim}
|
|
$ dig @192.168.1.4 cmi.univ-mrs.fr +norecurse +notcp \
|
|
+noquestion +noauthority +noadditional MX
|
|
|
|
; <<>> DiG 9.3.1 <<>> @192.168.1.4 cmi.univ-mrs.fr
|
|
+norecurse +notcp +noquestion +noauthority +noadditional MX
|
|
; (1 server found)
|
|
;; global options: printcmd
|
|
;; Got answer:
|
|
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4914
|
|
;; flags: qr ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 2
|
|
|
|
;; ANSWER section:
|
|
cmi.univ-mrs.fr. 86236 IN MX 10 gyptis.univ-mrs.fr.
|
|
|
|
;; Query time: 6 msec
|
|
;; SERVER: 192.168.1.4#53(192.168.1.4)
|
|
;; WHEN: Sun Nov 6 19:56:15 2005
|
|
;; MSG SIZE rcvd: 157
|
|
|
|
\end{verbatim}
|
|
|
|
|
|
\subsubsection{Arborescence des systèmes de fichiers Unix}
|
|
|
|
schémas avec /bin, /boot, /etc, /usr, /var, etc.
|
|
|
|
Avantages de la répartition en répertoires :
|
|
- Nombre de fichiers limités par répertoires
|
|
- Performance (accès plus rapide, recherche optimisée, etc.)
|
|
|
|
\subsubsection{Gestion des utilisateurs}
|
|
|
|
On peut voir les fichiers qui stocke les utilisateurs et des renseignements
|
|
sur eux (et même leurs mots de passe) comme un annuaire~:
|
|
|
|
Extrait d'un fichier /etc/passwd~:
|
|
|
|
\begin{verbatim}
|
|
root:x:0:0:root:/root:/bin/bash
|
|
daemon:x:1:1:daemon:/usr/sbin:/bin/sh
|
|
bin:x:2:2:bin:/bin:/bin/sh
|
|
sys:x:3:3:sys:/dev:/bin/sh
|
|
\end{verbatim}
|
|
|
|
NIS/NIS+ est un service standard Unix qui permet de partager
|
|
des fichiers/annuaires pour toutes les machines d'un réseau :
|
|
|
|
\begin{verbatim}
|
|
/etc/passwd
|
|
/etc/group
|
|
/etc/hosts
|
|
/etc/aliases
|
|
/etc/protocols
|
|
/etc/services
|
|
\end{verbatim}
|
|
|
|
LDAP/Active Directory
|
|
|
|
|
|
\section{Protocole LDAP}
|
|
|
|
\subsection{Historique}
|
|
|
|
X.500, standard promulgué par l'OSI\footnote{International Organization for Standardization} et l'ITU-T\footnote{International Telecommunication Union-Telecommunication Standardization Sector}, définit :
|
|
|
|
- DAP (Directory Access protocol) : protocole de communication DUA<->DSA
|
|
- DSP (Directory System Protocol) : protocole de communication entre DSAs
|
|
- DISP (Directory Information Shadowing Protocol) : protocole de synchronisation/réplication entre DSAs
|
|
- DOP (Directory Operational Bindings Management Protocol) : protocole de gestion de liaison opérationnelle d'annuaire
|
|
|
|
|
|
DIB (Directory Information Base) : objets, classes d'objet, OID
|
|
DIT (Directory Information Tree) : noeud, feuille, alias, DN, RDN,
|
|
Modèles clients (DUA) / serveurs (DSA) : connexion, opération, réplication, droits, authentification
|
|
|
|
|
|
% Schémas d'après http://www.sysium.com/ldap.html
|
|
% http://sec.cs.kent.ac.uk/x500book/
|
|
|
|
Ces protocoles standards et ouverts ont été normalisés au début des années 1990.
|
|
S'appuyant sur des couches réseaux aujourd'hui peu répandues (modèle OSI), on
|
|
ne retrouve directement ces protocoles que dans des applications spécifiques
|
|
(armée, gouvernement, etc.). Néanmoins, ces protocoles ont posés les fondements
|
|
de toutes les applications d'annuaires modernes.
|
|
|
|
|
|
LDAP est dérivé du protocole DAP X.500, c'est-à-dire le protocole de communication entre un DUA et DSA.
|
|
Il s'agit d'une version simplifiée (d'où l'appelation "Light") principalement tirée du fait
|
|
qu'elle s'appuye sur la couche réseau TCP/IP, version simplifiée et répandue du modèle réseau d'OSI.
|
|
C'est l'IETF (Internet Engineering Task Force) qui centralise les travaux sur LDAP et publie les
|
|
spécifications dans des RFCs. La dernière version de LDAP est la version 3.
|
|
|
|
|
|
\subsection{Vocabulaire}
|
|
|
|
\textbf{Schéma}\\
|
|
Un schéma est une définition de classes d'objets, d'attributs et leur syntaxe. Chaque serveur utilisant un schéma spécifique ou des extensions doit l'enregistrer notamment pour obtenir un OID.\\
|
|
|
|
Exemple de définition d'attributs~:
|
|
|
|
\begin{verbatim}
|
|
attributetype ( 1.3.6.1.4.1.18413.21.3.10 NAME 'postfixTransport'
|
|
DESC 'transport for Postfix'
|
|
EQUALITY caseExactIA5Match
|
|
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{20} SINGLE-VALUE )
|
|
|
|
attributetype ( 1.3.6.1.4.1.18413.21.3.20 NAME 'isActive'
|
|
DESC 'an account is active or not'
|
|
EQUALITY booleanMatch
|
|
SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE )
|
|
\end{verbatim}
|
|
|
|
SYNTAX (1.3.6.1.4.1.1466.115.121.1.x)~:
|
|
|
|
\begin{verbatim}
|
|
7 = Boolean
|
|
8 = Certificat
|
|
15 = Directory String
|
|
26 = IA5 String
|
|
27 = INTEGER
|
|
50 = Telephone Number
|
|
\end{verbatim}
|
|
|
|
EQUALITY :
|
|
|
|
\begin{verbatim}
|
|
telephoneNumberMatch
|
|
integerMatch
|
|
booleanMatch
|
|
caseExactIA5Match
|
|
caseIgnoreIA5Match
|
|
\end{verbatim}
|
|
|
|
|
|
\textit{Liens~:}\\
|
|
\url{http://www.openldap.org/doc/admin22/schema.html}\\
|
|
\url{http://www.iana.org/cgi-bin/enterprise.pl}\\
|
|
\url{http://www.rfc-editor.org/rfc/rfc2252.txt}\\
|
|
|
|
EQUALITY type
|
|
SYNTAX type
|
|
|
|
\textbf{Objectclass}\\
|
|
Les classes d'objet, définies dans un schéma par un nom et OID (Object IDentifier), modélisent des objets définissant un certain nombres d'attributs obligatoires ou facultatifs. Elles peuvent être de plusieurs types~:\\
|
|
- structurelle çad correspondant à la description d'objets basiques~: personnes, groupes, etc.
|
|
- auxiliaire càd correspondant à des informations complémentaires à des objets de classe "structure"
|
|
- abstraite càd désignant des objets basiques de LDAP comme 'top' ou 'alias'
|
|
|
|
Les ObjectClass forment une hiérarchie. Prenons l'exemple de la classe d'objet "person" : elle est définie en tant que "SUP top STRUCTURAL", c'est à dire que c'est une classe structurelle en dessous de la classe abstraite 'top'. L'ObjectClass 'top' est toujours tout en haut. En pratique, il n'est pas nécessaire de le préciser mais il sera toujours là (même si il n'apparait pas). Les classes abstraites sont implicitement là~!\\
|
|
|
|
\textbf{OID (Object IDentifier)}\\
|
|
Un OID est une séquence de nombres entiers séparés par des points normalisée dans la RFC 2256. L'OID doit être unique afin de permettre une compatibilité entre les applications. C'est l'IANA\footnote{Internet Assigned Numbers Authority} qui est responsable de leur attribution et chaque entreprise peut obtenir un OID.\\
|
|
|
|
\textit{Lien~:} \url{http://www.isi.edu/cgi-bin/iana/enterprise.pl}\\
|
|
|
|
\textbf{attribut}\\
|
|
Les attributs, définis dans un schéma, sont rattachés à une classe d'objet. Un attribut définit une certaine syntaxe et des contraintes pour des données~: on peut rapprocher l'attribut LDAP du type de données d'une base de données.\\
|
|
|
|
\textbf{entrée (ou objet)}\\
|
|
Il s'agit d'un ensemble de données entrées formant un noeud dans l'arbre. Elle est définit de manière unique par un DN. Elle contient un ou plusieurs attributs. Une donnée est rattachée à un attribut. On peut avoir plusieurs valeurs pour un attribut.\\
|
|
|
|
un objet doit être identifié de manière unique
|
|
son adresse permet de retrouver l'objet
|
|
un objet peut avoir plusieurs noms
|
|
|
|
|
|
\textbf{DN (Distinguish Name)}\\
|
|
Le DN est une suite de valeurs (\textit{code = valeur}, où \textit{code} est l'un des attributs de l'entrée et \textit{valeur} est la valeur associée à l'attribut dans l'entrée) séparées par des virgules. L'ordre est important : on remonte l'arbre (le suffixe se trouve donc à gauche). Le DN définit une entrée unique pour un annuaire LDAP. Exemple~: \textit{cn=Manager,dc=evolix,dc=net}\\
|
|
|
|
\textbf{RDN (Relative DN)}\\
|
|
|
|
|
|
%(on remonte vers le suffixe)
|
|
|
|
\textbf{suffixe}\\
|
|
Il s'agit du DN du domaine. Il est souvent calqué sur un nom de domaine appartenant à la structure. Exemple : \textit{dc=evolix,dc=net}\\
|
|
|
|
\textbf{CN (Common Name)}\\
|
|
Il s'agit simplement d'un attribut (obligatoire) appartenant à la classe d'objet person. Il est souvent utilisé comme premier code dans le DN d'une entrée correspiondant à une personne. Mais l'on peut tout aussi bien utiliser un autre attribut (uid est également souvent utilisé).\\
|
|
|
|
|
|
DIT
|
|
Un DSA est un serveur de l'architecture LDAP/X.500
|
|
Un DUA est un client LDAP/X.500
|
|
|
|
|
|
\subsection{Protocole d'accès}
|
|
|
|
Capture de trame LDAP
|
|
|
|
Commentaires sur le protocole.
|
|
|
|
|
|
\subsection{RFCs à propos de LDAP}
|
|
|
|
RFC 1777 : LDAPv2
|
|
RFC 2251 : LDAPv3
|
|
|
|
RFC 2252 : syntaxe des attributs
|
|
RFC 2254 : filtres de recherche LDAP
|
|
RFC 2255 : format des URLs LDAP
|
|
|
|
|
|
\subsection{Principes des schémas LDAP}
|
|
|
|
attributs
|
|
Syntaxe attributs
|
|
Classes d'objects
|
|
Arborescence des classes d'objet
|
|
|
|
|
|
\subsection{Format LDIF}
|
|
|
|
Ldap Data Interchange Format
|
|
|
|
RFC 2849
|
|
|
|
Représentation sous forme de fichier texte des données
|
|
présentes dans un annuaire.
|
|
|
|
Syntaxe pour gérer des ajouts, modifications, suppressions.
|
|
|
|
|
|
|
|
\subsubsection{Les modèles LDAP}
|
|
|
|
modèle = services offerts par un serveur LDAP
|
|
|
|
La RFC 2251 définit deux modèles :
|
|
|
|
\subsubsection{Modèle protocole}
|
|
\subsubsection{Modèle données}
|
|
|
|
Néanmoins, certains ouvrages présentent quatres modèles :
|
|
|
|
\subsubsection{Modèle d'information}
|
|
\subsubsection{Modèle de nommage}
|
|
\subsubsection{Modèle fonctionnel}
|
|
\subsubsection{Modèle de sécurité}
|
|
|
|
|
|
\subsection{Annuaires LDAP vs Bases de données}
|
|
|
|
\subsubsection{Accès en lecture (consultation)}
|
|
|
|
|
|
\subsubsection{Modèle hiérachique (arborescence)}
|
|
|
|
Pour stocker un grand nombre de données et pouvoir y accéder de façon optimisée,
|
|
il faut séparer les données. Les séparer dans plusieurs branches du même niveau
|
|
revient à les répartir dans différentes tables. Mais si l'on prend en considération
|
|
que le nombre de branches est important, il devient nécessaire d'également séparer ces
|
|
branches. On entre donc dans un modèle hierarchique impossible à avoir avec une base
|
|
de données classique (pas de hiérarchie entre les tables).
|
|
|
|
|
|
\subsubsection{Possibilité d'une modèle distribué}
|
|
|
|
|
|
\subsubsection{Sécurité (authentification, gestion des droits)}
|
|
|
|
|
|
\subsubsection{Orientée objet}
|
|
|
|
|
|
\subsubsection{etc.}
|
|
|
|
|
|
\subsection{Vue du marché LDAP}
|
|
|
|
\subsubsection{Logiciels serveurs LDAP}
|
|
|
|
OpenLDAP
|
|
|
|
|
|
MS Active Directory
|
|
|
|
% http://mi.cnrs-orleans.fr/Security/Win2k/ActiveDirectory/ActiveDirectory1.htm
|
|
|
|
Novell eDirectory
|
|
|
|
etc.
|
|
|
|
\subsubsection{Logiciels compatibles LDAP}
|
|
|
|
Microsoft Outlook
|
|
|
|
|
|
Apache
|
|
|
|
|
|
ProFTPD
|
|
|
|
|
|
Applications WEB
|
|
|
|
\subsubsection{Logiciels clients LDAP}
|
|
|
|
Il existe plusieurs logiciels clients pour visualiser, insérer, modifier, supprimer, etc. des données issues d'un annuaire LDAP~:
|
|
|
|
\begin{itemize}
|
|
|
|
\item \textbf{LDAP Browser/Editor} logiciel graphique en Java permettant
|
|
de visualiser, modifier et rechercher aisément. Import et export au
|
|
format LDIF sont pratiques.\\
|
|
\textit{Lien~:} \url{http://www-unix.mcs.anl.gov/~gawor/ldap/}
|
|
|
|
\item \textbf{PhpLDAPadmin} interface web en PHP permettant d'effectuer de nombreuses opérations aisément.\\
|
|
\textit{Lien~:} \url{http://phpldapadmin.sourceforge.net/}
|
|
|
|
\end{itemize}
|
|
|
|
Voir aussi les clients proprios (notam. Microsoft)
|
|
|
|
|
|
\section{Champs d'applications des annuaires LDAP}
|
|
|
|
\subsection{Service d'authentification}
|
|
|
|
\subsubsection{L'authentification avec LDAP}
|
|
|
|
simple\_bind
|
|
simple\_bind\_s
|
|
|
|
\subsubsection{Utilisation dans un logiciel}
|
|
|
|
|
|
|
|
\subsubsection{Exemple avec Windows/Active Directory}
|
|
|
|
|
|
|
|
\subsubsection{Exemple avec Linux/libnss}
|
|
|
|
|
|
|
|
\subsubsection{Exemple avec Apache}
|
|
|
|
|
|
\subsubsection{Autres exemples}
|
|
|
|
|
|
|
|
\subsubsection{Utilisation avec SASL}
|
|
|
|
|
|
|
|
\subsubsection{Un pas vers la SSO}
|
|
|
|
|
|
|
|
|
|
\subsection{Service de stockage d'informations}
|
|
|
|
\subsubsection{Informations stockées avec LDAP}
|
|
|
|
\subsubsection{Utilisation dans un logiciel}
|
|
|
|
\subsubsection{Stockage de profils}
|
|
|
|
\subsubsection{Contrôle d'accès aux données}
|
|
|
|
\subsubsection{Exemple avec un carnet d'adresses}
|
|
|
|
\subsubsection{LDAP et les langages de programmation}
|
|
|
|
|
|
|
|
|
|
%\section{Méta-annuaire LDAP}
|
|
%Annuaire d'annuaire
|
|
|
|
\section{Architecture et mise en place}
|
|
|
|
%http://www.sysium.com/fr/offres-ldap/annuaire-ldap/demarche-ldap.html
|
|
|
|
\subsection{Concevoir un cahier des charges}
|
|
|
|
Respect des conventions
|
|
Lister applications
|
|
Lister contenu
|
|
|
|
\subsubsection{Audit de l'existant}
|
|
|
|
\subsubsection{Expression des besoins}
|
|
|
|
\subsubsection{Définition du contenu et architecture}
|
|
|
|
\subsubsection{Choix techniques}
|
|
|
|
\subsubsection{Ajout de schémas personnalisés}
|
|
|
|
Applications clients
|
|
Utiliser schémas existants
|
|
Étendre ou ajouter des schémas
|
|
|
|
\subsubsection{Politique de sécurité}
|
|
|
|
ACLs
|
|
|
|
\subsubsection{Test et recette}
|
|
|
|
Vérifications
|
|
Benchmarks
|
|
|
|
|
|
\subsection{Utilisation et administration}
|
|
|
|
\subsubsection{Gestion des données}
|
|
|
|
\subsubsection{Logiciels client LDAP}
|
|
|
|
\subsubsection{Import/export données}
|
|
|
|
\subsubsection{Utilisation avec SSL/TLS}
|
|
|
|
\subsubsection{Réplication}
|
|
|
|
\subsubsection{Sauvegarde}
|
|
|
|
|
|
\section{Application pratique}
|
|
|
|
|
|
\subsection{Mise en place d'un annuaire LDAP}
|
|
|
|
\subsubsection{Installation}
|
|
|
|
\subsubsection{Configuration}
|
|
|
|
\subsubsection{Gestion des droits}
|
|
|
|
\subsubsection{Installation des schémas}
|
|
|
|
\subsubsection{Sécurité}
|
|
|
|
|
|
\subsection{Utilisation d'un annuaire LDAP}
|
|
|
|
\subsubsection{Installation des outils nécessaires}
|
|
|
|
\subsubsection{Configuration}
|
|
|
|
\subsubsection{Écriture des fichiers au format LDIF}
|
|
|
|
\subsubsection{Ajout/modification/suppression données}
|
|
|
|
\subsubsection{Recherche de données}
|
|
|
|
%\subsection{Utilisation avec TLS}
|
|
|
|
\subsubsection{Focus sur l'authentification LDAP}
|
|
|
|
\newpage
|
|
\section{OpenLDAP}
|
|
~\\
|
|
\subsection{Présentation}
|
|
~\\
|
|
LDAP (Lightweight Directory Access Protocol) est un protocole pour accéder à un service d'annuaire. Les annuaires permettent de partager des informations, telles que des coordonnées d'entités ou personnes ou encore des données système. Un annuaire est une base de données spécifique structurée dans une arborescence hiérarchique. Un annuaire est censé être largement plus performant en consultation qu'un système de gestion de bases de données classique. LDAP peut servir d'annuaire pour gérer des coordonnées, pour servir des applications (SMTP, Groupware, etc.) ou pour gérer l'authentification (UNIX, Apache, IMAP, etc.)\\
|
|
~\\
|
|
\textit{Liens~:}\\
|
|
|
|
\url{http://www-sop.inria.fr/semir/personnel/Laurent.Mirtain/ldap-livre.html}\\
|
|
\url{http://www.cru.fr/ldap/}\\
|
|
\url{http://www.quesaco.org/astuces.php?targt=ldap}\\
|
|
\url{http://www.fefe.de/tinyldap/}\\
|
|
\url{http://www.commentcamarche.net/ldap/}\\
|
|
\url{http://www.lifl.fr/~boulet/formation/syst-dist/exposes2003-2004/ldap/}\\
|
|
|
|
http://www.computerbooksonline.com/chapters/ldapchap.htm
|
|
http://www.editions-eyrolles.com/Livre/9782212115048/annuaires-ldap
|
|
http://yolinux.com/TUTORIALS/LinuxTutorialLDAP.html
|
|
|
|
\subsection{Installation}
|
|
|
|
\subsubsection{À partir des sources}
|
|
~\\
|
|
|
|
On peut utiliser la méthode classique de recompilation à partir des sources~:
|
|
|
|
\begin{verbatim}
|
|
$ ./configure [options]
|
|
$ make depend
|
|
$ make
|
|
# make install
|
|
\end{verbatim}
|
|
|
|
\subsubsection{Par paquets}
|
|
~\\
|
|
|
|
Sous Debian, les paquets principaux à installer sont~:
|
|
~\\
|
|
\textbf{slapd} : serveur OpenLDAP\\
|
|
\textbf{libldap} : librairies OpenLDAP\\
|
|
\textbf{ldap-utils} : outils OpenLDAP\\
|
|
~\\
|
|
|
|
\emph{Dépendances Debian~:}
|
|
\begin{center}
|
|
\begin{tabular}{|c|c|}
|
|
\hline
|
|
libc6 :& librairies "GNU C"\\
|
|
\hline
|
|
libdb4.2 :& librairies "Berkeley v4.2 Database"\\
|
|
\hline
|
|
libgcrypt11 :& librairies cryptographiques LGPL\\
|
|
\hline
|
|
libgnutls11 :& librairies GNU TLS\\
|
|
\hline
|
|
libgpg-error0 :& librairie pour erreurs/messages composants GnuPG\\
|
|
\hline
|
|
libiodbc2 :& gestion pilote iODBC\\
|
|
\hline
|
|
libltdl3 :& librairie libltdl (wrapper dlopen pour GNU libtool)\\
|
|
\hline
|
|
libsasl2 :& librairies SASL v2\\
|
|
\hline
|
|
libslp1 :& librairies OpenSLP\\
|
|
\hline
|
|
libwrap0 :& librairies TCP wrapper de Wietse Venema\\
|
|
\hline
|
|
zlib1g :& librairies de compression gzip\\
|
|
\hline
|
|
perl :& fameux language interprêté de Larry Wall\\
|
|
\hline
|
|
\end{tabular}
|
|
\end{center}
|
|
~\\
|
|
|
|
|
|
|
|
\subsection{Configuration}
|
|
~\\
|
|
Le répertoire \textit{/etc/ldap/schema/} contient les schémas LDAP disponibles.\\
|
|
~\\
|
|
Certains schémas sont présents par défaut.\\
|
|
Il est aussi possible d'en ajouter ou d'en définir manuellement.\\
|
|
~\\
|
|
\textit{Lien~:} \url{http://www.openldap.org/doc/admin22/schema.html}\\
|
|
~\\
|
|
\texttt{ldap.conf} est le fichier de configuration pour toutes les applications clientes faisant appel aux bibliothèques OpenLDAP (dans le paquet Debian libldap2). Parmi celles-ci se trouvent, non exhaustivement, Sendmail, Pine, Balsa, Evolution, Gnome Meeting, etc. Voici un exemple de ce fichier~:\\
|
|
|
|
\begin{verbatim}
|
|
BASE dc=evolix,dc=net
|
|
URI 127.0.0.1
|
|
\end{verbatim}
|
|
~\\
|
|
\texttt{slapd.conf} est le fichier de configuration pour le démon slapd~:\\
|
|
|
|
\begin{verbatim}
|
|
#modules
|
|
modulepath /usr/lib/ldap
|
|
moduleload back_bdb
|
|
backend bdb
|
|
|
|
#schemas
|
|
include /etc/ldap/schema/core.schema
|
|
include /etc/ldap/schema/cosine.schema
|
|
include /etc/ldap/schema/nis.schema
|
|
include /etc/ldap/schema/inetorgperson.schema
|
|
include /etc/ldap/schema/misc.schema
|
|
|
|
#options
|
|
schemacheck on
|
|
pidfile /var/run/slapd.pid
|
|
argsfile /var/run/slapd.args
|
|
replogfile /var/lib/ldap/replog
|
|
loglevel 0
|
|
|
|
#base
|
|
database bdb
|
|
suffix "dc=evolix,dc=net"
|
|
directory "/var/lib/ldap"
|
|
index objectClass eq
|
|
lastmod on
|
|
|
|
\end{verbatim}
|
|
|
|
|
|
Les données LDAP sont dans le répertoire \texttt{/var/lib/ldap/} sous Debian~:\\
|
|
|
|
\begin{verbatim}
|
|
# ls /var/lib/ldap/
|
|
__db.001 __db.003 __db.005 dn2id.bdb log.0000000001
|
|
__db.002 __db.004 DB_CONFIG id2entry.bdb objectClass.bdb
|
|
\end{verbatim}
|
|
|
|
|
|
\subsection{Gestion des droits}
|
|
|
|
Pour gérer les droits d'accès à l'annuaire LDAP, on écrit des règles dites ACL (Access Control List) dans le fichier de configuration pour le démon slapd \textit{slapd.conf}. Voici un exemple~:\\
|
|
\begin{verbatim}
|
|
access to attribute=userPassword
|
|
by dn="cn=admin3,dc=evolix,dc=net" write
|
|
by anonymous auth
|
|
by self write
|
|
by * none
|
|
|
|
access to dn.children="ou=Clients,dc=evolix,dc=net"
|
|
by dn.regex="cn=admin,ou=Clients,dc=evolix,dc=net" write
|
|
by dn.children="ou=People,dc=evolix,dc=net" write
|
|
by users none
|
|
by * none
|
|
|
|
access to *
|
|
by dn.regex="cn=admin,dc=evolix,dc=net" write
|
|
by users read
|
|
by * none
|
|
|
|
# Administrateur "en dur" (voir slappasswd)
|
|
rootdn "cn=admin2,dc=evolix,dc=net"
|
|
rootpw {SSHA}ez1NjoyNPknjuKrORzXpem16h/tGgee7
|
|
\end{verbatim}
|
|
|
|
Remarquons qu'on peut utiliser un administrateur "en dur" (\texttt{rootdn} dans le fichier \texttt{slapd.conf}) qui aura alors un accès à toutes les ressources (les lignes lui attribuant des droits sont inutiles). Mais on peut tout à fait utiliser un utilisateur LDAP classique~!
|
|
~\\
|
|
Pour écrire des règles ACL, on précise donc une entité LDAP et ensuite on précise des droits pour des entités LDAP~:
|
|
|
|
\begin{verbatim}
|
|
access to dn.<scope-style>=<DN> attrs=[attributs]
|
|
by <entité LDAP> <droit LDAP>
|
|
\end{verbatim}
|
|
|
|
Lorsque l'on fait une opération sur une certaine entité de l'annuaire LDAP, les droits sont déterminés par le premier entité LDAP rencontré. Ainsi, on précisera toujours les droits par défaut à la fin.\\
|
|
~\\
|
|
|
|
Exemple typique d'une règle ACL~:
|
|
|
|
\begin{verbatim}
|
|
access to dn.children="ou=Clients,dc=evolix,dc=net" attrs=telephoneNumber
|
|
by dn.regex="cn=admin,ou=Clients,dc=evolix,dc=net" write
|
|
by dn.children="ou=People,dc=evolix,dc=net" write
|
|
by users read
|
|
by * none
|
|
\end{verbatim}
|
|
|
|
Droits LDAP~:
|
|
|
|
\begin{verbatim}
|
|
none =0 no access
|
|
auth =x needed to bind
|
|
compare =cx needed to compare
|
|
search =scx needed to apply search filters
|
|
read =rscx needed to read search results
|
|
write =wrscx needed to modify/rename
|
|
\end{verbatim}
|
|
|
|
Entités LDAP~:
|
|
|
|
\begin{verbatim}
|
|
* All, including anonymous and authenticated users
|
|
anonymous Anonymous (non-authenticated) users
|
|
users Authenticated users
|
|
self User associated with target entry
|
|
dn[.<basic-style>]=<regex> Users matching a regular expression
|
|
dn.<scope-style>=<DN> Users within scope of a DN
|
|
\end{verbatim}
|
|
|
|
\begin{verbatim}
|
|
dn[.<basic-style>]= dn.regex, dn.exact
|
|
dn.<scope-style> = dn.base, dn.one, dn.subtree, dn.children
|
|
\end{verbatim}
|
|
|
|
On peut utiliser une liste d'attributs en ajoutant attr=<attributs>\\
|
|
On peut utiliser un filtre en ajoutant filter=<filtre>\\
|
|
|
|
Exemple~:
|
|
|
|
\begin{verbatim}
|
|
to dn.one="ou=People,dc=evolix,dc=net" filter=(gidNumber=2000)
|
|
\end{verbatim}
|
|
|
|
|
|
Attention la syntaxe du fichier \texttt{slapd.conf} est importante~!
|
|
Par exemple, il ne faut pas insérer de commentaires dans les règles ACL.
|
|
Ainsi l'exemple suivant est non valable~:
|
|
|
|
\begin{verbatim}
|
|
access to *
|
|
# commentaires
|
|
by * none
|
|
\end{verbatim}
|
|
|
|
|
|
\textit{Lien~:}
|
|
\url{http://www.openldap.org/doc/admin22/slapdconfig.html\#Access\%20Control}
|
|
|
|
\subsection{Utilisation}
|
|
|
|
On crée le domaine et éventuellement son administrateur (si non présent).\\
|
|
À noter que sous Debian, cette opération est automatiquement faite à l'installation (questions posées via debconf)\\
|
|
~\\
|
|
Contenu du fichier \texttt{domaine.ldif}~:\\
|
|
|
|
\begin{verbatim}
|
|
dn: dc=evolix, dc=net
|
|
objectclass: top
|
|
objectclass: dcObject
|
|
objectClass: organization
|
|
o: exemple
|
|
dc: evolix
|
|
description: LDAP Evolix
|
|
|
|
dn: cn=admin,dc=evolix,dc=net
|
|
objectclass: organizationalRole
|
|
cn: admin
|
|
\end{verbatim}
|
|
|
|
\begin{verbatim}
|
|
# ldapadd -x -h solaris -D "cn=admin2,dc=evolix,dc=net" -W -f domaine.ldif
|
|
Enter LDAP Password:
|
|
adding new entry "dc=evolix,dc=net"
|
|
adding new entry "cn=admin2,dc=evolix,dc=net"
|
|
\end{verbatim}
|
|
~\\
|
|
On crée ensuite un annuaire.\\
|
|
~\\
|
|
\texttt{create.ldif}~:\\
|
|
|
|
\begin{verbatim}
|
|
dn: ou=annuaire,dc=evolix,dc=net
|
|
objectClass: organizationalUnit
|
|
ou: annuaire
|
|
description: Annuaire Evolix
|
|
\end{verbatim}
|
|
|
|
\begin{verbatim}
|
|
# ldapadd -x -D "cn=admin2,dc=evolix,dc=net" -W -f create.ldif
|
|
Enter LDAP Password:
|
|
adding new entry "ou=annuaire, dc=evolix, dc=net"
|
|
\end{verbatim}
|
|
~\\
|
|
\textbf{Remarque} : il est conseillé d'utiliser \texttt{slapaddd -x -D [...] fichier.ldif plutot que slapdadd < fichier.ldif} afin d'éviter des erreurs de syntaxes.\\
|
|
Éventuellement pour des fichiers LDIF importants, la deuxième méthode est plus rapide.\\
|
|
|
|
On remplit l'annuaire avec des données. Par exemple, avec le fichier \texttt{entree.ldif}~:\\
|
|
~\\
|
|
\begin{verbatim}
|
|
dn: cn=Gregory, ou=annuaire, dc=evolix, dc=net
|
|
objectClass: person
|
|
objectClass: inetOrgPerson
|
|
cn: Gregory
|
|
sn: reg
|
|
telephoneNumber: 06 98 86 00 00
|
|
\end{verbatim}
|
|
|
|
|
|
\begin{verbatim}
|
|
ldapadd -x -D "cn=admin2,dc=evolix,dc=net" -W -f entree2.ldif
|
|
\end{verbatim}
|
|
|
|
Dans cet exemple, on utilise le mot de passe "en dur" dans le fichier \texttt{slapd.conf}.\\
|
|
~\\
|
|
On peut également utiliser~:
|
|
|
|
\begin{verbatim}
|
|
# slapadd < entree.ldif
|
|
\end{verbatim}
|
|
|
|
~\\
|
|
Pour une recherche dans la table, on peut utiliser le client \texttt{ldapsearch}. Par exemple~:\\
|
|
|
|
\begin{verbatim}
|
|
$ ldapsearch -x -b "ou=annuaire,dc=evolix,dc=net" -D \
|
|
"cn=admin2,dc=evolix,dc=net" -W -h 192.168.1.5
|
|
\end{verbatim}
|
|
|
|
Quelques options disponibles~:
|
|
|
|
\begin{verbatim}
|
|
-L : renvoie les résultat au format LDIFv1
|
|
-LL : désactive les commentaires
|
|
-LLL : désactive l'affichage de la version de LDIF
|
|
-h <host> : permet de se connecter à un serveur distant
|
|
(par défaut, il s'agit de localhost)
|
|
\end{verbatim}
|
|
|
|
~\\
|
|
Pour faire des modifications en mode console, on peut utiliser un \texttt{ldapmodify}. Par exemple, prenons le fichier \texttt{modif.ldif}~:
|
|
|
|
\begin{verbatim}
|
|
dn: cn=Gregory, ou=annuaire, dc=evolix, dc=net
|
|
changetype: modify
|
|
replace: telephoneNumber
|
|
telephoneNumber: 04 98 86 00 00
|
|
\end{verbatim}
|
|
|
|
|
|
Au lieu de spécifier \texttt{remplace:}, on peut mettre \texttt{add:} (il est possible de mettre plusieurs valeurs pour le même atribut) ou \texttt{delete:} (bien sûr sans mettre de valeur pour l'attribut supprimé).\\
|
|
On peut ensuite effectuer effectivement les modifications~:
|
|
~\\
|
|
\begin{verbatim}
|
|
$ ldapmodify -x -D "cn=admin2,dc=evolix,dc=net" -W -f /tmp/modif.ldif
|
|
\end{verbatim}
|
|
|
|
On notera que diverses informations sur les changements sont retenues si l'option \texttt{lastmod on} est présente dans le fichier \texttt{slapd.conf}~: la date de modification (\texttt{modifyTimestamp}), l'auteur de la modification (\texttt{modifiersName}), etc.\\
|
|
|
|
~\\
|
|
Pour la suppression, on peut également procéder en utilisant un fichier LDIF. Par exemple, voici un fichier \texttt{suppr.ldif}~:
|
|
|
|
\begin{verbatim}
|
|
cn=Gregory, ou=annuaire, dc=evolix, dc=net
|
|
\end{verbatim}
|
|
|
|
Les modifications effectives seront faites par la commande \texttt{ldapdelete}~:
|
|
|
|
\begin{verbatim}
|
|
$ ldapdelete -x -D "cn=root,dc=evolix,dc=net" -W -f /tmp/suppr.ldif
|
|
\end{verbatim}
|
|
|
|
On peut également faire directement~:
|
|
|
|
\begin{verbatim}
|
|
$ ldapdelete -x -D "cn=admin2,dc=evolix,dc=net" -W \
|
|
"cn=Gregory,ou=annuaire, dc=evolix, dc=net"
|
|
\end{verbatim}
|
|
~\\
|
|
|
|
Bien sûr, toutes ces opérations peuvent être automatisées à l'aide Shellscripts ou bien à l'aide d'autres clients en Perl, PHP, Java... (voir ci-après)
|
|
|
|
\subsubsection{Exemples d'utilisation}
|
|
~\\
|
|
|
|
\textbf{Carnet d'adresses}\\
|
|
~\\
|
|
|
|
Pour une utilisation en tant que carnet d'adresses, on peut se connecter grâce à des clients mail comme Outlook, Mozilla-Thunderbird, etc.\\
|
|
~\\
|
|
|
|
\textbf{Comptes Unix}\\
|
|
~\\
|
|
|
|
L'utilisation en tant qu'annuaire d'utilisateurs/mots de passe peut se faire sous Linux en utilisant la librairie NSS (Name Service Switch)\footnote{\url{http://www.gnu.org/software/libc/manual/html_node/Name-Service-Switch.html}} et PAM (Pluggable Authentication Modules)\footnote{\url{http://www.kernel.org/pub/linux/libs/pam/}}.\\
|
|
~\\
|
|
Sous Debian GNU/Linux, on fera~:
|
|
|
|
\begin{verbatim}
|
|
# apt-get install ldap-utils libnss-ldap libpam-ldap
|
|
\end{verbatim}
|
|
|
|
Pour utiliser notre annuaire en plus des comptes UNIX classiques, on précisera dans le fichier \texttt{/etc/nsswitch.conf}~:
|
|
|
|
\begin{verbatim}
|
|
passwd: compat ldap
|
|
group: compat ldap
|
|
shadow: compat ldap
|
|
\end{verbatim}
|
|
~\\
|
|
|
|
On précise les paramètres de l'annuaire LDAP dans le fichier \texttt{/etc/libnss-ldap.conf}~:
|
|
|
|
\begin{verbatim}
|
|
host IP_serveur_LDAP
|
|
base dc=evolix,dc=net
|
|
ldap_version 3
|
|
#binddn cn=unix,dc=evolix,dc=net
|
|
#bindpw XXX
|
|
#rootbinddn cn=adminunix,dc=evolix,dc=net
|
|
\end{verbatim}
|
|
|
|
Attention, ces fichiers doivent être lisibles par tous les utilisateurs. Si l'on doit préciser \texttt{binddn} et \texttt{bindpw}, on prendra bien garde à ce que l'utilisateur LDAP précisé ne puisse accéder aux données LDAP utiles uniquement en lecture. Pour \texttt{root} on peut préciser un utilisateur LDAP différent grâce à la directive \texttt{rootbinddn} et le mot de passe sera stocké dans le fichier \texttt{/etc/ldap.secret} accessible en lecture uniquement à \texttt{root}.\\
|
|
|
|
On vérifiera que cela fonctionne correctement en faisant~:\\
|
|
|
|
\begin{verbatim}
|
|
$ getent passwd
|
|
\end{verbatim}
|
|
|
|
Ensuite, pour pouvoir utiliser ces données à partir d'applications, on modifie le fichier \texttt{/etc/pam\_ldap.conf} qui est de syntaxe similaire au fichier \texttt{libnss-ldap.conf}~:\\
|
|
|
|
\begin{verbatim}
|
|
host IP_serveur_LDAP
|
|
base dc=evolix,dc=net
|
|
ldap_version 3
|
|
#binddn cn=unix,dc=evolix,dc=net
|
|
#bindpw XXX
|
|
#rootbinddn cn=adminunix,dc=evolix,dc=net
|
|
pam_password crypt
|
|
\end{verbatim}
|
|
~\\
|
|
|
|
Afin d'optimiser less requêtes les plus fréquentes, on indexe les valeurs qui vont être demandées le plus souvent. Dans le fichier \texttt{slapd.conf}~:
|
|
|
|
\begin{verbatim}
|
|
index uidNumber eq
|
|
index gidNumber eq
|
|
index memberUid eq
|
|
\end{verbatim}
|
|
|
|
Et on doit ensuite le faire prendre en compte à OpenLDAP en utilisant la commande \texttt{slapindex}~:\\
|
|
|
|
\begin{verbatim}
|
|
# slapindex -f slapd.conf && /etc/init.d/slapd restart
|
|
\end{verbatim}
|
|
|
|
On peut également installer \texttt{nscd} (Name Service Cache Daemon) qui utilise un système de cache utilisateur afin d'optimiser les requêtes vers un annuaire. Notons qu'il faut prendre gare au cache de \texttt{nscd} lors de changement (on devra souvent relancer \texttt{nscd}).\\
|
|
~\\
|
|
|
|
\textbf{Postfix}\\
|
|
~\\
|
|
Les bases de données d'utilisateurs et de leurs paramètres d'un serveur de messagerie électronique peuvent être stockés dans une base de données externe et notamment un annuaire LDAP.\\
|
|
~\\
|
|
Dans le fichier \texttt{main.cf} de Postfix, on utilisera une configuration type~:\\
|
|
\begin{verbatim}
|
|
alias_maps = [autres bases] ldap:ldapbla
|
|
ldapbla_server_host = [serveur ldap]
|
|
ldapbla_search_base = [dn de base]
|
|
ldapbbla_result_attribute = [type de champs à chercher]
|
|
#ldapaliases_bind = yes
|
|
#ldapaliases_bind_dn = cn=postfix,dc=evolix,dc=net
|
|
#ldapaliases_bind_pw = XXX
|
|
ldapaliases_query_filter = (mail=%s)
|
|
ldapaliases_result_attribute = uid
|
|
ldapaliases_debuglevel = 0
|
|
\end{verbatim}
|
|
|
|
Par défaut, Postfix regarde le(s) attribut(s) \texttt{mailacceptinggeneralid} pour déterminer à qui le mail est destiné (on peut spécifier un mail "entier" ce qui permet de différencier \textit{alias@domain1.tld} de \textit{alias@domain1.tld}). Ensuite, il regarde le(s) attribut(s) \texttt{maildrop} pour déterminer à qui distribuer le mail. On change cela grâce aux directives \texttt{query\_filter} et \texttt{result\_attribute} dans Postfix.
|
|
|
|
On peut aussi préciser un nom de fichier où l'on mettra ces directives. Par exemple~:
|
|
\begin{verbatim}
|
|
alias_maps = [autres bases] ldap:/etc/postfix/ldap-aliases.cf
|
|
\end{verbatim}
|
|
|
|
Dans le fichier \texttt{/etc/postfix/ldap-aliases.cf} on mettra les mêmes directives que celles précisées ci-dessus sans le suffixe \textit{ldapbla\_}.\\
|
|
|
|
~\\
|
|
Pour notre exemple, on aura des entrées LDAP ressemblant à~:\\
|
|
|
|
\begin{verbatim}
|
|
dn: uid=pnom,[dn de base]
|
|
objectClass: inetOrgPerson
|
|
objectClass: inetLocalMailRecipient
|
|
objectClass: posixAccount
|
|
sn: Nom
|
|
givenName: Prenom Nom
|
|
mail: pnom@domain.tld
|
|
mail: prenom.nom@domain.tld
|
|
cn: Prenom Nom
|
|
displayName: Prenom Nom
|
|
uid: pnom
|
|
userPassword: XXXX
|
|
uidNumber: 1006
|
|
gidNumber: 1000
|
|
homeDirectory: /home/pnom/
|
|
\end{verbatim}
|
|
|
|
Il est aussi envisageable d'avoir des entrées correspondant uniquement à des aliases (et non rattachés à un utilisateur) et notamment préciser un alias de collecte pour un domaine (\texttt{mailacceptinggeneralid: @domain.tld}).\\
|
|
~\\
|
|
|
|
%http://archives.neohapsis.com/archives/postfix/1999-q4/1358.html
|
|
|
|
|
|
\textbf{Apache}\\
|
|
~\\
|
|
|
|
On peut utiliser l'authentification Apache avec un annuaire OpenLDAP. Il existe plusieurs modules pour utiliser LDAP avec Apache. Pour Apache2, un module \textit{mod\_auth\_ldap} est intégré par défaut\footnote{\url{http://httpd.apache.org/docs-2.0/mod/mod\_auth\_ldap.html}}. Voici un exemple de configuration~:
|
|
|
|
\begin{verbatim}
|
|
AuthName "Acces Prive"
|
|
AuthType Basic
|
|
AuthLDAPEnabled on
|
|
AuthLDAPURL ldap://127.0.0.1/ou=people,dc=evolix,dc=net?uid?one
|
|
AuthLDAPAuthoritative on
|
|
require valid-user
|
|
\end{verbatim}
|
|
|
|
\textbf{Diverses applications}\\
|
|
~\\
|
|
|
|
De nombreuses applications permettent d'utiliser une base OpenLDAP pour le stockage de données et/ou l'authentification. Typiquement, une application comme Egroupware permet l'utilisation d'une base OpenLDAP pour l'authentification des utilisateurs et pour le stockage des contacts. Plus globalement, un annuaire LDAP est souvent utilisé comme un serveur d'authentification~: toutes les applications d'une structure l'utilisent pour authentifier les utilisateurs. Centraliser l'authentification offre de nombreux avantages~: un mot de passe identique pour toutes les applications, facilité d'administration pour gérer ajout/changement, etc. Par contre, le serveur OpenLDAP est dans ce cas extrêmement critique car si il est défaillant, toutes les applications peuvent être inutilisables~! Ainsi, il peut être important d'avoir une politique de sauvegarde et de tolérance de panne.
|
|
|
|
|
|
\subsection{Utilisation avec TLS}
|
|
|
|
Afin de sécuriser les connexions entre le client et le serveur (chiffrement et authentification), on peut utiliser TLS (Transport Layer Security). TLS utilise des certificats X.509. Il peut être essentiel de ne pas transporter des données non chiffrées surtout lorsqu'un serveur OpenLDAP est utilisé en tant que serveur d'authentification. Ainsi, si on utilise LDAP en mode classique, les mots de passe circulent en clair~!\\
|
|
~\\
|
|
|
|
Pour utiliser un certificat sur le serveur OpenLDAP, il nous faut obtenir un certificat X.509 et une clé privée. Selon la politique de sécurité en place au sein de sa structure, on utilisera un certificat signé par une autorité de certification ou bien généré par une PKI (Public Key Infrastructure) interne. On peut également générer un certificat auto-signé.\\
|
|
~\\
|
|
On rappelle la procédure de génération d'un certificat auto-signé~:\\
|
|
~\\
|
|
|
|
On crée une "demande" de certificat en se basant sur des paramètres aléatoires ainsi qu'une clé privée \texttt{privkey.pem} protégée par un mot de passe~:
|
|
|
|
\begin{verbatim}
|
|
$ openssl req -new > demande.csr
|
|
\end{verbatim}
|
|
|
|
Si l'on veut supprimer ce mot de passe de protection (utile dans le cas d'un serveur), on ajoute l'argument \texttt{-out cleprivee.pem} et l'on obtient une clé privée \texttt{cleprivee.pem} non protégée~:
|
|
|
|
\begin{verbatim}
|
|
$ openssl rsa -in privkey.pem -out cleprivee.pem
|
|
\end{verbatim}
|
|
|
|
Enfin, on génère le certificat basé sur la demande et signé par la clé privée~:
|
|
|
|
\begin{verbatim}
|
|
$ openssl x509 -in demande.csr -out certificat.pem -req -signkey
|
|
cleprivee.pem -days 365
|
|
\end{verbatim}
|
|
|
|
On peut ensuite ajouter les lignes suivantes dans le fichier \texttt{slapd.conf}~:
|
|
\begin{verbatim}
|
|
TLSCertificateFile /path/to/certs/certificat.pem
|
|
TLSCertificateKeyFile /path/to/certs/cleprivee.pem
|
|
\end{verbatim}
|
|
|
|
On peut ensuite redémarrer le serveur OpenLDAP.\\
|
|
~\\
|
|
|
|
Du côté du client, il faut posséder le certificat pour pouvoir se connecter au serveur avec TLS. On veillera à utiliser un moyen sûr pour transporter le certificat serveur jusqu'au client afin d'assurer également l'authentification lors de la connexion. Pour se connecter avec le client console (paquet \textit{ldap-utils}), on crée un fichier \texttt{~/.ldaprc} qui contiendra le chemin vers le certificat serveur~:
|
|
|
|
\begin{verbatim}
|
|
TLS_CACERT /path/to/cert/certificat.pem
|
|
\end{verbatim}
|
|
|
|
On peut ensuite se connecter en utilisant l'option \texttt{-ZZ}. Par exemple~:
|
|
|
|
\begin{verbatim}
|
|
$ ldapsearch -x -b "dc=formations,dc=evolix,dc=fr" -D \
|
|
"cn=admin,dc=formations,dc=evolix,dc=fr" -LL uid -h \
|
|
ldap.formations.evolix.fr -ZZ -W
|
|
\end{verbatim}
|
|
|
|
On note qu'il est obligatoire d'utiliser le nom de domaine du serveur présent dans le certificat. Sinon la connexion en TLS est impossible~!\\
|
|
~\\
|
|
|
|
De même, on peut utiliser TLS avec des clients LDAP.\\
|
|
|
|
\newpage
|
|
|
|
\subsection{Annuaires distribués}
|
|
|
|
\subsubsection{Liens entre annuaire}
|
|
|
|
Le but est de lier différentes branches d'annuaires distincts. Les liaisons possibles sont le service referral (apparu dans la norme LDAPv3) et le chaînage de données (qui ressemble à des requêtes DNS récursives).
|
|
|
|
Pour le service referral, cela consiste à un serveur \texttt{example.com} de déléguer une branche, par exemple \texttt{dc=myref,dc=example,dc=com}, à un autre serveur, par exemple \texttt{bis.example.com}.
|
|
|
|
\texttt{example.com} comportera une entrée du type~:
|
|
|
|
\begin{verbatim}
|
|
dn: dc=myref,dc=example,dc=com
|
|
objectClass: referral
|
|
objectClass: extensibleObject
|
|
dc: myref
|
|
ref: ldap://bis.example.com/dc=myref,dc=example,dc=com
|
|
\end{verbatim}
|
|
|
|
\texttt{bis.example.com} pourra également pointer vers \texttt{example.com} pour les entrées non définies. Dans ce cas, on précisera dans le fichier \texttt{slapd.conf}~:
|
|
|
|
\begin{verbatim}
|
|
referral ldap://example.com/
|
|
\end{verbatim}
|
|
|
|
Il faut utiliser l'option \texttt{-M} pour contrôler ces informations sans "suivre" les referral. Par exemple, pour supprimer un referral~:
|
|
|
|
\begin{verbatim}
|
|
ldapdelete -M -x -D "cn=admin,dc=example,dc=com" -W "dc=myref,dc=example,dc=com"
|
|
\end{verbatim}
|
|
|
|
\subsubsection{Réplication}
|
|
|
|
Dans cette architecture, il y a un serveur OpenLDAP maître et un serveur OpenLDAP esclave. La gestion des réplications est faite grâce au daemon slurpd (Standalone LDAP Update Replication Daemon) sur le serveur OpenLDAP maître.~\\
|
|
|
|
\textit{Lien~:}
|
|
\url{http://www.openldap.org/doc/admin22/config\_repl.gif}\\
|
|
~\\
|
|
Sur le serveur maître~:\\
|
|
~\\
|
|
\texttt{slapd.conf}\\
|
|
\begin{verbatim}
|
|
replogfile /var/lib/ldap/replog
|
|
replica uri=ldap://ldap2.evolix.net:389
|
|
binddn="cn=Replicator,dc=evolix,dc=net"
|
|
bindmethod=simple credentials=secret
|
|
\end{verbatim}
|
|
~\\
|
|
Sur le serveur esclave~:\\
|
|
~\\
|
|
|
|
\texttt{slapd.conf}
|
|
\begin{verbatim}
|
|
rootdn "cn=Replicator,dc=evolix,dc=net"
|
|
rootpw {SSHA}UflDkKSi+YdiQ+5OUrM1uJsJKZDSO++W
|
|
updatedn "cn=Replicator,dc=evolix,dc=net"
|
|
updateref "ldap://ldap.evolix.net"
|
|
\end{verbatim}
|
|
|
|
Les modifications LDAP sont stockées dans le replogfile qui est vidé par slurpd. Si le serveur esclave est disponible, elles lui sont ensuite envoyés. Si aucun accès en écriture n'est possible, les modificatiosn sont rejetés et conservés dans des fichiers \texttt{.rej}. À noter que la première fois les données LDAP doivent être importés manuellement sur le serveur esclave.
|
|
|
|
|
|
\subsection{Clients OpenLDAP}
|
|
~\\
|
|
|
|
Il existe plusieurs logiciels clients pour visualiser, insérer, modifier, supprimer, etc. des données dans une base OpenLDAP~:
|
|
~\\
|
|
\begin{itemize}
|
|
\item \textbf{ldap-utils} commandes en mode console (ldapadd, ldapcompare, ldapdelete, ldapmodify, ldapmodrdn, ldappasswd, ldapsearch, ldapwhoami)
|
|
|
|
\item \textbf{LDAP Browser/Editor} logiciel graphique en Java permettant
|
|
de visualiser, modifier et rechercher aisément. Import et export au
|
|
format LDIF sont pratiques.\\
|
|
\textit{Lien~:} \url{http://www-unix.mcs.anl.gov/~gawor/ldap/}
|
|
|
|
\item \textbf{GQ} logiciel graphique en GTK permettant de visualiser aisément.\\
|
|
\textit{Lien~:} \url{http://biot.com/gq/}
|
|
|
|
\item \textbf{PhpLDAPadmin} interface web en PHP permettant d'effectuer de nombreuses opérations aisément.\\
|
|
\textit{Lien~:} \url{http://phpldapadmin.sourceforge.net/}
|
|
|
|
\end{itemize}
|
|
|
|
% voir le package Debian 'cpu'
|
|
|
|
|
|
% http://www.urec.cnrs.fr/cours/Applis/x500/
|
|
% http://www.sysium.com/ldap.html
|