Intégration des Protocoles LDAP, Kerberos

et RADIUS

Plan :
1. Introduction (Objectifs du projet) :.....................................................1
1.1 Contexte du Projet..............................................................................1
1.2 Idée Globale du Projet.........................................................................2
1.3 Objectifs Techniques...........................................................................2
1.4 Public Cible et Cas d'Usage.................................................................3
2. Architecture (Schéma des serveurs + IPs) :.......................................4
2.1 Schéma d'Infrastructure.....................................................................4
2.1.1 Diagramme Global........................................................................4
2.1.2 Flux d'Authentification...............................................................6
3. Configuration Pas à Pas............................................................................7
3.1 Configuration du Serveur LDAP (OpenLDAP)....................................7
3.2 Configuration du Serveur Kerberos (MIT Kerberos).......................11
4.2 Configuration du Serveur RADUIS (FreeRADUIS)........................16
Conclusion..................................................................................................23

1. Introduction (Objectifs du projet) :

1.1 Contexte du Projet

Dans les environnements informatiques modernes, la gestion sécurisée
des identités et des accès est un enjeu critique. Les organisations
doivent garantir :

 Une authentification fiable des utilisateurs

 Une centralisation des comptes (éviter les doublons)

 Un contrôle d'accès granulaire aux ressources réseau

Les solutions traditionnelles (comptes locaux par machine) montrent leurs
limites :

 Complexité de gestion (mots de passe dispersés)

 Risques de sécurité (credentials faibles, audits difficiles)

 Manque de flexibilité (pas de Single Sign-On)

Ce projet propose une solution intégrée combinant :

 LDAP comme annuaire central (stockage des utilisateurs)

 Kerberos pour l'authentification forte (tickets chiffrés)

 RADIUS pour sécuriser l'accès réseau (Wi-Fi, VPN)

1.2 Idée Globale du Projet

1. LDAP :

o Centralise les comptes utilisateurs

(uid=user1,ou=users,dc=lab,dc=local).

o Stocke les mots de passe (optionnellement liés à Kerberos).

2. Kerberos :

o Génère des tickets TGT après authentification.

o Utilise LDAP comme backend pour les utilisateurs (si intégré).

3. RADIUS :

o Reçoit les requêtes d'accès réseau (ex: Wi-Fi).

o Vérifie les identifiants via LDAP ou Kerberos.

4. Client :

o Teste l'authentification via kinit (Kerberos) ou ldapsearch.

o Se connecte au Wi-Fi avec identifiants LDAP (via RADIUS).

1.3 Objectifs Techniques

1.3.1 Objectif Principal

Déployer une infrastructure d'authentification unifiée permettant :

 Aux utilisateurs de se connecter une seule fois (SSO) via Kerberos

 Aux administrateurs de gérer les comptes depuis un point unique

(LDAP)
  Au réseau de vérifier les accès dynamiquement (RADIUS)

1.3.2 Objectifs Spécifiques

1. LDAP (OpenLDAP) :

o Héberger un annuaire avec les comptes utilisateurs/groupes

o Structurer l'arborescence (dc=lab,dc=local, ou=users, etc.)

2. Kerberos (MIT Kerberos) :

o Configurer un royaume (realm) pour émettre des tickets TGT

o Intégrer LDAP comme source de vérité pour les utilisateurs

3. RADIUS (FreeRADIUS) :

o Authentifier les requêtes réseau (Wi-Fi, switchs)

o Utiliser LDAP/Kerberos comme backend d'authentification

4. Sécurité :

o Chiffrer les échanges (TLS pour LDAP, chiffrement Kerberos)

o Mettre en place des politiques de mots de passe

1.4 Public Cible et Cas d'Usage

1.4.1 Bénéficiaires

 Administrateurs systèmes : Gestion simplifiée des comptes

 Utilisateurs finaux : Expérience d'authentification transparente

(SSO)

 Équipe sécurité : Audit centralisé des accès

1.4.2 Scénarios d'Application

1. Accès aux postes de travail :

o Les employés se connectent une fois (Kerberos) et accèdent à

toutes les ressources autorisées.

2. Accès Wi-Fi sécurisé :

o Les identifiants LDAP servent à s'authentifier sur le réseau via

RADIUS.

3. Gestion des permissions :

 o Les groupes LDAP définissent les droits d'accès (ex : "compta",
"dev").

4. Technologies Choisies

Protocol
Logiciel Raison du Choix
e

