Ce document traite de la sécurité des accès aux systèmes d'information, en abordant des mécanismes tels que l'authentification, l'utilisation de mots de passe, et les techniques d'authentification forte. Il présente également divers protocoles comme Radius, TACACS+, et Kerberos, expliquant leur fonctionnement et leurs avantages. En outre, il détaille des concepts comme le Single Sign-On (SSO) et les différentes architectures d'authentification associées.

1. 1
S€curit€ des r€seaux
Chapitre 4 – S€curit€ des acc‚s

2. Sommaire
S€curit€ des Acc•s
• Authentification
– Mots de passe
– Authentification/Authentification forte
• Les protocoles / Utilisation
– RADIUS
– TACACS / TACACS+
– Kerberos
– 802.1x
2

3. Introduction
• La s€curit€ des acc•s fait intervenir un certain nombre de
m€canismes
– Filtrage des €changes par un Firewall
– Filtrage des €changes par un relais applicatif
– Authentification des tiers
• Algorithmes ‚ clefs publiques
• Nous allons d€velopper ce point en pr€sentant d’autres solutions
d’authentification
• Cette section a €galement pour but de pr€senter les protocoles
permettant de g€rer l’authentification et les acc•s au syst•me
d’information de l’entreprise
– Le concept du „ Single Sign On …
– Les protocoles RADIUS, TACACS, Kerberos
3

4. Authentification – Bases (1)
• Identification : Identit€ num€rique  Personne
– Chaque personne ayant acc•s au syst•me d’information doit se voir attribuer un
IDENTIFIANT UNIQUE
• L’authentification = Challenge
– L’authentification repose toujours sur un challenge lanc€ par le syst•me de
destination ‚ l’intention du client afin que celui-ci prouve sont identit€
• Mot de passe, clef priv€e, empreinte digitale, …
• La r€ussite du challenge valide l’association client  Identifiant
4
Qui Ätes vous ?
Prouvez le.
Dupond
= 1 identifiant
Mon mot de passe
est toto
OK, c'est DUPOND

5. Authentification – Bases (2)
• Trois m€thodes d’authentification
– La connaissance
• Secret connu (ex : mot de passe)
– La possession
• Possession d’un objet (ex: Carte, badge, clef)
– L’entit€
• Caract€ristique physique (ex :biom€trie)
• Prise une ‚ une ces techniques ont toutes des points
faibles,
– C’est la combinaison de plusieurs m€thodes
d’authentification qui permet de mettre en place des
solutions d’authentification forte
5

6. Mots de passe
• Utilisation de mots de passe
– Gestion Indispensable
• Cr€ation, Modification, D€blocage, Suppression
– Probl•me : stockage, transfert sur le r€seau, rejeu, m€morisation difficile pour
les utilisateurs, gestion pour l’administrateur
– Des r•gles simples rarement respect€es
• 8 caract•res minimum
• Non pr€dictible (Pr€nom, nom, identifiant, …)
• Renouvellement r€gulier
• Jamais €crit
– La plupart des intrusions ont pour origine un mot de passe trivial, un compte
syst•me ou applicatif ayant conserv€ son mot de passe par d€faut
6

7. Badges et cartes
• Cartes d’identit€ (sans mot de passe)
– Code barre, Carte magn€tique, puce
– Probl•mes :
• Copie, vol, liaison lecteur Serveur, rejeu
7
 Cartes d’identit• + mot de passe
 Authentification double facteur
 Probl‚mes :
 Liaison lecteur Serveur, rejeu
 En cas copie ou de vol le pirate doit ƒ simplement „
r€soudre un probl‚me de mot de passe

8. Mot de passe unique
• OTP (One Time Password)
– Mot de passe utilisable une seule fois
• Protection contre le rejeu
• Non pr€dictible si l’algorithme est gard€ secret
– Pour parer aux probl•mes de vol on adjoint souvent au code g€n€r€ un code
personnel (PIN)
– Plusieurs techniques
• Asynchrone (challenge/r€ponse)
– Envoi d’un challenge par le serveur, l’utilisateur poss•de une calculatrice qui
transforme le challenge en un mot de passe qu’il saisit. Le serveur fait la mˆme
op€ration et compare.
• Synchrone d€pendant du temps
– Le mot de passe est fonction du temps et est g€n€r€ ‚ intervalle r€gulier. Le challenge
(utilis€ dans le mode asynchrone) est en fait la date et l’heure.
• Synchrone ind€pendant du temps
– Utilisation d’un compteur interne ‚ la calculatrice incr€ment€ ‚ chaque utilisation. Le
serveur est synchronis€ sur ce compteur et n’accepte pas de code ant€rieur au
compteur
8

