authentification

Transcription

authentification

PROJET DE SYNTHÈSE
V 2.5
TSGERI AFPA MARSEILLE ST-JEROME
AUTHENTIFICATION
PROJET DE SYNTHÈSE
V 2.5
É M E TT E U R
Auteur
Objet du document
Destinataires
Chérif SADI
ETUDE DE SYNTHESE
Oscar LOGGER
MISE A JOUR DU DOCUME NT
Version
Auteur
Description de la modification
Date
1.0
Chérif SADI
CREATION
05/09/11
1.1
Chérif SADI
MODIFICATION
12/09/11
2.0
Chérif SADI
MODIFICATION
15/09/11
2.1
Chérif SADI
MODIFICATION
26/09/11
2.2
Chérif SADI
MODIFICATION
03/10/11
2.3
Chérif SADI
MODIFICATION
18/10/11
2.4
Chérif SADI
MODIFICATION
09/11/11
2.5
Chérif SADI
MODIFICATION
28/11/11
RESUME
Analyse du marché et descriptif des technologies et des différentes méthodes et techniques
d’authentification.
OBJECTIF DU DOCUMENT
Description d’un mécanisme d’authentification via une plateforme de test.
DOCUMENT DE REFERENCE
Ce document est une compilation des différentes informations disponibles sur le Web dont les sources
sont mentionnées dans la bibliographie et les travaux cités en fin de ce document.
2/49
PROJET DE SYNTHÈSE
V 2.5
PREAMBULE
Le projet de synthèse est ainsi l’occasion de mettre en œuvre les connaissances acquises antérieurement
pour mettre en œuvre par simulation un ensemble ou sous-ensemble d’un système.
Ce projet a été réalisé dans le cadre d’une synthèse de « L’authentification » qui a pour but la finalisation
de la certification TSGERI.
Je tiens à remercier dans un premier temps, toute l’équipe pédagogique de L’AFPA de Marseille StJérôme et les intervenants professionnels qui sont responsables de la formation TSGERI, pour avoir
assuré la partie théorique de celle-ci.
Je tiens également à remercier Monsieur Oscar LOGGER, en qualité de formateur principal pour l’aide et
pour m’avoir donné le cap et les conseils concernant les missions évoquées dans ce rapport, qu’il m’a
apporté lors des différents suivis tout au long de ma certification professionnelle.
3/49
PROJET DE SYNTHÈSE
V 2.5
SOMMAIRE
1.
L’authentification ...................................................................................................................... 7
1.1.
La définition et les facteurs ............................................................................................................7
1.2.
L’authentification forte ...................................................................................................................7
1.3.
L’authentification unique ................................................................................................................7
1.4.
Les mécanismes ............................................................................................................................7
1.4.1. Les mots de passe statiques ...........................................................................................7
1.4.2. Les mots de passe à usage unique ..................................................................................7
1.4.3. La cryptographie à clé publique .......................................................................................8
1.4.4. Le jeton de contrôle .......................................................................................................8
1.5.
Les failles et attaques liée à l’authentification ..................................................................................8
1.5.1. Faiblesses du login/mot de passe ....................................................................................8
1.5.2. Le Sniffing .....................................................................................................................8
1.5.3. Ip Spoofing ....................................................................................................................9
1.5.4. Le déni de service (DDoS) ...............................................................................................9
1.5.5. L'attaque Man-In-The-Middle ..........................................................................................9
1.6.
Les protocoles ...............................................................................................................................9
1.6.1. AAA ...............................................................................................................................9
1.6.2. SSL/TLS ....................................................................................................................... 10
1.6.3. 802.1X ......................................................................................................................... 10
1.6.4. PAP ............................................................................................................................. 10
1.6.5. CHAP ........................................................................................................................... 10
1.6.6. MS-CHAP ..................................................................................................................... 11
1.6.7. EAP ............................................................................................................................. 11
1.6.7.1
EAP-TTLS / PEAP ................................................................................................... 11
1.6.7.2
EAP-TLS ................................................................................................................ 11
1.6.7.3
EAP-MD5 ............................................................................................................... 11
1.6.7.4
LEAP ..................................................................................................................... 12
2.
Etude de l'existant .................................................................................................................. 13
2.1.
Les solutions existante du marché ................................................................................................ 13
2.1.1. La technologie biométrique ........................................................................................... 13
2.1.2. La carte à puce Digipass ............................................................................................... 13
2.1.3. La carte à puce audio ................................................................................................... 13
2.1.4. La technologie RSA SecurID .......................................................................................... 13
2.2.
Les serveurs d’application ............................................................................................................ 14
2.2.1. RADIUS ....................................................................................................................... 14
2.2.2. DIAMETER ................................................................................................................... 14
2.2.3. TACACS ....................................................................................................................... 14
2.2.4. KERBEROS ................................................................................................................... 14
2.3.
Les services d’annuaires .............................................................................................................. 14
2.3.1. NIS.............................................................................................................................. 15
2.3.2. NIS+ ........................................................................................................................... 15
2.3.3. DNS ............................................................................................................................ 15
2.3.4. LDAP ........................................................................................................................... 15
2.3.5. ACTIVE DIRECTORY ..................................................................................................... 15
3.
Description du besoin ............................................................................................................. 16
3.1.
Remote Authentication Dial-In User .............................................................................................. 16
4/49
PROJET DE SYNTHÈSE
V 2.5
3.1.1. Principe de fonctionnement ........................................................................................... 16
3.2.
Lightweight Directory Access Protocol ........................................................................................... 18
3.2.1. Principe de fonctionnement ........................................................................................... 18
4.
Mise en place du projet ........................................................................................................... 20
4.1.
Pré-requis ................................................................................................................................... 20
4.2.
Installation des services ............................................................................................................... 20
4.2.1. Installation du service d’annuaire .................................................................................. 20
4.2.2. Installation du service radius ......................................................................................... 20
4.2.1. Installation du service samba ........................................................................................ 20
4.2.2. Installation de phpldapadmin ........................................................................................ 20
4.2.3. Installation des librairies ldap ........................................................................................ 20
4.3.
Configuration des fichiers ............................................................................................................ 21
4.3.1. Schéma samba et radius ............................................................................................... 21
4.3.2. Smb.conf ..................................................................................................................... 24
4.3.3. Mot passe LDAP vers SAMBA ......................................................................................... 27
4.3.4. Smbldap-tools .............................................................................................................. 27
4.3.5. Smbldap_bind.conf ....................................................................................................... 27
4.3.6. Smbldap.conf ............................................................................................................... 27
4.3.7. Peupler son arbre ......................................................................................................... 28
4.3.8. Test du serveur radius .................................................................................................. 29
4.3.9. Clients.conf .................................................................................................................. 30
4.3.10.
Modules/ldap ............................................................................................................ 30
4.3.11.
Site-enabled/default .................................................................................................. 31
4.3.12.
Site-enabled/inter-tunnel ........................................................................................... 31
4.3.13.
Redémarrage des services ......................................................................................... 32
5.
L’analyse des étapes d’authentification ................................................................................. 33
5.1.
Test de l’utilisateur par défaut dans la base radius ........................................................................ 33
5.2.
Test d’un utilisateur dans l’annuaire ldap ...................................................................................... 35
5.2.1. Access-Accept .............................................................................................................. 35
5.2.2. Analyse de l’acceptation ................................................................................................ 37
5.2.1. Access-Reject ............................................................................................................... 38
5.2.1. Analyse du refus .......................................................................................................... 40
6.
Conclusion............................................................................................................................... 42
7.
Bibliographie ........................................................................................................................... 43
8.
Travaux cités........................................................................................................................... 44
9.
Annexes .................................................................................................................................. 45
9.1.
Terminologie ............................................................................................................................... 45
9.1.1. Acronymes ................................................................................................................... 45
9.1.2. Glossaire ...................................................................................................................... 45
9.1.3. Définitions ................................................................................................................... 47
I L L U S T R AT I O N S
Figure
Figure
Figure
Figure
Figure
Figure
1
2
4
5
6
7
:
:
:
:
:
:
Protocole CHAP ................................................................................................................. 10
Protocole LEAP.................................................................................................................. 12
Architecture globale du serveur radius ................................................................................ 16
Protocole du serveur radius ............................................................................................... 17
Historique X.500 et LDAP ................................................................................................... 18
Exemple d'organisation de type « information tree » ........................................................... 18
5/49
PROJET DE SYNTHÈSE
V 2.5
INTRODUCTION
La sécurisation des systèmes d'information est une tâche dont la complexité ne cesse de croître, car tout
cela est due à l'augmentation du nombre d'applications et a la mondialisation qui nous impose le besoin
d'ouverture vers l'extérieur.
L'authentification des utilisateurs est a l’heure actuelle une nécessité, qu'ils accèdent depuis l'intérieur ou
l'extérieur de leur entreprise.
Dans le premier chapitre, nous citerons d'abord les techniques et méthodes d'authentification existantes.
Puis dans le deuxième chapitre, nous détaillerons le mode de fonctionnement d’un service
d’authentification et d’annuaire qui seront nécessaire pour le développement du projet.
Dans le troisième chapitre, nous détaillerons la mise en place, les phases de test et les critiques du
mécanisme d’authentification qui sera mis en place.
6/49
PROJET DE SYNTHÈSE
V 2.5
1 . L’ A U T H E N T I F I C AT I O N
Elle est l'un des services fondamentaux dans le domaine de la sécurité informatique. C'est un processus
critique sur un réseau, car l’accès aux ressources est basé sur l’identification.
1 .1 .
L a d é fi ni t i o n e t l e s fac t e ur s
L'authentification est la procédure qui consiste à vérifier l'identité d'une personne ou d’un équipement.
Les facteurs d’authentification sont multiples :
Ce que l’on est (empreints digitaux, la biométrie)
Ce que l’on possède (carte à puce)
Ce que l’on sait (mot de passe, login)
Ce que l’on sait faire (signature manuscrite)
1 .2 .
L’ a u t he nt i f i c at i o n fo r t e
Une procédure d'identification qui requiert l’utilisation de deux facteurs d'authentification.
1 .3 .
L’ a u t he nt i f i c at i o n u ni q ue
Une méthode permettant à un utilisateur de ne procéder qu'à une seule authentification pour accéder à
plusieurs applications informatiques (Web, mail, etc.).
1 .4 .
Le s mé c a ni sme s
La fiabilité des mécanismes d’authentification dépend de la technologie qu’on utilise. Ce sous chapitre
décrit les principales techniques utilisées :
1.4.1.
Les mots de passe statiques
L’authentification par mot de passe classique est le mécanisme le plus utilise à l’heure actuelle. Elle par
une procédure de connexion durant laquelle on fournit son login-mot de passe.
Le noyau récupère ces informations et regarde dans sa base de donnes si la personne est bien
enregistrée et si le mot de passe qui a été tapé est valide. S’il est correct, l’authentification est réussie et
l’accès au système est valide.
1.4.2.
Les mots de passe à usage unique
Un mot de passe n'est valable une seule fois. Ils permettent de combler certaines lacunes de sécurité
associées aux mots de passe classique. Car si un intrus potentiel parvient à enregistrer un mot de passe
qui était déjà utilisé pour se connecter à un service ou pour effectuer une opération, il ne sera pas en
mesure de l'utiliser car il ne sera plus valide.
En revanche, ils ne peuvent pas être mémorisés par les êtres humains, par conséquent, ils nécessitent
des technologies complémentaires afin de s'en servir.
7/49
PROJET DE SYNTHÈSE
1.4.3.
V 2.5
La cryptographie à clé publique
La cryptographie à clé publique fait intervenir deux sortes de clés, une clé publique publiée sur le réseau
et une clé privée secrète. La clé privée sert pour le décryptage des données ainsi que pour le cryptage
de quelques données afin de vérifier l’intégrité. La clé publique sert pour le cryptage des données et pour
la vérification de la signature. Les deux clés sont reliées par une équation mathématique (algorithme)
complexe.
1.4.4.
Le jeton de contrôle
Les techniques par jeton de contrôle ou token sont des systèmes d’authentification forte qui nécessitent
généralement l’emploi d’une carte spéciale appelée smart-card ou token-card, bien que certains
systèmes existent sous forme logicielle pour réduire le coût de déploiement. Il y’a deux techniques de
vérification connue: La challenge-réponse et la synchronisation.
1 .5 .
Le s f ai l l e s e t a tt aq ue s l i é e à l ’ au t he n t i fi c at i o n
Dans cette partie, nous nous intéresserons aux faiblesses l'authentification par login-MDP classique.
Ensuite, une présentation de quelques attaques utilisant ces failles.
1.5.1.
Faiblesses du login/mot de passe
L’authentification par login/mot de passe est devenue obsolète pour plusieurs raisons :
Le disque dur où il est stocké peut faire l'objet d'attaques et nombreux sont les moyens de
retrouver les mots de passe stockés celui-ci est accessible.
Un mot de passe choisi par l'utilisateur est souvent simple à retenir. Il peut donc être attaqué
par un dictionnaire.
Il est possible d'intercepter un mot de passe au moment où l'utilisateur le tape sur son clavier.
Souvent les mots de passe sont transférés en clair sur le réseau.
Un mot de passe a une durée de vie généralement longue (plusieurs semaines au minimum).
Même si le mot de passe est correctement choisi pour être dur à trouver, il reste attaquable par
la méthode de force brute.
Il existe un grand nombre d’attaques qui utilisent les failles au moment de l'authentification et qui
permettent à une personne le pouvoir usurper l’identité et de détourner des ressources, de les falsifier ou
de les supprimer. Certaines requièrent plus de compétences que d’autres.
1.5.2.
Le Sniffing
Le renifleur ou l’analyseur de protocole est un logiciel qui peut lire au passage les données transitant par
le biais d'un réseau local non-Switch(é).
Il permet une consultation aisée des données non-chiffrées et peut ainsi servir à intercepter des mots de
passe qui transitent en clair ou toute autre information non-chiffrée.
8/49
PROJET DE SYNTHÈSE
1.5.3.
V 2.5
Ip Spoofing
L'usurpation d'adresse IP est une technique utilisée en informatique qui consiste à envoyer des paquets
IP en utilisant une adresse IP source qui n'a pas été attribuée à l'ordinateur qui les émet.
Le but peut être de masquer sa propre identité lors d'une attaque d'un serveur, ou d'usurper en quelque
sorte l'identité d'un autre équipement du réseau pour bénéficier des services auquel il a accès.
1.5.4.
Le déni de service (DDoS)
Une attaque par déni de service est une attaque ayant pour but de rendre indisponible un service,
d'empêcher les utilisateurs légitimes d'un service de l'utiliser. Il peut s'agir de :
L’inondation d’un réseau afin d'empêcher son fonctionnement.
La perturbation des connexions entre deux machines, empêchant l'accès à un service particulier.
L’obstruction d'accès à un service à une personne en particulier.
L'attaque par déni de service peut ainsi bloquer un serveur de fichiers, rendre impossible l'accès à un
serveur web, empêcher la distribution de courriel dans une entreprise ou rendre indisponible un site
internet.
1.5.5.
L'attaque Man-In-The-Middle
L'attaque de l'homme du milieu est une attaque qui a pour but d'intercepter les communications entre
deux parties, sans que ni l'une ni l'autre ne puisse se douter que le canal de communication entre elles a
été compromis. Le canal le plus courant est une connexion à Internet de l'internaute lambda.
L'attaquant doit d'abord être capable d'observer et d'intercepter les messages d'une victime à l'autre.
L'attaque « homme du milieu » est particulièrement applicable dans le protocole original d'échange de
clés Diffie-Hellman, quand il est utilisé sans authentification.
1 .6 .
Le s p ro t o c o l e s
Les mécanismes d’authentification décrits dans cette partie ont tout d’abord été des protocoles de
couche de la liaison de données puisqu’ils ont été initialement utilisés par le protocole PPP qui permet
l’ouverture de session sur le réseau RTC.
Ils sont également utilisés dans la couche réseau grâce aux évolutions de PPP :
PPPoA (over ATM) et PPPoE (over Ethernet) qui sont principalement utilisés pour ouvrir des connexions
ADSL. Cependant, ces mécanismes sont les briques de nombreux serveurs et applications
d’authentification comme Radius.
1.6.1.
AAA
AAA correspond à un protocole qui réalise trois fonctions : l'authentification, l'autorisation, et
la traçabilité (en Anglais : Authentication, Autorisation, Accounting).
9/49
PROJET DE SYNTHÈSE
V 2.5
Il correspond a un modèle de sécurité implémenté dans certains routeurs Cisco mais que l'on peut
également utiliser sur toute machine qui peut servir de NAS (Network Authentification System).Ils
requièrent une identification d'une personne ou d’un équipement avant d’accorder des droits d’accès.
1.6.2.
SSL/TLS
Transport Layer Security, anciennement nommé Secure Sockets Layer, est un protocole de sécurisation
des échanges sur Internet, développé à l'origine par Netscape.
Il a été renommé en Transport Layer Security par l'IETF suite au rachat du brevet de Netscape par l'IETF
en 2001.
1.6.3.
802.1X
802.1X est un standard lié à la sécurité des réseaux informatiques, mis au point en 2001 par l'IEEE.
Il permet de contrôler l'accès aux équipements d'infrastructures réseau (et par ce biais, de relayer les
informations liées aux dispositifs d'identification).
1.6.4.
PA P
Password Authentication Protocol est un protocole d'authentification pour PPP. Les données sont
transmises en texte clair sur le réseau ce qui le rend par conséquent non sécurisé.
L’avantage de PAP est qu'il est extrêmement simple à implémenter, lui permettant d'être utilisé dans des
systèmes embarqués très légers. Sur des systèmes de taille raisonnable on préférera sans doute le
protocole CHAP.
1.6.5.
CHAP
Challenge Handshake Authentication Protocol est un protocole d'authentification pour PPP à base de
challenge, ce qui le rend bien plus sûr que son pendant PAP.
L'objectif de CHAP est que le pair s'authentifie auprès d'un authentificateur sans échange de mot de
passe en clair sur le réseau et sans que l'échange puisse être rejoué par un tiers à l'écoute.
La contrainte est que chaque partie partage un « secret » (mot de passe) commun. Microsoft a
développé la variante MS-CHAP qui supprime cette contrainte.
Figure 1 : Protocole CHAP
10/49
PROJET DE SYNTHÈSE
1.6.6.
V 2.5
MS-CHAP
MS-CHAP est la version Microsoft du protocole. Ce protocole existe en deux versions : MS-CHAPv1 et MSCHAPv2.
1.6.7.
EAP
Extensible Authentication Protocol est un mécanisme d'identification universel, fréquemment utilisé dans
les réseaux sans fil (ex : Wifi) et les liaisons point à point (PPP).
1.6.7.1
EAP-TTLS / PEAP
EAP-Tunneled Transport Layer Security, a été Co-développé par Funk Software et par certicom. C’est
également un standard ouvert IETF.
Il est supporté sur de nombreuses plates-formes, et offre un très bon niveau de sécurité. Il utilise des
certificats X-509 uniquement sur le serveur d'identification.
Le certificat est optionnel du côté client. Le défaut de EAP-TTLS par rapport à PEAP est de ne pas être
présent nativement sur les systèmes Microsoft et Cisco.
En revanche, il est légèrement plus sécurisé que LEAP car il ne diffuse pas le nom de l'utilisateur en clair.
1.6.7.2
EAP-TLS
EAP-TLS est un Standard ouvert IETF. On le retrouve implanté chez de nombreux fabricants de matériel
sans fil.
C’est le seul protocole EAP qui doit obligatoirement être implanté sur un matériel pour pouvoir porter le
logo WPA ou WPA2.Il offre une bonne sécurité.
En effet il utilise deux certificats pour la création d'un tunnel sécurisé qui permettra ensuite
l'identification : un côté serveur et un côté client.
Cela signifie que même si le mot de passe est découvert, il ne sera d'aucune utilité sans le certificat
client.
Bien que le protocole EAP-TLS fournisse une excellente sécurité, l'obligation de disposer d'un certificat
client est peut-être son talon d'Achille.
En effet, lorsque l'on dispose d'un grand parc de machines, il peut s'avérer difficile et coûteux de gérer
un certificat par machine. C'est pour se passer du certificat client que les protocoles PEAP et EAP-TTLS
ont été créés.
TLS est considéré comme le successeur du standard SSL. Il utilise une Infrastructure à clés
publiques pour sécuriser les communications d'identification entre les clients et le serveur radius.
1.6.7.3
EAP-MD5
EAP-MD5 est un autre standard ouvert IETF, mais il offre un niveau de sécurité faible.
11/49
PROJET DE SYNTHÈSE
V 2.5
La fonction de hachage MD5 utilisée est vulnérable aux attaques par dictionnaire, et elle ne supporte pas
les clefs WEP dynamiques.
1.6.7.4
LEAP
Lightweight Extensible Authentication Protocol est une implémentation propriétaire du protocole EAP
conçu par Cisco Systems.
La société a fait beaucoup d'efforts pour promouvoir ce protocole.
Il a permis à d'autres fabricants de réaliser des produits « LEAP Compatible » au travers du programme
CCE (Cisco Certified Extensions). Ce protocole n'est pas présent nativement sous Windows.
Figure 2 : Protocole LEAP
Il était connu pour être vulnérable aux attaques par dictionnaire comme EAP-MD5.
Mais il ne l'est plus depuis la version ASLEAP (2003) de Joshua Wright.
Cisco continue de soutenir que LEAP est une solution sécurisée si l'on utilise des mots de passe
suffisamment complexes.
Mais tout le monde sait bien que dans la réalité les mots de passe complexes sont rarement utilisés.
De nouveaux protocoles comme EAP-TTLS ou PEAP ne rencontrent pas ce type de fragilité car ils créent
un tunnel TLS pour sécuriser l'identification.
De plus ces nouveaux protocoles étant plus ouverts, ils peuvent être utilisés sur des points d'accès de
marque Cisco ou non.
12/49
PROJET DE SYNTHÈSE
V 2.5
2 . E T U D E D E L ' E X I S TA N T
2 .1 .
Le s s o l u t i o n s e x i st a nt e d u m a rc hé
2.1.1.
La technologie biométrique
Elle est la science qui permet d'identifier de manière automatique une personne en
se basant sur ses caractéristiques physiologiques ou comportementales. En effet,
chaque personne est unique de ce fait, chacun possède sa propre caractéristique
biométrique, et elle rend cette technologie assez stable. Généralement, on distingue
deux catégories de méthodes d'authentification biométrique, les méthodes basées
sur les caractéristiques physiques telles que le visage, la voix et ADN, et celles basées sur les
caractéristiques comportementales comme la signature, la manière de marcher ou de taper sur un
clavier.
2.1.2.
La carte à puce Digipass
Le Digipass est un produit de sécurité de VASCO Data Security International,
fournissant une authentification forte des utilisateurs et des signatures numériques via
des jetons de sécurité réalisées par les utilisateurs de petites ou de logiciels sur les
téléphones mobiles, appareils portables ou des PC. Il est compatible avec plus de 50 fournisseurs
internationaux pour une variété de e-commerce, e-banking, e-réseautage et applications egouvernement. Elle utilise le serveur temps et l’authentification à deux facteurs et peut être utilisé pour
signer des transactions électroniques. Il a été inventé en 1989 par un belge Mr Dominique COLARD.
2.1.3.
La carte à puce audio
La société Audio Smart Card développe une offre matérielle et logicielle permettant
de répondre efficacement à tous les besoins d'authentification distants sur l'ordinateur et
le téléphone. Elle propose une carte à puce audio s’appliquant aussi bien à l’économie, à
l’e banking, au call center, au transport, à la santé, aux ressources humaines, aux
services télécom, etc. Basée sur le principe du mot de passe dynamique car elle utilise
comme support d’authentification une carte à puce audio qui fonctionne en liaison avec le serveur
d’authentification Secure Sound Pro Server.
2.1.4.
La technologie RSA SecurID
SecurID est un système de token, ou authentifieur, produit par la société RSA Security
et destiné à proposer une authentification forte à son utilisateur. La majorité des tokens
SecurID affichent un code à 6 chiffres changeant généralement toutes les minutes.
L'utilisateur ajoute un Pin Code PIN personnel au TokenCode lu sur l'authentifieur
SecurID. Le tout est appelé un PassCode (soit PassCode = PIN Code + TokenCode).
Par ailleurs, le Token expire au bout d'un certain temps (3 à 5 ans selon les modèles).Ce système de
Token, de type OTP, est utilisé pour les applications Web (par exemple le eBanking) et les technologies
de type VPN (IPSEC, SSL), SSH, Citrix.
13/49
PROJET DE SYNTHÈSE
2 .2 .
V 2.5
L e s se r ve u r s d ’ a p p l i c a t i o n
Voici une présentation des principaux serveurs :
2.2.1.
RADIUS
Remote Authentication Dial-In User Service est un protocole de type client-serveur qui a pour rôle
d’authentifier les requêtes qui lui parviennent d’un poste client.
Il existe plusieurs solutions de serveur radius qu’elles soient commerciales ou open source :
ACS (Cisco sous Windows).
Aegis (sous Linux).
IAS (sous Windows).
Open Radius (Open source).
Free Radius (Open source, BSD, Windows).
2.2.2.
DIAMETER
Diameter est un protocole d'authentification, il est successeur du protocole radius.
2.2.3.
TACACS
Terminal Access Controller Access-Control System (TACACS) est un protocole d'authentification distante
utilisé pour communiquer avec un serveur d'authentification, généralement utilisé dans des réseaux Unix.
TACACS permet à un serveur d'accès distant de communiquer avec un serveur d'authentification dans
l'objectif de déterminer si l'utilisateur a le droit d'accéder au réseau.
2.2.4.
KERBEROS
Kerberos est un protocole d'authentification réseau qui repose sur un mécanisme de clés secrètes
(chiffrement symétrique) et l'utilisation de tickets, et non de mots de passe en clair, évitant ainsi le
risque d'interception frauduleuse des mots de passe des utilisateurs.
Créé au Massachusetts Institute of Technology (MIT), il porte le nom grec de Cerbère, gardien des
Enfers (Κέρϐερος). Kerberos a d'abord été mis en œuvre sur des systèmes Unix.
2 .3 .
Le s se r vi c e s d ’ an n ua i re s
Un annuaire va permettre de centraliser les données des utilisateurs et des services afin de rendre plus
simple l’administration.
Un annuaire peut être associé à un système de stockage de données permettant de rendre accessible un
ensemble d'informations à tous les utilisateurs de ce système.
Voici un exemple:
Carnet d'adresses.
14/49
PROJET DE SYNTHÈSE
V 2.5
Annuaire téléphonique.
Serveur DNS ...
Sur un système informatique, les données ne sont pas organisées de manière relationnelle comme sur
les SGBD classiques (MySQL, PgSQL, SQL Server, ...) mais de manière hiérarchique.
Si on souhaite faire une comparaison entre les services d'annuaire et les SGBD classiques, on peut établir
que :
La consultation des données est plus rapide pour l'annuaire par rapport aux SGBD classiques.
La duplication des données est facilitée.
Le stockage des données peut être réalisé dans un plus faible espace.
Les avantages des services d'annuaire sont leur rapidité pour accéder aux informations, les mécanismes
de sécurité pouvant être mis en œuvre, la centralisation des informations et les possibilités de
redondance de l'information.
Voici une présentation des principaux serveurs :
2.3.1.
NIS
Network Information Service (NIS) nommé aussi Yellow Pages est un protocole client-serveur développé
par Sun permettant la centralisation d'informations sur un réseau UNIX.
2.3.2.
NIS+
Il est l’évolution de NIS plus sécurisée et mieux adaptée aux gros réseaux, il est développé par Sun.
2.3.3.
DNS
Domain Name System est un service permettant d'établir une correspondance entre une adresse IP et un
nom de domaine et, plus généralement, de trouver une information à partir d'un nom de domaine.
À la demande de Jon Postel, Paul Mockapetris inventa le « DNS » en 1983 et en écrivit la première
implémentation.
2.3.4.
LDAP
Lightweight Directory Access Protocol est à l'origine un protocole permettant l'interrogation et la
modification des services d'annuaire.
2.3.5.
ACTIVE DIRECTORY
Active Directory est la mise en œuvre par Microsoft des services d'annuaire pour les systèmes
d'exploitation Windows.
L'objectif principal d'Active Directory est de fournir des services centralisés d'identification et
d'authentification à un réseau d'ordinateurs utilisant le système Windows.
15/49
PROJET DE SYNTHÈSE
V 2.5
3. DESCRIPTION DU BESOIN
Pour les besoins de notre étude, nous avons de décider de mettre en place un banc de test pour une
analyse détailler un mécanisme d’authentification. Mais avant toute chose, nous allons expliquer le
principe de fonctionnement des solutions que nous allons utiliser.
3 .1 .
Re mo t e Aut he n t i c a t i o n Di al -In U se r
3.1.1.
Principe de fonctionnement
C’est un protocole d’authentification standard Client/serveur qui permet de centraliser les données
d’authentification : Les politiques d’autorisation et de droits d’accès, traçabilité. Ce processus doit être
relié à une source d’informations, qui est souvent un annuaire LDAP.
Auparavant, les noms et les mots de passe des utilisateurs devaient être dupliqués sur chaque serveur
pouvant être accédé à distance (par un modem RTC par exemple). L’arrivé de ce serveur a permit aux
F.A.I d’authentifier les utilisateurs distants connectés, à partir d’une seule base utilisateurs. Ce protocole
avait particulièrement un sens avant l’ADSL illimité, car il permettait de mesurer le temps précis de
connexion des abonnés et facturer en conséquence.
L’identification sur les sites Web peut aussi être gérée par RADIUS. Apache est sans doute le client
RADIUS le plus répandu (le module « mod_auth_radius » permet à un serveur Apache de valider une
authentification en interrogeant un serveur Radius). Aujourd’hui, ce protocole est aussi souvent utilisé
pour les connexions à Internet sans fil (WLAN - avec le protocole 802.1X qui assure l'identification par
port pour l'accès à un réseau).
Figure 3 : Architecture globale du serveur radius
On le retrouve aussi bien au sein de la téléphonie sur IP comme outil de gestion des connexions, autour
du protocole SIP notamment. Dans ce cas, l'annuaire SIP chargé de l'authentification communique avec
le serveur Radius en utilisant ce protocole. Son fonctionnement est simple :
16/49
PROJET DE SYNTHÈSE
V 2.5
Figure 4 : Protocole du serveur radius
L’utilisateur (le supplicant) se connecte (via PPP ou Telnet) à un client (Network Access Server),
qui est en général une passerelle/proxy.
Le client demande à l’utilisateur son nom et son mot de passe, et il les communique de manière
sécurisée à un serveur RADIUS relié à une base de données ou à un annuaire LDAP.
En fonction de la zone d’accès demandée et des droits de l’utilisateur, le serveur peut exiger des
informations supplémentaires pour l’authentification.
La réponse CHALLENGE permet d’éviter de transmettre le mot de passe. Le client envoie alors
une autre requête répondant au Challenge pour s'authentifier.
Si l’identification réussie, le serveur répond par un ACCEPT (REJECT dans le cas contraire).
Le serveur envoie enfin les autorisations de l’utilisateur. Il pourra par la suite bloquer une
connexion en cours et assurer une journalisation des accès.
Les limitations du protocole :
Il a été conçu au départ pour des identifications sur des liaisons lentes et peu sûres.
Le choix du protocole UDP (port 1812) conduit à des échanges laborieux basés sur des
temporisations de réémission et des échanges d’accusé de réception.
Sécurité relative reposant sur le secret partagé. Certaines implémentations clientes limitent en
plus sa taille.
Chiffrement de l’attribut User-Password par une fonction de hachage MD5, plutôt réservé pour
des opérations de signature.
Le rejeu des réponses du serveur est possible.
Pas de mécanisme d'identification du serveur. Il est ainsi possible de se faire passer pour un
serveur et de récolter les noms et mots de passe des utilisateurs.
17/49
PROJET DE SYNTHÈSE
V 2.5
Les normes qui complètent le protocole RADIUS sont les protocoles d’authentification PAP, CHAP
ou EAP.
3 .2 .
L i g h t w e i g ht Di re c t o r y Ac c e s s Pr o t o c o l
3.2.1.
Principe de fonctionnement
Il est actuellement en version 3 et il est normalisé par l’IETF. Il s’agit d’un protocole d’interrogation
d’annuaire. On dit qu’il est allégé, par comparaison à la norme X500, son ancêtre, dont la mise en œuvre
était très lourde.
Figure 5 : Historique X.500 et LDAP
LDAP au cœur du système d’information car Il regroupe les données d’une entité au même endroit. On
dit que c’est un annuaire fédérateur. C’est un standard incontournable par ce que la plupart des
applications récentes s’appuient dessus : les outils de messageries, les actifs du réseau (proxy,
firewall…), les progiciels de gestion, les réseaux intranets, etc. Une majorité de logiciel utilisent LDAP
pour l’authentification.
Figure 6 : Exemple d'organisation de type « information tree »
18/49
PROJET DE SYNTHÈSE
V 2.5
LDAP est une base donnée hiérarchique et non pas relationnelle comme les SGBD. On peut ainsi
représenter son contenu sous forme d’arbre. L’annuaire est conçu pour référencer toutes sortes
d’informations : Informations sur des personnes, sur des applications, sur un parc informatique…
Le concept de l’annuaire, c’est de maintenir de façon cohérente et contrôlée une grande quantité de
données et d’optimiser la consultation en lecture au dépend de l’écriture. Les accès concurrents sont
gérés et la quantité de donnée pouvant être stockée est quasi illimité. La contrepartie est que les mises
doivent être ponctuelles et les enregistrements peu volumineux :
On utilise des chaînes de caractère courtes et on limite le nombre de fichiers binaires (certificats,
photos…).
LDAP propose donc des mécanismes pour gérer l’authentification. Plusieurs méthodes sont possibles en
fonction du niveau de sécurité désiré :
La connexion anonyme est généralement limitée à la consultation de parties restreintes de
l’annuaire.
L’authentification par login/mot de passe.
L’authentification par login/mot de passe avec hachage de ce dernier.
L’authentification par login/mot de passe avec un tunnel TLS entre le client et l’application et
entre l’application et l’annuaire.
L’authentification par certificat X509.
Authentification plus élaborée grâces aux API SASL (Simple Authentification and Security Layer).
Cette API permet d’intégrer facilement des mécanismes d’authentification forte comme
Kerberos, Radius, ou des systèmes de mot de passe à usage unique comme OTP.
Il est aussi possible de sécuriser les échanges entre l’annuaire LDAP et les clients par LDAP sur
TLS ou LDAPS.
Le principal avantage du serveur est la normalisation de l'authentification. Il est très facile de
programmer un module d'authentification reposant sur le serveur à partir d'un langage possédant une
API de type LDAP. C'est l'opération Bind qui permet d'authentifier un utilisateur. Aujourd’hui, de plus en
plus d'applications Web possèdent un module d'authentification prenant en charge le protocole LDAP.
Les applications peuvent ainsi déléguer l’étape d’authentification à l’annuaire LDAP qui met en œuvre
l’une des méthodes précédentes. Par exemple sur les systèmes GNU/Linux récents, les fichiers
Password et shadow sont de plus en plus remplacés par des appels à LDAP. Les données peuvent être
accédées par le module PAM.
PAM est un mécanisme qui permet justement de déléguer les fonctionnalités d’authentification, sans rien
recompiler. Il peut être paramétré en fonction de l’application (base de compte NTLM pour les anciennes
versions de Windows, base de compte Unix ou autre) et en fonction du mode d’accès à l’application
(Intranet, Extranet, Web). Le module de connexion de PAM fournit l’interface avec les annuaires (ou les
fichiers). C’est cette couche qui validera que l’identifiant et le mot de passe sont valides et retournera
une réponse aux applications.
19/49
PROJET DE SYNTHÈSE
V 2.5
4 . M I S E E N P LA C E D U P R O J E T
4 .1 .
P r é - re q ui s
Pour les besoins du projet, nous allons utiliser une machine virtuelle (VMware Player) ou éventuellement
un pc classique pour installer un système d’exploitation Unix open-source (Ubuntu 11.10).Tous les
services sera dans la même machine pour faciliter la phase de test.
4 .2 .
I n st al l a t i o n d e s se r vi c e s
4.2.1.
Installation du service d’annuaire
Entrer la commande suivante pour installer le service d’annuaire:
apt-get install slapd ldap-utils ldapvi
Une fois l'application installé, l'ensemble des fichiers se trouvent dans : « /etc/ldap ».
Une fois l’installation du serveur effectuée, arrêtez le service en faisant :
/etc/init.d/slapd stop
4.2.2.
Installation du service radius
Entrer la commande suivante pour installer le service d’authentification:
apt-get install freeradius freeradius-ldap
Une fois l'application installé, l'ensemble des fichiers se trouvent dans : « /etc/freeradius».
/etc/init.d/freeradius stop
4.2.1.
Installation du service samba
Entrer la commande suivante pour installer le service d’authentification:
apt-get install samba-doc samba smbclient smbfs smbldap-tools
Une fois l'application installé, l'ensemble des fichiers se trouvent dans : « /etc/samba».
/etc/init.d/smbd stop
4.2.2.
Installation de phpldapadmin
Entrer la commande suivante pour installer l’interface d’administration de l’annuaire:
apt-get install phpldapadmin
4.2.3.
Installation des librairies ldap
Nous allons maintenant installer et configurer la librairie qui permet d’utiliser l’annuaire (libnss-ldap) et la
librairie qui permet de s’authentifier sous unix (libpam-ldap)
apt-get install libnss-ldap libpam-ldap
20/49
PROJET DE SYNTHÈSE
V 2.5
Maintenant que les librairies sont configurées, on doit activer la recherche LDAP en modifiant le fichier de
configuration «/etc/nsswitch.conf ». Pour cela il faut simplement ajouter ldap à passwd,group et
shadow :
passwd: compat ldap
group: compat ldap
shadow: compat ldap
4 .3 .
Co n fi g u rat i o n d e s fi c hi e r s
4.3.1.
Schéma samba et radius
L’installation de ce schéma est essentielle car il contient les attributs nécessaires au LDAP pour le bon
dialogue avec samba en PDC :
gunzip -d /usr/share/doc/samba-doc/examples/LDAP/*.gz
cp /usr/share/doc/samba-doc/examples/LDAP/samba.schema /etc/ldap/schema/
Puis:
cp /usr/share/doc/freeradius/examples/openldap.schema
/etc/ldap/schema/freeradius.schema
Une fois cette étape finie dans l’ancienne version il suffisait d’ajouter le schéma dans « slapd.conf ».
Mais avec la nouvelle version quand on fait un :
ls -l /etc/ldap/slapd.d/cn=config/cn=schema
On obtient :
-rw-------rw-------rw-------rw-------
1
1
1
1
15474
11308
6438
2802
24
24
24
24
sept.
sept.
sept.
sept.
13:39
13:39
13:39
13:39
cn={0}core.ldif
cn={1}cosine.ldif
cn={2}nis.ldif
cn={3} inetorgperson.ldif
Et on constate que notre schéma n’est pas présent.
La solution est de créer un fichier « /etc/ldap/slapd.conf » manuellement et d’y inclure les schémas
nécessaires. Attention il faut remettre les anciens schémas sous peine d’avoir un message d’erreur.
nano /etc/ldap/slapd.conf
Puis
# This is the main slapd configuration file. See slapd.conf(5) for more
# info on the configuration options.
#######################################################################
# Global Directives:
# Features to permit
# allow bind_v2
# Schema and objectClass definitions
######## Schéma par défaut
include
/etc/ldap/schema/core.schema
21/49
PROJET DE SYNTHÈSE
include
/etc/ldap/schema/cosine.schema
include
/etc/ldap/schema/nis.schema
include
/etc/ldap/schema/inetorgperson.schema
V 2.5
######## On rajoute le schema samba
include
/etc/ldap/schema/samba.schema
######## On rajoute le schema freeradius
include
/etc/ldap/schema/radius.schema
# Schema check allows for forcing entries to
# match schemas for their objectClasses's
schemacheck
on
# Where the pid file is put. The init.d script
# will not stop the server if you change this.
pidfile
/var/run/slapd/slapd.pid
# List of arguments that were passed to the server
argsfile
/var/run/slapd.args
# Read slapd.conf(5) for possible values
loglevel
0
# Where the dynamically loaded modules are stored
modulepath
/usr/lib/ldap
moduleload
back_bdb
#######################################################################
# Specific Backend Directives for bdb:
# Backend specific directives apply to this backend until another
# 'backend' directive occurs
backend
checkpoint
bdb
512 30
#######################################################################
# Specific Backend Directives for 'other':
# Backend specific directives apply to this backend until another
# 'backend' directive occurs
#backend
<other>
#######################################################################
# Specific Directives for database #1, of type bdb:
# Database specific directives apply to this databasse until another
# 'database' directive occurs
database
bdb
22/49
PROJET DE SYNTHÈSE
V 2.5
# The base of your directory in database #1
######## Donnez le nom de votre base LDAP (normalement debconf a rajouté pour vous
cette ligne)
suffix
"dc=test,dc=local"
######## Donnez le nom de votre base LDAP avec le nom Admin. (ligne à créer)
rootdn
"cn=Manager,dc=test,dc=local"
######## Dans une console root lancez la commande slappasswd, donnez votre mot de
passe que vous aviez
######## mis à l'installation de slapd (dans debconf), la commande vous renvoie le mot
de passe crypté,
######## copiez le. (Ligne à créer)
rootpw
{SSHA}nqoi1V9f/OUnyYNbFYostLPgjfcnTCYC
# Where the database file are physically stored for database #1
directory
"/var/lib/ldap"
# Indexing options for database #1
index
objectClass eq
# Save the time that the entry gets modified, for database #1
lastmod
on
# Where to store the replica logs for database #1
# replogfile
/var/lib/ldap/replog
# The userPassword by default can be changed
# by the entry owning it if they are authenticated.
# Others should not be able to see it, except the
# admin entry below
# These access lines apply to database #1 only
access to attrs=userPassword
by dn="cn=Manager,dc=test,dc=local" write
by anonymous auth
by self write
by * none
# Ensure read access to the base for things like
# supportedSASLMechanisms.
Without this you may
# have problems with SASL not knowing what
# mechanisms are available and the like.
# Note that this is covered by the 'access to *'
# ACL below too but if you change that as people
# are wont to do you'll still need this if you
23/49
PROJET DE SYNTHÈSE
V 2.5
# want SASL (and possible other things) to work
# happily.
access to dn.base="" by * read
# The admin dn has full write access, everyone else
# can read everything.
access to *
by dn="cn=Manager,dc=test,dc=local" write
by * read
Et on sauvegarde en sortant. Une fois ce fichier créé on lance la commande suivante qui convertira au
nouveau format :
slaptest -f /etc/ldap/slapd.conf -F /etc/ldap/slapd.d/
La commande doit vous retourner :
config testing succeeded
Si on refait un petit :
ls -l /etc/ldap/slapd.d/cn=config/cn=schema
On constate que le schéma est bien ajouté, mais que le propriétaire est root et non OpenLDAP comme
ci-dessous :
-rw-------rw-------rw-------rw-------rw-------
1
1
1
1
1
-rw------- 1
15474
11308
6438
2802
12492
24
24
24
24
24
sept.
sept.
sept.
sept.
sept.
13:39
13:39
13:39
13:39
14:13
cn={0}core.ldif
cn={1}cosine.ldif
cn={2}nis.ldif
cn={3}inetorgperson.ldif
cn={4}samba.ldif
14497 24 sept. 14:14 cn={5}freeradius.ldif
On va donc lancer les commandes suivantes pour lui donner les droits :
chown openldap:openldap /etc/ldap/schema/ -R
chown openldap:openldap /etc/ldap/slapd.d/ -R
Un fois ces commandes exécuté on peut enfin faire un redémarrage du serveur.
/etc/init.d/slapd restart
4.3.2.
Smb.conf
Avant toute chose faire une copie de sauvegarde du fichier d’origine :
cp /etc/samba/smb.conf /etc/samba/smb.conf.save
Une fois la copie effectuée, éditez le fichier avec votre éditeur préférer et changer les paramètres à
l’intérieur.
Voici ci-dessous mon fichier pour exemple :
[global]
workgroup = test
server string = Controleur de domaine
netbios name = serveur_test
domain master = yes
24/49
PROJET DE SYNTHÈSE
V 2.5
local master = yes
domain logons = yes
client lanman auth = yes
client ntlmv2 auth = yes
lanman auth = yes
ntlm auth = yes
security = user
os level = 40
ldap ssl = off
ldap passwd sync = yes
passdb backend = ldapsam:ldap://127.0.0.1
ldap admin dn = cn=Manager,dc=test,dc=local
ldap suffix = dc=test,dc=local
ldap group suffix = ou=Groups
ldap user suffix = ou=Users
ldap machine suffix = ou=Machines
add user script = /usr/sbin/smbldap-useradd -m "%u"
ldap delete dn = yes
delete user script = /usr/sbin/smbldap-userdel "%u"
add machine script = /usr/sbin/smbldap-useradd -w "%u"
add group script = /usr/sbin/smbldap-groupadd -p "%g"
#delete group script = /usr/sbin/smbldap-groupdel "%g"
add user to group script = /usr/sbin/smbldap-groupmod -m "%u" "%g"
delete user from group script = /usr/sbin/smbldap-groupmod -x "%u" "%g"
set primary group script = /usr/sbin/smbldap-usermod -g "%g" "%u"
logon path = \\%L\profiles\%U
logon drive = P:
logon home = \\%L\%U
socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192
case sensitive = No
default case = lower
preserve case = yes
short preserve case = Yes
#character set = iso8859-1
#domain admin group = @admin
dns proxy = No
wins support = Yes
winbind use default domain = Yes
nt acl support = Yes
msdfs root = Yes
hide files = /desktop.ini/ntuser.ini/NTUSER.*/
# autre possibilité "veto files = "
#
# Reglage de l'encodage des caracteres :
unix charset = iso-8859-15
display charset = iso-8859-15
dos charset = 850
#
[netlogon]
path = /home/dev/netlogon
writable = No
25/49
PROJET DE SYNTHÈSE
V 2.5
browseable = No
write list = Administrateur
#
[profiles]
path = /home/dev/profiles
browseable = No
writeable = Yes
profile acls = yes
create mask = 0700
directory mask = 0700
#
[homes]
comment = Repertoire Personnel
browseable = No
writeable = Yes
#
[partage]
comment = Repertoire commun
browseable = Yes
writeable = Yes
public = No
path = /home/partage
#
[printers]
comment = All Printers
path = /var/spool/samba
create mask = 0700
printable = Yes
browseable = No
#
[print$]
comment = Printer Drivers
path = /var/lib/samba/printers
Une fois le fichier sauvegardé il va falloir créer les répertoires pour les scripts de connexion, les profiles
itinérants ainsi que le partage sur le serveur.
mkdir /home/dev/netlogon
mkdir /home/dev/profiles && chmod 777 /home/dev/profiles
mkdir /home/dev/partage
Après la création des répertoires ne pas oublier de vérifier la configuration du fichier smb.conf de samba
en faisant :
testparm
Cette commande doit vous renvoyer :
Loaded services file OK. Server role: ROLE_DOMAIN_PDC
N’oubliez pas de faire un petit :
/etc/init.d/samba start
26/49
PROJET DE SYNTHÈSE
4.3.3.
V 2.5
Mot passe LDAP vers SAMBA
Afin d’administrer correctement le serveur LDAP samba aura besoin du mot de passe administrateur de
celui-ci... Pour cela tapez la commande suivante et donné le mot de passe administrateur du ldap.
smbpasswd -w *****
Samba doit vous répondre :
Setting stored password for "cn=Manager,dc=test,dc=local" in secrets.tdb
4.3.4.
Smbldap-tools
smbldap-tools est un ensemble de script permettant de créer les utilisateurs POSIX de manière
automatique. La configuration de celui-ci se fait par l’intermédiaire de deux fichiers qui ne sont pas
encore présent sur notre système :
/etc/smbldap-tools/smbldap_bind.conf
/etc/smbldap-tools/smbldap.conf
Il faudra donc les créer manuellement...
4.3.5.
Smbldap_bind.conf
Voici le détail du fichier ci-dessous :
masterDN="cn=Manager,dc=test,dc=local"
masterPw="MDP"
slaveDN="cn=Manager,dc=test,dc=local"
slavePw="MDP"
Comme vous pouvez le constater le mot de passe administrateur du LDAP est en clair, il est donc
important de lui changer les droits d’accès...
chmod 600 /etc/smbldap-tools/smbldap_bind.conf
4.3.6.
Smbldap.conf
Il contient un peu plus de paramètre et a aussi besoin du SID du domaine. Pour cela faire un :
net getlocalsid
Vous devez obtenir :
SID for domain DEV is: S-1-5-21-738282185-3837675623-175508106
Une fois le SID en poche il ne reste plus qu’a faire le fichier de configuration comme ci-dessous :
SID="S-1-5-21-738282185-3837675623-175508106"
masterLDAP="127.0.0.1"
masterPort="389"
slaveLDAP="127.0.0.1"
slavePort="389"
ldapTLS="0"
verify="require"
suffix="dc=test,dc=local"
usersdn="ou=Users,${suffix}"
27/49
PROJET DE SYNTHÈSE
V 2.5
computersdn="ou=Machines,${suffix}"
groupsdn="ou=Groups,${suffix}"
idmapdn="ou=Idmap,${suffix}"
# La ligne ci-dessous est commentee pour eviter une erreur lors de
# l'execution de la commande smbldap-populate.
# sambaUnixIdPooldn="cn=NextFreeUnixId,${suffix}"
#sambaUnixIdPooldn="sambaDomainName=dev,${suffix}"
scope="sub"
hash_encrypt="SSHA"
crypt_salt_format="%s"
userLoginShell="/bin/bash"
userHome="/home/%U"
userHomeDirectoryMode="700"
#Nom d'affichage - utiliser smbldap-useradd -c
userGecos="User"
defaultUserGid="513"
defaultComputerGid="515"
skeletonDir="/etc/skel"
#Les mots de passe expirent dans 10ans
defaultMaxPasswordAge="3650"
with_smbpasswd="0"
smbpasswd="/usr/bin/smbpasswd"
with_slappasswd="0"
slappasswd="/usr/sbin/slappasswd"
# mk_ntpasswd="/usr/local/sbin/mkntpwd"
4.3.7.
Peupler son arbre
Il va créer notre arbre de base au sein du LDAP. Pour cela il suffit de faire :
smbldap-populate
Le résultat doit être :
Populating LDAP directory for domain dev (S-1-5-21-738282185-3837675623-175508106)
(using builtin directory structure)
entry dc=test,dc=local already exist.
adding new entry: ou=Users,dc=afpa,dc=local
adding new entry: ou=Groups,dc=afpa,dc=local
adding new entry: ou=Machines,dc=afpa,dc=local
adding new entry: ou=Idmap,dc=afpa,dc=local
adding new entry: uid=root,ou=Users,dc=afpa,dc=local
adding new entry: uid=nobody,ou=Users,dc=afpa,dc=local
adding new entry: cn=Domain Admins,ou=Groups,dc=afpa,dc=local
adding new entry: cn=Domain Users,ou=Groups,dc=afpa,dc=local
adding new entry: cn=Domain Guests,ou=Groups,dc=afpa,dc=local
28/49
PROJET DE SYNTHÈSE
V 2.5
adding new entry: cn=Domain Computers,ou=Groups,dc=afpa,dc=local
adding new entry: cn=Administrators,ou=Groups,dc=afpa,dc=local
adding new entry: cn=Account Operators,ou=Groups,dc=afpa,dc=local
adding new entry: cn=Print Operators,ou=Groups,dc=afpa,dc=local
adding new entry: cn=Backup Operators,ou=Groups,dc=afpa,dc=local
adding new entry: cn=Replicators,ou=Groups,dc=afpa,dc=local
entry sambaDomainName=, serveur_test dc=test,dc=local already exist. Updating it...
Please provide a password for the domain root:
Changing UNIX and samba passwords for root
New password:
Retype new password:
Si vous avez des messages d’erreurs assurez-vous que votre schéma samba est bien présent dans les
schémas de votre serveur OpenLDAP.Le serveur samba est prêt à contrôler le domaine.Vous pouvez
aussi visualiser que sur votre interface phpldapadmin l’architecture a été mis à jour.Il est possible
d’ajouter un user administrateur en faisant :
smbldap-populate -a Administrateur
4.3.8.
Test du serveur radius
Une fois l'installation finalisée, nous pouvons tester le serveur sans modification nécessaire.
Lancer la commande suivante:
freeradius -X
Nous pouvons remarquer que le serveur fonctionne et écoute correctement:
/*********/
} # server
radiusd: #### Opening IP addresses and Ports ####
listen {
type = "auth"
ipaddr = *
port = 0
}
listen {
type = "acct"
ipaddr = *
port = 0
}
listen {
type = "control"
listen {
}
}
Listening on authentication address * port 1812
29/49
PROJET DE SYNTHÈSE
V 2.5
Listening on accounting address * port 1813
Listening on proxy address * port 1814
Ready to process requests.
Pour ainsi mettre en place l'authentification via radius, nous allons configurer certains fichiers pour que le
serveur puisse communiquer avec le serveur LDAP et utiliser le protocole d'authentification souhaité.
4.3.9.
Clients.conf
Modification du fichier :
/*********/
#
#
You can now specify one secret for a network of clients.
#
When a client request comes in, the BEST match is chosen.
#
i.e. The entry from the smallest possible network.
#
client 127.0.0.1{
secret
= testing123
shortname = test en boucle local
/*********/
Dans ce fichier on peut aussi éventuellement paramétrer un client dans le réseau pour effectuer un test
via un autre pc du réseau.
4.3.10.
Modules/ldap
/*********/
#
ldap {
#
#
Note that this needs to match the name in the LDAP
#
server certificate, if you're using ldaps.
server = "127.0.0.1"
identity = "cn=Manager,o=test,dc=local" password = sgueuglife
basedn = "o=test,dc=local"
filter = "(&(uid=%{%{Stripped-User-Name}:-%{User-Name}})(dialupAccess=yes))"
base_filter = "(objectclass=radiusprofile)"
/*********/
# default_profile = "cn=radprofile,ou=dialup,o=test,c=UA"
# profile_attribute = "radiusProfileDn" access_attr = "dialupAccess"
30/49
PROJET DE SYNTHÈSE
V 2.5
/*********/
#
Novell may require TLS encrypted sessions before returning
#
the user's password.
#
password_attribute = userPassword
/*********/
Ici, nous précisons les paramètres du serveur d’annuaire ainsi que les attributs d'authentifications.
4.3.11.
Site-enabled/default
/*********/
#
#
The ldap module will set Auth-Type to LDAP if it has not
#
already been set ldap
/*********/
#
# Use the checkval module
checkval
/*********/
# Uncomment it if you want to use ldap for authentication
#
# Note that this means "check plain-text password against
# the ldap database", which means that EAP won't work,
# as it does not supply a plain-text password. Auth-Type LDAP {
ldap
}
#
#
Allow EAP authentication. eap
/*********/
4.3.12.
Site-enabled/inter-tunnel
/*********/
#
The ldap module will set Auth-Type to LDAP if it has not
#
already been set ldap
/*********/
#
# Use the checkval module checkval
31/49
PROJET DE SYNTHÈSE
V 2.5
/*********/
# Uncomment it if you want to use ldap for authentication
#
# Note that this means "check plain-text password against
# the ldap database", which means that EAP won't work,
# as it does not supply a plain-text password. Auth-Type LDAP {
ldap
}
#
#
Allow EAP authentication. eap
/*********/
Il faut decommenter toutes les lignes dans ces differents fichiers qui pointent vers le serveur ldap et le
mode eap.
4.3.13.
Redémarrage des services
Une fois que vous avez terminé toute l'installation et la configuration de votre serveur Linux, pensez à
relancer les deux services:
/etc/init.d/smbd restart
/etc/init.d/slapd restart
/etc/init.d/freeradius restart
A l’issue de cette étape, on peut démarrer notre phase de test.
32/49
PROJET DE SYNTHÈSE
V 2.5
5 . L’ A N A LY S E D E S E TA P E S D ’ A U T H E N T I F I C AT I O N
5 .1 .
Te s t d e l ’ u t i l i s at e u r p ar d é fa ut d an s l a b a se rad i us
Maintenant nous allons ouvrir une autre fenêtre du terminal pour pouvoir effectuer nos tests. Nous avons
au préalable décommenté l’utilisateur par défaut « Steve »dans le fichier « /etc/radiusd/users ».Pour
effectuer cette manipulation, nous allons stopper le serveur radius :
/etc/init.d/ freeradius stop
Et puis le lancer en mode debugge :
freeradius -X
Nous constatons que le serveur est en écoute et en attente des instructions de commande :
Listening on authentication address * port 1812
Listening on accounting address * port 1813
Listening on authentication address 127.0.0.1 port 18120 as server inner-tunnel
Listening on proxy address * port 1814
Ready to process requests
Puis nous allons utiliser la commande radtest :
radtest {username} {password} {hostname} 10 {radius_nas_secret}
Nous allons voir les étapes défiler dans la première fenêtre :
root@testeur:~# radtest steve testing localhost 0 testing123
Sending Access-Request of id 209 to 127.0.0.1 port 1812
User-Name = "steve"
User-Password = "testing"
NAS-IP-Address = 127.0.0.1
NAS-Port = 0
rad_recv: Access-Accept packet from host 127.0.0.1 port 1812, id=209, length=20
La réponse nous démontre que l’authentification est valide. Regardons la deuxième fenêtre pour une
analyse plus dans le détail.
rad_recv: Access-Request packet from host 127.0.0.1 port 57457, id=209, length=57
User-Name = "steve"
User-Password = "testing"
NAS-Port = 0
# Executing section authorize from file /etc/freeradius/sites-enabled/default
+- entering group authorize {...}
++[preprocess] returns ok
++[chap] returns noop
++[mschap] returns noop
++[digest] returns noop
[suffix] No '@' in User-Name = "steve", looking up realm NULL
[suffix] No such realm "NULL"
++[suffix] returns noop
33/49
PROJET DE SYNTHÈSE
V 2.5
[eap] No EAP-Message, not doing EAP
++[eap] returns noop
[files] users: Matched entry steve at line 76
++[files] returns ok
[ldap] performing user authorization for steve
[ldap]
expand: %{Stripped-User-Name} ->
[ldap]
... expanding second conditional
[ldap]
expand: %{User-Name} -> steve
[ldap]
expand: (uid=%{%{Stripped-User-Name}:-%{User-Name}}) -> (uid=steve)
[ldap]
expand: dc=test,dc=local -> dc=test,dc=local
[ldap] ldap_get_conn: Checking Id: 0
[ldap] ldap_get_conn: Got Id: 0
[ldap] attempting LDAP reconnection
[ldap] (re)connect to localhost:389, authentication 0
[ldap] bind as cn=Manager,dc=test,dc=local/sgueuglife to localhost:389
[ldap] waiting for bind result ...
[ldap] Bind was successful
[ldap] performing search in dc=test,dc=local, with filter (uid=steve)
[ldap] object not found
[ldap] search failed
[ldap] ldap_release_conn: Release Id: 0
++[ldap] returns notfound
rlm_checkval: Could not find item named Calling-Station-Id in request
rlm_checkval: Could not find attribute named Calling-Station-Id in check pairs
++[checkval] returns notfound
++[expiration] returns noop
++[logintime] returns noop
++[pap] returns updated
Found Auth-Type = PAP
# Executing group from file /etc/freeradius/sites-enabled/default
+- entering group PAP {...}
[pap] login attempt with password "testing"
[pap] Using clear text password "testing"
[pap] User authenticated successfully
++[pap] returns ok
Login OK: [steve/testing] (from client localhost port 0)
# Executing section post-auth from file /etc/freeradius/sites-enabled/default
+- entering group post-auth {...}
++[ldap] returns noop
++[exec] returns noop
Sending Access-Accept of id 209 to 127.0.0.1 port 57457
Finished request 0.
Going to the next request
Waking up in 4.9 seconds.
Cleaning up request 0 ID 209 with timestamp +13
34/49
PROJET DE SYNTHÈSE
V 2.5
Nous constatons que le serveur radius nous revoie une réponse positive dans sa base de données (fichier
« /etc/radiusd/users ») et que cette utilisateur n’existe pas dans l’annuaire ldap car il n’a pas été crée
dans celui-ci donc tous est normal.
5 .2 .
Te s t d ’ u n u t i l i s at e u r d a ns l ’ a nnu ai re l d ap
5.2.1.
Access-Accept
Dans le même principe, nous allons tester l’utilisateur « sheerif » dans l’annuaire « test. Local ».Voici la
premiere fenêtre:
root@testeur:~# radtest sheerif sgueuglife localhost 0 testing123
User-Name = "sheerif"
User-Password = "sgueuglife"
NAS-Port = 0
rad_recv: Access-Accept packet from host 127.0.0.1 port 1812, id=234, length=20
Voici la seconde fenêtre qui va nous détailler les étapes de l’authentification:
User-Name = "sheerif"
NAS-Port = 0
[suffix] No '@' in User-Name = "sheerif", looking up realm NULL
++[files] returns noop
[ldap] performing user authorization for sheerif
[ldap]
[ldap]
[ldap]
expand: %{User-Name} -> sheerif
[ldap]
expand: (uid=%{%{Stripped-User-Name}:-%{User-Name}}) -> (uid=sheerif)
[ldap]
[ldap] performing search in dc=test,dc=local, with filter (uid=sheerif)
35/49
PROJET DE SYNTHÈSE
V 2.5
[ldap] No default NMAS login sequence
[ldap] looking for check items in directory...
[ldap] userPassword -> Cleartext-Password ==
"{SSHA}F4yuBKJTrwY7eKUTWC6KXOlxdMNlaWJS"
[ldap] userPassword -> Password-With-Header ==
[ldap] sambaNtPassword -> NT-Password ==
0x3642423045413232414345313041433137343732343844343536424436333839
[ldap] sambaLmPassword -> LM-Password ==
0x3046324331453541323538363131353341374441354446433445343642354235
[ldap] looking for reply items in directory...
[ldap] Setting Auth-Type = LDAP
[ldap] user sheerif authorized to use remote access
++[ldap] returns ok
[pap] Normalizing NT-Password from hex encoding
[pap] Normalizing LM-Password from hex encoding
[pap] Normalizing SSHA1-Password from base64 encoding
[pap] WARNING: Auth-Type already set.
Not setting to PAP
++[pap] returns noop
Found Auth-Type = LDAP
+- entering group LDAP {...}
[ldap] login attempt by "sheerif" with password "sgueuglife"
[ldap] user DN: uid=sheerif,ou=Users,dc=test,dc=local
[ldap] bind as uid=sheerif,ou=Users,dc=test,dc=local/sgueuglife to localhost:389
[ldap] user sheerif authenticated succesfully
++[ldap] returns ok
Login OK: [sheerif/sgueuglife] (from client localhost port 0)
Finished request 1.
36/49
PROJET DE SYNTHÈSE
V 2.5
5.2.2.
Analyse de l’acceptation
La première étape est un « Access-Request » qui contient l'identité de l'utilisateur qui veut s’authentifier:
[suffix] No '@' in User-Name = "sheerif", looking up realm NULL
La réponse de l’annuaire après une vérification dans sa base :
[ldap] performing user authorization for sheerif
[ldap]
[ldap]
[ldap]
expand: %{User-Name} -> sheerif
[ldap]
expand: (uid=%{%{Stripped-User-Name}:-%{User-Name}}) -> (uid=sheerif)
[ldap]
[ldap] performing search in dc=test,dc=local, with filter (uid=sheerif)
[ldap] No default NMAS login sequence
[ldap] looking for check items in directory...
[ldap] userPassword -> Cleartext-Password ==
[ldap] userPassword -> Password-With-Header ==
[ldap] sambaNtPassword -> NT-Password ==
0x3642423045413232414345313041433137343732343844343536424436333839
[ldap] sambaLmPassword -> LM-Password ==
0x3046324331453541323538363131353341374441354446433445343642354235
[ldap] looking for reply items in directory...
[ldap] Setting Auth-Type = LDAP
[ldap] user sheerif authorized to use remote access
++[ldap] returns ok
Puis vient la validation du mot de passe de l’utilisateur dans l’annuaire :
37/49
PROJET DE SYNTHÈSE
V 2.5
+- entering group LDAP {...}
[ldap] login attempt by "sheerif" with password "sgueuglife"
[ldap] user DN: uid=sheerif,ou=Users,dc=test,dc=local
[ldap] bind as uid=sheerif,ou=Users,dc=test,dc=local/sgueuglife to localhost:389
[ldap] user sheerif authenticated succesfully
++[ldap] returns ok
Login OK: [sheerif/sgueuglife] (from client localhost port 0)
Puis un « Access-Accept » qui permet d’accepter la requête du client après interrogation de sa base
d'authentification :
Finished request 1.
5.2.1.
Access-Reject
Dans le même principe, nous allons tester l’utilisateur « Manager» dans l’annuaire « test. Local ».Voici la
première fenêtre:
root@testeur:~# radtest Manager sgueuglife localhost 0 testing123
User-Name = "Manager"
NAS-Port = 0
rad_recv: Access-Reject packet from host 127.0.0.1 port 1812, id=235, length=20
Voici la seconde qui va nous détailler les étapes de l’authentification:
User-Name = "Manager"
NAS-Port = 0
[suffix] No '@' in User-Name = "Manager", looking up realm NULL
38/49
PROJET DE SYNTHÈSE
V 2.5
[ldap] performing user authorization for Manager
[ldap]
[ldap]
[ldap]
expand: %{User-Name} -> Manager
[ldap]
expand: (uid=%{%{Stripped-User-Name}:-%{User-Name}}) -> (uid=Manager)
[ldap]
[ldap] performing search in dc=test,dc=local, with filter (uid=Manager)
[pap] WARNING! No "known good" password found for the user.
because of this.
Authentication may fail
ERROR: No authenticate method (Auth-Type) found for the request: Rejecting the user
Failed to authenticate the user.
Login incorrect (
port 0)
[ldap] User not found): [Manager/sgueuglife] (from client localhost
Using Post-Auth-Type Reject
+- entering group REJECT {...}
[attr_filter.access_reject]
attr_filter: Matched entry DEFAULT at line 11
++[attr_filter.access_reject] returns updated
Delaying reject of request 2 for 1 seconds
Sending delayed reject for request 2
Sending Access-Reject of id 235 to 127.0.0.1 port 45040
39/49
PROJET DE SYNTHÈSE
5.2.1.
V 2.5
Analyse du refus
La première étape est un « Access-Request » qui contient l'identité de l'utilisateur qui veut s’authentifier:
[suffix] No '@' in User-Name = "Manager", looking up realm NULL
L’utilisateur est inexistant dans l’annuaire :
[ldap] performing user authorization for Manager
[ldap]
[ldap]
[ldap]
[ldap]
expand: (uid=%{%{Stripped-User-Name}:-%{User-Name}}) -> (uid=Manager)
[ldap]
[ldap] performing search in dc=test,dc=local, with filter (uid=Manager)
Puis vient l’invalidation du mot de passe:
[pap] WARNING! No "known good" password found for the user.
because of this.
Authentication may fail
ERROR: No authenticate method (Auth-Type) found for the request: Rejecting the user
Failed to authenticate the user.
Login incorrect (
port 0)
[ldap] User not found): [Manager/sgueuglife] (from client localhost
Un « Access-Reject » est émis par le serveur radius pour spécifier au client que sa requête non valide.
Using Post-Auth-Type Reject
+- entering group REJECT {...}
[attr_filter.access_reject]
attr_filter: Matched entry DEFAULT at line 11
++[attr_filter.access_reject] returns updated
40/49
PROJET DE SYNTHÈSE
V 2.5
Delaying reject of request 2 for 1 seconds
Sending delayed reject for request 2
Sending Access-Reject of id 235 to 127.0.0.1 port 45040
41/49
PROJET DE SYNTHÈSE
V 2.5
6. CONCLUSION
Ce projet est une alternative efficace qui peut-être adaptée à toutes les entreprises qui souhaitent avoir
une sécurisation de leurs infrastructure réseaux.
Dans ce dernier chapitre, nous avons présenté la maquette expérimentale, la phase de réalisation de
notre projet en présentant les solutions mises en place, la démarche de travail, le principe de
fonctionnement de chaque solution, finalement, nous avons présenté les tests de validation effectués.
Nous avons trouve l’étude du sujet de notre projet de synthèse très passionnant du fait de sa richesse
technique.
D’autre part, la mise en œuvre fut extrêmement complexe car les références sur internet ne sont pas
mises à jour, et que le sujet en lui-même est assez lourd et complexe.
L’élaboration de ce projet nous a permis, d’une part, d’approfondir les connaissances et le savoir faire
acquis durant ma formation à l’AFPA de St-Jérôme, et d’autre part, de préparer mon intégration à la vie
professionnelle et de me se situer sur le marché de l’exploitation de la production informatique.
42/49
PROJET DE SYNTHÈSE
V 2.5
7. BIBLIOGRAPHIE
http://www.commentcamarche.net/authentification/radius.php3
http://infodotnet.blogspot.com/2008/03/install-and-configure-freeradius-with.html
http://www.normes-internet.com/normes.php?rfc=rfc2865&lang=fr
http://www.etsi.org/frameset/home.htm?/technicalactiv/VPN/vpn.htm
http://www.untruth.org/~josh/security/radius/radius-auth.html
http://www.supinfo-projects.com/fr/2005/radius_fr/
http://www.supinfo-projects.com/fr/2005/radius%5Ffr/
http://www.commentcamarche.net/contents/internet/ldap.php3/
http://www.cisco.com/en/us/tech/tk59/technologies_tech_note/
43/49
PROJET DE SYNTHÈSE
V 2.5
8 . T R AVA U X C I T E S
Authentification réseau avec Radius : 802.1x, EAP, Free Radius de Serge Border.
Pascal THONIEL. Sécurité des systèmes d’information. Technique de l’ingénieur.
Marcel Rizcallah. Annuaires LDAP. EYROLLES.
Serge Bordères. Authentification réseau avec Radius. EYROLLES.
44/49
PROJET DE SYNTHÈSE
V 2.5
9. ANNEXES
9 .1 .
Te r mi no l o g i e
9.1.1.
Acronymes
Termes
Explication
LDAP
Light Directory Access Protocol
DN
Distinguished Name
RDN
Relative Distinguished Name
OID
Object Identifier
NIS
Network Information Service
SASL
Simple Authentification and Security Layer
TLS
Transport Layer Security
LDIF
LDAP Data Inter change Format
9.1.2.
Glossaire
Termes
Explication
IETF
Internet Engineering Task Force. Organisation
l'Internet.
ISO
International Standard Organisation. Organisation internationale de standardisation,
réunissant les organismes de normalisation de pas mal de pays dans le monde, et qui
travaille dans tous les domaines.
Kerberos
Protocole d'authentification réseau créé au MIT. Kerberos utilise un système de
tickets au lieu de mots de passe en texte clair. Ce principe renforce la sécurité du
système et empêche que des personnes non autorisées interceptent les mots de passe
des utilisateurs.
LDAP
Protocole d’accès à un annuaire qui permet de stocker des données légèrement typées,
organisées selon des classes particulières et présentées dans un arbre.
OSI
Open System InterConnect. Modèle en couches fournissant un cadre conceptuel et
normatif aux échanges entre systèmes hétérogènes. Le modèle OSI comporte 7 couches
1. Physique,
2. Liaison de données,
3. Réseau,
4. Transport,
5. Session,
6. Présentation,
7. Application.
PAM
Pluggable Authentification Modules. Technologie de gestion des interfaces
d’authentification pour les applications en nécessitant sur les systèmes Unix.
NSS
Name Server Switch. Technologie de résolution de nom sur les systèmes Unix.
RFC
Request For Comment. Référence auprès de la Communauté Internet, qui décrivent,
spécifient, aident à la mise en œuvre, standardisent et débattent de la majorité des
normes, standards, technologies et protocoles liés à Internet et aux réseaux en général.
préparant les principaux standards de
45/49
PROJET DE SYNTHÈSE
V 2.5
ACL
(Access Control List) Liste spécifiant les droits attribués à un ou plusieurs acteurs
(ex : un utilisateur) sur une ressource (ex : un fichier).
BDC
(Backup Domain Controller) Contrôleur secondaire de domaine, prend le relais du PDC en
cas de panne. Appellation propre à un domaine NT.
Classe
Permet de définir les particularités d'une famille d'objets, en spécifiant des attributs
obligatoires, et/ou des attributs optionnels possibles. Il y a possibilité d'héritage entre
classes, multiple ou non, pour les objets LDAP (Pour une sous-classe, obtention
automatique des attributs définis dans les classes supérieure dont elle hérite). Toutes les
classes héritent de la classe Top, qui est la classe du sommet de la hiérarchie des classes
(un seul attribut : objectClass).
DC
(Domain Controller) Terme générique pour désigner un contrôleur de domaine, qu'il soit
PDC, BDC (NT) ou qu'il n'ait pas de niveau d'importance particulier (Active Directory).
DIB
(Directory Information Base) Un annuaire LDAP/X.500 est une collection d'information de
toutes catégories. Ces informations sont stockées dans la "Directory Information Base"
ou DIB. La DIB est composées d'entrées, dont le contenu est régit par les notions d'objet
et de classes.
DIT
(Directory Information Tree) Un arbre LDAP/X.500 est organisé de façon arborescente, à
partir d'une racine unique nommée 'root'. Cette racine peut être vue comme une entrée
nulle (objet vide).
DN
(Distinguish Name) Au sein d'un annuaire LDAP, représente le nom et le chemin d'un
objet.Exemple : "cn=Users,ou=Groups,dc=afpa,dc=local".
Entrées
LDAP
Les entrées LDAP sont une collection d'attributs. Chaque attribut décrit un type bien
particulier d'information, et peut contenir une ou plusieurs valeurs (On dit qu'un attribut
peut être multi-valué). A chaque type d'attribut est lié une syntaxe spécifique donnant le
format possible de ses valeurs.
GID
(Group Identifier) Identité numérique représentant un groupe d'utilisateurs sous Unix.
GUI
(Graphical User Interface) Interface graphique
LDAP
(Lightweight Directory Access Protocol) Adaptation allégée du protocole X500. Protocole
de gestion d'annuaires réseaux.
NetBios
(Network Basic Input/Output System) n'est pas un protocole. Méthode de communication
sur un protocole existant ; est en fait une couche intermédiaire entre SMB et un
protocole sous-jacent tel que TCP (cf. NBT) ou IPX. Il fonctionne à la couche 5 (session)
du modèle OSI. Fournit une méthode de résolution de noms et de services aux couches
supérieures. Utilise un modèle de noms de machines de 15 caractères + 1 caractère de
contrôle spécifiant les services offerts par la machines.
NSS
(NSSwitch, Name Service Switch) Mécanisme qui intercepte les requêtes de noms
effectuées par la machine (concernant les noms de machines, d'utilisateurs : cf. getent,
...) et les redirige vers différentes sources d'informations (LDAP, MySQL...). Fonctionne
avec différents modules.
Objets LDAP
La notion d'objet permet de représenter abstraitement tout type d'information ou d'entité
existante. Une classe d'objet est une famille d'objets ayant certaines caractéristiques
communes.
OIDs
(Object Identifiers) Les Object Identifiers sont des suites uniques de nombres, qui
servent à identifier de façon sûre un type de donnée. Des OIDs sont utilisés pour
désigner l'identité des classes, des types d'attributs, et des syntaxes possibles de ces
46/49
PROJET DE SYNTHÈSE
V 2.5
attributs. Les OIDs sont formés à partir de la hiérarchie spécifiée par l'OSI, au niveau
mondial (de la même façon que les objets décrits dans les MIBs...)
PAM
(Pluggable Authentication Modules) Mécanisme d'authentification par modules. Il est
ainsi possible d'utiliser toutes sortes de sources de données (fichier passwd, LDAP,
biométrie...) pour valider un utilisateur.
PDC
(Primary Domain Controller) Contrôleur principal de domaine. Appellation propre à un
domaine NT.
SAM
(Security Account Manager) Base de données contenant les informations de sécurité sur
un serveur Windows NT, notamment les comptes et mots de passes des utilisateurs.
Schéma
Le schéma d'un annuaire est un ensemble de règles, qui doivent être utilisées par le
gestionnaire d'arbre (DIB et DIT), pour limiter les possibilités de création et de
structuration des entrées.
SID
(Security Identifier) Un SID est un identifiant unique attribué à chaque acteur d'un
domaine Windows. Il est composé d'une partie nommée "SID local", qui identifie le
domaine, et d'une seconde que l'on appelle "RID" (Relative Identifier), qui identifie
l'acteur (utilisateur/groupe/machine) au sein du domaine : un exemple de SID pourraitêtre : S-1-5-21-3493456274-4211610059-1786859526-512 qui identifie le groupe
d'Administrateurs du domaine (512) au sein du domaine S-1-5-21-34934562744211610059 .
TLS
(Transport Layer Security) Anciennement SSLv3.0, renommé et normalisé par l'IETF, cf.
RFC2246. Protocole de dialogue sécurisé pour attaquer un serveur LDAP.
UID
(User Identifier) Identifiant numérique représentant un utilisateur sous Unix.
UNC
(Universal Naming Convention)Convention de nommage universelle (sous Windows)
permettant de désigner le chemin d'un répertoire partagé. Ex. : \\Serveur\partage.
X500
Standard conçu par les opérateurs télécoms pour interconnecter leurs annuaires
téléphoniques.
9.1.3.
Définitions
Termes
Explication
Authentification
L’authentification est un procédé qui permet de vérifier l’identité d’une entité
(personne, système, etc..), afin d’autoriser cette entité d’avoir accès a une ressource
ou à un ensemble de ressources.
Physique
Authentification des accès physique à travers un réseau privé ou distant
(adresse MAC, clé wep, etc..).
Logique
Authentification des utilisateurs à travers un système ou une application
(annuaire, base de données, etc..).
Simple
Elle requiert un seul élément qui confirme et valide les droits pour permettre l'accès
à une ressource. L’exemple le plus connu est celui qu’ont utilise tout les jours c’est le
mot de passe.
Forte
Elle requiert plusieurs éléments combinés qui confirme et valide les droits pour
permettre l'accès à une ressource. Les exemples sont multiple mais le plus connu
reste la carte bancaire car elle combine la puce + bande magnétique + mot de
passe.
Unique
Elle permet à un utilisateur de ne procéder qu'à une seule authentification pour
47/49
PROJET DE SYNTHÈSE
V 2.5
accéder à plusieurs applications informatiques. Un exemple connu est MSN car avec
le même login + mot de passe, on a accès à la boite mail et a tous les autres
services annexes (Messenger, stockage, etc..).
Locale
C’est actuellement la solution que tout le monde utilise pour se connecte ou se
« logger » à son pc portable pour un particulier ou son ordinateur de bureau
(généralement dans les petites entreprises).La gestion de cette authentification se
fait localement dans chaque ordinateur par la gestion des comptes utilisateurs.
Centralisée
Le principe de base est ici de disposer d'un annuaire (base de données) globale qui
centralise tous les utilisateurs. Cela permet également de gérer de la politique de
sécurité. Un exemple de mise en œuvre est le contrôleur de domaine « active
directory ». Cette approche est principalement destinée à des services dépendant
tous d'une même entité.
Identification
L’identification est la capacité de reconnaitre une entité de manière unique et
catégorique. Cette identification peut prendre la forme d’un pseudonyme, d’un alias
ou tout simplement le nom réel de l’utilisateur. Elle peut aussi prendre la forme
d’une série de chiffres et de lettres.
Certification
La certification est l’assurance et la preuve absolue de la validité de l’identification et
de l’authentification d’une entité. Elle se traduit généralement par l’échange de
certificat dit : « électronique » ou numérique.
48/49
PROJET DE SYNTHÈSE
V 2.5
FI N DU DOCUME NT
49/49

authentification

Transcription

Documents pareils

TP Java EE

ENIB - Déploiement de l`ENT

fiche de poste - cat a - L`Université Paris Descartes

LDAP SAVOIR DUREE : 2 JOURS INTRODUCTION A LDAP

Formation - AIO Solutions

Logiciel: Xelios VNA 5 (Virtual Network Access)

INSTALLATION ET CONFIGURATION DE LDAPBROWSER OUTIL

Gestion des mots de passe Gestion des photos

à l`université du Havre

Le RESEAU EM@ Espace Multimédia de l