Standard ouvert, flexible, bien

LDAP OpenLDAP
documenté

Kerbero MIT
Solution robuste pour le SSO
s Kerberos

FreeRADIU Compatible avec la majorité des

RADIUS
S équipements réseau
2. Architecture (Schéma des serveurs + IPs) :

2.1 Schéma d'Infrastructure

2.1.1 Diagramme Global

Figure 1 : Diagramme Global du Projet

Ce diagramme illustre l’interaction entre les trois serveurs principaux

(Kerberos, LDAP, RADIUS) dans le cadre d’une infrastructure
d’authentification centralisée, telle que mise en œuvre dans notre projet."

Tableau des Composants

Élément Rôle IP/URL Logiciel OS

Annuaire VM1-
ldap.My- CentO
central des 192.168.5.1 OpenLDAP
domaine.com S 10
utilisateurs 33

krb.My- Émission VM2- MIT CentO

domaine.com des tickets 192.168.5.1 Kerberos S 10
 Élément Rôle IP/URL Logiciel OS

Kerberos 34

Gestion des VM3-

radius.My- FreeRADIU CentO
accès 192.168.5.1
domaine.com S S 10
réseau 35

VM4-
Machine de Debian
Client1 192.168.5.1 -
test 12.9
29

Protocoles et Ports Utilisés

Por
Protocole Usage Chiffrement
t

Communication de Non (ou

LDAP 389
base StartTLS)

LDAPS 636 LDAP sécurisé TLS/SSL

Kerberos 88 Émission de tickets AES-256

181 Authentification RADIUS

RADIUS
2 réseau Encryption

2.1.2 Flux d'Authentification

 Figure 2 : Flux d’Authentification

1- Client → Kerberos: Demande un ticket (TGT) avec login/mot de passe.

2- Kerberos → LDAP: Vérifie l'utilisateur si intégré.
3- Client → RADIUS: Demande l'accès réseau (ex: Wi-Fi).
4- RADIUS → LDAP/Kerberos: Valide les credentials.
5- RADIUS → Client: Accès accordé/rejeté.

3. Configuration Pas à Pas

3.1 Configuration du Serveur LDAP (OpenLDAP)

Objectif :
Mettre en place un annuaire centralisé pour stocker les identifiants des
utilisateurs de manière sécurisée, et l’utiliser comme backend commun
pour Kerberos et RADIUS

Mise en Place du Serveur LDAP

Nous avons installé le serveur OpenLDAP sur une machine CentOS

(192.168.5.133). Une fois l’installation terminée, nous avons démarré le
service slapd et confirmé son bon fonctionnement.

- Configuration initiale du service slapd :

Pendant cette étape, les informations suivantes ont été définies :

 Nom de domaine : MY-DOMAINE.COM

 Organisation : My Organization

 Mot de passe administrateur LDAP : [défini pendant l’installation]

 Base DN générée automatiquement : dc=MY-DOMAINE,dc=COM

systemctl status slapd – Le service est actif

Sortie de la commande #systemctl status slapd, montrant que le service est actif (active
(running)).
- Ca confirme que le service LDAP (slapd) est lancé correctement, ce qui est essentiel pour la
suite des opérations (ajout des utilisateurs, intégration avec Kerberos ...)

- Structure de l’annuaire LDAP :

Nous avons construit une arborescence claire pour les utilisateurs, en respectant la hiérarchie
suivante :
Chaque utilisateur est représenté par une entrée LDAP contenant son nom, prénom, mot de
passe (hashé), etc.

- Ajout d’un utilisateur LDAP:

Nous avons créé un utilisateur nommé test1 avec les attributs suivants :

 uid: test1

 Nom Complet: Test User

 Mot de passe: chiffré (SSHA)

 homeDirectory: /home/test1

 loginShell: /bin/bash

 uidNumber et gidNumber: 10000

L’utilisateur appartient à la classe inetOrgPerson ainsi qu’aux classes nécessaires pour une
intégration Unix (posixAccount).

- Arborescence complète de l’annuaire LDAP :

Cette structure permet :

 La séparation claire entre utilisateurs (ou=users) et groupes (ou=groups).

 L’administration centrale via cn=Manager.

 L’utilisation des utilisateurs dans des environnements Unix/Linux grâce à la classe

posixAccount

 Arborescence complète obtenue via ldapsearch :

 - Connexion à distance :
Test de connexion à distance depuis une machine client Debian
(192.168.5.129)