9. Biom€trie
• Se base sur les propri€t€s du corps humain et la faible
probabilit€ de trouver des caract€ristiques identiques sur
deux personnes diff€rentes
– S’assure de l’association physique de l’identifiant avec la personne
• Fond de l’œil, empreinte digitale, voix
– Probl•mes :
• Cr€ation des authentifiants (fiabilit€)
• Liaison lecteur  Serveur, rejeu
• Ne fonctionne pas avec le mat€riel
9

10. Authentification Unique
• SSO (Single Sign On)
– Le Single Sign On est une facilit€ permettant ‚ un utilisateur de ne
s’authentifier qu’une seule fois pour acc€der ‚ un ensemble de ressources
h€t€rog•nes ; on distingue :
• Le „ SSO Poste … appliqu€ aux autorisations pour l’acc•s aux serveurs
applicatifs du Syst•me d’information
• Le „ SSO Serveur … appliqu€ aux applications Web type Intranet, Services
Internet, …
– Le Single Sign On permet ‚ l’utilisateur de n’avoir qu’un seul mot de passe
pour l’acc•s ‚ un ensemble d’applications
• Le b€n€fice pour la s€curit€ est la r€duction du nombre de mots de passe ‚
m€moriser par l’utilisateur, €vitant en th€orie les mots de passe trop simples
ou €crits sur un papier
– Pour l’administrateur, la centralisation de la base des mots de passe
garantie une administration simplifi€e et homog•ne de la politique
d’authentification
10

11. Inconv€nients
• Le b€n€fice apport€ par le SSO en terme de s€curit€ est grandement att€nu€
par le fait qu’il permet de contourner d’une certaine mani•re le processus
d’authentification en l’automatisant
– Comment garantir que c’est bien l’utilisateur qui se trouve devant son poste si
celui-ci n’a plus ‚ intervenir pour s’authentifier ?
– Le SSO implique la mise en place de m€canismes garantissant la pr€sence
PHYSIQUE de l’utilisateur devant son poste
• Carte ‚ puce dans un lecteur par exemple
– L’utilisateur devant enlever la carte ‚ puce du lecteur ‚ chaque fois qu’il s’absente ; l’obligeant
‚ r€p€ter le processus d’authentification ‚ son retour…
• Le SSO est souvent pr€sent€ par les constructeurs comme un moyen de
pr€parer l’arriv€e des PKI (car pr€parant l’infrastructure ‚ l’int€gration des PKI)
mais pour beaucoup le SSO semble ˆtre une fonctionnalit€ des PKI ‚ ne pas
exploiter
– Cf. „ CDROM/Infrastructure ‚ clefs publiques/Ten Risks of PKI.doc …
• Par Carl Ellison et Bruce Schneier deux experts en cryptographie et s€curit€
11

12. SSO Serveur
• 3 alternatives d’architecture
– SSO Reverse Proxy: L’acc•s aux applications et l’authentification primaire
sont r€alis€s par un serveur de s€curit€ install€ en mode reverse proxy,
– SSO proxy web: L’acc•s aux applications et l’authentification primaire sont
r€alis€s par un serveur de s€curit€ install€ en mode proxy web ou associ€ ‚
un portail d’entreprise,
– SSO bas€e sur des agents filtres: Un agent install€ sur chaque serveur est
intercal€ entre le poste client et le serveur de s€curit€ dont il est le client.
• Les 3 architectures peuvent ˆtre associ€es pour r€pondre aux
contraintes impos€es par l’environnement technique et applicatif.
12

13. SSO Serveur (2)
• Architecture SSO Reverse Proxy
13
PROCESSUS
ETAPE 1: Le client demande
au DNS l’@ IP du serveur
intranet , le DNS lui
communique l’@ IP du Reverse
Proxy SSO.
ETAPE 2: Le client r•alise
une authentification primaire
aupr‚s du reverse proxy SSO
et demande la connexion au
serveur intranet, le reverse
proxy SSO interroge l’annuaire
pour valider les droits de client
et r•cup•rer le couple L/P
correspondant ƒ l’Intranet,
 ETAPE 3: Le reverse proxy
