Authentification et mobilité (document destiné aux Administrateurs)

Une page spéciale d'introduction à 802.1X a été composée a l'adresse des utilisateurs.

Plan :

I) Introduction

• a) Nos objectifs
• b) Organigramme de la solution complète
• c) Rappels sur 802.1X
  • Principes de base
  • Mécanisme de base
• d) Méthodes d'authentification supportées

II) Authentification et mobilité avec 802.1X

• a) Principes et mécanismes mis en oeuvre
  • Mise en place des VLANs à l'échelle d'un site
  • Unification des mots de passe
  • Eléments en central et au sein des labos
  • Divers :
    • Le realm
    • Le RadiusGroupName
    • Le compte "visiteurs"
    • L'origine d'une requête
• b) Installations & configurations
  • En central :
    • Le RADIUS
    • Le LDAP
    • Le Routeur de Site (A FAIRE)
  • Dans les laboratoires :
    • Le routeur (A FAIRE)
    • Les switches (A FAIRE)
    • Le portail captif
    • Le DHCP (A FAIRE)
  • L'accounting :
    • Le principe (A FAIRE)
    • La mise en place en central (A FAIRE)
    • La remontée des logs depuis les labos (A FAIRE)
• c) Exemples concrets
  1. Pannes et diagnostics (à compléter)
  2. Exemple d'un labo sans Active Directory
  3. Exemple d'un labo avec Active Directory
  4. Exemple de mobilité d'un utilisateur d'un labo sans AD
  5. Exemple de mobilité d'un utilisateur d'un labo avec AD
  6. Exemples de mobilité inter-site
  7. Exemples de connexion par Portail Captif

1. Configuration (pour les administrateurs)
2. Modes de connexions (pour les utilisateurs)

•   Avec une clé WPA seule
•   Via le portail captif
•   En 802.1x
•   Via le VPN

VI) Contributions

I) Introduction :

I.a) Nos objectifs :

• Répondre aux besoins de mobilité et de délocalisation (Campus-Polygone)
• Prendre en compte la nécessité d'identifier désormais les utilisateurs du réseau
  (voir aussi la loi mars 2006 qui impose que toute connexion Internet soit identifiée,
  ainsi que la note du CNRS du 1er décembre 2009)
• Intégrer les accès WiFi et tous les types de client
• Disposer de traces fiables et précises (accounting)
• Nous appuyer sur
  • les standards et les normes (RADIUS, 802.1X, LDAP, EAP, les VLANs, Kerberos , ...),
  • Les logiciels libres ( FreeRadius, Xsupplicant, ChilliSpot, SAMBA, openVPN , ...),
  • La réflexion et le travail entamé dans les universités depuis 2003 ( voir aussi, et aussi ).
• Y intégrer l'incontournable spécificité Microsoft
  • PEAP, l'authentification native avec Windows
  • les Active Directory pouvant se trouver dans les laboratoires
• Adopter une politique compatible avec les organismes qui promeuvent la mobilité par la gestion des accès réseau, en France ( ARREDU ), et dans le monde ( EduRoam)
• Limiter les contraintes aux administrateurs et aux utilisateurs

I.b) Organigramme de la solution complète :

Le VPN répond à la problématique "délocalisation de certains chercheurs", lorsque le mécanisme 802.1X n'est pas applicable.
Le portail captif offre un accès minimum (Internet, imprimantes, ...) aux ordinateurs ne supportant pas 802.1X.
Cependant, dans tous les cas il y a authentification et traces dans les logs de la connexion.

I.c) Rappels sur 802.1X :

• de maîtriser les accès au réseau : qui autoriser ? dans quel VLAN ?
• d'dentifier les connexions et les utilisateurs : login, @IP, @MAC, date, heure
• de leur affecter dynamiquement un VLAN -> Mobilité

• Dès que Jean Dubois allume son ordinateur ou qu'il le connecte au réseau, le switch ou la borne WiFi lui demande de s'authentifier (1).
• Le witch ou la borne transmet son login et son mot-de-passe au RADIUS central (2).
• Le RADIUS vérifie son identification auprès du LDAP central ou de l'Active Directory de son labo (3).
  (le LDAP indique au passage quels VLANs Jean Dubois a le droit d'aller (cf. RGN plus bas) )
• Si son identification est correcte, le RADIUS indique au switch ou à la borne WiFi dans quel VLAN placer Jean Dubois (4).

I.d) Méthodes d'authentification supportées :

• EAP-TTLS : authentification qui impose un certificat électronique côté serveur et un "login/mot de passe" côté utilisateur (le certificat du serveur pour créer un tunnel dans lequel transitera le mot de passe).
  Cette méthode standard est essentiellement utilisée par Linux et MAC.