Pour vérifier que le service LDAP est bien accessible depuis une autre
machine, nous avons exécuté la commande suivante :

# ldapsearch -x -H ldap://192.168.5.133 -D "cn=Manager,dc=my-

domain,dc=com" -W -b "dc=my-domain,dc=com"
 Résultat de ldapsearch depuis un client – preuve que la connexion fonctionne.

Conclusion de la configuration (LDAP)

Le serveur OpenLDAP est désormais fonctionnel. Il contient une structure

propre pour gérer les utilisateurs. Les clients peuvent interroger le serveur
à distance, ce qui permet son intégration avec d'autres services comme
Kerberos et RADIUS

3.2 Configuration du Serveur Kerberos (MIT Kerberos)

Objectif :
Mettre en place un système d’authentification centralisé basé sur des
tickets pour permettre le Single Sign-On (SSO) sous CentOS
(192.168.5.134) , avec intégration à LDAP comme source d'utilisateurs.

- Installation et Configuration de Kerberos

Nous avons utilisé MIT Kerberos. Voici les points clés de la configuration :
  Le Realm configuré : MY-DOMAIN.COM

 Le serveur KDC et l’admin server sont installés sur la même

machine.

 Le fichier principal de configuration : /etc/krb5.conf a été adapté

pour correspondre au domaine et aux services locaux.

- Fichier de configuration /etc/krb5.conf

Voici le contenu principal du fichier /etc/krb5.conf permettant l'intégration avec OpenLDAP :

 Contenu du fichier /etc/krb5.conf après modification

- Création et initialisation de la base de données KDC

Avant toute utilisation, nous avons initialisé la base de données Kerberos avec : #kdb5_util create -s

- 👤 Création de l’administrateur Kerberos

Nous avons créé un principal administrateur :

 Création réussie de l’utilisateur admin/admin

- Vérification des services Kerberos

Après configuration, nous avons vérifié que les services Kerberos fonctionnaient correctement

Le service krb5-kdc est actif et fonctionne normalement :

krb5-kdc :
➡️KDC (Key Distribution Center) est le cœur de Kerberos. Il permet de :

 Générer des tickets TGT après l'authentification.

 Valider l'identité de l'utilisateur.

 Fournir des tickets de service.

Le service krb5-admin-server est également actif :

krb5-admin-server :
Ce service est dédié à l’administration de la base de données Kerberos. Il
permet :

 L’ajout et la suppression de comptes (addprinc, delprinc...).

 La gestion des mots de passe.

 L’utilisation des commandes kadmin et kadmin.local

- Intégration de Kerberos avec LDAP

Kerberos est configuré pour utiliser OpenLDAP comme base de
données des identités, ce qui permet une centralisation complète de
l’authentification.

Voici un extrait du fichier de configuration /etc/krb5.conf :

 Contenu du fichier /etc/krb5.conf indiquant l'intégration entre

Kerberos et LDAP

Explication des champs clés :

 db_library = kldap : Indique que Kerberos va utiliser LDAP comme

base de données via la bibliothèque kldap.

 ldap_kadmind_dn : DN de l’utilisateur autorisé à gérer les entrées administratives

(via kadmin).

 ldap_kdc_dn : DN utilisé par le KDC pour accéder à LDAP.

  ldap_service_password_file : Fichier contenant le mot de passe
chiffré pour l’accès LDAP.

 ldap_servers : Adresse du serveur LDAP.

 ldap_conns_per_server : Nombre de connexions parallèles que Kerberos peut établir

avec le serveur LDAP.

- Connexion à distance :

Test d’authentification depuis un client Debian

Sur un poste client Debian 12.9 (192.168.5.129) , nous avons testé

l’authentification Kerberos avec un utilisateur existant dans
l’annuaire LDAP :

kinit [email protected]

Password for [email protected]

Authentification réussie — aucune erreur retournée, ce qui indique que le

ticket TGT a été délivré correctement.

Ensuite, nous avons utilisé klist pour vérifier la réception du ticket

: klist
 Le ticket TGT est bien délivré, valide pendant 10 heures, avec
une option de renouvellement jusqu'à 7 jours.

Cela prouve que l'utilisateur test1 est authentifié via Kerberos en

utilisant les informations provenant de LDAP : kinit test1

Klist :

Authentification réussie avec obtention du ticket TGT

Conclusion de la configuration (Kerberos)