SSO •tablit une connexion avec
le serveur intranet en
pr•sentant le coupe L/P du
client.

14. SSO Serveur (3)
• Architecture SSO Proxy Web
14
PROCESSUS
ETAPE 1: Le client web se
connecte au serveur proxy
web SSO.
ETAPE 2: Le client r•alise
une authentification primaire
aupr‚s du proxy web SSO et
demande la connexion au
serveur intranet, le proxy
web SS0 interroge l’annuaire
pour valider les droits de
client et r•cup•rer le couple
L/P correspondant ƒ
l’Intranet,
 ETAPE 3: Le proxy web
SSO •tablit une connexion
avec le serveur intranet en
pr•sentant le coupe L/P du
client.
ANNUAIRE
Client web avec config url « Proxy.ccinca.fr »
Proxy.ccinca.fr
Application RH Portail INTRANET
@ X
ETAPE 2
ETAPE 3
ETAPE 1

15. SSO Serveur (4)
• Architecture SSO Agents
15
PROCESSUS
ETAPE 1: Le client web se
connecte au serveur portail sur
lequel est install• l’agent SSO
et fournit son couple L/P.
ETAPE 2: L’agent interroge le
serveur SSO pour valider le
couple L/P. Ce dernier
interroge l’annuaire et retourne
la r•ponse.
 ETAPE 3: Le client ƒ cliqu•
sur l’ic„ne intranet dans le
portail. L’agent transmet au
serveur SSO l’identit• du client
et du serveur cible (intranet).
Le serveur SSO interroge
l’annuaire et envoi ƒ l’agent du
serveur intranet le couple L/P
secondaire. Ce dernier joue
l’authentification.

16. Radius
• RADIUS (Remote Dial-In User Service)
– Radius est un protocole qui permet ‚ un serveur d’acc•s (au sens large du
terme) de communiquer avec un serveur central pour authentifier les
utilisateurs et autoriser les acc•s
– Mod•le Client-Serveur, standard de l’IETF RFC 2138
– Toutes les transactions RADIUS sont authentifi€es par l'utilisation d'un
secret qui n'est jamais transmis sur le r€seau. De plus les communications
sont en partie chiffr€es en utilisant une clef secr•te d€finie sur le serveur
et le client
– Le client RADIUS est souvent int€gr€ dans les serveurs d’acc•s (NAS)
€mettant les requˆtes pour authentifier les utilisateurs qui tentent
d’acc€der au r€seau
– La modularit€ du protocole permet son utilisation pour une grande
vari€t€ d’applications et notamment les proxys applicatifs
16

17. Principe
17
1.L’utilisateur initie une connexion PPP avec le serveur d’accƒs
2.Le serveur d’accƒs demande l’identifiant et le mot de passe (PAP) ou envoi un
challenge (CHAP – MD5)
3.L’utilisateur r„pond
4.Le client RADIUS (le NAS) envoi l’identifiant et le mot de passe au serveur
RADIUS (authentification) en le chiffrant avec la clef qu’il partage avec le serveur
5.Le serveur RADIUS r„pond avec les messages Accept, Reject, or Challenge.
6.Le client RADIUS se configure en fonction du contenu des messages Accept ou
Reject (autorisation)

18. Principe
18
1.L’utilisateur initie une connexion PPP avec le serveur d’accƒs
2.Le serveur d’accƒs demande l’identifiant et le mot de passe (PAP) ou envoi un
challenge (CHAP – MD5)
3.L’utilisateur r„pond
4.Le client RADIUS (le NAS) envoi l’identifiant et le mot de passe au serveur
RADIUS (authentification) en le chiffrant avec la clef qu’il partage avec le serveur
5.Le serveur RADIUS r„pond avec les messages Accept, Reject, or Challenge.
6.Le client RADIUS se configure en fonction du contenu des messages Accept ou
Reject (autorisation)

19. Pourquoi utiliser RADIUS
• AAA (Authorization Authentication Accounting)
– Radius fournit en plus de l’Authentification, un moyen de g€rer les
autorisations d’acc•s et la journalisation des €changes
• Protocole robuste et tr•s r€pandu
– NAS, VPN, Authentification domaine, Proxy, …
• Modularit€ permettant une adaptation ‚ la plupart des
contextes
– Attributs configurables
19

