Qu'est-ce que l'authentification RADIUS ? Fonctionnement et utilité
Published
L'authentification RADIUS utilise un serveur centralisé pour déterminer si un utilisateur ou un équipement peut rejoindre un réseau et ce qu'il peut faire une fois connecté. Ainsi, un point d'accès interroge ce serveur au lieu de vérifier sa propre liste de mots de passe. Mais en cas de réussite de la connexion, qui décide si cet équipement peut accéder aux systèmes du personnel, utiliser uniquement l'accès Internet invité ou rester connecté indéfiniment ?
C'est la partie qu'une simple explication de vérification de mot de passe n'aborde pas. RADIUS est également un canal de politique réseau : l'équipement réseau reçoit des instructions sur la façon de traiter la connexion, et pas seulement sur l'autorisation d'accès.
Table des matières
- Ce que signifie RADIUS et pourquoi il a été créé
- Comment fonctionne une connexion RADIUS, étape par étape
- EAP-TLS et certificats pour une identité d'appareil forte
- Attributs RADIUS qui déterminent l'accès au réseau
- Cas d'utilisation courants de RADIUS et ce que chacun détermine
- Limites et idées reçues à éviter
- Déterminer si RADIUS convient à votre réseau
Ce que signifie RADIUS et pourquoi il a été créé
RADIUS signifie Remote Authentication Dial-In User Service. D'un point de vue technique, il s'agit d'un protocole - un ensemble de règles partagées pour l'échange de messages - plutôt que du serveur lui-même. Un serveur RADIUS applique ces règles et prend les décisions d'accès.
Prenons le cas d'une entreprise disposant de points d'accès WiFi, de commutateurs de bureau et d'une passerelle d'accès à distance. Si chaque équipement gérait ses propres identifiants, les administrateurs devraient mettre à jour des listes distinctes à chaque arrivée ou départ d'un collaborateur. Centraliser ces décisions offre aux équipements un point d'interrogation unique.
Ce problème est antérieur aux réseaux WiFi d'entreprise WiFi. Selon l'historique de RADIUS, Livingston Enterprises a développé ce protocole en 1991, en réponse à une demande de Merit Network liée au contrôle d'accès à NSFNET, un des premiers réseaux dorsaux d'Internet. Les serveurs d'accès à distance pouvaient consulter un serveur d'authentification partagé au lieu de gérer des identifiants indépendants.
La liste d'invités partagée
Pensez à un établissement qui dispose de plusieurs entrées. Chaque porte a un videur, mais chaque videur consulte la même liste d'invités. La liste peut également distinguer l'accès ordinaire de l'accès aux coulisses, tandis que l'établissement enregistre qui est entré et qui est sorti.
RADIUS sépare ces responsabilités en AAA :
- L'authentification établit l'identité de l'utilisateur ou de l'équipement.
- L'autorisation détermine les services et les ressources réseau qu'il peut utiliser.
- La comptabilité (Accounting) enregistre l'activité de la session, y compris les événements de connexion et de déconnexion.
L'illustration montre la différence entre un appareil demandant l'accès et le serveur décidant de l'autoriser ou non.
L'équipement qui applique le résultat est appelé un serveur d'accès réseau (Network Access Server ou NAS). Malgré son nom, il peut s'agir d'un point d'accès, d'un commutateur, d'un contrôleur sans fil ou d'une passerelle de réseau privé virtuel.
Pour les équipes qui coordonnent la connectivité physique et les contrôles d'identité, la maintenance et le déploiement du haut débit de Southern Tier Resources constituent une ressource d'infrastructure pertinente. Veillez à bien distinguer les responsabilités : l'installation et la maintenance de la connectivité ne correspondent pas à la définition des personnes autorisées à l'utiliser.
RADIUS reste fondamental pour le WiFi d'entreprise WiFi, l'accès distant et la sécurité des ports filaires, car les administrateurs peuvent séparer les décisions d'identité des équipements qui les appliquent, tout en utilisant un protocole commun entre les différents fournisseurs.
Fonctionnement d'une connexion RADIUS, étape par étape
Commencez par séparer les participants :
- Terminal ou supplicant désigne l'ordinateur portable, le téléphone ou le logiciel d'authentification qui demande l'accès.
- Authentificateur désigne le NAS qui contrôle la connexion.
- Serveur d'authentification désigne le serveur RADIUS qui évalue l'identité et la politique d'accès.
Il y a un piège de terminologie ici. Dans la documentation du protocole, le RADIUS client est généralement le NAS, et non l'ordinateur portable de l'employé. L'ordinateur portable est le point d'accès terminal qui tente de se connecter.
Le schéma donne une vue simplifiée de ces rôles.
Suivre la requête et la réponse
Pour les déploiements UDP traditionnels, la référence Wireshark RADIUS identifie UDP 1812 pour l'authentification et l'autorisation et UDP 1813 pour la comptabilité. UDP, le protocole de datagramme utilisateur, achemine les messages réseau individuels sans établir de connexion de transport persistante.
Le terminal demande l'accès. Un ordinateur portable se connecte au WiFi d'entreprise WiFi, par exemple, et l'authentificateur lance l'échange d'identité. L'accès réseau ordinaire reste contrôlé pendant le déroulement de l'authentification.
Le NAS envoie une demande Access-Request. Il transmet les informations d'authentification et le contexte de connexion au point de terminaison d'authentification RADIUS. La demande identifie à la fois la personne ou le dispositif qui cherche à accéder au réseau et l'équipement réseau qui gère la connexion.
Le serveur vérifie les preuves. Selon la méthode d'authentification, il peut consulter un annuaire, valider la confiance des certificats ou utiliser un service de jetons. Un annuaire est une base de données d'identités, et pas nécessairement le serveur RADIUS lui-même.
Un défi poursuit la conversation. Un message Access-Challenge demande un autre échange d'authentification lorsque la méthode le requiert. Cela ne signifie pas automatiquement qu'une personne doit saisir un code supplémentaire.
Le serveur renvoie une décision. Le message Access-Accept autorise l'accès et peut inclure des champs de politique. Le message Access-Reject me la tentative en échec.
L'authentificateur applique la réponse. Il ouvre la connexion contrôlée et applique les instructions prises en charge, telles que l'attribution d'un segment réseau. Dans ce flux, le NAS applique la décision du serveur plutôt que d'approuver l'identité de manière indépendante.
La comptabilisation enregistre la session. Des messages distincts signalent le début de la session, les mises à jour intermédiaires et les événements d'arrêt. Ces enregistrements aident les administrateurs à distinguer une connexion réussie d'une connexion restée active.
Règle de dépannage : Identifiez le dernier échange réussi avant de modifier les identifiants. Une requête qui n'atteint jamais le serveur constitue un problème différent d'une identité rejetée.
Utilisez le filtre d'affichage radius de Wireshark ou le journal d'authentification du NAS pour suivre la séquence. Associez la demande, la réponse et le contexte de la session ; vérifiez si le NAS a appliqué la politique renvoyée plutôt que de s'arrêter à un message d'acceptation.
Pour une présentation visuelle de l'échange, visionnez la vidéo ci-jointe.
EAP-TLS et certificats pour une identité d'appareil forte
L'Extensible Authentication Protocol, ou EAP, est un framework permettant d'acheminer un dialogue d'authentification. Sur le réseau d'entreprise WiFi et le réseau filaire 802.1X, la norme de contrôle d'accès basée sur les ports, l'authentificateur relaye cet échange au serveur au sein des attributs RADIUS EAP-Message.
Le point d'accès n'a pas besoin de mettre en œuvre lui-même chaque méthode d'authentification. Son rôle est de relayer l'échange et d'appliquer le résultat.
EAP-TLS utilise le protocole Transport Layer Security avec des certificats pour l'authentification mutuelle. L'équipement prouve la possession de la clé privée de son certificat, tandis qu'il valide également le serveur. Les spécifications EAP de l'éditeur du RFC décrivent l'authentification basée sur des certificats et la manière dont l'identité authentifiée peut éclairer l'autorisation et la comptabilité.
Le schéma montre le point de terminaison, le point d'accès et le serveur d'authentification participant à cet échange.
Les certificats doivent avoir un propriétaire
Un certificat lie une identité à une clé cryptographique publique. La clé privée correspondant doit rester protégée ; la seule copie d'un fichier de certificat ne devrait pas suffire à usurper l'identité de l'équipement.
Contrairement au WiFi à mot de passe partagé WiFi, EAP-TLS ne requiert pas de mot de passe personnel commun. Cependant, il nécessite une infrastructure à clés publiques (ou PKI) gérée qui délivre les certificats et maintient la confiance.
Intégrer le cycle de vie dans le déploiement :
- Émettez des certificats automatiquement. Utilisez la gestion des appareils mobiles, ou MDM, avec le protocole SCEP (Simple Certificate Enrollment Protocol) ou un connecteur d'enrôlement pris en charge.
- Installez le certificat et le profil réseau ensemble afin que les appareils sachent à quelle identité de serveur faire confiance.
- Renouvelez avant l'expiration, y compris pour les appareils qui passent de longues périodes hors du bureau.
- Révoquez les identifiants après une perte, une mise à la retraite ou une modification de la politique d'accès, et assurez-vous que le service d'authentification vérifie la révocation.
- Maintenez le magasin de confiance, à savoir la liste des autorités de certification de confiance et des paramètres de validation du serveur de l'appareil.
Pour une alternative basée sur un mot de passe, comparez EAP-TLS et PEAP avant de choisir une méthode d'intégration.
Des certificats expirés peuvent entraîner des interruptions de service. Un mappage incorrect du champ d'identité Subject Alternative Name du certificat peut associer un appareil à une mauvaise politique d'accès. Un serveur inaccessible ou une règle de secours trop permissive peut provoquer soit des dysfonctionnements, soit des accès non autorisés.
Une identité forte pour les équipements dépend de la gestion du cycle de vie, et ne se résume pas à sélectionner EAP-TLS dans un menu de configuration.
Attributs RADIUS qui déterminent l'accès au réseau
Les attributs de placement VLAN démontrent pourquoi RADIUS ne se limite pas à un contrôle d'accès. Un réseau local virtuel, ou VLAN, est un segment réseau logique : le personnel et les invités peuvent utiliser la même infrastructure d'accès tout en bénéficiant d'accès réseau différents.
Les attributs sont des champs étiquetés au sein des messages RADIUS. Ils transportent les données d'authentification, le contexte de connexion et les résultats d'autorisation ; la spécification RADIUS définit le mécanisme d'attributs extensibles qui rend ces échanges de politiques possibles.
Attributs RADIUS clés et ce qu'ils contrôlent
Il s'agit de valeurs de configuration illustratives et non de paramètres par défaut obligatoires. L'exemple de session invité exprime la règle de délai d'expiration plutôt que de prescrire une durée universelle.
| Attribut | Élément véhiculé | Exemple de valeur | Effet sur l'accès |
|---|---|---|---|
| User-Name | Identité présentée | jsmith@example.com | Identifie la politique qui s'applique |
| EAP-Message | Paquets d'échange d'authentification | Données d'initialisation de connexion EAP-TLS | Véhicule la conversation d'authentification |
| Message-Authenticator | Vérification de l'intégrité des paquets | Valeur HMAC | Aide à rejeter les réponses falsifiées lorsqu'elles sont requises et validées |
| Tunnel-Type, Tunnel-Medium-Type, Tunnel-Private-Group-ID | Placement du VLAN | VLAN, Ethernet, identifiant du VLAN du personnel | Place l'équipement sur le VLAN du personnel configuré |
| Session-Timeout | Durée maximale de la session en secondes | Durée de la session invité convertie en secondes | Met fin à la session invité d'illustration de huit heures |
| Filter-Id | Nom d'un filtre ou d'une politique local(e) à l'équipement | guest-limited | Sélectionne les restrictions configurées sur l'équipement effectuant l'application |
| Calling-Station-Id | Adresse MAC du client | AA:BB:CC:DD:EE:FF | Associe la session à une adresse d'équipement signalée |
| NAS-IP-Address ou NAS-Identifier | Équipement réseau demandeur | ap-floor2 en tant que NAS-Identifier | Fournit un contexte pour les règles spécifiques au site |
| Acct-Session-Id | Identifiant de la session de comptabilité | 1A2B3C4D | Lie les enregistrements de début, d'intermédiaire et de fin |
HMAC désigne le code d'authentification de message basé sur une fonction de hachage (keyed-hash message authentication code), une vérification d'intégrité par clé. Il ne remplace pas le chiffrement du transport.
Plusieurs distinctions sont essentielles lors de la lecture de ce tableau. User-Name identifie l'identité revendiquée, mais la méthode d'authentification en fournit la preuve. Calling-Station-Id fournit le contexte de l'équipement, mais une adresse matérielle transmise ne constitue pas à elle seule une preuve d'identité suffisante.
Pour l'attribution du VLAN, envoyez la combinaison complète d'attributs de tunnel attendue par l'équipement. Le VLAN cible doit déjà exister et être accessible via les chemins réseau appropriés ; la réception de son identifiant ne crée pas le segment.
Filter-Id nomme une politique, au lieu de porter nécessairement les restrictions elles-mêmes. Une limitation de bande passante ne s'applique que si l'équipement d'exécution prend en charge et mappe correctement cette politique.
Un Access-Accept ne prouve pas que les restrictions prévues ont été appliquées. Vérifiez le comportement résultant de VLAN, du filtre et de la session sur le NAS.
L'Accounting ajoute la piste d'audit. L'association d'un identifiant de session entre les événements de connexion aide les analystes à distinguer des visites distinctes provenant d'une même identité.
Testez les définitions du NAS, les secrets partagés, les tentatives et la transmission de la comptabilité en plus des attributs. Une vérification d'identité réussie avec des champs d'autorisation manquants ou des journaux incomplets offre aux administrateurs un contrôle bien inférieur à ce que suggère le résultat de la connexion.
Cas d'usage courants de RADIUS et leurs décisions associées
Un service RADIUS partagé peut prendre en charge différents déploiements, à condition que les administrateurs définissent la méthode d'authentification et la politique appropriées pour chacun d'eux.
Déploiements courants de RADIUS et ce qu'ils déterminent
| Cas d'usage | Dispositif d'application | Ce que décide RADIUS | Méthode typique |
|---|---|---|---|
| WiFi du personnel WiFi | Point d'accès ou contrôleur | Admet l'appareil et sélectionne le VLAN du personnel VLAN | EAP-TLS ou PEAP-MSCHAPv2 |
| WiFi invité WiFi | Point d'accès avec portail captif | Accorde l'accès après connexion et applique des limites de session | Connexion Web ou profil Passpoint/OpenRoaming |
| Accès VPN distant | Concentrateur VPN | Vérifie l'utilisateur et attribue une politique de groupe ou une plage d'adresses | Mot de passe avec code à usage unique ou EAP |
| Port de commutateur filaire | Commutateur réseau | Ouvre le port pour les appareils approuvés et attribue un VLAN VLAN | EAP-TLS, ou contournement d'authentification MAC pour les appareils sans supplicant |
| Administration des équipements réseau | Connexion au routeur ou au commutateur | Confirme les privilèges d'administrateur et prend en charge la comptabilisation ; les contrôles au niveau des commandes nécessitent une prise en charge explicite de la plateforme | RADIUS ou TACACS+ avec un compte d'annuaire |
PEAP-MSCHAPv2 est une option basée sur un mot de passe : Protected EAP crée un tunnel TLS autour de la méthode d'authentification par mot de passe interne. Elle nécessite une validation rigoureuse du certificat du serveur et constitue souvent une solution de transition lorsque les certificats clients ne sont pas déployés.
Les méthodes destinées aux invités répondent à une problématique différente. Un portail captif présente une page de connexion web, tandis que Passpoint et OpenRoaming utilisent des profils pris en charge et des accords d'identité pour la découverte du réseau et l'authentification. Aucune de ces méthodes ne doit impliquer un accès de niveau personnel.
La fonctionnalité MAC authentication bypass, ou MAB, vérifie l'adresse MAC transmise par un appareil lorsque celui-ci ne peut pas exécuter de supplicant. Dans la mesure où les adresses peuvent être usurpées, il convient de placer ces appareils dans des segments restreints plutôt que de considérer cette vérification comme l'équivalent d'une authentification par certificat.
Accès réseau par rapport à l'accès administrateur
TACACS+ (Terminal Access Controller Access-Control System Plus) est un autre protocole AAA couramment utilisé pour l'administration des équipements. Il sépare l'authentification, l'autorisation et la comptabilité, ce qui convient aux flux de travail détaillés d'autorisations administratives.
RADIUS renvoie généralement l'authentification et l'autorisation ensemble. Le RADIUS traditionnel n'encrypte pas l'intégralité du paquet, tandis que TACACS+ protège le corps de son paquet ; aucune de ces distinctions ne dispense d'utiliser un transport sécurisé et une configuration solide.
Commencez par le cas d'usage où l'accès individuel importe le plus. Pour les réseaux de collaborateurs distants, une migration multisite des mots de passe partagés vers l'authentification d'entreprise doit inclure la préparation des points d'accès, la correspondance des cartes de règles et un plan de retour en arrière testé.
Limites et idées reçues à éviter
Un attaquant transformant un Access-Reject en Access-Accept met en évidence la vulnérabilité consistant à considérer tout service d'authentification centralisé comme automatiquement sécurisé. Les RADIUS conseils de sécurité de JumpCloud décrivent la manière dont un attaquant situé sur le parcours de transmission peut exploiter les déploiements existants applicables lorsque la validation Message-Authenticator n'est pas appliquée, ce qui constitue le risque associé à Blast-RADIUS.
Le RADIUS traditionnel utilise couramment UDP et des mécanismes plus anciens basés sur MD5. La robustesse des identifiants, l'intégrité des réponses et la confidentialité du transport sont des enjeux distincts : en améliorer un ne corrige pas automatiquement les autres.
Protéger l'échange de politiques
- Exigez la validation Message-Authenticator pour le trafic pertinent conformément aux directives actuelles du fournisseur. Confirmez que les valeurs manquantes ou invalides entraînent un rejet.
- Utilisez RADIUS sur TLS, également appelé RadSec, lorsqu'il est pris en charge, pour protéger l'échange entre le serveur et le NAS.
- Effectuez une rotation des secrets partagés et protégez leur stockage, ou utilisez une confiance de transport basée sur des certificats lorsque l'équipement le prend en charge.
- Appliquez des correctifs aux serveurs, commutateurs, contrôleurs et points d'accès. Testez l'interopérabilité après avoir modifié les exigences de validation.
Point de contrôle de sécurité : Vérifiez ce que le NAS rejette, et pas seulement ce que le serveur envoie.
RADIUS ne fournit pas non plus d'authentification multifacteur (ou MFA) en soi. Un fournisseur d'identités, un flux de travail à code à usage unique ou un autre mécanisme intégré fournit des facteurs supplémentaires ; le projet de révision de l'IETF concernant RADIUS explique pourquoi les hypothèses opérationnelles et de protocole restent importantes autour de ces intégrations.
Un certificat d'équipement ne prouve pas à lui seul qu'une personne a effectué l'authentification multifacteur (MFA). L'authentification de l'équipement établit quel appareil détient les identifiants de connexion ; la MFA utilisateur apporte des preuves supplémentaires sur l'identité de la personne.
Enfin, la désactivation d'une identité ne met pas universellement fin à une connexion déjà active. La réauthentification, la fin de session ou la modification d'autorisation prise en charge (Change of Authorization, connue sous le nom de CoA) doivent imposer ce résultat.
Traitez le contrôle d'accès WiFi comme un système opérationnel : la révocation, les journaux, la disponibilité du serveur et le comportement de secours doivent faire l'objet de tests cohérents sur l'ensemble des sites.
Déterminer si RADIUS convient à votre réseau
RADIUS convient parfaitement lorsque l'accès doit être régi par des identités individuelles et des politiques de groupe, plutôt que par la possession d'un mot de passe partagé. Si un petit réseau isolé peut se passer de cette infrastructure supplémentaire, la gestion des appareils, le roulement du personnel et la définition de autorisations distinctes pour les invités ou les prestataires sont autant de raisons majeures d'envisager son déploiement.
Choisissez en fonction des contrôles dont vous avez besoin, et non du nombre de points d'accès. Un site modeste doté de systèmes sensibles pour le personnel peut nécessiter des décisions d'accès plus strictes qu'un réseau réservé aux invités bien plus étendu.
Élaborer un plan de déploiement réalisable
- Mappez les groupes d'accès. Consignez ce à quoi le personnel, les invités, les prestataires et les équipements autonomes doivent avoir accès.
- Vérifiez la compatibilité des équipements. Confirmez la prise en charge des attributs RADIUS compatibles, de l'authentification d'entreprise, du transport protégé et du comportement de comptabilité.
- Choisissez les parcours d'intégration. Utilisez un accès basé sur des certificats pour les points de terminaison gérés et un portail approprié ou un profil d'itinérance pour les invités.
- Attribuez la responsabilité des certificats. Désignez l'équipe responsable de l'inscription, du renouvellement, des paramètres de confiance et de la gestion des équipements perdus.
- Définissez le comportement en cas de défaillance. Décidez si un service d'authentification indisponible doit bloquer l'accès ou autoriser une solution de secours strictement restreinte.
- Testez avant de déployer à plus grande échelle. Incluez les identités rejetées, les serveurs indisponibles, les modifications de politiques et les enregistrements de comptabilité incomplets.
Un service géré constitue une alternative au maintien en interne de vos propres serveurs d'authentification. Notre solution Cloud RADIUS dans Purple Access oriente les appareils vers le réseau ouvert, sécurisé ou xPSK en fonction de l'identité, chacun sur son propre VLAN, et rejette tout utilisateur dont le compte est désactivé lorsque celui-ci quitte l'entreprise. Notre cloud RADIUS garantit par contrat un SLA de disponibilité de 99,9 %.
Pour un déploiement dans le secteur de l'hôtellerie, le personnel d'étage, de réception et d'exploitation peut s'authentifier à l'aide de certificats EAP-TLS fournis par MDM via SCEP, se voir attribuer un VLAN par groupe d'annuaire, et perdre l'accès lorsque leur compte est désactivé.
Commencez par un site représentatif. Confirmez ses groupes, ses types d'équipements, ses capacités d'application et ses tests de défaillance avant d'étendre la configuration à l'ensemble du parc.
Purple Access associe un Cloud RADIUS géré, une authentification du personnel basée sur des certificats et des politiques d'accès VLAN pilotées par l'identité sur vos points d'accès existants. Rendez-vous sur Purple Access pour échanger au sujet de vos groupes d'utilisateurs, de l'intégration de vos appareils et d'un plan de déploiement concret pour votre premier site.