Le serveur Kerberos est fonctionnel et bien intégré avec LDAP. Les
utilisateurs peuvent obtenir un ticket d’authentification (SSO) à partir de
leurs identifiants LDAP, ce qui simplifie la gestion des accès au sein de
l’infrastructure.

4.2 Configuration du Serveur RADUIS (FreeRADUIS)

Objectif :

 Authentifier, autoriser et enregistrer les accès des utilisateurs à un

réseau.

 Utilisé notamment pour les connexions VPN, WiFi sécurisé (802.1X),

ou l'accès aux ressources réseau.

 Dans notre projet, FreeRADIUS va servir comme point central

d'authentification réseau, en interagissant avec LDAP pour vérifier
les identifiants des utilisateurs.

Dans le cadre de notre infrastructure d’authentification centralisée,

FreeRADIUS sur a pour rôle de :

 📡 Recevoir les demandes d'accès réseau provenant des clients

(ex: point d'accès Wi-Fi).

 🔐 Interroger le serveur LDAP pour vérifier les identifiants des

utilisateurs.

 🧾 Assurer la traçabilité des connexions (qui s’est connecté, quand

et depuis quelle adresse IP).

 🔄 Servir d’intermédiaire entre le réseau et les services d’identité

(LDAP/Kerberos).

Concrètement, dans notre projet :

 Le client (machine virtuelle Debian (VM4-192.168..5.129) ) tente de

se connecter à un réseau ou un service contrôlé par FreeRADIUS.

 FreeRADIUS envoie la requête d’authentification vers le serveur

.

 Si l'identifiant et le mot de passe sont valides, l'accès est autorisé.

 Sinon, l'accès est refusé

« Cette configuration permet de centraliser l’accès réseau avec les mêmes

identifiants que ceux utilisés pour se connecter aux systèmes ou services
internes, assurant ainsi une meilleure gestion de la sécurité et des
utilisateurs. »

- Mise en Place du Serveur FreeRADUIS

Nous avons installé le serveur FreeRADUIS sur une machine CentOS
(VM3-192.168.5.135). Une fois l’installation terminée, nous avons démarré
le service slapd et confirmé son bon fonctionnement.

Vérification du statut du service :

 Le service FreeRADUIS fonctionne correctement

- Ouverture des ports :

Le serveur FreeRADIUS utilise par défaut les ports suivants :

 1812/udp : utilisé pour les requêtes d’authentification.

 1813/udp : utilisé pour les requêtes de comptabilisation

(accounting).

Ces ports doivent être ouverts dans le pare-feu (firewall) pour

permettre au serveur de recevoir les requêtes des clients (par exemple les
routeurs, les points d’accès Wi-Fi ou d'autres machines du réseau).

- Test du serveur avec un utilisateur local

 - testuser : nom de l’utilisateur à tester.
- password : mot de passe associé à cet utilisateur.
- localhost : adresse du serveur FreeRADIUS (ici on teste en
local).
- 0 : numéro de port NAS (arbitraire dans un test).
- testing123 : shared secret défini pour le client localhost dans
le fichier /etc/raddb/clients.conf

 Résultat : Received Access-Reject

Cela signifie que le serveur a bien reçu et traité la requête, mais n’a pas pu authentifier
l’utilisateur (ce qui est normal ici puisque testuser n'existe pas encore dans la base
locale ou LDAP).
C’est une bonne indication que le serveur fonctionne correctement et est prêt à être
relié à LDAP.

- Intégration de FreeRADIUS avec LDAP avec LDAP et Test depuis

la machine cliente

Dans cette étape, nous avons connecté le serveur FreeRADIUS à

l'annuaire LDAP afin d'utiliser les comptes utilisateurs LDAP pour
l’authentification. Ensuite, nous avons testé cette configuration depuis une
machine cliente (VM4).

1. Configuration du module LDAP dans FreeRADIUS

 Nous avons activé et configuré le module LDAP situé dans
/etc/raddb/mods-enabled/ldap.

 Le serveur LDAP utilisé est celui de l’adresse IP 192.168.5.133.

 Le compte d’admin LDAP utilisé pour la liaison est :

cn=Manager,dc=my-domain,dc=com avec le mot de passe
admin_password.
 - Pour que RADIUS puisse interroger l’annuaire LDAP à chaque
tentative d’authentification.

2. Déclaration de la machine cliente dans FreeRADIUS

Dans le fichier clients.conf, nous avons déclaré notre machine cliente VM4
avec :

Paramètre Valeur Description

192.168.5.1 Adresse IP du client (votre VM

ipaddr
36 Debian).

Mot de passe partagé pour

secret testing123 authentifier les requêtes RADIUS
(à changer en production).

Désactive la vérification de
require_message_authenticator no
signature pour simplifier les tests.

- Pour que FreeRADIUS reconnaisse et accepte les requêtes

envoyées depuis cette machine cliente.

3. Test du serveur avec un utilisateur existe dans LDAP

Le client envoie ses identifiants à RADIUS, qui les vérifie auprès du serveur LDAP
et accepte la connexion si les informations sont correctes.

Résultat :
Access-Accept → Le serveur RADIUS a accepté la connexion, ce qui signifie que
o L'utilisateur test1 existe dans la base (LDAP/Kerberos)

o Le mot de passe 12345678 est correct

Schéma de Ce Test :
Client → (envoie identifiants) → RADIUS → (vérifie avec LDAP) → Accepte

4. Test du serveur avec un utilisateur existe dans LDAP depuis la

machine cliente
Après avoir configuré le serveur FreeRADIUS pour qu'il utilise LDAP comme
source d’authentification, nous avons effectué un test
d’authentification à distance à partir de la machine cliente (VM4-
192.168.5.129) pour vérifier que tout fonctionne correctement.

Sur la machine cliente (VM4-192.168.5.129), nous avons utilisé la

commande radtest pour envoyer une requête d’authentification au serveur
RADIUS :
 Élément Description

Test1 Nom d’utilisateur présent dans LDAP

12345678 Mot de passe de l’utilisateur

192.168.5.135 Adresse IP du serveur FreeRADIUS

0 Numéro de port NAS simulé (peut être 0 pour un test)

Clé secrète définie dans le fichier clients.conf du

Testing123
serveur FreeRADIUS

Résultat attendu : Received Access-Accept

 Cela signifie que :

- Le client a envoyé une requête au serveur FreeRADIUS.
- Le serveur a consulté le serveur LDAP.
- Les identifiants étaient corrects.
- L’accès a été accepté

Conclusion De la configuration (RADUIS)

La configuration du serveur FreeRADIUS a été réalisée avec succès. Nous
avons intégré le serveur LDAP comme source d’authentification
centralisée. Grâce aux tests effectués avec la commande radtest depuis
une machine cliente, nous avons confirmé que :
  Le serveur FreeRADIUS répond correctement aux requêtes
d’authentification.

 L’authentification des utilisateurs via LDAP fonctionne parfaitement.

 La communication entre le client et le serveur est bien établie.

Cette configuration permet désormais un contrôle centralisé des accès

réseau, ce qui renforce la sécurité et simplifie la gestion des utilisateurs.

Conclusion

Ce projet visait à mettre en place une infrastructure d'authentification

unifiée en utilisant Kerberos, LDAP et RADIUS, afin de sécuriser l'accès aux
ressources réseau tout en centralisant la gestion des identités et des
permissions. Au terme de cette implémentation, les principaux objectifs
ont été atteints avec succès.

Résumé des configurations effectuées :

1. Kerberos (KDC) : La configuration du serveur Kerberos (KDC) a

permis d'établir un mécanisme d'authentification unique (SSO) pour
les utilisateurs. Cette solution garantit une sécurité renforcée grâce
à l'utilisation de tickets d'authentification pour chaque utilisateur,
évitant ainsi la gestion redondante des mots de passe.

2. LDAP (Lightweight Directory Access Protocol) : Le serveur

LDAP a été mis en place pour centraliser la gestion des comptes
utilisateurs et des informations d'annuaire. Il assure une gestion
structurée et sécurisée des identités au sein de l'organisation, et
permet une authentification rapide et efficace des utilisateurs à
travers le réseau.

3. RADIUS (Remote Authentication Dial-In User Service) : La

configuration de FreeRADIUS a permis de contrôler l'accès au réseau
en fonction des politiques définies par l'organisation. Cette solution
 garantit que seules les connexions autorisées puissent accéder aux
ressources réseau, tout en offrant des mécanismes d'audit et de
suivi des connexions.

Perspectives d'amélioration :

L'architecture mise en place peut être étendue pour intégrer des

mécanismes de sécurité supplémentaires, tels que la mise en place de
l'authentification multi-facteurs (MFA), et des outils de surveillance pour
détecter les tentatives d'accès non autorisées.