20. Exemple d’utilisation RADIUS
• Acc•s nomades
20
Commutateur
Serveur
Radius
Authentification avec cl• partag•e
( preshared key )
Op•rateur Tiers
R•seau
priv•
Dial El‚ve
Serveur
Radius
Op•rateur
NAS
Op•rateur
Authentification avec cl• partag•e
Radius Op•rateur ( preshared key )

21. Exemple d’utilisation RADIUS (2)
• R€seaux Wifi
21
Commutateur
Serveur
W2000
Borne Wifi
Portable
WEP
RADIUS
Authentification EAP
W2000
AD
Serveur
Radius
Authentification
domaine AD
DHCP
Relais
DHCP
Adresse IP
Options DHCP
Authentification PEAP
Enrƒlement domaine ( filaire )

22. TACACS
• TACACS (Terminal Access Controller Access Control System)
– TACACS est un ancien protocole du monde Unix qui permet ‚ un serveur
d’acc•s de faire suivre vers un serveur d’authentification les authentifiants
(login/mot de passe) d’un utilisateur afin de d€terminer quelles
autorisations peuvent lui ˆtre attribu€es
• Date du temps de ARPANET…
– TACACS est un protocole plus ancien et beaucoup moins sŠr que RADIUS
et TACACS+
– TACACS ainsi qu’une version plus r€cente XTACACS (eXtended TACACS –
Cisco 1990) sont deux protocoles normalis€s par l’IETF RFC 1492
– Cisco a d€clar€ en 1997 la fin du support de ces protocoles ceux-ci ayant
€t€ remplac€s
• TACACS et XTACACS ne sont plus utilis€s de nous jours
22

23. TACACS+
• En d€pit de son nom TACACS+ n’est pas une €volution de
TACACS mais un nouveau protocole
• TACACS+ est, au mˆme titre que RADIUS un protocole qui
permet ‚ un serveur d’acc•s de communiquer avec un serveur
central pour authentifier les utilisateurs et autoriser les acc•s
– L’impl€mentation diff•re cependant de celle de son „ concurrent …
RADIUS sur certains points
• AAA (Authorization Authentication Accounting)
– TACACS+ fournit en plus de l’Authentification, un moyen de g€rer les
autorisations d’acc•s et la journalisation des €changes
• TACACS+ a fait l’objet d’un Draft de la part de Cisco mais n’a
pas €t€ normalis€ et reste propri€taire
23

24. Pourquoi utiliser TACACS+
• En environnement Cisco celui-ci semble plus sŠr que RADIUS
– Chiffrement de la totalit€ du message
– Utilisation de TCP
• TACACS+ soufre cependant de quelques vuln€rabilit€s (au
mˆme titre que RADIUS)
– Rejeu, la taille du mot de passe peut ˆtre d€termin€e en fonction de
la taille du paquet, ...
– Celles-ci ont normalement €t€ corrig€es, mais combien d’anciennes
version de l’IOS continuent encore ‚ ˆtre utilis€es ?
• TACACS+ reste tr•s populaire sur les r€seaux Cisco
24

25. RADIUS/TACACS+
• Radius
– Utilise UDP
– Publique, normalis€, forte interop€rabilit€ et modularit€
– Plus l€ger que TACACS+ (dans son concept)
– Regroupe dans un seul profil utilisateur authentification et autorisation
• TACACS+
– Utilise TCP
– Chiffre la totalit€ des messages
– Propri€taire Cisco
• On trouve cependant quelques impl€mentations sur d’autres produits
– Supporte plus de protocoles que RADIUS
• AppleTalk Remote Access, Net BIOS Frame, …
– Dissocie les profils d’authentification et d’autorisation
25

26. Kerberos
• Kerberos a €t€ con‹u au MIT (Massachusetts Institute of Technology) dans les
ann€es 1980. Aujourd’hui Kerberos V tend ‚ se r€pandre.
• Kerberos est un protocole d’authentification r€seau
– Fournit l’authentification mutuelle grŒce ‚ des clefs partag€es et du chiffrement (DES
ou 3DES) ou un tiers de confiance
– Utilise un m€canisme ‚ base de Tickets
– Principe : tous les mots de passe et les droits d’acc•s sont stock€s sur un serveur
s€curis€
• Les constituants d’une infrastructure utilisant Kerberos sont :
– Les clients Kerberos
– Les serveurs d’acc•s supportant Kerberos (routeur, passerelle ou serveur d’acc•s)
– Les serveurs compatibles Kerberos
– Le serveur de g€n€ration de Tickets (Key Distribution Center)
26