• PEAP : authentification developpée par Microsoft et Cisco, et donc nativement supportée par Windows. Elle travaille de la même façon que EAP-TTLS, mais brouille le mot de passe avant de l'envoyer dans le tunnel ( détail )

II) Authentification et mobilité avec 802.1X :

Contexte du polygone CNRS-Grenoble :

• l'un appuyant son authentification sur le LDAP central : le laboratoire LABO-LDAP
• l'autre sur son Active Directory : le laboratoire LABO-AD

1) Principe et mécanismes mis en oeuvre :

• Mise en oeuvre des VLANs à l'échelle d'un site ( à l'échelle d'un labo ) :
  
  
  
  Cette mise en oeuvre à l'échelle d'un site implique :
  • Les serveurs RADIUS et LDAP sont en central
  • Le LDAP dispose des mots de passe en NT-hash
  • Le RADIUS sait dialoguer soit avec le LDAP soit avec un AD de labo
  • Chaque labo :
    • A son jeu de VLANs -> nécessité d'un plan global
    • Configure son routeur (ACLs, mode trunk, VTP) et ses switches (RADIUS, mode trunk, VTP)
    • Installe un portail captif
  • Etablissement d'un plan de numérotation global. Chaque labo a ses sous-réseaux et ses VLANs. Exemple pour LABO-LDAP et LABO-AD :
  
  

  VLAN	LABO-LDAP	No de VLAN	LABO-AD	No de VLAN
  Interne	147.173.240.x/22	240	147.173.224.x/22	224
  DMZ	147.173.244.x/24	244	147.173.228.x/24	228
  Invité	147.173.245.x/24	245	147.173.229.x/24	229
  Trafic-Chilli	147.173.246.x/24	246	147.173.230.x/24	230
  Auth-Chilli	10.8.246.x/24	846	10.8.230.x/24	830
  Administration	192.168.240.x/24	540	192.168.224.x/24	524
  VPN	147.173.251.x/24	251	147.173.235.x/24	235

  
  
      Note: Le VLAN Auth-Chilli (10.8.X.y) affecté au réseau privé du portail captif (ChilliSpot) est aussi nommé VLAN "nomadisme" car permet les accès VPNs directs entre le Polygone et le Campus.
  
  
• Unification des mots de passe :
  La solution présentée ici s'appuie à la fois sur un LDAP central sous UNIX et sur les Active Directory présents dans certains laboratoires.
  Rendre le RADIUS capable d'interroger l'un ou l'autre -selon la source de la requête ou la destination de connexion souhaitée- présente les avantages suivants :
  • laisser aux administrateurs de labo gérer leur base comme ils l'entendent
  • n'imposer qu'une seule authentification à l'utilisateur
  • ne pas avoir à dupliquer les informations
  Par contre, si l'on veut utiliser la mobilité, le fait qu'il y ait plusieurs bases impose de maintenir une cohérence au niveau des noms et des mots de passe des utilisateurs du site.
  Il faut donc qu'en LDAP central figurent les 2 représentations des mots de passe, ainsi qu'un SID (il peut être la simple copie de l'uid number UNIX).
  La synchronisation lors de la mise à jour d'un mot de passe est réalisée grâce à la page HTTPS réservée aux administrateurs de labo.
  
  
• Eléments en central :
  • Un serveur RADIUS a été installé en central pour éviter aux labos d'avoir à installer/gérer le leur. Il répond aux demandes d'authentification de l'ensemble des laboratoires et consulte soit le LDAP central soit l'Active Directory (AD) de labo si le labo en maintient un.
  • En central un serveur LDAP assure déjà l'authentification de la messagerie et des connexions HTTPS. Pour l'authentification PEAP il lui a été ajouté 2 champs : un sambaLMPassword et un sambaNTPassword (reflètent le userPassword), ainsi qu'un sambaSID (mis à la même valeur que l'uid-number).
  
  
• Eléments au sein des labos :
  • Des switches supportant 802.1X et 1 prise par port.
  • Un portail captif doit être installé pour les ordinateurs ne supportant pas 802.1X (Ex: vieux PCs de manip)
  
  
