Authentification forte auprès d`un serveur LDAP par la méthode

Transcription

TELECOM-
ANNEE 2003/2004
Option SSR – Projet de fin d’étude
Authentification forte auprès d'un serveur
LDAP par la méthode SASL Kerberos
EI3 Option SSR
Enseignant encadrant : Maryline MAKNAVICIUS-LAURENT
Vivien LE POUPON
Vincent ROYER
Table de matières
Introduction .............................................................................................................................. 4
1. Kerberos................................................................................................................................ 5
1.1
Présentation ................................................................................................................ 5
1.2
Architecture................................................................................................................ 6
1.2.1
Le Royaume Kerberos (Kerberos Realm) :........................................................ 6
1.2.2
Les « principals » : ............................................................................................. 6
1.2.3
Le serveur Kerberos ........................................................................................... 8
1.2.4
Les services « kerbérisés » :............................................................................. 11
1.3
Fonctionnement d’une authentification Kerberos .................................................... 12
2
LDAP ............................................................................................................................... 14
2.1
Introduction à LDAP................................................................................................ 14
2.2
Qu'est-ce que LDAP ? .............................................................................................. 15
2.2.1
Un annuaire LDAP est-il une base de données ? ............................................. 15
2.2.2
Les avantages des annuaires LDAP ................................................................. 16
2.2.3
Dans quel cas utiliser LDAP pour stocker des données ? ................................ 16
2.3
Structure d'un arbre d'annuaire LDAP ..................................................................... 17
3
Authentification Kerberos/SASL pour accès LDAP : ................................................ 19
3.1
Principe général........................................................................................................ 19
3.2
Installation................................................................................................................ 20
3.2.1
Installation de OpenSSL et création de certificats ........................................... 20
3.2.2
Installation Kerberos V .................................................................................... 21
3.2.2.1 Installation des composants :........................................................................ 21
3.2.2.2 Configuration du fichier krb5.conf : ............................................................ 21
3.2.2.3 Configuration du fichier kdc.conf : .............................................................. 22
3.2.2.4 Création de la base Kerberos pour notre « royaume » : ............................... 22
3.2.2.5 Configuration du fichier kadm5.acl : ........................................................... 23
3.2.2.6 Création des utilisateurs et des administrateurs Kerberos............................ 23
3.2.3
Installation Cyrus SASL................................................................................... 24
3.2.4
Installation de OpenLDAP ............................................................................... 25
3.2.4.1 Configuration du fichier ldap.conf :............................................................. 26
3.2.4.2 Configuration du fichier slapd.conf : ........................................................... 27
3.2.4.3 Lancement du serveur LDAP :..................................................................... 28
3.2.4.4 Création d’un principal LDAP dans la base Kerberos ................................. 28
3.2.4.5 Initialisation de la base LDAP : ................................................................... 29
3.2.4.6 A propos des listes d’accès de la base LDAP : ............................................ 30
4
Tests ................................................................................................................................. 31
4.1
Test de services « kerbérisés » avec Kerberos V et SASL : .................................... 31
4.2
Test de OpenLDAP .................................................................................................. 34
4.2.1
Affichage des mécanismes d’authentification supportés : ............................... 34
4.2.2
Tests de recherches dans l’annuaire ................................................................. 35
4.2.3
Tests de modifications de la base ..................................................................... 36
4.2.4
Captures de trames ........................................................................................... 41
2
Conclusion............................................................................................................................... 43
Annexe A : Génération des certificats sous OpenSSL ........................................................ 44
Annexe B : Fichiers configuration Kerberos V ................................................................... 48
1
Fichier krb5.conf : ........................................................................................................ 48
2
Fichier kdc.conf :.......................................................................................................... 49
Annexe C : Fichiers configuration LDAP ............................................................................ 50
1
Fichier ldap.conf : ........................................................................................................ 50
2
Fichier slapd.conf :....................................................................................................... 54
Annexe D - Tests sur OpenLDAP ......................................................................................... 56
Références ............................................................................................................................... 59
3
Introduction
Kerberos et LDAP se sont établis comme des valeurs sûres dans leurs domaines
respectifs. Leur association, d’ailleurs de plus en plus mise en pratique, est
intéressante. Elle permet de sécuriser un annuaire LDAP efficacement, ce qui n’est
pas réalisé par défaut par cette norme.
De plus, cette implémentation requiert l’utilisation d’éléments tels que SASL afin
d’assurer le dialogue entre Kerberos et LDAP. En effet, LDAP n’est pas nativement
prévu pour une mise en œuvre avec le programme d’authentification. Une
« couche » intermédiaire SASL est alors nécessaire.
Ces éléments ont donc étés pour nous une source d’intérêt supplémentaire, ce projet
nous permettant de nous familiariser avec divers domaines et normes. Réussir à
installer Kerberos, puis assurer son fonctionnement avec LDAP représente une
expérience enrichissante, et c’est avec une grande motivation que nous nous
sommes lancés dans ce projet.
Le travail s’est divisé en trois phases principales : familiarisation avec les éléments
impliqués, installation et configuration de ces éléments, et enfin tests du
fonctionnement.
Pour ce rapport, nous avons adoptés une structure similaire à celle de notre
cheminement. Ainsi, nous allons nous appliquer à décrire brièvement Kerberos et
son fonctionnement dans un premier temps, puis faire de même avec LDAP dans un
deuxième temps. Ensuite, les différentes procédures d’installation et
d’implémentation seront abordées. Enfin, nous détaillerons les tests qui ont étés mis
en œuvre afin de s’assurer du bon fonctionnement de l’ensemble, et des paramètres
de configuration à retenir.
4
1. Kerberos
1.1 Présentation
Kerberos est un protocole mis au point par le MIT. Il permet l’authentification forte
des utilisateurs pour l’accès à certains services dits « kerbérisés ».
Kerberos est le nom du chien de la mythologie grecque gardant les portes du dieu
des enfers Hadès. D'où le nom symbolique de ce protocole d’authentification réseau
conçu par Miller et Neuman dans le cadre du projet Athena (démarré en 1983) du
Massachusetts Institute of Technologie (MIT). Nous sommes aujourd'hui à la version
5 du protocole.
Il est standardisé et défini par 2 RFC : la RFC 1510 pour l’implémentation du
protocole, et la RFC 1964 pour le mécanisme et le format d’insertion des jetons de
sécurité dans les messages Kerberos.
Très largement utilisé dans le monde Unix/Linux, il également à la base du système
d’authentification de l’Active Directory de Windows 2000 de Microsoft.
Le plus souvent les services accessibles au sein d’un réseau demandent
l’authentification des utilisateurs. Cette authentification consiste en un login et un mot
passe qui, la plupart du temps, circulent en clair sur le réseau. C’est par exemple le
cas du FTP ou du Telnet.
Certaines procédures permettent de sécuriser ces échanges (certificats et
cryptographie), mais étant donné le nombre, souvent très important, de services à
sécuriser et le nombre d’utilisateurs et de serveurs, la mise en place et
l’administration de telles architectures sont souvent très complexes.
Kerberos a pour vocation de simplifier cette architecture en centralisant
l’authentification des utilisateurs et des services. Proche du concept de Single-SignOn (SSO), Kerberos réalise l’authentification des utilisateurs et gère ensuite leur
accès aux différents services. L’utilisateur s’authentifie une première fois auprès du
serveur Kerberos et accède ensuite aux services de façon transparente, aucune
nouvelle authentification ne lui sera demandée par aucun service dit « kerbérisé ».
5
1.2 Architecture
1.2.1 Le Royaume Kerberos (Kerberos Realm) :
Une architecture Kerberos est constituée de serveurs Kerberos, d’utilisateurs, de
postes de travail et de serveurs hébergeant des services.
Toutes ces entités sont rassemblées et définies au sein d’un « Royaume Kerberos»
(Kerberos Realm).
1.2.2 Les « principals » :
Au sein de ce royaume, les utilisateurs et les hôtes (postes et serveurs) hébergeant
des services constituent les « principals ». Il sont déclarés dans la base Kerberos
selon le schéma : nom/instance@KRB-REALM
A chaque « principal » est associé un mot de passe qui fait office de clé secrète
(hashage du mot de passe). Les utilisateurs doivent saisir leur mot de passe pour
s’identifier auprès du serveur Kerberos et récupérer un ticket d’accès aux services.
Pour les hôtes et les services, qui ne peuvent pas saisir leur mot de passe, la clé
secrète est stockée localement (sur l’hôte) dans un fichier .keytab (par exemple :
/etc/krb5.keytab).
Par exemple pour le royaume INT-EVRY.FR :
¾ Les utilisateurs peuvent être déclarés comme :
o root/[email protected] pour un administrateur
6
o toto/[email protected] pour un élève toto
o Dupond/[email protected] pour l’enseignant Dupond.
¾ Les postes de travail peuvent être déclarés comme :
o host/[email protected] pour le poste déclaré en tant que
PC1 dans le DNS du domaine int-evry.fr
o host/[email protected] pour le poste déclaré en tant que
PC2 dans le DNS du domaine int-evry.fr
¾ Les services peuvent être déclarés comme :
o ftp/[email protected] pour le serveur FTP hébergé
sur le serveur déclaré en tant que server1 dans le DNS du domaine
int-evry.fr
o ldap/[email protected] pour l’annuaire LDAP hébergé
sur le serveur déclaré en tant que server1 dans le DNS du domaine
int-evry.fr
7
1.2.3 Le serveur Kerberos
Le serveur Kerberos est constitué de plusieurs entités logiques qui sont souvent
regroupées physiquement en un seul et même serveur.

KADMIN :
Ce module permet d’administrer le serveur Kerberos. Il gère les utilisateurs, les hôtes
et services du domaine Kerberos, leurs droits d’accès (ACL), ainsi que les méthodes
de chiffrement utilisées (des3-hmac-sha1, des-cbc-crc, des-cbc-md5,...).
Son accès est le plus souvent réservé à l’administrateur du domaine qui peut
accéder localement au serveur (commande kadmin.local) ou à distance depuis un
hôte du domaine (kadmin).
La configuration du serveur se fait à travers le fichier krb5.conf.

KDC (Key Distribution Center) :
Ce Centre de distribution des clés contient une base de données regroupant les
utilisateurs, les services et les clés qui leur sont associés. Ce module a pour fonction
d’authentifier les utilisateurs avant de leur offrir un accès aux services
« kerbérisés », il joue le rôle de serveur d’authentification (AS).
Pour obtenir un accès aux services « kerbérisés » un utilisateur doit avant tout
obtenir un ticket d’accès (TGT : Ticket Granting Ticket) auprès du KDC.
Il s’identifie auprès du KDC en tant qu’utilisateur C (principal : [email protected], par
exemple) et reçoit alors un ticket d’accès crypté avec sa clé sécrète. Il est important
de noter que la clé sécrète ne circule à aucun moment sur le réseau, l’utilisateur
saisit en local son mot de passe pour déchiffrer le ticket du KDC.
Le TGT reçu va ensuite permettre à l’utilisateur C de dialoguer avec le TGS (voir cidessous) afin d’obtenir des tickets d’accès pour les différents services « kerbérisés ».
Pour récupérer un TGT, l’utilisateur doit saisir la commande : kinit <principal> (où
« principal » désigne l’identifiant de l’utilisateur).
Le système demande alors à l’utilisateur de rentrer son mot de passe de façon à
déchiffrer le ticket. Si le mot de passe est valide l’utilisateur dispose alors d’un ticket
pour dialoguer avec le TGS.
8
Avec la commande : klist, l’utilisateur peut vérifier qu’il possède bien un ticket pour
dialoguer avec le TGS.
Le TGT a une durée de vie limitée (par défaut huit heures) et prédéfinie dans le
fichier de configuration kdc.conf :
L’utilisateur peut à tout moment détruire son ticket à l’aide de la commande :
kdestroy.
En plus du TGT, le KDC fournit à l’utilisateur une clé de session pour dialoguer avec
le TGS (clé notée Kc,tgs).
Le KDC constitue l'élément le plus sensible de tout le domaine Kerberos. S'il est
compromis, c'est tout le domaine Kerberos qui est compromis avec lui. Il est donc
nécessaire que le serveur hébergeant le KDC soit parfaitement sécurisé.
9

Le TGS (Ticket Granting Service) :
Le TGS a pour fonction de fournir des tickets d’accès aux services « kerbérisés ».
Lorsque un utilisateur souhaite accéder à un service « kerbérisé », il émet une
demande auprès du TGS.
Dans cette demande le client («c») inclue l’identifiant du service auquel il souhaite
accéder (« s »), le TGT qu’il a obtenu du KDC (voir partie précédente), un indicateur
d’authentification (« Ac ») crypté avec la clé de session Kc,tgs (clé de session entre le
client et le TGS, reçue du KDC).
Le TGS vérifie que le TGT est bien valide (ce qui signifie que le client a bien été
authentifié par le KDC) ainsi que l’indicateur d’authentification, puis renvoie les
informations pour accéder au service demandé.

Contenu du TGT :
Le TGT permet à l’utilisateur authentifié de récupérer des tickets d’accès aux
services auprès du TGS.
Il contient un identifiant du client, la clé de session pour les échanges entre le TGS et
le client ainsi qu’une durée de validité (lutter contre le rejeu).
Le TGT est crypté à l’aide de la clé secrète du TGS.
10
1.2.4 Les services « kerbérisés » :
De nombreux services peuvent s’appuyer sur Kerberos pour authentifier les
utilisateurs. Les applications doivent toutefois être modifiées.
Certains services sont installés de base en version « kerbérisé » lors de l’installation
de Kerberos. Ils comportent le préfixe « k » de façon à les différencier des services
standard : kssh, krlogin, ksu,…
Ces services font référence aux fichiers krb5.conf et kdc.conf pour rediriger les
authentifications vers le KDC correspondant.
Certaines applications n’existent pas en version « kerbérisée ». Plutôt que de
modifier leur code source, on peut insérer une couche supplémentaire entre
l’application et le service Kerberos qui se charge de convertir l’authentification
Kerberos en un format valide pour l’application.
SASL (défini dans le RFC 2222) permet d’ajouter des mécanismes d’authentification
à des protocoles orientés connexion (~ plug-in). SASL est implanté dans LDAPv3.
Parmi les mécanismes supportés par SASL, citons Kerberos IV, S/Key, Digest-MD5
ou GSSAPI.
On peut ainsi utiliser les librairies SASL (librairie Cyrus-SASL) pour réaliser ce type
d’authentification. SASL (Simple Authentication and Security Layer) permet
l’authentification de type Kerberos 5 grâce au mode GSSAPI.
Authentification de type Kerberos pour l’accès à un annuaire LDAP, basé sur SASL.
Source : CNRS
11
1.3 Fonctionnement d’une authentification Kerberos
Le schéma ci-dessous détaille toute la procédure d’authentification d’un utilisateur
pour l’accès à un service à l’aide de Kerberos.

Etape 1 :
¾ L’utilisateur C contacte le KDC afin de demander un accès vers le TGS.
C s’identifie suivant un « principal » enregistré dans la base du KDC.

Etape 2 :
¾ Le KDC vérifie si le « principal » existe bien dans la base de Kerberos
et si oui répond à la demande de C.
¾ Il envoie alors une clé de session (Kc,tgs) permettant le dialogue entre C
et le TGS, cette clé est cryptée à l’aide de la clé secrète (Kc) de C.
12
Kc est un hash du mot de passe de C, à aucun moment elle ne circule
sur le réseau. Lorsque C reçoit la réponse du TGS, une invite de
commande lui demande de saisir son mot de passe de façon à
décrypter la clé de session Kc,tgs.
¾ De plus, le KDC renvoie un ticket TGT constitué de l’identifiant de C,
d’une clé de session (Kc,tgs) pour les dialogues entre C et le TGS, ainsi
que d’une durée de validité du ticket, le tout crypté à l’aide de la clé
secrète (Ktgs) du TGS.

Etape 3 :
¾ L’utilisateur C contacte alors le TGS afin d’obtenir un accès au service
S. En réalité cet échange est transparent pour l’utilisateur qui se
contente de contacter le service auquel il souhaite accéder, par
exemple : ftp myftp.mondomaine.fr. C’est l’application « kerbériséeé »
(ici le FTP) qui se charge de contacter le TGS pour authentifier
l’utilisateur.
¾ C envoi l’identifiant S du service auquel il souhaite accéder. Il envoi
aussi Le TGT qu’il a obtenu du KDC lors de l’étape 2, ainsi qu’un
identifiant Ac crypté à l’aide de la clé de session Kc,tgs.

Etape 4 :
¾ Le TGS répond à C de façon cryptée à l’aide de la clé de session Kc,tgs.
¾ Le TGS envoie à C un ticket d’accès (Tc,s) au service S crypté avec la
clé secrète (Ks) de S. Il envoi aussi une clé de session (Kc,s) permettant
de chiffrer les futurs échanges entre C et S.

Etape 5 :
¾ Le client C envoie le ticket d’accès (Tc,s) au service à S, qu’il a reçu du
TGS. Ce ticket est crypté à l’aide de la clé secrète de S qui est alors le
seul à pouvoir déchiffrer le ticket.
¾ Il envoie également un identifiant (Ac) de C, qui permet au service S
d’authentifier le client C et de tester la validité du ticket Tc,s par
comparaison.
Il est important de noter qu’aucune information compromettante n’a transité en clair
sur le réseau lors de ces échanges. Si un pirate écoutait les communications, les
informations qu’il récupèrerait seraient très difficilement exploitables.
13
2 LDAP
2.1 Introduction à LDAP
Dans l'industrie informatique, on entend de plus en plus parler de LDAP. Mais en
quoi consiste cette norme, et comment la mettre en application ? Nous allons nous y
intéresser, avec pour objectif de se familiariser avec les concepts sous-jacents à
LDAP et son environnement plutôt que de rentrer dans les détails.
Pour commencer, la mise en oeuvre de LDAP à l'échelle d'une entreprise permet à
n'importe quelle application, exécutée à partir de presque n'importe quelle machine,
d'obtenir des informations provenant de l'annuaire LDAP. Et ce répertoire peut être
utilisé pour stocker un large éventail de données : adresses électroniques et
informations de routage du courrier, clés de sécurité publiques, données relatives
aux RH, listes de contacts, et bien plus...
Mais il est aussi possible d'utiliser une base de données Oracle, Microsoft SQL,...
afin de stocker la plupart de ces mêmes données. En quoi LDAP est-il différent ?
C'est ce que nous allons voir.
14
2.2 Qu'est-ce que LDAP ?
LDAP (Lightweight Directory Access Protocol) est basé sur la norme X.500, mais est
sensiblement plus simple, et peut-être adapté plus aisément aux besoins des
utilisateurs. Contrairement à X.500, LDAP supporte TCP/IP, ce qui est nécessaire
pour l'accès à Internet. Les spécifications LDAP principales sont toutes définies dans
des RFCs (dont une liste complète est donnée en annexe).
Source : F5 Network, http://www.f5.com/solutions/archives/whitepapers/ldap.html
2.2.1 Un annuaire LDAP est-il une base de données ?
Tout comme un Système de Gestion de Base de Données (SGBD) de Microsoft,
Oracle, ou autre, est employé pour traiter les requêtes et mises à jours sur une base
de données relationnelle, un serveur LDAP est employé pour traiter les requêtes et
mises à jours sur un annuaire LDAP. En d'autres termes, un annuaire LDAP est un
type de base de données, mais il ne s'agit pas d'une base de données relationnelle.
Et contrairement aux bases de données qui sont conçues pour traiter des centaines
ou des milliers de modifications par minute, les annuaires LDAP sont fortement
optimisés pour la lecture.
15
2.2.2 Les avantages des annuaires LDAP
Alors, quels sont les avantages des annuaires LDAP ? La popularité actuelle de
LDAP est due à un certain nombre de facteurs que nous pouvons résumer ici.
Le meilleur argument en faveur de LDAP est sans doute le fait qu'une entreprise peut
accéder à l'annuaire LDAP d'à peu près n'importe quelle plate-forme, et ceci à partir
d'un nombre croissant d'applications qui lui sont compatibles. Il est également facile
d'adapter les applications internes de l'entreprise de manières à ce qu'elles intègrent
LDAP.
Le protocole LDAP étant à la fois « cross plate-forme » et normalisé, les applications
n'ont pas à s'inquiéter du type de serveur accueillant l'annuaire. En fait, LDAP est
beaucoup plus largement accepté dans l'industrie en raison de son statut de
standard Internet. Les fournisseurs sont plus disposés à procéder à l'intégration de
LDAP dans leurs produits du fait qu'ils n'ont pas se soucier de savoir ce qui est à
l'autre extrémité. En revanche, les fournisseurs désirant intégrer directement un
SGBD doivent habituellement concevoir leur produit de manière à ce qu'il fonctionne
individuellement avec les solutions des différents fournisseurs de serveurs de base
de données.
À la différence de beaucoup de bases de données relationnelles, il n'est pas
nécessaire de payer le client logiciel de connexion ou une licence.
La plupart des serveurs LDAP sont simples à installer, faciles à maintenir et à
optimiser.
Les serveurs LDAP peuvent dupliquer tout ou partie de leurs données via des
méthodes « push » ou « pull », permettant de faire parvenir ces données à des
bureaux distants, d'accroître la sécurité, etc... La technologie de duplication est
intégrée et facile à configurer. A l'opposé, plusieurs des grands fournisseurs de
SGBD facturent ce dispositif, et il est bien plus difficile à gérer convenablement.
LDAP permet d'affecter efficacement des droits de lecture et de modification suivant
des besoins spécifiques, en utilisant des ACLs (Access Control Lists). Les ACLs
peuvent contrôler l'accès selon l'identité du demandeur des données, quelles
données sont demandées, où les données sont stockées, et d'autres aspects de
l'enregistrement étant modifié. Tout ceci est fait par l'annuaire LDAP directement,
ainsi il n'est pas nécessaire de s'inquiéter de mettre en oeuvre un contrôle d'accès
au niveau d'applicatif.
2.2.3 Dans quel cas utiliser LDAP pour stocker des données ?
La plupart des serveurs LDAP sont fortement optimisés pour des opérations de
lecture. A cause de ceci, la plupart des annuaires LDAP ne sont pas bien adaptés au
stockage de données fréquemment modifiées. Par exemple, un serveur d'annuaire
LDAP convient tout à fait pour stocker l'annuaire de téléphone interne d'une
entreprise, mais il ne faut pas songer à l'employer pour la base de données
principale d'un site d'e-commerce à fort débit.
16
2.3 Structure d'un arbre d'annuaire LDAP
Les serveurs d'annuaire LDAP stockent leurs données hiérarchiquement. La
structure d'un annuaire est relativement similaire à ce que l'on peut trouver pour les
arbres DNS ou les dossiers du système de fichier UNIX. Comme pour les noms
d'hôte DNS, dans un annuaire LDAP, le champ Distinguished Name (DN) d'un
enregistrement est lu du bas vers le haut, de l'entrée individuelle (feuille) vers la
racine de l'arbre.
Le niveau supérieur d’un arbre d’annuaire LDAP est la base, généralement appelée
« base DN ». Il existe 3 notations pour cette base. Si on considère l’annuaire d’une
entreprise française Yggdrasil localisée sur Internet à l’adresse yggdrasil.com, alors
on aura :
o="Yggdrasil", c=FR
(base DN au format X.500)
Ici, o=”Yggdrasil” fait référence à l’organisation, le second champ notifiant le pays
d’origine. Ce format de notation étant source de confusion, il a évolué vers ceux
présentés ci-dessous.
o=yggdrasil.com
(base DN dérivé de la localisation Internet de l’entreprise)
Ici, la base utilisée correspond au nom de domaine Internet de l’entreprise.
dc=yggdrasil, dc=com
(base DN dérivé des composants du domaine DNS de l’entreprise)
Comme précédemment, le nom de domaine DNS est utilisé, mais il est décomposé
en dc (domain components).
Sous la racine de l’annuaire, on créera des répertoires qui séparent logiquement les
données. Pour des raisons historiques (X.500), la plupart des annuaires LDAP
désignent ces séparations logiques par les initiales OU, pour « Organizational Unit ».
Dans X.500, OU était utilisé pour représenter l’organisation fonctionnelle à l’intérieur
d’une entreprise : ventes, finance, etc… Les implémentations actuelles de LDAP ont
gardé la convention d’appellation ‘ou=’, mais divisent les choses en larges catégories
telles que ou=people, ou=groups, ou=serveurs, etc…
Par exemple, l’arbre d’un annuaire LDAP (entrées individuelles exclues) pourrait
ressembler à ceci :
dc=int-evry, dc=fr
ou=people
ou=eleves
ou=enseigants
ou=administratifs
ou=servers
ou=groups
ou=machines
17
dc = com
dc = org
dc = fr
dc = int-evry, dc = fr
ou = people
ou = servers
ou = groups
uid = jdupond
Toutes les entrées stockées dans un annuaire LDAP ont un "Distinguished Name",
ou DN, unique. Ce DN se compose de deux parties : le DN relatif (RDN), et l’endroit
dans l’annuaire où se trouve l’enregistrement.
Le RDN a généralement pour base l’attribut cn (Common Name), ou l’attribut uid
(User ID).
Des exemples de DN complets seraient :
cn=jotun, ou=machines, dc=yggdrasil, dc=com
uid=gdupont, ou=people, dc=int-evry, dc=fr
18
3 Authentification Kerberos/SASL pour accès LDAP :
3.1 Principe général
Dans cette partie nous allons décrire la mise en œuvre de l’authentification de type
Kerberos, basée sur SASL, pour l’accès à un annuaire LDAP. Le but étant de d’offrir
un accès à l’annuaire LDAP pour les utilisateurs disposant d’un ticket Kerberos
valide.
Configuration de la maquette :
Pour mettre en œuvre cette architecture nous avons disposé de deux postes de
travail reliés au réseau de l’INT. Nous avons utilisé le réseau de l’INT de façon à
bénéficier du serveur DNS de l’INT pour la résolution des noms de machines.
Ces deux postes fonctionnent sous une distribution Linux RedHat 9.
DNS INT
mci-0475e84aa8.int-evry.fr
mci-0475e2d1ae.int-evry.fr
- Kerberos Kadmin
- Kerberos KDC
- Cyrus SASL
- OpenSSL
- Client FTP « kerbérisé »
- Client Telnet « kerbérisé »
- Client OpenLDAP
- Kerberos Workstation
- Cyrus SASL
- OpenSSL
- Serveur FTP « kerbérisé »
- Serveur Telnet « kerbérisé »
- Serveur openLDAP
Le premier poste nous a servi de serveur Kerberos (KDC et TGS) et de client pour
accéder aux services « kerbérisés » de l’autre serveur.
Sur le second poste nous avons installé les différents services « kerbérisés » (Telnet,
FTP), ainsi que la base OpenLDAP dont l’authentification Kerberos sera effectuée
par SASL.
19
3.2 Installation
Dans cette partie nous allons décrire l’installation et la configuration des différents
logiciels.
Pour faciliter l’installation de certains composants nous avons installé l’utilitaire aptget sous RedHat (http://apt.freshrpms.net/).
3.2.1 Installation de OpenSSL et création de certificats
Afin de sécuriser les échanges avec l’annuaire LDAP, nous pouvons utiliser SSL et
TLS. De plus, Kerberos et SASL utilisent des fonctions cryptographiques faisant
appel à des librairies de OpenSSL.
La première étape consiste donc à installer les librairies OpenSSL. L’installation est
automatique à l’aide de la commande : apt-get install openssl
Nous commençons par générer un certificat pour notre serveur hébergeant les
services. Ce certificat va être auto-signé, il faut pour cela générer un certificat
d’Autorité de Certification (CA). Cette opération est réalisée à l’aide de OpenSSL et
nous créons ainsi un certificat de CA : demoCA/cacert.pem
Puis, nous générons un certificat pour notre serveur que nous signons avec le
certificat du CA que nous venons de créer.
Nous obtenons ainsi un certificat : server.crt.pem et une clé privée pour notre
serveur : server.key.pem
Ces trois certificats ainsi crées sont placé dans le répertoire : /etc/openldap/certs/
et servirons ensuite pour la configuration de SSL/TLS avec OpenLDAP.
(Le détail de la création de ces certificats est donné dans l’annexe A)
20
3.2.2 Installation Kerberos V
3.2.2.1
Installation des composants :
La dernière version de Kerberos est la version 5, elle peut être récupérée à partir du
site du MIT (http://web.mit.edu/kerberos/www/) ou bien à l’aide de apt-get sous
RedHat.
Avec la commande « apt-cache search kerberos » on affiche la liste de tous les
éléments Kerberos installables :
- krb5-devel
- krb5-lib
- krb5-serveur
- krb5-workstation
On installe ces divers éléments sur le serveur Kerberos à l’aide de la commande
« apt-get install <element> ».
Sur les postes utilisant Kerberos pour authentifier des utilisateurs ou hébergeant des
services « kerbérisés », il faut également installer les éléments krb5-lib et krb5workstation.
3.2.2.2
Configuration du fichier krb5.conf :
Le fichier /etc/krb5.conf est le fichier de paramétrage du serveur Kerberos, il permet
de configurer le « royaume » Kerberos, les algorithmes de chiffrement utilisés ou
encore l’adresse du KDC.
(Le fichier krb5.conf est donné en annexe de ce rapport).
¾ Dans la partie [ logging ], on renseigne le chemin vers les fichiers de log.
¾
Dans la partie [ libdefaults ], on paramètre les tickets Kerberos.
Il faut s’assurer que la ligne suivante est bien présente et que le fichier
krb5.keytab existe (sinon il faut le créer). Ce fichier permet au serveur de
stocker les services et hôtes auquel il peut accéder (stockage de la clé secrète
du service). Ce fichier doit également être présent sur tous les serveurs
hébergeant des services « kerbérisés ».
default_keytab_name = /etc/krb5.keytab
¾
Dans la partie [ realms ], on configure notre « royaume » Kerberos, en
indiquant l’adresse du KDC , l’adresse du serveur d’administration (kadmin) et
le nom de domaine par défaut :
[realms]
INT-EVRY.FR = {
kdc = mci-0475e84aa8.int-evry.fr:8800
admin_server = mci-0475e84aa8.int-evry.fr:7490
default_domain = int-evry.fr
}
21
¾
[ domain_realm ] permet de configurer notre « royaume » Kerberos et de
faire le lien avec notre nom de domaine.
[domain_realm]
.int-evry.fr = INT-EVRY.FR
int-evry.fr = INT-EVRY.FR
localhost = INT-EVRY.FR
¾ Enfin, [ kdc ] permet de configurer le chemin vers le fichier de configuration
du KDC (kdc.conf).
3.2.2.3
Configuration du fichier kdc.conf :
Le fichier /var/kerberos/krb5kdc/kdc.conf permet de paramétrer le KDC (serveur
de distribution des clés). Il permet, par exemple, de régler la durée de vie des tickets
Kerberos ou les ports d’écoute du KDC pour notre « royaume » INT-EVRY.FR.
[kdcdefaults]
kdc_ports = 8800,7500
[realms]
INT-EVRY.FR = {
profile = /etc/krb5.conf
database_name = /var/kerberos/krb5kdc/principal
admin_keytab = /var/kerberos/krb5kdc/kadm5.keytab
acl_file = /var/kerberos/krb5kdc/kadm5.acl
kadmind_port = 7490
kdc_ports = 8800
max_life = 8h 0m 0s
max_renewable_life = 7d 0h 0m 0s
default_principal_flags = +preauth
}
Il faut s’assurer que les chemins vers les différents fichiers indiqués sont
corrects. En fonction de la version du système d’exploitation ou des options
d’installation, ces chemins peuvent être modifiés.
3.2.2.4
Création de la base Kerberos pour notre « royaume » :
Nous allons maintenant créer notre base de donnée Kerberos à l’aide de la
commande :
[root@mci-0475e84aa8 root]# kdb5_util create -s
Le système demande alors un mot de passe pour l’administrateur de la base.
On lance ensuite les différents services Kerberos :
[root@mci-0475e84aa8 root]# /sbin/service krb5kdc
[root@mci-0475e84aa8 root]# /sbin/service Kadmin
start
start
22
3.2.2.5
Configuration du fichier kadm5.acl :
Une fois la base Kerberos créée, il faut donner des droits d’accès à certains
utilisateurs privilégiés comme les administrateurs.
Le ficher /var/kerberos/krb5kdc/kadm5.acl définit les droits d’accès des utilisateurs
à la base Kerberos.
Nous allons ainsi donner tous les droits sur la base aux « principals » :
<nom>/[email protected]
Dans le fichier kadm5.acl, on place la ligne :
*/[email protected] *
3.2.2.6
Création des utilisateurs et des administrateurs Kerberos
Nous allons créer des utilisateurs et des administrateurs pour la base Kerberos. Les
utilisateurs peuvent utiliser les services « kerbérisés » alors que les administrateurs
peuvent modifier cette base (créer, supprimer ou modifier des « principals »).
Nous avons choisi de définir les administrateurs selon le schéma :
<nom>/[email protected] (en accord avec les ACL définies dans la partie
précédente). Ainsi, l’administrateur root sera nommé : root/[email protected]
De même, l’élève Dupond
dupond/[email protected]
(simple
utilisateur)
pourrait
être
nommé :
Il faut entrer ces « principals » dans la base Kerberos à l’aide de l’utilitaire kadmin.
Etant donné que aucun administrateur n’a encore été défini, la seule façon d’accéder
à kadmin et de le lancer en local sur le serveur Kerberos avec la commande :
kadmin.local
shell% kadmin.local
On peut ensuite ajouter un “principal” sous kadmin à l’aide de la commande
« addprinc <principal> » :
kadmin.local: addprinc root/[email protected]
NOTICE: no policy specified for "root/[email protected]";
assigning "default".
Le serveur Kerberos demande alors de saisir un mot de passe pour cet utilisateur (un
hash de ce mot de passe va générer la clé sécrète associée à ce principal) :
Enter password for principal root/[email protected]:
Re-enter password for principal root/[email protected]:
Un message informe que le principal a bien été créé et on peut alors quitter kadmin
avec la commande “quit” :
Principal "root/[email protected]" created.
kadmin.local: quit
On créé ainsi les différents utilisateurs et administrateurs de la base Kerberos.
23
Maintenant que les administrateurs sont inscrits dans la base Kerberos, on peut
accéder à distance au serveur kadmin. Il suffit d’installer les packages Kerberos sur
un poste distant et d’y copier nos fichiers de configuration. Depuis ce poste distant,
on peut maintenant accéder à kadmin (plus besoin de la commande kadmin.local).
Mais il faut pour cela disposer d’un ticket Kerberos valide.
Pour obtenir un ticket Kerberos, on tape la commande « kinit <principal> », le
système demande alors à l’utilisateur d’entrer son mot de passe :
Pour consulter la liste des tickets Kerberos qu’il possède, un utilisateur peut taper la
commande « klist » :
A tout moment l’utilisateur peut détruire son ticket à l’aide de la commande
« kdestroy ».
3.2.3 Installation Cyrus SASL
La librairie Cyrus SASL va permettre de coupler l’authentification Kerberos avec
l’accès à l’annuaire LDAP.
Pour une authentification de type Kerberos V, c’est le mode GSSAPI (Generic
Security Service Application Program Interface) de SASL qui doit être utilisé.
Le package d’installation de la bibliothèque cyrus-sasl peut être téléchargée sur le
site : http://asg.web.cmu.edu/sasl/
24
Il est important d’installer la dernière version (2.1.18 ou +) qui offre une meilleure
compatibilité avec OpenLDAP.
Une fois le package téléchargé et « dépackagé » l’installation se fait de la façon
suivante :
# ./configure [options]
La liste des options de configuration peut être affichée à l’aide de la commande :
./configure --help
Dans notre cas, nous avons utilisé les options :
./configure
--enable-ano
–-prefix=/usr
–-disable-krb4
–-with-openssl=/usr/include
–-enable-gssapi
On peut ensuite installer la bibliothèque :
# make
# make install
Arrivé à ce point, et avant de passer à l’installation et la configuration de
OpenLDAP, il peut être intéressant d’effectuer des tests de la combinaison
Kerberos/SASL-GSAPI avec des services simples comme FTP et Telnet.
Ceci doit permettre de s’assurer que tout a était jusqu’ici bien configuré. Le
détail de ces tests est donné dans la partie suivante (4.1)
3.2.4 Installation de OpenLDAP
Une fois tous ces composants installés, nous pouvons passer à l’installation du
serveur OpenLDAP.
La dernière version de OpenLDAP peut être téléchargée à partir de l’adresse :
http://www.openldap.org/
Après avoir décompressé le fichier, l’installation s’effectue avec les commandes :
# ./configure [options]
Dans notre cas, nous avons utilisé les options :
./configure –-prefix=/usr –-with-tls –-enable-slapd –-withcyrus-sasl –-enable-crypt –-enable-ldbm –-enable-bdb=no
On procède ensuite à l’installation :
# make
# make depend
# make install
25
Une fois l’installation effectuée, il faut éditer les fichiers /etc/openldap/slpad.conf et
/etc/openldap/ldap.conf pour paramétrer l’annuaire.
3.2.4.1
Configuration du fichier ldap.conf :
Certaines modifications doivent être apportées au fichier ldap.conf :
¾ Configuration du nom d’hôte du serveur hébergeant l’annuaire :
# Your LDAP server. Must be resolvable without using LDAP.
HOST mci-0475e2d1ae.int-evry.fr
¾ Configuration de la base LDAP
# The distinguished name of the search base.
base dc=int-evry,dc=fr
¾ Ports pour accéder à l’annuaire (en mode normal, SSL ou TLS)
# The port.
# Optional: default is 389.
port 389
port 636
# normal et TLS
# SSL
¾ Activer cryptage TLS/SSL (pointer vers les certificats créés pour notre CA)
# OpenLDAP SSL mechanism
# start_tls mechanism uses the normal LDAP port, LDAPS typically 636
ssl start_tls
# OpenLDAP SSL options
# Require and verify server certificate (yes/no)
# Default is "no"
tls_checkpeer yes
# CA certificates for server certificate verification
# At least one of these are required if tls_checkpeer is "yes"
tls_cacertfile /etc/openldap/certs/cacert.pem
#tls_cacertdir /etc/ssl/certs
¾ Désactiver l’authentification du client par TLS/SSL
# Client certificate and key
# Use these, if your server requires client authentication.
#tls_cert
#tls_key
ssl no
(Le fichier ldap.conf que nous avons utilisé est donné en annexe C)
26
3.2.4.2
Configuration du fichier slapd.conf :
Certaines modifications doivent être apportées au fichier sladp.conf :
¾ Ajouter le schéma Kerberos V pour l’authentification
include
/etc/openldap/schema/krb5-kdc.schema
¾ Configurer la référence vers l’annuaire LDAP
# Do not enable referrals until AFTER you have a working
# directory service AND an understanding of referrals.
referral
ldap://mci-0475e2d1ae.int-evry.fr
¾ Ajouter les chemins d’accès aux certificats OpenSSL pour l’utilisation du
cryptage SSL/TLS :
#
# The next three lines allow use of TLS for connections using a
# dummy test certificate, but you should generate a proper
# certificate by changing to /usr/share/ssl/certs, running
# "make slapd.pem", and fixing permissions on
TLSCipherSuite
HIGH:MEDIUM:+SSLv2
TLSCertificateFile
/etc/openldap/certs/server.crt.pem
TLSCertificateKeyFile
/etc/openldap/certs/server.key.pem
TLSCACertificateFile
/etc/openldap/certs/cacert.pem
TLSVerifyClient
never
¾ Activation de la méthode d’authentification SASL, avec déclaration du
« royaume » (reaml) Kerberos et l’adresse du serveur LDAP :
sasl-realm
sasl-host
INT-EVRY.FR
¾ Définitions des listes d’accès et des droits utilisateur :
# Write access to principals Manager and */admin , default read
# access for everything else
access to *
by dn="uid=[^/]+/admin\+(realm=INT-EVRY\.FR)?" write
by dn="uid=Manager\+(realm=INT-EVRY\.FR)?"
write
by *
read
¾ Paramétrage de l’annuaire et de l’administrateur :
database
suffix
#suffix
rootdn
#rootdn
#
#
#
#
#
ldbm
"dc=int-evry,dc=fr"
"o=My Organization Name,c=US"
"cn=Manager,dc=int-evry,dc=fr"
"cn=Manager,o=My Organization Name,c=US"
Cleartext passwords, especially for the rootdn, should
be avoided. See slappasswd(8) and slapd.conf(5) for details.
Use of strong authentication encouraged.
rootpw
manager
rootpw
{crypt}ijFYNcSNctBYg
27
3.2.4.3
Lancement du serveur LDAP :
LDAP est un service tournant sur le poste, par conséquent il peut être démarré à
l’aide de la commande :
[root@mci-0475e2d1ae root]# /sbin/service ldap start
Mais il peut également être lancé avec la commande :
[root@mci-0475e2d1ae root]# slapd start
On peut également spécifier le port d’écoute (389 en normal ou avec TLS, 636 avec
SSL) à l’aide de l’option « -h » :
Normal/TLS: [root@mci-0475e2d1ae root]# slapd –h ldap:///
SSL:
[root@mci-0475e2d1ae root]# slapd –h ldaps:///
Une méthode efficace pour vérifier si le service est bien en écoute sur le port
souhaité est d’utiliser la commande nmap :
[root@mci-0475e2d1ae root]# nmap localhost
3.2.4.4
Création d’un principal LDAP dans la base Kerberos
De façon à permettre l’authentification des utilisateurs de l’annuaire LDAP à travers
Kerberos, il faut créer un principal correspond au service LDAP dans la base
Kerberos avec l’utilitaire kadmin :
kadmin : addprinc -randkey ldap/mci-0475e2d1ae.int-evry.fr
28
La clé privée du service est générée de façon aléatoire et stockée dans le fichier
cache krb5.keytab sur le serveur LDAP ainsi que sur le serveur Kerberos :
kadmin : ktadd –k /etc/krb5.keytab ldap/mci-0475e2d1ae.int-evry.fr
De plus sur on doit ajouter dans le fichier krb5.keytab du serveur LDAP les
« principals » des hôtes autorisés à se connecter à l’annuaire :
kadmin : ktadd –k /etc/krb5.keytab host/ mci-0475e84aa8.int-evry.fr
3.2.4.5
Initialisation de la base LDAP :
On initialise la base LDAP à l’aide d’un fichier init.ldif :
# Racine de la base
dn: dc=int-evry,dc=fr
objectclass: top
objectclass: dcObject
objectclass: organization
o: Guessant
dc: guessant
# Définition de l’administrateur
dn: cn=Manager,dc=int-evry,dc=fr
objectclass: organizationalRole
cn: Manager
# Ajout d’un utilisateur
dn: uid=jdupond,ou=people,dc=int-evry,dc=fr
objectClass: inetOrgPerson
cn: Jean Dupond
givenName: Jean
sn: Dupond
mail: [email protected]
telephoneNumber: +33 6 01 01 98
title: DSI
uid: jdupond
userPassword: 1r2ewu65ZEm9ePs56
Le fichier init.ldif est importé dans la base à l’aide de la commande :
ldapadd -H ldap://mci-0475e2d1ae.int-evry.fr/ -I -f init.ldif
Cette commande d’ajout ne fonctionnera que si l’utilisateur s’est authentifié auprès
de Kerberos (et dispose donc d’un ticket TGT valide).
De plus, l’utilisateur doit disposer de droits suffisants au niveau des listes d’accès
(voir partie suivante sur les listes d’accès LDAP). D’après notre fichier slpad.conf
nous autorisons l’accès en écriture à la base pour les « principals » : [email protected] et < * >/[email protected].
Explicitons les arguments de cette commande ldapadd :
o -H ldap://mci-0475e2d1ae.int-evry.fr/ : spécifie l’annuaire LDAP
vers lequel la requête doit être envoyée. L’option –ZZ pourrait être
ajoutée afin de crypter la requête avec TLS. De même, si l’on avait
spécifié l’adresse ldaps://mci-0475e2d1ae.int-evry.fr/ nous aurions
29
utilisé le cryptage SSL (à noter qu’il ne faut pas spécifier l’option –ZZ
dans ce cas).
o –I : Active l’authentification par SASL
o -f init.ldif : spécifie que c’est le contenu du fichier init.ldif qui doit
être ajouté la base LDAP.
3.2.4.6
A propos des listes d’accès de la base LDAP :
Les listes d’accès à la base LDAP sont définies dans le fichier slapd.conf. Nous
aurions également pu définir ces règles dans un fichier myldap.access et ajouter un
lien vers ce fichier dans splad.conf avec la commande : include /../…/myldap.access
Par défaut (c'est-à-dire s’il l’on modifie par les listes d’accès) tous les utilisateurs,
authentifiés ou non, ont accès en lecture sur la base et seul l’administrateur a un
accès en écriture.
Les listes d’accès sont définies selon le modèle :
Quoi ?
Qui ? Quel accès ?
Qui ? Quel accès ?
…
Selon la syntaxe :
Access to <partie de l’annuaire>
by <utilisateur>
<read/write/auth/none/…>
by <utilisateur>
<read/write/auth/none/…>
…
L’utilisateur correspond à la personne qui se connecte à la base, si aucune
authentification n’est demandée à l’utilisateur ce dernier est considéré comme
anonymous.
Lorsque nous utilisons Kerberos/SASL pour l’authentification, les utilisateurs
disposant de tickets TGT valides sont authentifiés et autorisés à accéder à la base.
Mais ces derniers n’étant pas connus par l’annuaire (sous le format :
[email protected]), ils sont considérés comme anonymes au niveau de LDAP
et ne disposent que de droits en lecture.
Il faut donc, au niveau des listes d’accès effectuer un mappage entre le principal
Kerberos et les utilisateurs LDAP :
access to *
write
by *
Dans la commande précédente « uid=Manager\+(realm=INT-EVRY\.FR)? » réalise ce
mappage entre le « principal » Kerberos : Manager, et un utilisateur authentifié dans
LDAP.
De même, "uid=[^/]+/admin\+(realm=INT-EVRY\.FR)?" représente tous les
« principals » définis comme <nom>/[email protected].
30
4 Tests
4.1 Test de services « kerbérisés » avec Kerberos V et SASL :
¾ FTP « kerbérisé » :
Le service FTP est d’ordinaire peu sécurisé puisque l’identifiant et le mot de passe
de l’utilisateur circulent en clair sur le réseau (cf. capture d’une trame FTP cidessous).
Trame FTP capturée avec Linkview entre le client et le serveur FTP, on voit que le l’identifiant et le
mot de passe de l’utilisateur circulent en clair sur le réseau.
Cette authentification peut être sécurisée par l’utilisation du couple Kerberos/SASL.
Kerberos se charge de l’authentification et SASL (à travers le mode GSSAPI) fait
correspondre cette authentification au niveau du serveur FTP.
Le package Kerberos-workstation doit être installé sur le serveur et sur le client
FTP ainsi que les fichiers de configurations Kerberos (krb5.conf et kdc.conf) avec
les mêmes paramètres que sur le serveur Kerberos.
De même, Cyrus-SASL doit être installé sur les deux postes, avec la prise en charge
de GSSAPI comme mécanisme d’authentification.
Il faut ensuite créer dans la base Kerberos un « principal » correspondant au serveur
FTP : ftp/[email protected] (avec mci-0475e2d1ae.intevry.fr le nom du poste hébergeant le serveur FTP, tel qu’il est déclaré dans le DNS).
Il s’agit d’un service et non d’un utilisateur, par conséquence le mot de passe
Kerberos ne pourra être saisi. Le mot de passe doit donc être généré de façon
aléatoire et enregistré dans le fichier cache krb5.keytab sur le serveur FTP.
Sur le serveur FTP, l’administrateur doit donc exécuter les commandes suivantes
sous kadmin :
[root@mci-0475e2d1ae root]# kadmin
kadmin : ank -randkey ftp/mci-0475e2d1ae.int-evry.fr
kadmin : ktadd –k /etc/krb5.keytab ftp/mci-0475e2d1ae.int-evry.fr
31
De la même façon, on doit ajouter dans la base Kerberos des « principals »
correspondant aux postes devant accéder au serveur FTP. Ces postes sont déclarés
de la façon suivante : host/<hostname>@REAML.KRB
De plus ces postes doivent être inclus dans le cache krb5.keytab du serveur FTP.
[root@mci-0475e2d1ae root]# kadmin
kadmin : ank -randkey host/mci-0475e84aa8.int-evry.fr
kadmin : ktadd –k /etc/krb5.keytab host/mci-0475e84aa8.int-evry.fr
Il reste ensuite à créer un ticket Kerberos sur l’hôte hébergeant le serveur FTP avec
la commande kinit.
Les utilisateurs authentifiés par Kerberos accéderont au serveur FTP en tant que
root, certains systèmes (comme RedHat) interdisent, par défaut, l’accès au FTP en
tant que root. Nous avons donc du modifier le fichier /etc/ftpuser pour supprimer cette
interdiction.
L’utilisateur qui souhaite accéder au serveur FTP doit avant tout obtenir un ticket
TGT auprès de Kerberos à l’aide de commande kinit :
Il peut ensuite accéder au serveur FTP et être authentifié avec le mécanisme
GSSAPI de SASL :
32
Une fois que l’utilisateur a accédé au moins une fois au serveur FTP, en tapant la
commande klist, on peut voir qu’un ticket correspondant au service FTP a était
généré :
En capturant des Kerberos/SASL, on trames FTP avec l’authentification s’assure que
la confidentialité des échanges est bien assurée :
¾ Telnet « kerbérisé » :
Pour la configuration de Telnet « kerbérisé » la configuration est à peu près
identique, le service Telnet doit être déclaré au niveau du serveur Kerberos comme :

host/mci-0475e2d1ae.int-evry.fr
De plus, sur le poste client la commande Telnet doit être lancée avec l’option « -a » :

telnet –a mci-0475e2d1ae.int-evry.fr
33
Capture avec Linkview d’une trame Telnet « kerbérisée ».
4.2 Test de OpenLDAP
Dans cette dernière phase du projet, nous avons réalisé un ensemble de tests pour
s’assurer du bon fonctionnement de l’annuaire LDAP avec la méthode
d’authentification Kerberos/SASL.
4.2.1 Affichage des mécanismes d’authentification supportés :
Dans ce premier test, nous avons fait afficher par l’annuaire les différents
mécanismes d’authentification qu’il supporte. C’est en fait une simple requête de
recherche que nous avons testée sous différents modes :
- Connexion anonyme à l’annuaire (ldapsearch avec option –x)
- Connexion anonyme avec cryptage SSL/TLS des échanges.
- Connexion Kerberos/SASL-GSSAPI (option –I)
Le détail de ce test est donné en annexe de ce rapport.
On remarque qu’avec l’authentification Kerberos/SASL, le fait que l’utilisateur
dispose d’un ticket Kerberos valide suffit à l’authentifier auprès de l’annuaire LDAP.
Le concept de SSO semble bien fonctionner.
Les modes SSL/TLS sont implémentables avec OpenLDAP et permettent de chiffrer
les échanges. Ils ne permettent toutefois pas de simplifier le mécanisme
d’authentification de l’utilisateur qui doit toujours s’identifier auprès de LDAP.
34
4.2.2 Tests de recherches dans l’annuaire
Nous avons ensuite effectué une recherche sur le contenu de la base LDAP. La
requête consiste à afficher tous les utilisateurs enregistrés dans l’annuaire. Nous
avons employé la méthode d’authentification Kerberos/SASL-GSSAPI avec un
cryptage des échanges basé sur SSL (ldaps://).
Avant de lancer la recherche nous obtenu un ticket TGT valide auprès du serveur
Kerberos.
La requête donne le résultat suivant :
[root@mci-0475e2d1ae cyrus-sasl-2.1.18]# ldapsearch -H ldaps://mci0475e2d1ae.int-evry.fr/ "uid=*"
SASL/GSSAPI authentication started
SASL SSF: 56
SASL installing layers
version: 2
#
# filter: uid=*
# requesting: ALL
#
# jdupond, people, int-evry, fr
cn: Jean Dupond
givenName: Jean
sn: Dupond
title: DSI
uid: jdupond
userPassword:: 1r2ewu65ZEm9ePs56
# search result
search: 5
result: 0 Success
# numResponses: 2
# numEntries: 1
L’authentification SASL a bien fonctionné et l’annuaire nous à renvoyé la liste des
utilisateurs qu’elle contient (un seul utilisateur : jdupond).
Les premières lignes décrivent le mécanisme d’authentification SASL :
SASL SSF: 56
version: 2
« SASL SSF: 56 » désigne le fait que le cryptage utilisé lors de l’authentification
SASL est effectué à l’aide d’une clé de 56 bits. Ce qui est parfaitement logique
puisque Kerberos utilise le DES comme algorithme de chiffrement avec des clés de
56 bits.
35
4.2.3 Tests de modifications de la base
Jusqu’ici les tests que nous avons effectués ont consisté à effectuer des requêtes
ldapsearch (recherches) sur l’annuaire LDAP. Or, ces requêtes ne nécessitent que
des droits d’accès en lecture sur la base LDAP.
D’après le fichier slapd.conf (voir installation OpenLDAP) de notre annuaire nous
autorisons l’accès en lecture à tous les utilisateurs (authentifiés ou non). Ainsi, par
défaut, le fait d’être authentifié par la méthode SASL ne délivre qu’un accès
anonyme à la base (en lecture seule).
C’est pourquoi dans notre fichier slpad.conf nous avons rajouté les lignes :
access to *
write
by *
read
Ainsi les lignes 2 et 3 confèrent des accès en écriture sur toute la base aux
utilisateurs authentifiés par Kerberos (« principals ») : < * >/[email protected] et
[email protected]
Ainsi avec l’authentification SASL, si nous disposons d’un ticket TGT valide au nom
de [email protected] nous devrions pouvoir avoir des droits d’accès en
écriture sur la base.
Dans cette dernière série de test nous allons essayer d’illustrer toutes ces propriètés.
¾ Modification de l’entrée LDAP avec authentification SASL :
Pour modifier une entrée de la base LDAP on utilise la commande « ldapmodify ».
Avec l’option « –f <fichier> » cette commande compare le contenu de <fichier> avec
l’annuaire et modifie la base en fonction.
Dans notre base initiale nous avions définit un utilisateur jdupond :
cn: Jean Dupond
givenName: Jean
sn: Dupond
title: DSI
uid: jdupond
userPassword:: 1r2ewu65ZEm9ePs56
36
Pour réaliser nos tests de modifications nous allons modifier cet enregistrement à
l’aide d’un fichier adduser1.ldif (où seul le numéro de téléphone de jdupond varie) :
# ------------------------------------------------------------------# Fichier adduser1.ldif.ldif
# ------------------------------------------------------------------dn: uid=jdupond,ou=people,dc=int-evry,dc=fr
cn: Jean Dupond
givenName: Jean
sn: Dupond
title: DSI
uid: jdupond
userPassword: 1r2ewu65ZEm9ePs56
# ----------------------------------------------
Ainsi, la commande « ldapmodify –f adduser1.ldif » devrait modifier le numéro de
téléphone de l’utilisateur jdupond dans la base LDAP.
On commence par récupérer un ticket TGT auprès du serveur Kerberos en tant que
[email protected] avec la commande :
[root@mci-0475e2d1ae home]# kinit [email protected]
Puis on envoie la requête « ldapmodify »à la base LDAP :
La modification semble avoir été prise en compte par l’annuaire. On peut visualiser le
contenu de la base LDAP à l’aide de l’outil ldapbrowser (interface graphique en
Java pour base LDAP : http://www.iit.edu/~gawojar/ldap/)
37
On voit que la modification de numéro de téléphone a bien été effectuée.
Si on essaye de détruire le ticket le ticket Kerberos, puis d’effectuer la modification à
nouveau, la connexion est refusée.
38
¾
Modification suivant différents modes d’authentification :
Nous allons maintenant tester de modifier les entrées LDAP en utilisant différents
modes d’authentification.
o Authentification SASL-GSSAPI avec cryptage TLS :
L’utilisateur qui souhaite se connecter dispose d’un ticket Kerberos valide
([email protected]), il souhaite modifier le titre de l’utilisateur jdupond (DSI en
RSSI) dans l’annuaire.
Il entre ainsi la commande :
[root@mci-0475e2d1ae home]# ldapmodify -H ldap://mci-0475e2d1ae.intevry.fr/ -ZZ
SASL SSF: 56
dn: uid=jdupond, ou=people, dc=int-evry, dc=fr
changetype: modify
replace: title
title: RSSI
modifying entry "uid=jdupond, ou=people, dc=int-evry, dc=fr"
La modification est alors effectuée avec succès. Ce qui est normal puisque le
« principal » [email protected] dispose de droits en écriture sur notre base
LDAP.
o
Authentification SASL-GSSAPI avec cryptage TLS sans ticket :
Pour ce deuxième test, nous supprimons notre ticket Kerberos puis nous effectuons
à nouveau le même test :
[root@mci-0475e2d1ae home]# kdestroy
[root@mci-0475e2d1ae home]# ldapmodify -H ldap://mci-0475e2d1ae.intevry.fr/ -ZZ
ldap_sasl_interactive_bind_s: Local error
L’accès à la base LDAP nous est alors refusé.
o Authentification simple/anonyme :
Nous allons maintenant tester des connexions anonymes sur l’annuaire LDAP. Pour
accèder de façon anonyme à la base on utilise l’option « -x » dans les requêtes
LDAP.
39
On commence par tester une recherche anonyme sur la base :
[root@mci-0475e2d1ae home]# ldapsearch -H ldap://mci-0475e2d1ae.intevry.fr/ -ZZ "uid=*" -x
version: 2
#
# filter: uid=*
# requesting: ALL
#
cn: Jean Dupond
givenName: Jean
sn: Dupond
uid: jdupond
userPassword:: NDVzNDU0ZHNkcXE=
title: RSSI
# search result
search: 3
result: 0 Success
# numResponses: 2
# numEntries: 1
La commande s’effectue sans problème puisque, dans la liste d’accès de notre base
LDAP, nous avons accordé un accès en lecture à tous les utilisateurs (même les
connexions anonymes).
Nous allons maintenant tenter d’effectuer une modification sur la base à partir d’une
connexion anonyme :
[root@mci-0475e2d1ae cyrus-sasl-2.1.18]# ldapmodify -H ldap://mci0475e2d1ae.int-evry.fr/ -ZZ -x
dn: uid=jdupond, ou=people, dc=int-evry, dc=fr
changetype: modify
replace: title
title: RSSI2
modifying entry "uid=jdupond, ou=people, dc=int-evry, dc=fr"
ldap_modify: Insufficient access
ldif_record() = 50
La connexion à l’annuaire est possible mais la requête de modification est refusée du
fait que nous n’ayons pas de droits en écriture (ldap_modify: Insufficient access)
sur la base (cf. connexion anonyme).
40
4.2.4 Captures de trames
Pour terminer notre série de test, nous avons réalisé quelques captures de trames
portant sur les échanges avec l’annuaire LDAP selon différents modes
d’authentification.
¾ Connexion simple à la base (anonyme et pas de cryptage) :
Dans ce cas on voit que les échanges passent en clair ainsi que le mot de passe (ici
nul).
¾ Connexion simple avec cryptage SSL :
En appliquant le cryptage avec SSL pour les échanges avec l’annuaire on assure la
confidentialité des échanges.
41
¾ Authentification Kerberos/SASL-GSSAPI (sans TLS/SSL) :
En utilisant l’authentification SASL, on voit que les informations de connexion ne
circulent pas en clair :
42
Conclusion
Au cours de ce projet de fin d’étude, nous avons vu la mise en place et l’utilisation du
protocole Kerberos pour sécuriser les mécanismes d’authentification.
Au premier abord, Kerberos apparaît comme compliqué à installer et à configurer.
Toutefois on trouve une grande quantité d’informations sur le sujet sur le site du MIT
ou sur Internet en général. La vraie difficulté de la mise en oeuvre de Kerberos réside
plutôt dans la « Kerbérisation » des applications.
Ce projet nous a permis de nous familiariser avec l’utilisation d’annuaires LDAP. Par
défaut, les annuaires LDAP sont peu sécurisés, les informations d’authentification
(utilisateur et mot de passe) circulent en clair sur le réseau.
Les échanges avec l’annuaire LDAP peuvent être cryptés à l’aide des protocoles
SSL/TLS qui sont pris en charge dans OpenLDAP. Ceci permet de sécuriser les
échanges et d’assurer la confidentialité des données. La mise en oeuvre de ces
protocoles est assez simple, puisqu’il suffit à partir des bibliothèques OpenSSL de
générer un ensemble de certificats et de clés et de configurer OpenLDAP en
fonction.
On pourrait alors se poser des questions sur l’intérêt de mettre en œuvre
l’authentification Kerberos/SASL sachant que SSL/TLS est bien plus simple à
déployer.
En fait, l’authentification Kerberos/SASL offre plus qu’une sécurisation des données
et des accès, il permet de mettre en oeuvre le concept de Single-Sign-On (SSO).
L’utilisateur s’authentifie une fois auprès de Kerberos et peut ensuite accéder à
l’ensemble des services « kerbérisés » sans avoir à s’authentifier de nouveau.
L’architecture Kerberos/SASL a pourtant quelques inconvénients. Avant tout, les
utilisateurs doivent être familiarisés avec la notion de ticket Kerberos les
commandes permettant de les manipuler (kinit, klist ou kestroy). Les applications ne
sont souvent pas nativement compatibles avec Kerberos, il faut soit les recompiler
soit utiliser des couches intermédiaires comme SASL. Ceci peut compliquer la phase
de déploiement des applications. De plus, le serveur Kerberos devient le point
sensible du réseau, si ce serveur tombe les utilisateurs ne pourront plus accéder à
aucun service. Il faut donc s’assurer que ce serveur est bien sécurisé et résiste aux
attaques de type déni de service.
Au final notre maquette simulant l’authentification de type Kerberos/SASL pour
l’accès à un serveur LDAP semble fonctionner correctement. Nous avons pu gérer
la notion de privilèges des utilisateurs grâce aux contrôles d’accès de LDAP
couplés aux « principals » Kerberos. Il serait intéressant de mettre en place cette
authentification à partir d’une infrastructure LDAP existante et conséquente. De
même, nous pourrions étudier ces mécanismes dans un environnement plus
hétérogène (postes et serveurs sous Linux, Windows ou Unix).
43
Annexe A : Génération des certificats sous OpenSSL
Génération du certificat du CA :
[root@mci-0475e2d1ae myCerts]# /usr/share/ssl/misc/CA -newca
CA certificate filename (or enter to create)
Making CA certificate ...
Generating a 1024 bit RSA private key
....++++++
.......++++++
writing new private key to './demoCA/private/./cakey.pem'
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:
----You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
----Country Name (2 letter code) [FR]:
State or Province Name (full name) [Essonne]:
Locality Name (eg, city) [EVRY]:
Organization Name (eg, company) [INT]:
Organizational Unit Name (eg, section) []:SSR
Common Name (eg, your name or your server's hostname) []:monCA
Email Address []:
Génération du certificat du serveur :
Pour le champ Common Name il est indispensable de saisir le hostname du
serveur tel qu’il est définit dans le DNS.
[root@mci-0475e2d1ae myCerts]# openssl req -nodes -out newreq.pem -keyout
newreq.pem -days 365 -newkey rsa:1024
Generating a 1024 bit RSA private key
............++++++
.........++++++
writing new private key to 'newreq.pem'
----You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
----Country Name (2 letter code) [FR]:
44
State or Province Name (full name) [Essonne]:
Locality Name (eg, city) [EVRY]:
Organization Name (eg, company) [INT]:
Organizational Unit Name (eg, section) []:SSR
Common Name (eg, your name or your server's hostname) []:mci0475e2d1ae.int-evry.fr
Email Address []:
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:intssr
An optional company name []:INT
Il faut ensuite signer le certificat du serveur avec le certificat de notre CA :
[root@mci-0475e2d1ae myCerts]# /usr/share/ssl/misc/CA -sign
Using configuration from /usr/share/ssl/openssl.cnf
Enter pass phrase for ./demoCA/private/cakey.pem:
Check that the request matches the signature
Signature ok
Certificate Details:
Serial Number: 1 (0x1)
Validity
Not Before: Jun 22 14:52:46 2004 GMT
Not After : Jun 22 14:52:46 2005 GMT
Subject:
countryName
= FR
stateOrProvinceName
= Essonne
localityName
= EVRY
organizationName
= INT
organizationalUnitName
= SSR
commonName
= mci-0475e2d1ae.int-evry.fr
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
Netscape Comment:
OpenSSL Generated Certificate
X509v3 Subject Key Identifier:
31:CD:4C:79:77:0B:B0:57:63:85:57:05:EE:05:8F:24:3E:D2:8A:08
X509v3 Authority Key Identifier:
keyid:E3:7F:D2:B5:B5:34:7B:BF:8E:A7:67:3B:88:1A:16:CE:B5:AB:D8:65
DirName:/C=FR/ST=Essonne/L=EVRY/O=INT/OU=SSR/CN=monCA
serial:00
Certificate is to be certified until Jun 22 14:52:46 2005 GMT (365 days)
Sign the certificate? [y/n]:y
1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Updated
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 1 (0x1)
Signature Algorithm: md5WithRSAEncryption
Issuer: C=FR, ST=Essonne, L=EVRY, O=INT, OU=SSR, CN=monCA
Validity
Not Before: Jun 22 14:52:46 2004 GMT
Not After : Jun 22 14:52:46 2005 GMT
45
Subject: C=FR, ST=Essonne, L=EVRY, O=INT, OU=SSR, CN=mci0475e2d1ae.int-evry.fr
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (1024 bit)
Modulus (1024 bit):
00:c3:dd:9d:c5:54:7f:eb:2c:f8:8f:6c:87:59:dd:
08:73:75:2f:1d:02:7e:ab:b4:ed:7c:88:3d:0b:a9:
bc:4a:a8:b1:88:85:ae:95:09:67:bf:7d:a5:31:43:
98:80:38:e1:9f:0c:6e:63:2b:2d:03:64:e8:3a:ac:
52:b1:f1:e7:a0:0c:b9:79:0c:6a:b9:42:d2:23:4f:
68:6d:a1:26:2a:c2:15:4a:5a:04:66:76:22:39:e3:
fe:14:68:84:61:06:6e:2c:1c:22:8a:e8:3f:f6:73:
71:4f:34:46:2c:88:e3:22:d5:f5:6a:88:25:78:e6:
75:ab:34:c0:af:21:19:01:05
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
Netscape Comment:
OpenSSL Generated Certificate
X509v3 Subject Key Identifier:
31:CD:4C:79:77:0B:B0:57:63:85:57:05:EE:05:8F:24:3E:D2:8A:08
X509v3 Authority Key Identifier:
keyid:E3:7F:D2:B5:B5:34:7B:BF:8E:A7:67:3B:88:1A:16:CE:B5:AB:D8:65
DirName:/C=FR/ST=Essonne/L=EVRY/O=INT/OU=SSR/CN=monCA
serial:00
Signature Algorithm: md5WithRSAEncryption
7f:36:8a:2b:ad:95:d7:83:cf:9c:e9:bd:bb:a7:fc:7e:43:9b:
d3:74:f1:02:c9:e4:0c:d1:51:e5:4a:1c:6c:14:db:6b:43:7e:
e8:7a:86:fc:91:56:08:1d:b5:0c:50:dc:68:0c:c7:a5:6d:6e:
83:80:c8:c2:1e:e9:c8:d5:37:39:a0:ec:f6:a3:90:67:c9:25:
41:a4:09:e5:50:56:d7:7e:63:76:90:e7:91:90:73:15:41:12:
ad:24:96:7f:5f:3f:35:d8:f1:14:06:2d:91:ec:6e:5a:70:cc:
58:dc:c2:31:bc:2d:b6:db:69:dc:ec:ec:0c:d9:3f:59:58:dc:
c9:33
-----BEGIN CERTIFICATE----MIIDIDCCAomgAwIBAgIBATANBgkqhkiG9w0BAQQFADBaMQswCQYDVQQGEwJGUjEQ
MA4GA1UECBMHRXNzb25uZTENMAsGA1UEBxMERVZSWTEMMAoGA1UEChMDSU5UMQww
CgYDVQQLEwNTU1IxDjAMBgNVBAMTBW1vbkNBMB4XDTA0MDYyMjE0NTI0NloXDTA1
MDYyMjE0NTI0NlowbzELMAkGA1UEBhMCRlIxEDAOBgNVBAgTB0Vzc29ubmUxDTAL
BgNVBAcTBEVWUlkxDDAKBgNVBAoTA0lOVDEMMAoGA1UECxMDU1NSMSMwIQYDVQQD
ExptY2ktMDQ3NWUyZDFhZS5pbnQtZXZyeS5mcjCBnzANBgkqhkiG9w0BAQEFAAOB
jQAwgYkCgYEAw92dxVR/6yz4j2yHWd0Ic3UvHQJ+q7TtfIg9C6m8SqixiIWulQln
v32lMUOYgDjhnwxuYystA2ToOqxSsfHnoAy5eQxquULSI09obaEmKsIVSloEZnYi
OeP+FGiEYQZuLBwiiug/9nNxTzRGLIjjItX1aogleOZ1qzTAryEZAQUCAwEAAaOB
4DCB3TAJBgNVHRMEAjAAMCwGCWCGSAGG+EIBDQQfFh1PcGVuU1NMIEdlbmVyYXRl
ZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUMc1MeXcLsFdjhVcF7gWPJD7SiggwgYIG
A1UdIwR7MHmAFON/0rW1NHu/jqdnO4gaFs61q9hloV6kXDBaMQswCQYDVQQGEwJG
UjEQMA4GA1UECBMHRXNzb25uZTENMAsGA1UEBxMERVZSWTEMMAoGA1UEChMDSU5U
MQwwCgYDVQQLEwNTU1IxDjAMBgNVBAMTBW1vbkNBggEAMA0GCSqGSIb3DQEBBAUA
A4GBAH82iiutldeDz5zpvbun/H5Dm9N08QLJ5AzRUeVKHGwU22tDfuh6hvyRVggd
tQxQ3GgMx6VtboOAyMIe6cjVNzmg7PajkGfJJUGkCeVQVtd+Y3aQ55GQcxVBEq0k
ln9fPzXY8RQGLZHsblpwzFjcwjG8Lbbbadzs7AzZP1lY3Mkz
-----END CERTIFICATE----Signed certificate is in newcert.pem
46
Déplacement des certificats pour leur utilisation avec OpenLDAP :
Il reste à renommer les certificats ainsi générés et les déplacer vers le répertoire
/etc/openldap/certs (cette opération doit être effectuée après l’installation de
OpenLDAP) :
# certificat de CA
cp demoCA/cacert.pem /etc/openldap/certs/
# Déplacement du certificat serveur
mv newcert.pem /etc/openldap/certs/server.crt.pem
# Déplacement de la clé privée du serveur
mv newreq.pem /etc/openldap/certs/server.key.pem
# L'utilisateur qui lance slapd de openLDAP doit pouvoir lire le certificat
et la clé privée (par défaut ldap)
chown ldap:ldap /etc/openldap/certs/server.*.pem
# La clé privée ne doit être lisible uniquement par cet utilisateur
chmod u=r,go= /etc/openldap/certs/server.key.pem
47
Annexe B : Fichiers configuration Kerberos V
1 Fichier krb5.conf :
[logging]
default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log
[libdefaults]
ticket_lifetime = 24000
default_realm = INT-EVRY.FR
default_keytab_name = /etc/krb5.keytab
default_tgs_enctypes = des3-hmac-sha1 des-cbc-crc
default_tkt_enctypes = des3-hmac-sha1 des-cbc-crc
permitted_enctypes = des3-hmac-sha1 des-cbc-crc
dns_lookup_realm = false
dns_lookup_kdc = false
kdc_req_checksum_type = 2
checksum_type = 2
ccache_type = 1
forwardable = true
proxiable = true
[realms]
INT-EVRY.FR = {
kdc = mci-0475e84aa8.int-evry.fr:8800
admin_server = mci-0475e84aa8.int-evry.fr:7490
default_domain = int-evry.fr
}
[domain_realm]
.int-evry.fr = INT-EVRY.FR
int-evry.fr = INT-EVRY.FR
localhost = INT-EVRY.FR
[kdc]
profile = /var/kerberos/krb5kdc/kdc.conf
48
2 Fichier kdc.conf :
[kdcdefaults]
kdc_ports = 8800,7500
[realms]
INT-EVRY.FR = {
profile = /etc/krb5.conf
database_name = /var/kerberos/krb5kdc/principal
admin_keytab = /var/kerberos/krb5kdc/kadm5.keytab
acl_file = /var/kerberos/krb5kdc/kadm5.acl
kadmind_port = 7490
kdc_ports = 8800
max_life = 8h 0m 0s
max_renewable_life = 7d 0h 0m 0s
default_principal_flags = +preauth
}
49
Annexe C : Fichiers configuration LDAP
1 Fichier ldap.conf :
#
#
#
#
#
#
#
#
@(#)$Id: ldap.conf,v 1.24 2001/09/20 14:12:26 lukeh Exp $
This is the configuration file for the LDAP nameservice
switch library and the LDAP PAM module.
PADL Software
http://www.padl.com
# Your LDAP server. Must be resolvable without using LDAP.
HOST mci-0475e2d1ae.int-evry.fr
# The distinguished name of the search base.
base dc=int-evry,dc=fr
# Another way to specify your LDAP server is to provide an
# uri with the server name. This allows to use
# Unix Domain Sockets to connect to a local LDAP Server.
#uri ldap://127.0.0.1/
#uri ldaps://127.0.0.1/
#uri ldapi://%2fvar%2frun%2fldapi_sock/
# Note: %2f encodes the '/' used as directory separator
# The LDAP version to use (defaults to 3
# if supported by client library)
#ldap_version 3
# The distinguished name to bind to the server with.
# Optional: default is to bind anonymously.
#binddn cn=proxyuser,dc=example,dc=com
# The credentials to bind with.
# Optional: default is no credential.
#bindpw secret
# The distinguished name to bind to the server with
# if the effective user ID is root. Password is
# stored in /etc/ldap.secret (mode 600)
#rootbinddn cn=manager,dc=example,dc=com
# The port.
# Optional: default is 389.
port 389
port 636
# The search scope.
#scope sub
#scope one
#scope base
# Search timelimit
#timelimit 30
# Bind timelimit
50
#bind_timelimit 30
# Idle timelimit; client will close connections
# (nss_ldap only) if the server has not been contacted
# for the number of seconds specified below.
#idle_timelimit 3600
# Filter to AND with uid=%s
#pam_filter objectclass=account
# The user ID attribute (defaults to uid)
#pam_login_attribute uid
# Search the root DSE for the password policy (works
# with Netscape Directory Server)
#pam_lookup_policy yes
# Check the 'host' attribute for access control
# Default is no; if set to yes, and user has no
# value for the host attribute, and pam_ldap is
# configured for account management (authorization)
# then the user will not be allowed to login.
#pam_check_host_attr yes
# Group to enforce membership of
#pam_groupdn cn=PAM,ou=Groups,dc=example,dc=com
# Group member attribute
#pam_member_attribute uniquemember
# Specify a minium or maximum UID number allowed
#pam_min_uid 0
#pam_max_uid 0
# Template login attribute, default template user
# (can be overriden by value of former attribute
# in user's entry)
#pam_login_attribute userPrincipalName
#pam_template_login_attribute uid
#pam_template_login nobody
# HEADS UP: the pam_crypt, pam_nds_passwd,
# and pam_ad_passwd options are no
# longer supported.
# Do not hash the password at all; presume
# the directory server will do it, if
# necessary. This is the default.
#pam_password clear
# Hash password locally; required for University of
# Michigan LDAP server, and works with Netscape
# Directory Server if you're using the UNIX-Crypt
# hash mechanism and not using the NT Synchronization
# service.
#pam_password crypt
# Remove old password first, then update in
# cleartext. Necessary for use with Novell
# Directory Services (NDS)
#pam_password nds
# Update Active Directory password, by
51
# creating Unicode password and updating
# unicodePwd attribute.
#pam_password ad
# Use the OpenLDAP password change
# extended operation to update the password.
#pam_password exop
# RFC2307bis naming contexts
# Syntax:
# nss_base_XXX
base?scope?filter
# where scope is {base,one,sub}
# and filter is a filter to be &'d with the
# default filter.
# You can omit the suffix eg:
# nss_base_passwd
ou=People,
# to append the default base DN but this
# may incur a small performance impact.
#nss_base_passwd
ou=People,dc=example,dc=com?one
#nss_base_shadow
ou=People,dc=example,dc=com?one
#nss_base_group
ou=Group,dc=example,dc=com?one
#nss_base_hosts
ou=Hosts,dc=example,dc=com?one
#nss_base_services
ou=Services,dc=example,dc=com?one
#nss_base_networks
ou=Networks,dc=example,dc=com?one
#nss_base_protocols
ou=Protocols,dc=example,dc=com?one
#nss_base_rpc
ou=Rpc,dc=example,dc=com?one
#nss_base_ethers
ou=Ethers,dc=example,dc=com?one
#nss_base_netmasks
ou=Networks,dc=example,dc=com?ne
#nss_base_bootparams
ou=Ethers,dc=example,dc=com?one
#nss_base_aliases
ou=Aliases,dc=example,dc=com?one
#nss_base_netgroup
ou=Netgroup,dc=example,dc=com?one
# attribute/objectclass mapping
# Syntax:
#nss_map_attribute
rfc2307attribute
#nss_map_objectclass
rfc2307objectclass
mapped_attribute
mapped_objectclass
# configure --enable-nds is no longer supported.
# For NDS now do:
#nss_map_attribute uniqueMember member
# configure --enable-mssfu-schema is no longer supported.
# For MSSFU now do:
#nss_map_objectclass posixAccount User
#nss_map_attribute uid msSFUName
#nss_map_attribute uniqueMember posixMember
#nss_map_attribute userPassword msSFUPassword
#nss_map_attribute homeDirectory msSFUHomeDirectory
#nss_map_objectclass posixGroup Group
#pam_login_attribute msSFUName
#pam_filter objectclass=User
#pam_password ad
# configure --enable-authpassword is no longer supported
# For authPassword support, now do:
#nss_map_attribute userPassword authPassword
#pam_password nds
# For IBM SecureWay support, do:
#nss_map_objectclass posixAccount aixAccount
#nss_map_attribute uid userName
#nss_map_attribute gidNumber gid
#nss_map_attribute uidNumber uid
52
#nss_map_attribute userPassword passwordChar
#nss_map_objectclass posixGroup aixAccessGroup
#nss_map_attribute cn groupName
#nss_map_attribute uniqueMember member
#pam_login_attribute userName
#pam_filter objectclass=aixAccount
#pam_password clear
# Netscape SDK LDAPS
#ssl on
# Netscape SDK SSL options
#sslpath /etc/ssl/certs/cert7.db
# OpenLDAP SSL mechanism
# start_tls mechanism uses the normal LDAP port, LDAPS typically 636
ssl start_tls
#ssl on
# OpenLDAP SSL options
# Require and verify server certificate (yes/no)
# Default is "no"
tls_checkpeer yes
# CA certificates for server certificate verification
# At least one of these are required if tls_checkpeer is "yes"
tls_cacertfile /etc/openldap/certs/cacert.pem
#tls_cacertdir /etc/ssl/certs
#TLS_CACERT /etc/openldap/certs/cacert.pem
#TLS_REQCERT demand
# SSL cipher suite
# See man ciphers for syntax
#tls_ciphers TLSv1
# Client certificate and key
# Use these, if your server requires client authentication.
#tls_cert
#tls_key
ssl no
pam_password md5
53
2 Fichier slapd.conf :
# $OpenLDAP: pkg/ldap/servers/slapd/slapd.conf,v 1.8.8.7 2001/09/27
20:00:31 kurt Exp $
#
# See slapd.conf(5) for details on configuration options.
# This file should NOT be world readable.
#
include
/etc/openldap/schema/core.schema
include
/etc/openldap/schema/cosine.schema
include
/etc/openldap/schema/inetorgperson.schema
include
/etc/openldap/schema/nis.schema
include
/etc/openldap/schema/redhat/rfc822-MailMember.schema
include
/etc/openldap/schema/redhat/autofs.schema
include
/etc/openldap/schema/redhat/kerberosobject.schema
include
/etc/openldap/schema/krb5-kdc.schema
# Define global ACLs to disable default read access.
# Do not enable referrals until AFTER you have a working directory
# service AND an understanding of referrals.
referral
ldap://mci-0475e2d1ae.int-evry.fr
#pidfile
#argsfile
//var/run/slapd.pid
//var/run/slapd.args
# Create a replication log in /var/lib/ldap for use by slurpd.
#replogfile
/var/lib/ldap/master-slapd.replog
#
#
#
#
#
#
Load dynamic backend modules:
modulepath
/usr/sbin/openldap
moduleload
back_ldap.la
moduleload
back_ldbm.la
moduleload
back_passwd.la
moduleload
back_shell.la
#
# The next three lines allow use of TLS for connections using a dummy test
# certificate, but you should generate a proper certificate by changing to
# /usr/share/ssl/certs, running "make slapd.pem", and fixing permissions on
TLSCipherSuite
HIGH:MEDIUM:+SSLv2
TLSCertificateFile
/etc/openldap/certs/server.crt.pem
TLSCertificateKeyFile
/etc/openldap/certs/server.key.pem
TLSCACertificateFile
/etc/openldap/certs/cacert.pem
TLSVerifyClient never
sasl-realm
sasl-host
INT-EVRY.FR
# Write access to principals Manager and */admin , default read access for
everything else
access to *
by dn="uid=Manager\+(realm=INT-EVRY\.FR)?" write
by * read
#######################################################################
54
# ldbm database definitions
#######################################################################
database
suffix
#suffix
rootdn
#rootdn
#
#
#
#
#
ldbm
"dc=int-evry,dc=fr"
"o=My Organization Name,c=US"
"cn=Manager,dc=int-evry,dc=fr"
"cn=Manager,o=My Organization Name,c=US"
Cleartext passwords, especially for the rootdn, should
be avoided. See slappasswd(8) and slapd.conf(5) for details.
Use of strong authentication encouraged.
rootpw
manager
rootpw
{crypt}ijFYNcSNctBYg
# The database directory MUST exist prior to running slapd AND
# should only be accessible by the slapd/tools. Mode 700 recommended.
directory
/var/lib/ldap
# Indices to maintain
index
objectClass,uid,uidNumber,gidNumber,memberUid
index
cn,mail,surname,givenname
eq
eq,subinitial
# Replicas to which we should propagate changes
#replica host=ldap-1.example.com:389 tls=yes
#
bindmethod=sasl saslmech=GSSAPI
#
authcId=host/[email protected]
55
Annexe D - Tests sur OpenLDAP
Affichage des différents mécanismes supportés :
¾ Connexion anonyme (simple/anonymous bind) :
On test avant tout une connexion anonyme (option -x) vers l’annuaire :
[root@mci-0475e2d1ae root]# ldapsearch -h localhost -p 389 -x -b
"" -s base -LLL supportedSASLMechanisms
L’annuaire affiche bien une réponse à la requête => Connexion établie avec succès.
¾ Connexion anonyme sécurisée par SSL/TLS :
o TLS (option -ZZ ):
[root@mci-0475e2d1ae root]# ldapsearch -H ldap://mci-0475e2d1ae.intevry.fr/ -p 389 -x -b "" -s base -LLL -ZZ supportedSASLMechanisms
56
o SSL (ldaps://):
[root@mci-0475e2d1ae root]# ldapsearch -H ldaps://mci-0475e2d1ae.intevry.fr/ -x -b "" -s base -LLL supportedSASLMechanisms
¾ Authentification Kerberos/SASL :
o Sans ticket Kerberos :
[root@mci-0475e2d1ae root]# ldapsearch -H ldaps://mci-0475e2d1ae.intevry.fr/ -I -b "" -s base -LLL supportedSASLMechanisms
L’utilisateur ne disposant pas de ticket Kerberos valide, il est rejeté par
l’authentification SASL/GSSAPI.
o Création d'un ticket Kerberos et test de nouveau :
On tente maintenant d’obtenir un ticket en tant qu’utilisateur root/admin :
[root@mci-0475e2d1ae root]# kinit root/admin
57
On vérifie que le ticket à bien été accordé avec la commande : klist
On tente à nouveau de se connecter à l'annuaire LDAP. Lorsque le terminal
demande l'authorization name, on laisse le champ vide, laissant ainsi le soin de
l'authentification à GSSAPI :
L'accès à l'annuaire LDAP a alors était acceptée par l'intermédiaire de Kerberos. On
peut vérifier la présence d'un ticket LDAP sur le poste client avec, à nouveau, la
commande klist :
On remarque, ainsi, que l’utilisateur dispose maintenant d’un ticket Kerberos d’accès
à l’annuaire LDAP.
58
Références
o
Kerberos V :
o Kerberos V5 Installation guide, http://web.mit.edu/kerberos/www/krb51.3/krb5-1.3.3/doc/krb5-install.htm
o OpenAFS, Kerberos 5, LDAP and Linux,
http://www.arayan.com/da/yazi/OpenAFS_Kerberos_5.html
o
SASL :
o RFC 1964 : Simple Authentication and Security Layer (SASL),
http://www.ietf.org/rfc/rfc2222.txt
o Project Cyrus, http://asg.web.cmu.edu/cyrus/
o Authentication service or what is Cyrus-SASL,
http://postfix.state-ofmind.de/patrick.koetter/smtpauth/what_is_smtp_auth.html
o
LDAP :
RFC - Initial LDAP specs :
o RFC 1777 -- Lightweight Directory Access Protocol
o RFC 1778 -- The String Representation of Standard Attribute Syntaxes
o RFC 1779 -- String Representation of Distinguished Names
o RFC 1959 -- An LDAP URL Format (obsoleted by RFC 2255)
RFC - LDAP v3 specs :
o RFC 2251 -- Lightweight Directory Access Protocol (v3)
o RFC 2252 -- Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions
o RFC 2253 -- Lightweight Directory Access Protocol (v3): UTF-8 String Representation
of Distinguished Names
o RFC 2254 -- The String Representation of LDAP Search Filters
o RFC 2255 -- The LDAP URL Format
o RFC 2256 -- A Summary of the X.500(96) User Schema for use with LDAPv3
59
URL :
o LDAPMAN.ORG, http://ldapman.org
o OpenLDAP 2.0 Guide de l'administrateur, http://www.idealx.org/fr/doc/Open-LDAPfr/Open-LDAP-fr.html
o OpenLDAP, http://mguessan.free.fr/nt/openldap.html
o
LDAP v3 How to ?, http://www.bayour.com/LDAPv3-HOWTO.html
60