27. Kerberos

28. Pourquoi utiliser Kerberos
• Authentification mutuelle s€curis€e
– Chiffrement des €changes
– Pas de transmission de mot de passe
• Transmission de clefs de session chiffr€es
– Gestion centralis€e de l’authentification
• Administration centralis€e et audit facilit€
– Kerberos permet le Single Sign On…
• Facilite la vie de l’utilisateur
– Possibilit€ de Kerberisation de toutes les applications =>
Utilisation d’API Kerberos
– Facilite la convergence vers la PKI
• Dans la mesure ou une partie du travail aura d€j‚ €t€ fait
28

29. Terminologie (1)
• Client
– Entit€ pouvant obtenir un ticket (user/host)
• Service
– Machine ou application (ftp, pop, ssh, …)
• Ticket
– Cr€dit (identit€ d’un client pour un service)
• TGT (Ticket Granting Ticket)
– Sorte de super-ticket obtenu ‚ la premi•re authentification, qui permet ensuite l’obtention
de tickets pour les services acc€d€s
• REALM (royaume)
– Domaine d’authentification
• 1 base de donn€e Kerberos + 1 ou plusieurs KDC
– Organisation hi€rarchique entre les domaines avec authentification
• „ Principal …
– Triplet (nom, instance, domaine)
• ex: user/group@REALM ou service/host.domain@REALM
29

30. Terminologie (2)
• KeyTab
– Fichier du client contenant une ou plusieurs clefs
• KDC (Key Distribution Center)
– Contient la base des clients et des serveurs ainsi que les clefs
• G•re les clefs pour les „ principales … et tickets
– AS (Authentication Server/Service)
• Fournit au client une clef de session et un TGT
– TGS (Ticket Granting Server/Service)
• Service d€livrant les tickets ‚ partir du TGT obtenu aupr•s de l’AS
30

31. Anatomie d’un Ticket
31
Domain
Principal Name
Ticket Flags
Encryption Key
Domain
Principal Name
Start Time
End Time
Host Address
Authorization Data
Chiffr• avec le mot de passe de l’utilisateur
32 bits indiquant les propri„t„s du ticket
Champ utilis„, dans Microsoft 2000 par exemple,
pour ajouter les autorisations concernent
l’utilisateur (propri„taire)
Adresse du client
Clef de session

32. Architecture
32

33. Kerberos - Probl•mes
• NAT
– Le ticket contient l’adresse du client
• Le support de ticket pouvant ˆtre utilis€ au travers du NAT a €t€ ajout€ ‚ Kerberos V (par
d€sactivation de la v€rification de l’adresse)
• Pour les versions pr€c€dentes il convient de d€sactiver la v€rification de l’adresse source
manuellement
– Facilite le rejeu
• Probl•mes de s€curit€
– Rejeu
• Il convient de synchroniser correctement les horloges
– Les passphrases trop simples
• Peut permettre un „ brute force … du mot de passe et donc une usurpation d’identit€
• Rejoint les probl•mes classiques de mots de passe
– Postes utilis€s par plusieurs personnes
• Rejoint les probl•mes du Single Sign On
33

34. 802.1x
• Nouvelle norme 802.1x
– Fonctionnement
– Utilisation
– Faiblesse(s)
– •volutions
34

35. 802.1x – Historique et environnement
• Quelques rep•res historiques dans la standardisation
– 1994-2003 : PPP (quelques dizaines de RFC!)
– 1997-2000 : RADIUS (RFC2058 remplac€ par 2138, puis 2865)
– 1998 : EAP (RFC2284)
– 2001 : 802.1X
• Environnement d’origine et €volution
– Connexion via un support physique (RTC, puis tous r€seaux)
– Prolonge jusqu’au niveau 2 le d€couplage entre l’€tablissement de la
connectivit€ et l’authentification
– •volution ensuite vers les r€seaux 802.11…..
35