• Le realm ou royaume :
  Ce champ précise le nom de la communauté lors d'une authentification RADIUS. Il permet une ré-orientation :
  • vers un autre RADIUS (proxy). Ex: jean.dupond@toulouse.cnrs.fr. Dans ce cas le realm = le domaine DNS de l'établissement.
  • soit vers un autre labo interne. Ex: jean.dupond@LABO-Y permet à Jean Dupond, depuis le labo LABO-X, de demander à se retrouver dans le réseau interne de son labo, le LABO-Y (s'il y est autorisé (cf. le radiusGroupName ci-dessous)).
    Selon que le laboratoire de destination appuie son authentification sur un Active Directory (AD) ou sur le LDAP central, le RADIUS soumettra l'authentification de l'utilisateur à l'un ou à l'autre.
  Le realm permet donc à l'utilisateur d'indiquer au RADIUS s'il souhaite se connecter au réseau d'un autre laboratoire (Ex: durand@lncmi) ou d'un autre site (durand@grenet.fr).
  
  
• Le radiusGroupName :
  ce champ spécial a été ajouté dans le LDAP central. Il peut prendre soit la valeur "interneLABO-XX" soit la valeur "inviteLABO-XX" et n'est (modifiable uniquement par l'administrateur informatique du labo (du LABO-XX en l'occurence).
  Quelques principes :
  • Si l'on affecte à un utilisateur "interneLABO-XX" et "interneLABO-YY", il sera indifféremment accepté dans les réseaux internes des labos XX et YY (uniquement dans ceux-là).
  • Si un utilisateur est "interne" dans un labo quelconque, il est accepté par défaut dans le réseau invité de tous les autres.
  • Si un utilisateur est "inviteLABO-XX", il sera refusé en interne ou en invité dans tous les autres labos (y compris le sien depuis un autre labo car le VLAN "invite" n'est pas routé).
  • Par défaut la valeur : "inviteLABO-XX" est affectée aux nouveaux entrants (temporaires ou permanents).
  
  
• Les visiteurs :
     Pour la problématique nomadisme on a ajouté dans le LDAP central :
  • Une entrée "visiteurs" réservée aux enregistrements de très courte durée (de 1 à 8 jours).
    Cette entrée "visiteurs" est une branche particulière de l'annuaire :
    
    • On ne crée pas de e-mail sur le serveur pour cette personne.
    • La fiche contient:
      son nom, son prénom, son e-mail, le nom du permanent qui le reçoit, le nombre de jours (max 8).
      Au delà de cette période la fiche est mémorisée pour des besoins éventuels d'identification ultérieurs.
    • Le "radiusGroupName" prend par défaut la valeur : "inviteLABO-XX", où LABO-XX=labo de la secrétaire qui remplit la fiche.
  • Un codage du mot de passe de l'utilisateur en Samba :
    sambaLMPassword, sambaNTPassword et un sambaSID
    Ceux-ci sont utilisés pour le codage "windowsien" du mot de passe en PEAP.
  Tout permanent peut créer des comptes "visiteur" via l'interface HTTPS.
  
  
• L'origine d'une requête :
  C'est grâce à l'adresse d'émission d'une requète en provenance d'un switch ou d'une borne WiFi, que le RADIUS central détermine dans quel labo se trouve actuellement l'utilisateur, et s'il se trouve à l'intérieur ou à l'extérieur de son labo.

2) Installations & configurations :

Le FreeRadius central :

Le LDAP Central :

Le Portail Captif :

• (1) le client demande une adresse sur le réseau
  -> le Portail Captif lui donne une adresse non-routable en 10.8.128.x
• (2) quand le client fait une requête web (port 80 ou 443),
  -> le Portail Captif intercepte cette requête
  -> il demande une authentification (une fenêtre de demande Login/mot de passe s'ouvre chez le client)
       (ces informations sont cryptées car le Portail Captif est un serveur HTTPS)
  
• (3) le Portail Captif les transmet au Radius Central.
• (4) Si l'authentification est OK :
  • le Portail Captif accorde au client une adresse IP routable.
    (parmi une plage d'adresses non-routables->routables pré-définie (Ex: 10.8.128.5->147.173.128.5). Détails ci-dessous en "configuration de ChilliSpot").
  • pour les besoins d'accounting (cf. chapitre 8) le Radius Central crée une entrée en base SQL

• sur le Switch :
  SW# sh interface fa0/19 status (le port où est connecté le PC ou la borne)
  Status           Vlan
  passe de :
  notconnect      1
  à :
  connected      846 (si 846 est le No de VLAN AuthChilli du labo)
  
  
• sur le PC client :
  cmd: ipconfig
  passe de :
  Autoconfiguration de l'adresse IP......... 169.254.182.7
  à :
  Adesse IP..................................10.8.246.2
  
  
• sur le serveur Chilli :
  tail -50 /var/log/daemon.log
  

3) Exemples concrets :

• côté ordinateur (si les autres y accèdent sans problème), vérifier :
  • la connectique
  • la configuration
  • certains virus peuvent empêcher l'accès au réseau
• côté Switch de labo (si ceux qui y sont connectés ont le même problème), vérifier :
  • si le secret entre le RADIUS central et ce Switch sont identiques
  • que l'@IP de ce Switch soit déclarée dans les fichiers huntgroup et client.conf du RADIUS Central
  
  

• le problème est nouveau :
  • vérifier les filtres côté labo, les branchements
• cela n'a jamais marché. Mettre en place ou vérifier :
  • la configuration et les filtres côté routeur labo
  • les filtres sur le routeur Central

1. L'utilisateur se connecte (ou allume son ordinateur).
2. Le switch lui demande de s'authentifier : il fournit son login et son mot-de-passe.
3. Le switch du CRETA transmet cette authentification au RADIUS central (le mot de passe transite dans un tunnel chiffré).
4. Le RADIUS central voit que la requête vient du CRETA et que celui-ci s'appuie sur le LDAP central.
   -> Il consulte donc le LDAP pour :
   1. qu'il valide l'authentification
   2. qu'il indique le(s) RadiusGroupName de l'utilisateur
5. Selon ce(s) RadiusGroupName, le RADIUS retourne au switch le VLAN dans lequel placer l'utilisateur :
   • si "interneCRETA"         -> VLAN interne du CRETA
   • si "interneAutreLABO" -> VLAN invite du CRETA
   • si "inviteCRETA"          -> VLAN invite du CRETA (cas aussi des visiteurs)
   • si "inviteAutreLABO"   -> Rejet
6. L'utilisateur se retrouve dans le VLAN correspondant.

1. L'utilisateur se connecte (ou allume son ordinateur), puis s'authentifie.
2. Le switch transmet cette authentification au RADIUS central.
3. Le RADIUS central voit que la requête vient de NEEL.
   Sachant que ce laboratoire appuie son authentification sur son Active Directory, le RADIUS consulte celui-ci afin :
   1. qu'il valide l'authentification
   2. qu'il indique si l'utilisateur est permanent ou invité
      Note : L'attribut qui indique cela n'est pas encore défini. En attendant tous les utilisateurs authentifiés sont acceptés dans le VLAN interne.
4. Selon cet attribut, le RADIUS indique au switch le VLAN dans lequel placer l'utilisateur :
   • si "interne"       -> VLAN interne du NEEL
   • si "invite"          -> VLAN invite du NEEL
5. L'utilisateur se retrouve dans le VLAN correspondant. Éventuellement il reçoit des mise-à-jour de la part de l'Active Directory.

1. L'utilisateur indique "dupond@creta" puis s'authentifie.
2. Le switch du labo dans lequel il est en visite transmet cette authentification au RADIUS central.
3. Le RADIUS central voit que la requête vient du LNCMI mais que l'utilisateur a précisé CRETA.
   Comme il voit que le CRETA s'appuie sur le LDAP central, il consulte celui-ci afin :
   1. qu'il valide l'authentification
   2. qu'il indique le(s) RadiusGroupName de l'utilisateur
4. Selon ce(s) RadiusGroupName, le RADIUS retourne au switch le VLAN dans lequel placer l'utilisateur.
   • VLAN interne CRETA s'il a "interneCRETA"
   • VLAN invité s'il est permanent d'un autre labo ou invité du labo LNCMI.
   • S'il n'est qu'invité d'un autre labo il est rejeté.
5. L'utilisateur se retrouve dans le VLAN correspondant.
   Il reçoit une adresse du serveur DHCP (du labo destinataire ou du labo local)

1. L'utilisateur indique "Utilisateur : dupond@neel" ou laisse comme d'habitude : "Utilisateur : dupond" + "Se connecter à : NEEL"
   puis il s'authentifie.
2. Le switch du labo dans lequel il est en visite transmet cette authentification au RADIUS central.
3. Le RADIUS central voit que la requête vient du CRETA mais que l'utilisateur souhaite se connecter à NEEL.
   Sachant que ce laboratoire dispose d'un Active Directory, le RADIUS consulte celui-ci afin :
   1. qu'il valide l'authentification
   2. qu'il indique si l'utilisateur est permanent ou invité
4. Avec cette information le RADIUS indique au switch du CRETA dans quel VLAN il doit placer l'utilisateur :
   • si "interne"       -> VLAN interne du NEEL
   • si "invite"          -> Rejet, car un invité ne peut se connecter depuis l'extérieur.
5. L'utilisateur se retrouve dans le VLAN correspondant. Éventuellement il reçoit des mise-à-jour de la part de l'Active Directory.
   Si son ordinateur n'est pas enregistré dans l'Active Directory, l'utilisateur se retrouve dans le réseau NEEL mais n'a pas accès au domaine Windows.

1. Pour s'authentifier, il indique "Utilisateur : dupond@toulouse.fr".
2. Le RADIUS de Grenoble voit que la requête ne lui est destinée, il la transmet au RADIUS national.
3. Quand le RADIUS national s'est assuré que @toulouse.fr correspond à un site enregistré comme participant à EduRoam, il lui proxifie (prolonge le tunnel) la requête.
4. Si le RADIUS de Toulouse valide l'authentification de l'utilisateur, le RADIUS de Grenoble demande au switch de labo de le placer dans son VLAN invité.

III) Wifi :

• Pour les administrateurs :

  Configurations préalables pour une salle de conférence.
  Documentation complète (2005) de la borne HP WL420 + ses Release notes (2007)

• Pour les clients (chercheurs, visiteurs) :

  Rappel : une borne WiFi annonce par des SSID les réseaux auxquels elle permet d'accéder. Votre ordinateur "voit" ces SSID via sa carte WiFi. Pour "voir" ces SSID et donc les réseaux sans fil disponibles :
    a) cliquez sur Démarrer -> Paramètres -> Connexions réseau.
    b) Faire un clic droit sur Connexion réseau sans fil -> Afficher les réseaux sans fil disponibles
  
  Au minimum deux types d'accès sont supportés dans les salles de conférence :
  1. Pour les conférences de courte durée (de l'ordre d'une journée) : utilisez le SSID qui comporte le mot invite (Exemple DR invite pour la salle de conférence de la DR).
     A l'aide d'une clé (d'une quinzaine de caractères) que le responsable de la conférence vous communique, vous avez alors accès au réseau Internet (et non pas au réseau interne du laboratoire).

     Note: Cette méthode ne permet aucune identification de la personne. Mais il serait administrativement lourd d'affecter à chaque participant un "login/mot de passe".

     Voici un exemple de connexion.

  2. Pour les conférences de plusieurs jours : utilisez le SSID qui comporte le mot chillispot (Exemple NANO D420 chillispot pour la salle de conférence du 3ème de NANO)
     Cet SSID vous fait passer par un portail captif, lequel vous demandera de vous authentifier par le couple "login/mot de passe" qui vous a été fourni (1).
     Note: Il vous faut activer le JavaScript sur votre navigateur.
     Voici un exemple de connexion.

IV) Les VPNs :

