AUTHENTIFICATION MANAGEMENT
MANEL KAWEM (RT4) TAYEB BEN ACHOUR (RT3)
SAMAR JAMEL (RT4) AMINE CHERIF (RT3) DORRA BOUGHZALA (RT3)
YASSINE DAMMAK (RT4) ABIR AKERMI (RT3)
1
Table des matières
I. Présentation de l’atelier : ... 2
II. Présentation des outils utilisés : ... 2
1. Vmware workstation : ... 2
2. Ubuntu : ... 2
3. Kerberos : ... 3
4. Service DNS : ... 3
5. Ntp : ... 4
6. SSH : ... 4
III. Architecture du réseau ... 5
IV. Configuration des outils ... 6
1. DNS : ... 6
2. NTP : ... 6
3. Kerberos : ... 9
a. Configuration de kerberos sur la machine serveur (server-kdc): ... 9
b. Configuration du royaume: ... 10
c. Configuration de la machine Client ... 12
4. SSH : ... 14
V. Un scénario de test ... 15
1. Schéma de fonctionnement : ... 15
2. Etapes du processus : ... 16
VI. Conclusion ... 18
1. Comparaison entre Kerberos et NTLM : ... 18
2. Correctifs et Personnalisations introduits par Microsoft : ... 19
2
I. Présentation de l’atelier :
Cet atelier vise essentiellement à la gestion du serveur d’authentification Kerberos et à son exploitation. En fait, l’interception des données et en extraire les mots de passe était depuis toujours le souci des chercheurs en sécurité informatique jusqu’à ce que Kerberos, et équivalents, apparaîssent. Ils ont remplacé tout cet automatisme par des clés secrètes et par l’utilisation des tickets, non en mots de passe afin d’éviter tous les risques de sécurité.
Ainsi, on va mettre en place dans notre atelier une architecture réseau permettant de tester cet outil et voir comment on peut l’exploiter dans d’autres services réseau.
II. Présentation des outils utilisés :
1. Vmware workstation :
C'est un logiciel libre de virtualisation permettant la création d'une ou plusieurs machines virtuelles au sein d'un même système d'exploitation (généralement Windows ou Linux), ceux-ci pouvant être reliés au réseau local avec une adresse IP différente, tout en étant sur la même machine physique (machine existant réellement).
2. Ubuntu :
« Ubuntu » est un système d’exploitation libre commandité par la société Canonical et une marque déposée par cette même société.
Fondé sur la distribution Linux Debian, ce système d'exploitation est constitué de logiciels libres, et il est disponible gratuitement, y compris pour les entreprises, selon un principe lié à la philosophie affichée du projet. On estime en 2011 qu'il y a plus de 25 millions d'utilisateurs des différentes versions pour ordinateurs.
En 2013, Mark « Shuttleworth » présente « Ubuntu Touch » et explique dans une vidéo qu' « Ubuntu » vise à être disponible pour tout un écosystème incluant les télévisions, les « smartphones », et les tablettes. Le gestionnaire de bureau « Unity », comme son nom l'indique, vise à unifier l’expérience utilisateur sur chacun des supports.
3
3. Kerberos :
Kerberos est un protocole d'authentification réseau mettant en oeuvre un système de chiffrement symétrique avec l'utilisation de tickets. 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 oeuvre sur des systèmes Unix. Ce protocole évite, en utilisant les tickets au lieu des mots de passe en clair, le risque d'interception frauduleuse des mots de passe des utilisateurs. En effet, une fois le client s'est identifié, il obtient un ticket. Le ticket joue le rôle d'une carte d'identité pour une courte durée, huit heures généralement (dix heures dans notre travail). Si nécessaire, celle-ci peut être coupée prématurément (avec la commande « kdestroy »). Une entité très importante se présente en mettant en oeuvre ce protocole est le KDC (Key Distribution Center). C’est un tiers de confiance qui connait et distribue les clés secrètes dans le royaume Kerberos.
4. Service DNS :
Le Domain Name System (ou DNS, système de noms de domaine) est un service permettant de traduire un nom de domaine en informations de plusieurs types qui y sont associées, notamment en adresses IP de la machine portant ce nom.
4
5. Ntp :
Le Protocole d'Heure Réseau (Network Time Protocol ou NTP) est un protocole qui permet de synchroniser, via un réseau informatique, l'horloge locale d'ordinateurs sur une référence d'heure. NTP est un protocole basé sur UDP et utilise le port 123.
6. SSH :
Secure Shell (SSH) est à la fois un programme informatique et un protocole de communication sécurisé. Le protocole de connexion impose un échange de clés de
chiffrement en début de connexion. Par la suite, tous les segments TCP sont authentifiés et chiffrés. Il devient donc impossible d'utiliser un sniffer pour voir ce que fait l'utilisateur.
Le protocole SSH a été conçu avec l'objectif de remplacer les différents programmes rlogin, telnet, rcp, ftp et rsh.
5
III. Architecture du réseau
Les clients :
Ces sont des applications agissant pour le compte des utilisateurs qui ont besoin d'accéder à une ressource, comme l'ouverture d'un fichier, l'interrogation d'une base de données ou d'accéder à un service … . Chaque client demande l'authentification Kerberos avant que la ressource est accessible. Une fois que le client est reconnu comme étant de confiance, une session sécurisée entre le client et le service hébergeant la ressource est établie. (Les clients peuvent aussi bien être des utilisateurs que des machines).
Le serveur d'authentification (AS pour Authentication Server) :
C’est le responsable d'identifier des utilisateurs distants, et des serveurs de livraison de tickets de service (TGS, pour Ticket Granting System), permettant de les autoriser à accéder à des services réseau.
Le service d'émission de tickets (TGS pour Ticket-Granting Service) :
Il s’agit d’un serveur émettant les tickets pour un service souhaité. Le client, pour accéder à un service en question, doit s’authentifier pour avoir un ticket du service d’émission de tickets (TGS) sous l’ordre du serveur d’authentification.
Le centre de distribution de clés (KDC pour Key Distribution Center) :
6
La plupart du temps, le serveur d’authentification et le serveur d’émission de tickets sont regroupés sur un même serveur, appelé Centre de Distribution des Clés (ou KDC, pour Key Distribution Center).de plus le KDC comporte une base de données qui stocke toutes les clés secrètes (ceux des clients et des services »), ainsi que certaines informations relatives aux comptes Kerberos (date de création, politiques, ...).
IV. Configuration des outils
Lors de cet atelier, 2 machines sont mises en œuvre :
server-kdc : le KDC avec @IP = 192.168.79.131
Client : le client avec @IP = 192.168.79.142
1. DNS :
Le fichier /etc/hosts aura le même contenu sur les deux machines :
2. NTP :
Les machines vont interagir entre elles. Du coup, elles doivent être synchrones.
On commence par l’installation de paquet NTP sur les deux machines :
Les machines doivent avoir la même horloge que server-kdc. Donc on doit configurer son ntp.conf en premier.
7
Ces deux lignes indiquent au serveur qu'il doit se synchroniser sur l'horloge local. Comme vous le constatez 127.127.1.0 ne représente pas l'adresse IP de la boucle locale. C'est en fait un subterfuge pour indiquer un pilote factice qui aurait pu faire référence à un oscillateur externe.
Ces lignes permettent de mettre en place des contrôles d'accès pour définir ce que sont autorisés à faire les serveurs nous fournissant le temps, et les clients se connectant.
Il faut indiquer sur quelle adresse ntp fait l’écoute, dans ce cas ntp écoute sur tous les adresses.
Maintenant on modifie le fichier /etc/ntp.conf sur la machine Client :
8
Ces deux lignes permettent au client de synchroniser le temps avec la machine « server- kdc »
On redémarre le service ntp pour enregistrer les modifications en tapant « service ntp restart ».
Une fois les fichiers ntp.conf configurés, on peut synchroniser le réseau de machine avec le serveur de temps local 192.168.79.131 correspondant à notre machine Kerberos (KDC) :
La commande « ntpdate » permet de synchroniser une machine avec le serveur de temps « server-kdc ».
9 Sur la machine client :
« offset = -0.7977577 sec » : il y’a une synchronisation entre le serveur de temps la machine « server-kdc » et la machine client
3. Kerberos :
a. Configuration de kerberos sur la machine serveur (server-kdc):
Dans cette première partie, on va installer et configurer le KDC Kerberos. On exécute donc les commandes suivantes:
Lors de l'installation du paquet par apt-get, il nous est demandé le nom du royaume (realm) Kerberos par défaut. Il nous est ensuite demandé le nom du serveur Kerberos du royaume ainsi que le nom du serveur d'administration.
On a précisé "server-kdc", le nom de notre station :
10
b. Configuration du royaume:
On configure le fichier /etc/krb5.conf : En installant le package de Kerberos, on le configure comme suit :
On définit server-kdc comme serveur Kerberos dans le royaume et comme serveur administratif du royaume
Ensuite, on configure le fichier /etc/krb5.conf :
ces lignes permettent d’envoyer la sortie vers ces fichiers log
Voici le contenu du fichier /etc/krb5kdc/kdc.conf correspondant à la configuration du KDC:
11 Ce fichier contient :
Les informations sur les bases de données Kerberos, des keytab et des acl.
Les ports du KDC.
Les informations sur les encodages supportés et sur la durée de vie des credentials.
Puis, on crée notre royaume Kerberos:
Une fois le royaume créé, il faut l’administrer en créant un principal pour l’administration de la base.
Dans notre cas c’est « root/admin@INF.ED.AC.UK»:
La commande « kadmin.local » nous permet ainsi de nous connecter en local sur l'admin- server et de pouvoir créer des politiques, des principals...
12
Ensuite, on crée le fichier «/etc/krb5kdc/kadmin.acl » qui définit les privilèges des principaux à créer.
Enfin, on peut tester l’authentification Kerberos:
kinit : qui va initialiser une connexion kerberos
klist : qui va montrer les sessions kerberos
Pour pouvoir utiliser "kadmin" en distant, nous devons créer les keytab pour les deux utilisateurs kadmin/admin et kadmin/changepw :
Maintenant que tout est configuré, nous allons donc démarrer krb5kdc et kadmind pour pouvoir utiliser kadmin en local et en distant.
c. Configuration de la machine Client
Pour que le client bénéficie des apports de la méthode d’authentification de Kerberos, on peut installer le paquet krb5-user.
Nous devons tout d'abord rajouter dans /etc/krb5.conf de la machine enseignant la déclaration de notre royaume « INF.ED.AC.UK »
13
Chaque fois l’utilisateur demande un ticket il doit entrer son mot de passe mais en utilisant les fichiers keytab on peut avoir des tickets sans intervention humaine.
Un keytab est un fichier contenant des paires de principals Kerberos avec une copie cryptée de la clé de chaque principal. Les fichiers keytab sont uniques à chaque hôte puisque leurs clés comprennent le hostname. Ce fichier est utilisé pour authentifier un principal sur un hôte pour Kerberos sans intervention humaine ou de stocker un mot de passe dans un fichier texte.
Sur la machine « server-kdc », on a ajouté un nouveau principal « utilisateur/admin »
Maintenant sur la machine « client » on sauvagarde pour le principal le mot de passe crypté dans un fichier keytab q’un doit indiquer
14
Maintenant, en demandant un ticket TGT et en indiquant le fichier keytab on n’a plus besoin de taper le mot de passe et si c’est le fichier par default if suffit de taper « kinit utilisateur/admin »
4. SSH :
SSH est un protocole de prise de commande a distance de manière sécurisée.
Il fonctionne en mode client/serveur.
Sur la machine serveur il suffit d’installer « openssh-server »
Pour la machine client, on doit installer « openssh-client »
Pour que ssh utilise kerberos pour son authentification , on doit modifier quelques parametres dans le fichier « /etc/ssh/sshd_config»
GSSAPI est une API pour homogénéiser l'authentification des échanges client-serveur sécurisés. Donc pour activer l’authentification avec il faut changer sa valeur a « yes »
De même pour la machine client, dans le fichier « /etc/ssh.ssh_config » , on doit modifier ces deux lignes en mettant ses valeurs a « yes »
Avant de tester le fonctionnement de ssh, chaque service kerborizé doit avoir un principal sur la machine KDC sous la forme « nom_service/nom_machine_KDC@REALM » avec l’option randkey un fichier « keytab » associé à ce service, ensuite il faut spécifier un autre principal qui prend le nom d’un « user » sur la machine client.
Dans le cas de ssh le principal associé à ce service doit prendre le nom « host »
15
Maintenant, on peut tester le fonctionnement du service ssh en tapant « ssh server-kdc » sur la machine client
V. Un scénario de test
1. Schéma de fonctionnement :
16
2. Etapes du processus :
• (1) .Un nom principal et la clé sont spécifiés pour le client.
• (2). Le client envoie le nom principal et une demande de TGT au KDC. Le KDC génère une clé de session et un TGT qui contient une copie de la clé de session, et utilise le ticket d'octroi de la clé de service (TGS) pour chiffrer le TGT. Il utilise ensuite la clé de la principale pour crypter à la fois le TGT déjà chiffré et une autre copie de la clé de session.
• (3). Le KDC envoie la combinaison cryptée de la clé de session cryptée et le TGT au client.
Le client utilise la clé du principal pour extraire la clé de session et le TGT crypté.
• (4). Lorsque le client souhaite utiliser un service, généralement pour obtenir l'accès à un système hôte local ou distant, il utilise la clé de session pour crypter une copie du ticket chiffré, l'adresse IP du client, un horodatage, et une demande de ticket de service, et il envoie cet article à la KDC.
Le KDC utilise ses copies de la clé de session et la clé TGS pour extraire le TGT, adresse IP, et l'heure, qui lui permettent de valider le client. À condition que le client et sa demande de service soient valides, le KDC génère une clé de session de service et un ticket de service qui contient l'adresse IP du client, une estampille temporelle, et une copie de la clé de session de service, et il utilise la clé de service à chiffrer le ticket de service. Il utilise ensuite la clé de session pour chiffrer à la fois le ticket de service et l'autre copie de la clé de session de service. La clé de service est généralement la clé du principal hôte pour le système sur lequel le fournisseur de service s’exécute.
• (5). Le KDC envoie la combinaison cryptée de la clé de session de service et le ticket de service cryptée au client. Le client utilise sa copie de la clé de session pour extraire le ticket de service chiffrée et la clé de session de service.
• (6). Le client envoie le ticket de service crypté au prestataire de services conjointement avec le nom principal et un horodatage chiffré avec la clé de session
de service.
Le fournisseur de service utilise la clé de service pour extraire les données dans le ticket de session de service, y compris la clé de session de service.
• (7). Le fournisseur de services permet au service pour le client, qui est généralement d'accorder l'accès à son système hôte. Si le client et le fournisseur de services sont hébergés sur des systèmes différents, ils peuvent chacun utiliser leur propre copie de la clé de session de service pour sécuriser les communications réseau pour la session de service.
Notez les points suivants concernant la poignée de main d'authentification:
17
• Les étapes (1) à (3) correspondent à l'aide de la kinit commande pour obtenir et mettre en cache un TGT :
* Au niveau de la machine serveur :
* Au niveau de la machine cliente :
• kinit : qui va initialiser une connexion kerberos .
• klist : qui va montrer les sessions kerberos .
• Les étapes (4) à (7) correspondent à l'aide d'un TGT pour avoir accès à un service Kerberos-courant.
18
• Authentification repose sur clés pré-partagées.
• Touches ne sont jamais envoyées en clair sur ne importe quel canal de communication entre le client, le KDC, et le fournisseur de service.
• Au début du processus d'authentification, le client et le KDC part la clé du principal et le KDC et la part du fournisseur de services la clé de service. Ni le principal ni le fournisseur de services ne connaissent la clé TGS.
• A la fin du processus, le client et le fournisseur de services de partage d'une clé de session de service qu'ils peuvent utiliser pour garantir la session de service. Le client ne connaît pas la clé de service et le fournisseur de service ne connaît pas la clé du principal.
• Le client peut utiliser le TGT pour demander l'accès à d'autres fournisseurs de services pour toute la durée du billet, qui est habituellement un jour. Le gestionnaire de session renouvelle le TGT se il expire alors que la session est active.
VI. Conclusion
1. Comparaison entre Kerberos et NTLM :
Le protocole Kerberos V5 est plus sécurisé, plus flexible et plus efficace que le protocole NTLM. Les avantages offerts par l’authentification Kerberos sont les suivants :
Authentification déléguée:
Les services Windows empruntent l’identité d’un client lorsqu’ils accèdent à des ressources pour le compte de ce client. Dans de nombreux cas, un service peut effectuer son travail pour le client en accédant aux ressources de l’ordinateur local. Les protocoles NTLM et Kerberos V5 fournissent les informations dont un service a besoin pour emprunter l’identité de son client localement. Toutefois, certaines applications distribuées sont conçues de telle sorte qu’un service frontal est obligé d’emprunter l’identité des clients lorsqu’il accède à des services principaux sur d’autres ordinateurs. Le protocole Kerberos V5 comprend un mécanisme de proxy qui permet à un service d’emprunter l’identité de son client lorsqu’il se connecte à d’autres services. Il n’existe aucun équivalent avec le protocole NTLM.
Interopérabilité:
L’implémentation par Microsoft du protocole Kerberos V5 est basée sur des spécifications normatives faisant l’objet de recommandations auprès du groupe de travail IETF. Par conséquent, l’implémentation Windows du protocole Kerberos V5 pose les bases d’une interopérabilité avec les autres réseaux où le protocole Kerberos V5 est utilisé à des fins d’authentification.
Authentification plus efficace auprès des serveurs:
Avec l’authentification NTLM, un serveur d’applications doit se connecter à un contrôleur de domaine afin d’authentifier chaque client. En revanche, avec le protocole d’authentification Kerberos V5, le serveur n’est pas obligé d’accéder à un contrôleur de domaine. À la place, le serveur peut authentifier le client en examinant les informations
19
d’identification présentées par le client. Les clients peuvent obtenir des informations d’identification pour un serveur particulier, puis réutiliser ces informations d’identification tout au long d’une session ouverte sur le réseau. Les tickets de session renouvelables remplacent l’authentification directe.
Authentification mutuelle:
À l’aide du protocole Kerberos, chacune des parties situées à chaque extrémité d’une connexion réseau peut vérifier que la partie distante est bien l’entité qu’elle prétend être.
Bien que le protocole NTLM permette aux serveurs de vérifier les identités de leurs clients, NTLM ne permet pas aux clients de vérifier l’identité d’un serveur. Par ailleurs, NTLM ne permet pas non plus à un serveur de vérifier l’identité d’un autre serveur. L’authentification NTLM a été conçue pour un environnement réseau dans lequel les serveurs sont considérés comme authentiques. Le protocole Kerberos V5 n’utilise pas ce genre d’hypothèse.
2. Correctifs et Personnalisations introduits par Microsoft :
Augmentation de la taille de mémoire tampon du jeton de contexte SSPI Kerberos Lorsque les applications cherchent à déterminer la taille maximale de mémoire tampon du jeton de contexte d’authentification afin de pouvoir préallouer de la mémoire, leur authentification peut échouer lorsque le message Kerberos ou le message de négociation retourné est plus grand que prévu.
Quels avantages cette modification procure-t-elle ?
L’augmentation de la taille par défaut de cette mémoire tampon évite un plus grand nombre d’échecs de demande d’authentification des applications en raison d’une limitation de l’espace.
En quoi le fonctionnement est-il différent ?
Dans Windows Server 2012 et Windows 8, il a été conseillé d’augmenter la taille de mémoire tampon du jeton de contexte SSPI Kerberos par défaut pour définir cette valeur au-delà de 48 000 octets.
Centre de distribution de clés avec événements d’avertissement pour les tickets Kerberos de grande taille
Le nouveau paramètre de stratégie de modèle d’administration du centre de distribution de clés Événements d’avertissement pour les tickets Kerberos de grande taille vous permet de contrôler les événements d’avertissement système consignés par un centre de distribution de clés lorsque des tickets délivrés durant l’authentification Kerberos sont proches ou supérieurs à une taille de valeur de seuil configurée. Les avertissements relatifs à la taille des tickets correspondent à l’ID d’événement 31 dans le journal système.
En quoi le fonctionnement est-il différent ?
Toutefois, vous devez prendre en compte certaines considérations pour fixer ce seuil d’avertissement. S’il est trop élevé, les avertissements ne sont pas émis avant les échecs d’authentification en raison de la taille de mémoire tampon du jeton de contexte d’authentification qui est plus importante que prévu. S’il est trop faible, l’augmentation des
20
entrées de journal rend l’analyse plus difficile. La taille doit être définie selon : Votre valeur de Registre MaxTokenSize personnalisée :
La taille déployée par le paramètre de stratégie de groupe Définir la taille maximale de la mémoire tampon des jetons de contexte SSPI Kerberos.
Si le paramètre Événements d’avertissement pour les tickets Kerberos de grande taille n’est pas activé, la valeur de seuil est par défaut de 12 000 octets, ce qui représente le paramètre par défaut pour MaxTokenSize pour les tickets Kerberos dans Windows 7, Windows Server 2008 R2 et les versions antérieures.
Nouvelles fonctionnalités et fonctionnalités modifiées pour les professionnels de l’informatique
Prise en charge par la filiale de l’authentification des ressources externes à la filiale : Dans Windows 7, lorsque l’utilisateur se connectait à l’aide d’une carte à puce avec un groupe mappé, le groupe était perdu lorsque l’utilisateur se connectait à des ressources en dehors de la filiale. Un périphérique exécutant Windows 8 dans une filiale utilise un contrôleur de domaine du concentrateur exécutant Windows Server 2012 pour obtenir un ticket TGT (Ticket-Granting Ticket). Il utilise le ticket TGT pour demander des tickets de service pour des ressources en dehors de la filiale. Aucune configuration n’est requise pour utiliser cette fonctionnalité.
Prise en charge des revendications, de l’authentification composée et du blindage Kerberos :
Si vous souhaitez créer un contrôle d’accès basé sur les revendications et l’authentification composée, vous devez déployer le contrôle d’accès dynamique. Cela nécessite une mise à niveau vers les clients Kerberos et l’utilisation du centre de distribution de clés, qui prennent en charge ces nouveaux types d’autorisation. Avec Windows Server 2012, il n’est pas nécessaire d’attendre que tous les contrôleurs de domaine et le niveau fonctionnel de domaine soient mis à niveau pour tirer parti des nouvelles options de contrôle d’accès.
Pour plus d’informations sur le contrôle d’accès dynamique dans Windows Server 2012, voir Contrôle d’accès dynamique : vue d’ensemble des scénarios et les rubriques connexes.
Quels avantages cette modification procure-t-elle ?
Vous pouvez créer un contrôle d’accès basé sur les revendications et l’authentification composée.
En quoi le fonctionnement est-il différent ?
Le nouveau paramètre de stratégie de modèle d’administration du centre de distribution de clés Prise en charge du centre de distribution de clés pour les revendications, l’authentification composée et le blindage Kerberos vous permet de configurer un contrôleur de domaine de façon à prendre en charge les revendications et l’authentification composée pour le contrôle d’accès dynamique et le blindage Kerberos à l’aide de l’authentification Kerberos. Ce paramètre de stratégie est configuré sur l’unité d’organisation du contrôleur de domaine.
Lorsque le paramètre Pris en charge (ou supérieur) est configuré, les contrôleurs de domaine
21
exécutant Windows Server 2012, Windows Server 2008 R2 ou Windows Server 2008 signalent la prise en charge par le domaine des revendications et de l’authentification composée pour le contrôle d’accès dynamique et le blindage Kerberos. Aucun contrôleur de domaine exécutant Windows Server 2003 ne peut se trouver dans un domaine qui prend en charge les revendications et l’authentification composée pour le contrôle d’accès dynamique et le blindage Kerberos.
En outre, le paramètre de stratégie de modèle d’administration Prise en charge par le client Kerberos des revendications, de l’authentification composée et du blindage Kerberos vous permet de configurer des périphériques exécutant Windows 8 pour prendre en charge les revendications et l’authentification composée pour le contrôle d’accès dynamique et le blindage Kerberos à l’aide de l’authentification Kerberos. L’authentification des périphériques exécutant Windows 8 échoue si aucun contrôleur de domaine exécutant Windows Server 2012 n’est trouvé. Il est important de s’assurer qu’il existe suffisamment de contrôleurs de domaine exécutant Windows Server 2012 pour tous les comptes, références et domaines de ressources qui sont pris en charge.