36. 802.1x – Objectifs
• Standardiser un m€canisme de relais d’authentification au
niveau 2
– Pour les acc•s via des interfaces IEEE 802{.3 .5 .11}
– Intervient avant d’€ventuels protocoles comme DHCP
• Pour permettre un contrŽle d’acc•s aux ressources
– Mˆme si l’acc•s physique au r€seau n’est pas contrŽlable
• Exemples d’utilisation :
– Acc•s Internet depuis une
aire publique
– Affectation ‚ un VLAN
donn€ en fonction de
l’authentification
36

37. 802.1x – Fonctionnement
• D€finitions
– Authentificateur : Entit€ qui sur le port du r€seau local facilite l’authentification d’une
autre entit€ attach€e sur le mˆme port.
– Serveur d’authentification : Entit€ qui procure un service d’authentification ‚ un
authentificateur. Ce service d€termine, ‚ partir des €l€ments de la requˆte du
demandeur, les services qui lui sont accessibles. Ce serveur peut ˆtre sur la machine qui
sert d’authentificateur ou accessible ‚ ce dernier via le r€seau.
– Authentifi€ : Entit€ qui sur le port du r€seau local qui est en train d’ˆtre authentifi€ par
l’authentificateur (€quivalent de peer dans EAP).
– Point d’acc•s r€seau : point d’acc•s physique (ex. prise RJ45 pour 802.3) ou logique
(association pour 802.11) au r€seau local (on emploie aussi le terme anglais de port, ou
interface).
– PAE (Port Access Entity) : Ensemble impl€mentant le protocole 802.1X, un mˆme PAE
peut jouer le rŽle d’authentificateur ou d’authentifi€.
– Syst•me : €quipement qui est connect€ au LAN par un ou plusieurs ports (ex: poste de
travail, serveur, hub, commutateur, routeur…).
37
Syst‚me d’authentification
Point d’acc‚s au
r•seau
Syst‚me „
authentifi•
Serveur
authentification
Authentification 802.1X

38. 802.1x - Utilisation
• 802.1X utilise le protocole EAP (Extensible
Authentication Protocol),
– Protocole d€di€ au transport de cr€dits d’authentification
– Plusieurs m€thodes d’authentification
• EAP-TLS : Authentification mutuelle du serveur et de
l’utilisateur avec des certificats €lectroniques
• EAP-TTLS: Seul le serveur doit disposer d’un certificat,
l’utilisateur est authentifi€ par login/mot de
passe
• EAP-PEAP: Equivalent ‚ EAP-TTLS mais propri€taire
Microsoft. Cette m€thode est disponible par
d€faut dans les syst•mes Windows r€cents
(XP, 2000, 2003)
38

39. 802.1x - Faiblesses
• Sont essentiellement dues ‚ la conception du protocole
dans un contexte de connexion physique
• La norme 802.1x est vuln€rable ‚ deux types d’attaques
(au moins)
– Attaque par interception
• Le pirate envoi un message de fin de connexion au client en se faisant
passer pour le point d’acc•s
• Le pirate usurpe l’identit€ du client vis ‚ vis du point d’acc•s
– Attaque par interposition
• Le pirate se fait passer pour le point d’acc•s vis-‚-vis du client et relaye
les flux vers le point d’acc•s ‚ la mani•re d’un proxy
39

40. WPA
• Wi-Fi Protected Access
– Con‹u par la WiFi Alliance pour remplacer le protocole
Wired Equivalent Privacy
• Combler une ‚ une les failles du WEP
• Rester compatible avec le mat€riel existant – il faut encore utiliser
le moteur WEP
– Ensemble de packages logiciels se superposant au
mat€riel:
• Authentification bas€e sur 802.1X et RADIUS
• Renouvellement des cl€s de chiffrement plus robuste dans le
temps (TKIP - Temporal Key Integrity Protocol)
• Meilleur m€canisme de contrŽle d’int€grit€ (MIC)
40

41. 802.11i
• Les principes
– IEEE 802.11i est obligatoire dans IEEE 802.11g et IEEE
802.11e
– Reprend les mˆmes m€canismes que WPA
– La gestion de la cl€ est la mˆme que WPA
– Le moteur WEP est remplac€ par un moteur AES
(Advanced Encryption Standard) d’o• le changement de
mat€riel n€cessaire
41