a) Connexion :

• Un enseignant de l'IMAG (portable vert) veut se connecter depuis le Polygone à son labo :
  
  • en labo2, il récupère dynamiquement une adresse en 10.8.2.0/24 (en labo1 il aurait récupéré une adresse en 10.8.1.0/24)
  • il lance une connexion vers le serveur VPN de l'IMAG (en 10.6.1.12)
  • Rt-labo2 sait que tout ce qui n'est pas 10.8.0.0 est à router sur le Campus
  • Rt-CAMPUS sait que 10.6.0.0 est à router vers Rt-IMAG
  • une fois à l'IMAG, la connexion est orientée vers 10.6.1.12.
• Un chercheur (portable mauve) veut se connecter depuis chez lui à son labo (labo2)
  
  • il lui suffit de lancer la connexion sur l'adresse routable du serveur VPN de labo2
• Depuis l'IMAG, un chercheur (portable cyan) veut se connecter à son labo (labo1)
  
  • à l'IMAG il récupère dynamiquement une adresse en 10.6.10.0/24 (de l'INP il aurait récupéré une adresse en 10.4.10.0/24)
  • il lance une connexion vers le serveur VPN de labo1 qui est en 10.8.1.12
  • Rt-IMAG sait que tout ce qui n'est pas 10.6.0.0 est à router sur Rt-CAMPUS
  • Rt-CAMPUS sait que 10.8.0.0 est à router vers le CNRS
  • Rt-CNRS oriente la connexion vers Rt-labo1, qui l'oriente ensuite sur le serveur VPN du labo.

Le serveur VPN du labo exige alors une authentification.

b) Authentification :

Dans le cas d'une authentification par certificat :

• si le serveur VPN de labo1 ne veut pas accepter dans le réseau interne tous les utilisateurs du CNRS, il ira consulter le serveur LDAP afin de n'accepter que ceux de labo1

Dans le cas d'une authentification par "login/mot de passe" :

• les serveurs Radius et LDAP seront consultés.

V) Les Aspects sécurité :

Avec une clé WPA seule :

Via le portail captif :

En 802.1x :

Via le VPN :

VI) Contributions :