Cet article va présenter une utilisation de la norme 802.1x au sein d'un réseau d'utilisateurs. L'objectif est d'authentifier l'utilisateur aussi bien au niveau réseau (d'où le 802.1x) qu'au niveau système, en une authentification unique, et gérée d'une manière centralisée (dans notre exemple, un annuaire LDAP).

Présentation des technologies

Archicture

802.1x

Le protocole 802.1x est un protocole d'authentification au niveau ethernet, cela permet l'autorisation d'une machine auprès du commutateur, avant même de disposer d'une adresse IP. Dans la plupart des cas (pour ne pas dire tous), cette authentification est assurée par une communication entre le commutateur (qui peut être également un Access Point Wifi) et un serveur radius, mais il peut être également réalisé par une base de données internes aux équipements.

Radius

Radius est un protocole d'AAA (Authorization, Authentication, Accounting) permettant l'authentification des utilisateurs. Il fut créé notamment pour l'authentication pour des services d'accès distants (RTC, DialUP).

LDAP

LDAP est un protocole de communication et d'interrogation vers un annuaire. Le sujet est tellement vaste qu'il fera sujet d'articles dédiés.

Un mot sur les commutateurs

Certains commutateurs permettent l'application de différentes politiques d'accès (des ACL) en fonction de l'état 802.1x d'un port, c'est à dire si la machine est authentifiée ou non. Cela permet par exemple d'autoriser les flux DHCP, DNS pour tout les utilisateurs (qu'ils soient authentifié ou non), et de donner un accès full IP aux utilisateurs authentifiés.

Réalisation

Authentification unique et mode déconnecté

Afin d'assurer une authentification unique pour l'utilisateur (du moins pour se connecter au réseau et au système), nous avons développé un module pam_supplicant qui permet non seulement de rejouter le couple identifiant / mot de passe au daemon wpa_supplictant mais il procède également à la mise à jour du fichier /etc/shadow. Cette dernière opération permet une synchronisation du mot de passe local à partir de celui du serveur LDAP, qui est utilisé par les autres applications de l'Intranet.

Cette synchronisation permet donc l'authentification sur le poste lorsque que celui ci est déconnecté du réseau.

Configuration radius et la problématique des mots de passe

Problématique : une authentification radius s'effectue à l'aide d'un login et d'un mot de passe fourni par l'utilisateur, cependant le mot de passe est généralement condensé (hashé) à l'aide d'algorithme comme MS-CHAPv2, le serveur radius ne recevant donc pas en clair le mot de passe de l'utilisateur.

Le serveur freeradius permet deux types d'authentification sur un annuaire LDAP, l'une vérifie via une opération bind avec les identifiants utilisateurs, l'autre permet de spécifier l'attribut LDAP utilisé pour stocker le mot de passe, et vérifie les identifiants par une recherche sur le login, puis une comparaison du mot de passe (avec application de hash le cas échéant).

Plusieurs solutions (du moins deux) s'offrent à nous :

Utilisation de deux attributs LDAP

On stocke dans l'annuaire LDAP le mot de passe hashé via la même méthode que celle utilisée par les clients radius. Néamnoins, si les administrateurs du système d'information souhaitent (à juste titre) que les utilisateurs ne disposent que d'un, et d'un seul mot de passe, cela oblige à synchroniser le champ userPassword et celui utilisé par le serveur radius (par exemple radiusTunnelPassword). De plus, cela pose un problème de sécurité, en effet, si le même mot de passe est utilisé pour les attributs userPassword et radiusTunnelPassword, l'un sera stocké de façon forte (généralement le champ userPassword utilise l'algorithme SSHA SHA1 avec génération de sel), et l'autre de façon faible (le MS-CHAPv2 se casse en quelques secondes). Ce problème peut être résolu par l'utilisation d'ACL au niveau du serveur d'annuaire, en autorisant que les serveurs légitimes à lire/écrire le champ radiusTunnelPassword).

Utilisation d'EAP TTLS PAP

L'autre solution est de forcer l'utilisation de mot de passe en clair lors de l'échange radius. Bien évidemment, cela peut sembler dangereux, c'est pourquoi il conviens d'utiliser les méthodes TTLS (Tunnel TLS) dans radius, qui permettent l'authentification Radius sur un tunnel chiffré (nécessite donc un certificat coté serveur). On parle donc d'EAP-TTLS-PAP. Cette solution à le gros avantage de pouvoir configurer le serveur Radius à effectuer une recherche, puis un bind auprès de l'annuaire, afin de vérifier l'identité de l'utilisateur. Plus de problèmatique de méthode de hash différentes, plus de problèmatique de synchro de mot de passe !