42. Lightweight Directory Access Protocol
• Historique
– 1988: La norme X500 (ISO)
• D€finit de mani•re tr•s compl•te le moteur, les modules
d’interrogation, les r•gles de nommage et les protocoles d’acc•s
(D.A.P),
– 1993: Lightweight Directory Access Protocol V1
• Fournit une interface d’acc•s simplifi€e aux annuaires X500,
fonctionne sur TCPIP.
– 1995: LDAP V2 (IETF RFC 1777).
• „ Proposed standard …: Annuaire natif, g•re sa propre base de
donn€e.
– 1997: LDAP V3 (IETF RFC 2251 + 3377 de 09/02).
• Enrichit de m€canismes de chiffrement, partitionnement, r€plication,
etc.
42

43. Lightweight Directory Access Protocol
(2)
• Le protocole LDAP
– Le protocole permettant d'acc€der ‚ l'information contenue dans
l'annuaire,
– Un mod•le d'information d€finissant le type de donn€es contenues dans
l'annuaire,
– Un mod•le de nommage d€finissant comment l'information est organis€e
et r€f€renc€e,
– Un mod•le fonctionnel qui d€finit comment on acc•de ‚ l'information ,
– Un mod•le de s€curit€ qui d€finit comment donn€es et acc•s sont
prot€g€s,
– Un mod•le de duplication qui d€finit comment la base est r€partie entre
serveurs,
– Des APIs pour d€velopper des applications clientes, LDIF, un format
d'€change de donn€es.
43

44. Lightweight Directory Access Protocol
(3)
• Architecture hi€rarchique mais distribu€e :
– Le service d’annuaire ne repose g€n€ralement pas sur un seul serveur
mais s’€tend sur une architecture technique distribu€e apportant
fiabilit€, disponibilit€ et performance,
– Notion de partitionnement: Il est possible de r€partir les donn€es sur
plusieurs serveurs pour des raisons de capacit€ (taille), gestion,
organisation,
– Les diff€rentes partitions sont n€anmoins li€es par des m€canismes de
referral ou de duplication (r€plication), un peu ‚ l’image de l’annuaire
D.N.S (Domain Name Service) utilis€ pour r€soudre les noms de
domaines en adresses IP
44

45. Lightweight Directory Access Protocol
(4)
• M€ta annuaire :
– R€cup€rer automatiquement les "informations d'entreprise" en
constituant un lien entre plusieurs annuaires ou bases disposant de
sch€mas et d’espaces de nommage diff€rents,
– Agr€ger et f€d€rer ces informations dans la base d'annuaire LDAP. Il
s’agit dans ce cas du mode „ aggr€gateur de contenu …,
– Synchroniser ces informations d'une application ‚ l'autre : envoi de
l'adresse e-mail issue de la messagerie dans l'application RH, envoi du
profil issu de l'application RH dans le serveur de r€sultats, etc. Pour ce
faire, il va cr€er des associations entre les diff€rentes sources de
donn€es et r€aliser entre elles des synchronisations automatiques
bidirectionnelles (mapping et translations entre les entr€es et leurs
attributs). Il s’agit dans ce cas du mode „ courtier d’information ….
45

46. Lightweight Directory Access Protocol
(5)
• Annuaire et Single Sign On :
– L’annuaire constitue le socle n€cessaire au contrŽle des identit€s
• Il centralise et d€livre de mani•re transparente les €l€ments
d'authentification, la liste des services et les droits associ€s ‚ chaque
utilisateur, que la personne authentifi€e soit un employ€ ou un partenaire
– Plate-forme d'authentification (agent ou serveur SSO) permet ‚
l'utilisateur de s'authentifier une seule fois avant d'acc€der ‚
l'ensemble des services (syst•mes, applications) auxquels il a droit.
• Elle prend en charge la gestion et l'historique des connexions aux services
autoris€s sur la base des informations de s€curit€ fournies par l'annuaire.
46

47. Lightweight Directory Access Protocol
(6)
• Annuaire et PKI:
– L’annuaire est une des briques du socle technique n€cessaire ‚ la mise
en oeuvre d’une architecture ‚ cl€ publique (P.K.I).
• Stocker les certificats valides en permettant ‚ tout utilisateur de trouver le
certificat d’un autre par son nom ou adresse e-mail et de v€rifier sa
validit€,
• Stocker les certificats r€voqu€s pour permettre ‚ toute application
d’effectuer les v€rifications avant de lancer des traitements sensibles,
• S€curiser les acc•s en modification de l’annuaire en assurant des fonctions
d’authentification utilisant les certificats X 509.
47