Sur cette page
Configuration des paramètres de l’interface 802.1X (procédure CLI)
Comprendre les modifications apportées à une session d’utilisateur autorisé par RADIUS
Filtrage des demandeurs 802.1X à l’aide des attributs du serveur RADIUS
Exemple : Connexion d’un serveur RADIUS 802.1X à un commutateur EX Series
Présentation des filtres dynamiques basés sur les attributs RADIUS
Présentation de l’affectation dynamique de VLAN à l’aide des attributs RADIUS
Configuration des groupes VLAN sur les commutateurs EX Series
Comprendre les VLAN invités pour 802.1X sur les commutateurs
Dépannage de l’authentification des terminaux sur les commutateurs EX Series
Avantages de l’utilisation des attributs standard RADIUS et des VSA
Attributs Radius et liste VSA pris en charge par la norme 802.1X
Authentification 802.1X
Norme IEEE 802.1X pour le contrôle d’accès réseau basé sur les ports et protège les réseaux locaux Ethernet contre les accès non autorisés des utilisateurs. Il bloque tout le trafic à destination et en provenance d’un demandeur (client) à l’interface jusqu’à ce que les informations d’identification du demandeur soient présentées et mises en correspondance sur le serveur d’authentification (un serveur RADIUS). Lorsque le demandeur est authentifié, le serveurcesse de bloquer l’accès et ouvre l’interface au demandeur. Lisez cette rubrique pour plus d’informations.
Présentation de la norme 802.1X pour les commutateurs
- Fonctionnement de l’authentification 802.1X
- Présentation des fonctionnalités 802.1X
- Authentification 802.1X sur les ports trunk
- Authentification 802.1X sur les interfaces de couche 3
- Prise en charge 802.1X sur le logiciel Junos OS Evolved
Fonctionnement de l’authentification 802.1X
L’authentification 802.1X fonctionne à l’aide d’une entité d’accès au port d’authentification (le commutateur) pour bloquer le trafic entrant d’un demandeur (périphérique final) au niveau du port jusqu’à ce que les informations d’identification du demandeur soient présentées et correspondent sur le serveur d’authentification (un serveur RADIUS). Une fois authentifié, le commutateur cesse de bloquer le trafic et ouvre le port au demandeur.
Le terminal est authentifié en single supplicant mode, single-secure supplicant mode ou multiple supplicant mode :
-
demandeur unique : authentifie uniquement le premier périphérique final. Tous les autres terminaux qui se connectent ultérieurement au port sont autorisés à accéder à l’intégralité du port sans autre authentification. Ils se greffent en fait sur l’authentification du premier terminal.
-
single-secure supplicant : n’autorise qu’un seul terminal à se connecter au port. Aucun autre terminal n’est autorisé à se connecter tant que le premier appareil n’est pas déconnecté.
-
multiple supplicant : permet à plusieurs terminaux de se connecter au port. Chaque terminal est authentifié individuellement.
L’accès réseau peut être défini plus précisément à l’aide de VLAN et de filtres de pare-feu, qui agissent tous deux comme des filtres pour séparer et faire correspondre les groupes d’équipements finaux aux zones du LAN dont ils ont besoin. Par exemple, vous pouvez configurer les VLAN pour qu’ils gèrent différentes catégories d’échecs d’authentification en fonction des éléments suivants :
-
Indique si le terminal est compatible ou non avec la norme 802.1X.
-
Indique si l’authentification MAC RADIUS est configurée ou non sur les interfaces de commutateur auxquelles les hôtes sont connectés.
-
Indique si le serveur d’authentification RADIUS devient indisponible ou envoie un message d’accès/rejet RADIUS. Reportez-vous à la section Configuration de la solution de secours en cas d’échec du serveur RADIUS (procédure CLI).
Présentation des fonctionnalités 802.1X
Les fonctionnalités 802.1X suivantes sont prises en charge sur Juniper Networks Commutateurs Ethernet :
-
VLAN invité : fournit un accès limité à un réseau local, généralement uniquement à Internet, pour les périphériques finaux qui ne répondent pas et qui ne sont pas compatibles 802.1X lorsque l’authentification MAC RADIUS n’est pas configurée sur les interfaces de commutateur auxquelles les hôtes sont connectés. En outre, un VLAN invité peut être utilisé pour fournir un accès limité à un LAN pour les utilisateurs invités. En règle générale, le VLAN invité permet d’accéder uniquement à Internet et aux terminaux des autres invités.
-
VLAN à rejet par le serveur : fournit un accès limité à un réseau local, généralement uniquement à Internet, pour les terminaux réactifs qui sont compatibles 802.1X, mais qui ont envoyé des informations d’identification incorrectes. Si le terminal authentifié à l’aide du VLAN de rejet du serveur est un téléphone IP, le trafic vocal n’est pas autorisé.
-
VLAN en cas d’échec du serveur : fournit un accès limité à un réseau local, généralement uniquement à Internet, pour les périphériques finaux 802.1X pendant un délai d’expiration du serveur RADIUS.
-
VLAN dynamique : permet à un équipement final, après authentification, d’être membre dynamique d’un VLAN.
-
VLAN privé : permet de configurer l’authentification 802.1X sur les interfaces membres de VLAN privés (PVLAN).
-
Modifications dynamiques d’une session utilisateur : permet à l’administrateur du commutateur de mettre fin à une session déjà authentifiée. Cette fonctionnalité est basée sur la prise en charge du message de déconnexion RADIUS défini dans la RFC 3576.
-
VLAN VoIP : prend en charge les téléphones IP. La mise en œuvre d’un VLAN vocal sur un téléphone IP est spécifique au fournisseur. Si le téléphone est compatible 802.1X, il est authentifié comme n’importe quel autre demandeur. Si le téléphone n’est pas compatible 802.1X, mais qu’un autre appareil compatible 802.1X est connecté à son port de données, cet appareil est authentifié, puis le trafic VoIP peut circuler vers et depuis le téléphone (à condition que l’interface soit configurée en mode demandeur unique et non en mode demandeur sécurisé unique).
REMARQUE :La configuration d’un VLAN VoIP sur des interfaces VLAN privées (PVLAN) n’est pas prise en charge.
-
Comptabilité RADIUS : envoie les informations comptables au serveur de comptabilité RADIUS. Les informations comptables sont envoyées au serveur chaque fois qu’un abonné se connecte ou se déconnecte et chaque fois qu’un abonné active ou désactive un abonnement.
-
Attributs du serveur RADIUS pour 802.1X : il
Juniper-Switching-Filter
s’agit d’un attribut spécifique au fournisseur (VSA) qui peut être configuré sur le serveur RADIUS pour définir plus précisément l’accès d’un demandeur pendant le processus d’authentification 802.1X. La configuration centralisée des attributs sur le serveur d’authentification évite d’avoir à configurer ces mêmes attributs sous la forme de filtres de pare-feu sur chaque commutateur du réseau local auquel le demandeur peut se connecter au réseau local. LeJuniper-Switching-Filter
est équivalent à la règle NAS-Filter-Rule référencée dans l’attribut 92 de RFC4849. -
Micro et macrosegmentation avec GBP à l’aide de Mist Access Assurance : vous pouvez appliquer la microsegmentation et la macrosegmentation dans une architecture VXLAN (Virtual Extensible LAN) à l’aide d’une stratégie basée sur des groupes (GBP). GBP s’appuie sur la technologie VXLAN sous-jacente pour fournir un contrôle d’accès indépendant de l’emplacement des terminaux. La GBP vous permet de mettre en uvre des politiques de sécurité cohérentes sur l’ensemble des domaines du réseau de l’entreprise. Vous évitez ainsi de configurer un grand nombre de filtres de pare-feu sur tous vos commutateurs et simplifiez la configuration de votre réseau. Le contrôle d’accès réseau (NAC) du cloud Juniper Mist attribue dynamiquement des balises GBP lors d’une transaction RADIUS. Grâce à l’authentification RADIUS 802.1X, les opérateurs réseau peuvent authentifier et autoriser automatiquement un utilisateur ou un équipement et le laisser entrer dans le réseau. Juniper Mist Access Assurance utilise l’identité de l’utilisateur et de l’équipement pour déterminer le rôle et le segment réseau que le réseau attribue à chaque utilisateur. Le réseau utilise VLAN ou GBP pour regrouper les utilisateurs en segments de réseau. Juniper Mist Access Assurance applique ensuite les politiques réseau associées à chaque segment
Cette fonctionnalité est actuellement prise en charge sur les châssis virtuels EX4100, EX4400, EX4650, QFX5120-32C, QFX5120-48Y et sur les châssis virtuels QFX5120-48Y.
Pour plus d’informations, voir, Example: Micro and Macro Segmentation using Group Based Policy in a VXLAN
Les fonctionnalités suivantes sont prises en charge pour authentifier les périphériques qui ne sont pas compatibles 802.1X :
-
Contournement MAC statique : fournit un mécanisme de contournement pour authentifier les périphériques qui ne sont pas compatibles 802.1X (tels que les imprimantes). Le contournement MAC statique connecte ces périphériques aux ports compatibles 802.1X, en contournant l’authentification 802.1X.
-
Authentification MAC RADIUS : permet d’autoriser les hôtes qui ne sont pas compatibles 802.1X à accéder au réseau local. MAC-RADIUS simule la fonctionnalité de demandeur de l’appareil client, en utilisant l’adresse MAC du client comme nom d’utilisateur et mot de passe.
Authentification 802.1X sur les ports trunk
À partir de Junos OS version 18.3R1, vous pouvez configurer l’authentification 802.1X sur les interfaces trunk, ce qui permet au périphérique d’accès réseau (NAS) d’authentifier un point d’accès (AP) ou un autre périphérique de couche 2 connecté. Un point d’accès ou un commutateur connecté au NAS prend en charge plusieurs VLAN et doit donc se connecter à un port trunk. L’activation de l’authentification 802.1X sur l’interface trunk protège le NAS d’une faille de sécurité dans laquelle un attaquant pourrait déconnecter l’AP et connecter un ordinateur portable pour obtenir un accès gratuit au réseau pour tous les VLAN configurés.
Veuillez noter les mises en garde suivantes lors de la configuration de l’authentification 802.1X sur les interfaces trunk.
-
Seuls les modes de demande unique et mono-sécurisé sont pris en charge sur les interfaces trunk.
-
Vous devez configurer l’authentification 802.1X localement sur l’interface trunk. Si vous configurez l’authentification 802.1X globalement à l’aide de la commande, la
set protocol dot1x interface all
configuration n’est pas appliquée à l’interface trunk. -
Les VLAN dynamiques ne sont pas pris en charge sur les interfaces trunk.
-
Le VLAN invité et le VLAN de rejet de serveur ne sont pas pris en charge sur les interfaces trunk.
-
La solution de secours contre échec serveur pour les clients VoIP n’est pas prise en charge sur les interfaces trunk (
server-fail-voip
). -
L’authentification sur le port trunk n’est pas prise en charge à l’aide du portail captif.
-
L’authentification sur le port trunk n’est pas prise en charge sur les interfaces agrégées.
-
La configuration de l’authentification 802.1X sur les interfaces membres de VLAN privés (PVLAN) n’est pas prise en charge sur les ports trunk.
Authentification 802.1X sur les interfaces de couche 3
À partir de Junos OS version 20.2R1, vous pouvez configurer l’authentification 802.1X sur les interfaces de couche 3. Veuillez noter les mises en garde suivantes lors de la configuration de l’authentification 802.1X sur les interfaces de couche 3 :
-
Seuls les clients compatibles EAP sont pris en charge.
-
Seul le mode demandeur unique est pris en charge.
-
Vous devez configurer l’authentification 802.1X localement sur les interfaces de couche 3. Si vous configurez l’authentification 802.1X globalement à l’aide de la commande, la configuration n’est pas appliquée aux interfaces de
set protocol dot1x interface all
couche 3. -
La prise en charge des interfaces de couche 3 n’inclut pas l’IRB ou les sous-interfaces.
-
Le VLAN invité, le VLAN de rejet de serveur et le VLAN d’échec de serveur ne sont pas pris en charge.
-
La solution de secours en cas d’échec serveur pour les clients VoIP n’est pas prise en charge (
server-fail-voip
). -
Seuls les attributs suivants sont acceptés par le serveur d’authentification dans le cadre des messages d’accès-acceptation RADIUS ou de certificat d’authenticité pour les clients authentifiés sur les interfaces de couche 3 :
-
Nom d’utilisateur
-
Délai d’expiration de la session
-
ID de la station d’appel
-
Acct-Session-ID
-
ID de port NAS
-
Rebond de port
-
Prise en charge 802.1X sur le logiciel Junos OS Evolved
À partir de Junos OS Evolved version 22.3R1, vous pouvez configurer l’authentification 802.1X sur les interfaces de couche 2. Les mises en garde suivantes s’appliquent pour l’authentification 802.1X sur les interfaces de couche 2.
-
Les fonctionnalités non prises en charge sont les suivantes :
-
VLAN invité, VLAN de rejet de serveur et VLAN d’échec de serveur
-
Reprise de secours contre l’échec du serveur pour les clients VoIP (server-fail-voip)
-
VLAN dynamique
-
Authentification sur les interfaces de couche 2 à l’aide du portail captif et de l’authentification Web centrale (CWA).
-
-
Les attributs non pris en charge du serveur d’authentification des messages d’accès-acceptation RADIUS ou de certificat d’authenticité pour les clients authentifiés sur les interfaces de couche 2 sont les suivants :
-
ip-mac-session-binding
-
Juniper-CWA-Redirect
-
Filtre de commutation Juniper
-
ID de filtre
-
Tunnel-Moyen-Type
-
VoIP-VLAN Juniper
-
Nom du VLAN de sortie
-
ID VLAN de sortie
-
Type de tunnel
-
ID de groupe privé de tunnel
-
-
Si l’IRB se trouve dans le domaine de pont, les ports compatibles 802.1x n’abandonnent pas le trafic acheminé pour les modes de demande unique sécurisé et multiple, même si l’utilisateur n’est pas authentifié. Les ports compatibles 802.1x sur l’interface de couche 2 acheminent le trafic uniquement pour la configuration en mode demandeur unique.
Voir également
Configuration des paramètres de l’interface 802.1X (procédure CLI)
L’authentification IEEE 802.1X assure la sécurité de la périphérie du réseau, protégeant les réseaux locaux Ethernet contre tout accès non autorisé des utilisateurs en bloquant tout le trafic à destination et en provenance d’un demandeur (client) à l’interface jusqu’à ce que les informations d’identification du demandeur soient présentées et mises en correspondance sur le authentication server serveur RADIUS. Lorsque le demandeur est authentifié, le commutateur cesse de bloquer l’accès et ouvre l’interface au demandeur.
Vous pouvez également spécifier une liste d’exclusion 802.1X pour spécifier les demandeurs qui peuvent contourner l’authentification et être automatiquement connectés au réseau local. Reportez-vous à la section Configuration du contournement MAC statique de 802.1X et de l’authentification MAC RADIUS (procédure CLI).
Vous ne pouvez pas configurer l’authentification utilisateur 802.1X sur les interfaces qui ont été activées pour le tunneling Q-in-Q.
Avant de commencer, spécifiez le ou les serveurs RADIUS à utiliser comme serveur d’authentification. Reportez-vous à la section Spécification des connexions au serveur RADIUS sur les commutateurs (procédure CLI).
Pour configurer le protocole 802.1X sur une interface :
Si les serveurs d’authentification RADIUS deviennent indisponibles ou inaccessibles, la solution de secours en cas d’échec du serveur est déclenchée. Par défaut, l’option est configurée sous server-fail
, ce qui force l’échec de l’authentification deny
du demandeur. Toutefois, il existe d’autres options que vous pouvez configurer en tant qu’actions à effectuer pour les terminaux en attente d’authentification lorsque le serveur expire.
Pour plus d’informations, reportez-vous à la section Interface (802.1X)
Ce paramètre spécifie le nombre de tentatives avant que le commutateur ne mette l’interface dans un état HELD .
Voir également
Comprendre les modifications apportées à une session d’utilisateur autorisé par RADIUS
Lors de l’utilisation d’un service d’authentification basé sur un modèle RADIUS client/serveur, les requêtes sont généralement initiées par le client et envoyées au serveur RADIUS. Il existe des cas dans lesquels une requête peut être initiée par le serveur et envoyée au client afin de modifier dynamiquement une session d’utilisateur authentifié déjà en cours. Le client qui reçoit et traite les messages est le commutateur, qui fait office de serveur d’accès réseau (NAS). Le serveur peut envoyer au commutateur un message de déconnexion lui demandant de mettre fin à une session ou un message de changement d’autorisation (CoA) lui demandant de modifier les attributs d’autorisation de session.
Le commutateur écoute les requêtes RADIUS non sollicitées sur le port UPD 3799 et accepte uniquement les demandes provenant d’une source fiable. L’autorisation d’envoi d’une demande de déconnexion ou de CoA est déterminée en fonction de l’adresse source et du secret partagé correspondant, qui doivent être configurés sur le commutateur ainsi que sur le serveur RADIUS. Pour plus d’informations sur la configuration de l’adresse source et du secret partagé sur le commutateur, consultez Exemple : Connexion d’un serveur RADIUS pour 802.1X à un commutateur EX Series.
- Messages de déconnexion
- Modification des messages d’autorisation
- Rebond de port de demande CoA
- Codes d’erreur et de cause
Messages de déconnexion
Le serveur RADIUS envoie un message de demande de déconnexion au commutateur afin de mettre fin à une session utilisateur et d’ignorer tout le contexte de session associé. Le commutateur répond à un paquet Disconnect-Request par un message Disconnect-ACK si la demande réussit, c’est-à-dire que tout le contexte de session associé est ignoré et que la session utilisateur n’est plus connectée, ou par un paquet Disconnect-NAK si la demande échoue, c’est-à-dire que l’authentificateur ne peut pas déconnecter la session et ignorer tout le contexte de session associé.
Dans les messages de demande de déconnexion, les attributs RADIUS sont utilisés pour identifier de manière unique le commutateur (NAS) et la session utilisateur. La combinaison des attributs d’identification NAS et des attributs d’identification de session incluse dans le message doit correspondre à au moins une session pour que la demande aboutisse ; sinon, le commutateur répond par un message Disconnect-NAK. Un message de demande de déconnexion ne peut contenir que des attributs d’identification de session et de NAS ; si d’autres attributs sont inclus, le commutateur répond par un message Disconnect-NAK.
Modification des messages d’autorisation
Les messages de changement d’autorisation (CoA) contiennent des informations permettant de modifier dynamiquement les attributs d’autorisation d’une session utilisateur afin de changer le niveau d’autorisation. Cela se produit dans le cadre d’un processus d’authentification en deux étapes, dans lequel le point de terminaison est d’abord authentifié à l’aide de l’authentification MAC RADIUS, puis est profilé en fonction du type d’appareil. Le message CoA permet d’appliquer une stratégie d’application adaptée à l’appareil, généralement en modifiant les filtres de données ou le VLAN.
Le commutateur répond à un message CoA par un message CoA-ACK si la modification de l’autorisation réussit, ou un message avec CoA-NAK si la modification échoue. Si une ou plusieurs modifications d’autorisation spécifiées dans un message CoA-Request ne peuvent pas être effectuées, le commutateur répond par un message CoA-NAK.
Dans les messages CoA-Request, les attributs RADIUS sont utilisés pour identifier de manière unique le commutateur (agissant comme le NAS) et la session utilisateur. Pour que la demande aboutisse, la combinaison des attributs d’identification NAS et des attributs d’identification de session incluse dans le message doit correspondre aux attributs d’identification d’au moins une session. sinon, le commutateur répond par un message CoA-NAK.
Les paquets CoA-Request incluent également les attributs d’autorisation de session qui seront modifiés si la demande est acceptée. Les attributs d’autorisation de session pris en charge sont répertoriés ci-dessous. Le message CoA peut contenir tout ou partie de ces attributs. Si un attribut n’est pas inclus dans le message CoA-Request, le NAS suppose que la valeur de cet attribut doit rester inchangée.
ID de filtre
ID de groupe privé de tunnel
Filtre de commutation Juniper
VoIP-VLAN Juniper
Délai d’expiration de la session
Rebond de port de demande CoA
Lorsqu’un message CoA est utilisé pour modifier le VLAN d’un hôte authentifié, les terminaux tels que les imprimantes ne disposent pas d’un mécanisme permettant de détecter le changement de VLAN, de sorte qu’ils ne renouvellent pas le bail de leur adresse DHCP dans le nouveau VLAN. À partir de Junos OS version 17.3, la fonctionnalité de rebond de port peut être utilisée pour forcer le périphérique final à lancer une renégociation DHCP en provoquant un battement de liaison sur le port authentifié.
La commande de rebond sur le port est envoyée depuis le serveur RADIUS à l’aide d’un attribut spécifique au fournisseur (VSA) de Juniper Networks. Le port est rejeté si la paire attribut-valeur VSA suivante est reçue dans le message CoA du serveur RADIUS :
Juniper-AV-Pair = « Port-Bounce »
Pour activer la fonctionnalité de rebond de port, vous devez mettre à jour le fichier de dictionnaire Junos (juniper.dct) sur le serveur RADIUS à l’aide du VSA Juniper-AV-Pair. Localisez le fichier de dictionnaire et ajoutez-y le texte suivant :
ATTRIBUTE Juniper-AV-Pair Juniper-VSA(52, string) r
Pour plus d’informations sur l’ajout du VSA, consultez la documentation FreeRADIUS.
Vous pouvez désactiver la fonctionnalité en configurant l’instruction ignore-port-bounce
au niveau de la hiérarchie [edit protocols dot1x authenticator interface interface-name
].
Codes d’erreur et de cause
Lorsqu’une opération de déconnexion ou de CoA échoue, un attribut Erreur-Cause (attribut RADIUS 101) peut être inclus dans le message de réponse envoyé par le NAS au serveur pour fournir des détails sur la cause du problème. Si l’erreur détectée ne correspond pas à l’une des valeurs d’attribut Erreur-Cause prises en charge, le routeur envoie le message sans attribut erreur-cause. Reportez-vous à la section Tableau 1 pour obtenir une description des codes de cause d’erreur qui peuvent être inclus dans les messages de réponse envoyés à partir du NAS.
Code |
Valeur |
Description |
---|---|---|
201 |
Suppression du contexte de session résiduel |
Envoyé en réponse à un message de demande de déconnexion si une ou plusieurs sessions utilisateur ne sont plus actives, mais que le contexte de session résiduel a été trouvé et supprimé avec succès. Ce code n’est envoyé que dans un message Disconnect-ACK. |
401 |
Attribut non pris en charge |
La requête contient un attribut qui n’est pas pris en charge (par exemple, un attribut tiers). |
402 |
Attribut manquant |
Un attribut critique (par exemple, l’attribut d’identification de session) est manquant dans une requête. |
403 |
Incompatibilité d’identification NAS |
La demande contient un ou plusieurs attributs d’identification NAS qui ne correspondent pas à l’identité du NAS qui reçoit la demande. |
404 |
Demande non valide |
Un autre aspect de la requête n’est pas valide, par exemple si un ou plusieurs attributs ne sont pas correctement formatés. |
405 |
Service non pris en charge |
L’attribut Service-Type inclus dans la demande contient une valeur non valide ou non prise en charge. |
406 |
Extension non prise en charge |
L’entité qui reçoit la demande (NAS ou proxy RADIUS) ne prend pas en charge les requêtes initiées par RADIUS. |
407 |
Valeur d’attribut non valide |
La requête contient un attribut dont la valeur n’est pas prise en charge. |
501 |
Interdiction administrative |
Le NAS est configuré pour interdire le respect des messages de demande de déconnexion ou de demande CoA pour la session spécifiée. |
503 |
Contexte de session introuvable |
Le contexte de session identifié dans la demande n’existe pas sur le NAS. |
504 |
Contexte de session non amovible |
L’abonné identifié par des attributs dans la requête appartient à un composant qui n’est pas pris en charge. Ce code n’est envoyé que dans un message Disconnect-NAK. |
506 |
Ressources non disponibles |
Une demande n’a pas pu être honorée en raison d’un manque de ressources NAS disponibles (telles que la mémoire). |
507 |
Demande initiée |
Le message CoA-Request inclut un attribut Service-Type avec la valeur Autoriser uniquement. |
508 |
Sélection de plusieurs sessions non prise en charge |
Les attributs d’identification de session inclus dans la demande correspondent à plusieurs sessions, mais le NAS ne prend pas en charge les requêtes qui s’appliquent à plusieurs sessions. |
Filtrage des demandeurs 802.1X à l’aide des attributs du serveur RADIUS
Il existe deux façons de configurer un serveur RADIUS avec des filtres de pare-feu de port (filtres de pare-feu de couche 2) :
-
Incluez un ou plusieurs termes de filtre dans l’attribut Juniper-Switching-Filter. L’attribut Juniper-Switching-Filter est un attribut spécifique au fournisseur (VSA) répertorié sous l’attribut numéro 48 dans le dictionnaire Juniper sur le serveur RADIUS. Utilisez ce VSA pour configurer des conditions de filtrage simples pour les utilisateurs authentifiés 802.1X. Rien n’a besoin d’être configuré sur le commutateur ; toute la configuration se trouve sur le serveur RADIUS.
-
Configurez un filtre de pare-feu local sur chaque commutateur et appliquez-le aux utilisateurs authentifiés via le serveur RADIUS. Utilisez cette méthode pour les filtres plus complexes. Le filtre de pare-feu doit être configuré sur chaque commutateur.
REMARQUE :Si la configuration du filtre de pare-feu est modifiée après que les utilisateurs ont été authentifiés à l’aide de l’authentification 802.1X, la session d’authentification 802.1X établie doit être interrompue et rétablie pour que les modifications apportées à la configuration du filtre de pare-feu prennent effet.
Cette rubrique comprend les tâches suivantes :
- Configuration des filtres de pare-feu sur le serveur RADIUS
- Application d’un filtre de pare-feu configuré localement à partir du serveur RADIUS
Configuration des filtres de pare-feu sur le serveur RADIUS
À partir de Junos OS Evolved version 22.4R1, vous pouvez configurer plusieurs ports source et de destination (ou plages de ports) sur une même ligne sans avoir à répéter la condition de correspondance. Cette fonctionnalité permet de raccourcir la longueur des VSA et de réduire la taille des paquets de réponse RADIUS.
Le filtre de commutation permet de provisionner une liste de valeurs pour le type d’éther, l’adresse IP, la balise source, le port source et le port de destination.
Juniper-Switching-Filter = match dst-port [ 80 25 443 ] src-port [5060 1025-2000] action allow
Juniper-Switching-Filter = match dst-port 500 source-tag [ 100, 200 ] action allow
Juniper-Switching-Filter = match src-port 9090 ip-proto [ 25 17] action allow
Juniper-Switching-Filter = match ether-type [ 3000-4000 8000 ] action allow
Vous pouvez configurer des conditions de filtrage simples à l’aide de l’attribut Juniper-Switching-Filter dans le dictionnaire Juniper sur le serveur RADIUS. Ces filtres sont envoyés à un commutateur chaque fois qu’un nouvel utilisateur est authentifié. Les filtres sont créés et appliqués sur tous les commutateurs EX Series qui authentifient les utilisateurs via ce serveur RADIUS sans que vous ayez besoin de configurer quoi que ce soit sur chaque commutateur individuel.
Cette procédure décrit l’utilisation du logiciel FreeRADIUS pour configurer le filtre de commutation Juniper VSA. Pour plus d’informations sur la configuration de votre serveur, consultez la documentation AAA fournie avec votre serveur.
Pour configurer l’attribut Juniper-Switching-Filter, saisissez un ou plusieurs termes de filtre à l’aide de l’interface de ligne de commande du serveur RADIUS. Chaque terme de filtre se compose de conditions de correspondance avec une action correspondante. Saisissez les termes de filtre entre guillemets ( » « ) en utilisant la syntaxe suivante :
Juniper-Switching-Filter = “match <destination-mac mac-address> <source-vlan vlan-name> <source-dot1q-tag tag> <destination-ip ip-address> <ip-protocol protocol-id> <source-port port> <destination-port port> action (allow | deny) <forwarding-class class-of-service> <loss-priority (low | medium | high)>”
Plusieurs conditions de correspondance peuvent être incluses dans un terme de filtre. Lorsque plusieurs conditions sont spécifiées dans un terme de filtre, elles doivent toutes être remplies pour que le paquet corresponde au terme de filtre. Par exemple, le terme de filtre suivant exige qu’un paquet corresponde à la fois à l’adresse IP de destination et à l’adresse MAC de destination pour répondre aux critères du terme :
Juniper-Switching-Filter = “match destination-ip 10.10.10.8 destination-mac 00:00:00:01:02:03 action allow”
Les termes de filtre multiples doivent être séparés par des virgules, par exemple :
Juniper-Switching-Filter = “match destination-mac 00:00:00:01:02:03 action allow, match destination-port 80 destination-mac 00:aa:bb:cc:dd:ee action allow”
Reportez-vous à la section Conditions et actions de correspondance VSA de Juniper-Switching-Filter pour obtenir la définition des conditions de correspondance et des actions.
Sur les commutateurs EX9200 et dans un Junos Fusion Enterprise avec EX9200 comme périphérique agrégé, le filtre de pare-feu dynamique est strictement appliqué à tous les paquets IP. Si le filtre est configuré pour n’autoriser qu’une adresse IP de destination spécifique, les paquets avec d’autres adresses IP comme adresse IP de destination seront abandonnés conformément aux règles de filtrage. Cela inclut tous les paquets de protocole IP, tels que les paquets DHCP, IGMP et ARP.
Pour configurer les conditions de correspondance sur le serveur RADIUS :
Application d’un filtre de pare-feu configuré localement à partir du serveur RADIUS
Vous pouvez appliquer un filtre de pare-feu de port (filtre de pare-feu de couche 2) aux stratégies utilisateur de manière centralisée à partir du serveur RADIUS. Le serveur RADIUS peut ensuite spécifier les filtres de pare-feu à appliquer à chaque utilisateur qui demande une authentification, ce qui réduit la nécessité de configurer le même filtre de pare-feu sur plusieurs commutateurs. Utilisez cette méthode lorsque le filtre de pare-feu contient un grand nombre de conditions ou que vous souhaitez utiliser des conditions différentes pour le même filtre sur différents commutateurs. Les filtres de pare-feu doivent être configurés sur chaque commutateur.
Pour plus d’informations sur les filtres de pare-feu, reportez-vous à Présentation des filtres de pare-feu pour commutateurs EX Series.
Pour appliquer un filtre de pare-feu de port de manière centralisée à partir du serveur RADIUS :
Si les filtres de pare-feu de port sont également configurés localement pour l’interface, les filtres de pare-feu configurés à l’aide de VSA sont prioritaires s’ils entrent en conflit avec les filtres de pare-feu de port configurés localement. S’il n’y a pas de conflit, ils sont fusionnés.
Exemple : Connexion d’un serveur RADIUS 802.1X à un commutateur EX Series
802.1X est la norme IEEE pour le contrôle d’accès réseau basé sur les ports (PNAC). La norme 802.1X vous permet de contrôler l’accès au réseau. Seuls les utilisateurs et les appareils fournissant des informations d’identification vérifiées par rapport à une base de données d’utilisateurs sont autorisés à accéder au réseau. Vous pouvez utiliser un serveur RADIUS comme base de données utilisateur pour l’authentification 802.1X, ainsi que pour l’authentification MAC RADIUS.
Cet exemple décrit comment connecter un serveur RADIUS à un commutateur EX Series et le configurer pour 802.1X :
Conditions préalables
Cet exemple utilise les composants logiciels et matériels suivants :
Junos OS version 9.0 ou ultérieure pour les commutateurs EX Series
Un commutateur EX Series faisant office d’entité d’accès au port d’authentification (PAE). Les ports de l’authentificateur PAE forment une porte de contrôle qui bloque tout le trafic à destination et en provenance des demandeurs jusqu’à ce qu’ils soient authentifiés.
Un serveur d’authentification RADIUS compatible 802.1X. Le serveur d’authentification fait office de base de données principale et contient les informations d’identification des hôtes (demandeurs) autorisés à se connecter au réseau.
Avant de connecter le serveur au commutateur, assurez-vous d’avoir :
Effectuez le pontage de base et la configuration VLAN sur le commutateur - effectué. Consultez la documentation décrivant la configuration d’un pontage de base et d’un VLAN pour votre commutateur. Si vous utilisez un commutateur qui prend en charge le style de configuration ELS (Enhanced L2 Software), reportez-vous à la section Exemple : Configuration d’un pontage de base et d’un VLAN pour un commutateur EX Series avec prise en charge ELS . Pour tous les autres commutateurs, reportez-vous à la section Exemple : Configuration d’un pontage de base et d’un VLAN pour un commutateur EX Series.
REMARQUE :Pour plus d’informations sur ELS, reportez-vous à la section Utilisation de la CLI logicielle de couche 2 améliorée.
Utilisateurs configurés sur le serveur d’authentification RADIUS.
Vue d’ensemble et topologie
Le commutateur EX Series agit comme un PAE d’authentification. Il bloque tout le trafic et agit comme une porte de contrôle jusqu’à ce que le demandeur (client) soit authentifié par le serveur. L’accès est refusé à tous les autres utilisateurs et appareils.
Figure 1montre un commutateur EX4200 connecté aux périphériques répertoriés à la .Tableau 2
Propriété | Paramètres |
---|---|
Matériel de commutation |
Commutateur d’accès EX4200, 24 ports Gigabit Ethernet : 8 ports PoE (ge-0/0/0 à ge-0/0/7) et 16 ports non-PoE (ge-0/0/8 à ge-0/0/23) |
Nom du VLAN |
Par défaut |
Un serveur RADIUS |
Base de données principale avec une adresse 10.0.0.100 connectée au commutateur sur le port ge-0/0/10 |
Dans cet exemple, connectez le serveur RADIUS au port d’accès ge-0/0/10 du commutateur EX4200. Le commutateur agit en tant qu’authentificateur et transmet les informations d’identification du demandeur à la base de données des utilisateurs sur le serveur RADIUS. Vous devez configurer la connectivité entre l’EX4200 et le serveur RADIUS en spécifiant l’adresse du serveur et en configurant le mot de passe secret. Ces informations sont configurées dans un profil d’accès sur le commutateur.
Pour plus d’informations sur les services d’authentification, d’autorisation et de comptabilité (AAA), consultez le Guide de configuration des bases du système Junos OS.
Configuration
Procédure
Configuration rapide de l’interface de ligne de commande
Pour connecter rapidement le serveur RADIUS au commutateur, copiez les commandes suivantes et collez-les dans la fenêtre du terminal du commutateur :
[edit] set access radius-server 10.0.0.100 secret juniper set access radius-server 10.0.0.200 secret juniper set access profile profile1 authentication-order radius set access profile profile1 radius authentication-server [10.0.0.100 10.0.0.200]
Procédure étape par étape
Pour connecter le serveur RADIUS au commutateur :
Définissez l’adresse des serveurs et configurez le mot de passe secret. Le mot de passe secret sur le commutateur doit correspondre au mot de passe secret sur le serveur :
[edit] user@switch# set access radius-server 10.0.0.100 secret juniper user@switch# set access radius-server 10.0.0.200 secret juniper
Configurez l’ordre d’authentification, en faisant radius de la première méthode d’authentification :
[edit] user@switch# set access profile profile1 authentication-order radius
Configurez une liste d’adresses IP de serveur à essayer dans l’ordre séquentiel pour authentifier le demandeur :
[edit] user@switch# set access profile profile1 radius authentication-server [10.0.0.100 10.0.0.200]
Résultats
Affichez les résultats de la configuration :
user@switch> show configuration access radius-server { 10.0.0.100 port 1812; secret "$ABC123"; ## SECRET-DATA } } profile profile1{ authentication-order radius; radius { authentication-server 10.0.0.100 10.0.0.200; } } }
Vérification
Pour vérifier que la configuration fonctionne correctement, effectuez les opérations suivantes :
Vérifiez que le commutateur et le serveur RADIUS sont correctement connectés.
But
Vérifiez que le serveur RADIUS est connecté au commutateur sur le port spécifié.
Action
Envoyez une requête ping au serveur RADIUS pour vérifier la connexion entre le commutateur et le serveur :
user@switch> ping 10.0.0.100
PING 10.0.0.100 (10.0.0.100): 56 data bytes
64 bytes from 10.93.15.218: icmp_seq=0 ttl=64 time=9.734 ms
64 bytes from 10.93.15.218: icmp_seq=1 ttl=64 time=0.228 ms
Sens
Les paquets de demande d’écho ICMP sont envoyés du commutateur au serveur cible à l’adresse 10.0.0.100 pour vérifier si le serveur est accessible sur le réseau IP. Les réponses d’écho ICMP sont renvoyées par le serveur, ce qui permet de vérifier que le commutateur et le serveur sont connectés.
Présentation des filtres dynamiques basés sur les attributs RADIUS
Vous pouvez utiliser les attributs de serveur RADIUS pour implémenter des filtres de pare-feu de port sur un serveur d’authentification RADIUS. Ces filtres peuvent être appliqués dynamiquement aux demandeurs qui demandent une authentification via ce serveur. Les attributs de serveur RADIUS sont des champs en texte clair encapsulés dans les messages d’accès-acceptation envoyés par le serveur d’authentification au commutateur lorsqu’un demandeur connecté au commutateur est authentifié avec succès. Le commutateur, agissant en tant qu’authentificateur, utilise les informations des attributs RADIUS pour appliquer les filtres associés au demandeur. Les filtres dynamiques peuvent être appliqués à plusieurs ports d’un même commutateur ou à plusieurs commutateurs utilisant le même serveur d’authentification, assurant ainsi un contrôle d’accès centralisé au réseau.
Vous pouvez définir des filtres de pare-feu directement sur le serveur RADIUS à l’aide de l’attribut Juniper-Switching-Filter, qui est un attribut RADIUS spécifique à Juniper Networks, également appelé attribut spécifique au fournisseur (VSA). Les VSA sont décrits dans la RFC 2138, Remote Authentication Dial In User Service (RADIUS). Le filtre de commutation Juniper VSA est répertorié sous l’ID d’attribut numéro 48 dans le dictionnaire Juniper sur le serveur RADIUS, avec l’ID de fournisseur défini sur le numéro d’ID Juniper Networks 2636. À l’aide de cet attribut, vous définissez des filtres sur le serveur d’authentification, qui sont appliqués à tous les commutateurs qui authentifient les demandeurs via ce serveur. Cette méthode élimine le besoin de configurer les mêmes filtres sur plusieurs commutateurs.
Vous pouvez également appliquer un filtre de pare-feu de port à plusieurs ports sur le même commutateur à l’aide de l’attribut Filter-ID, qui est l’ID d’attribut RADIUS numéro 11. Pour utiliser l’attribut Filter-ID, vous devez d’abord configurer un filtre sur le commutateur, puis ajouter le nom du filtre aux stratégies utilisateur sur le serveur RADIUS en tant que valeur de l’attribut Filter-ID. Lorsqu’un demandeur défini dans l’une de ces stratégies est authentifié par le serveur RADIUS, le filtre est appliqué au port de commutation qui a été authentifié pour le demandeur. Utilisez cette méthode lorsque le filtre de pare-feu comporte des conditions complexes ou si vous souhaitez utiliser des conditions différentes pour le même filtre sur différents commutateurs. Le filtre nommé dans l’attribut Filter-ID doit être configuré localement sur le commutateur au niveau de la hiérarchie [edit firewall family ethernet-switching filter
].
Les VSA sont pris en charge uniquement pour les configurations 802.1X à demandeur unique et les configurations à demandeurs multiples.
Voir également
Présentation de l’affectation dynamique de VLAN à l’aide des attributs RADIUS
Les VLAN peuvent être attribués dynamiquement par un serveur RADIUS aux demandeurs demandant une authentification 802.1X via ce serveur. Vous configurez le VLAN sur le serveur RADIUS à l’aide des attributs de serveur RADIUS, qui sont des champs en texte clair encapsulés dans les messages envoyés par le serveur d’authentification au commutateur lorsqu’un demandeur connecté au commutateur demande l’authentification. Le commutateur, agissant en tant qu’authentificateur, utilise les informations des attributs RADIUS pour attribuer le VLAN au demandeur. En fonction des résultats de l’authentification, un demandeur qui a commencé à s’authentifier dans un VLAN peut être affecté à un autre VLAN.
Pour réussir l’authentification, il faut que l’ID de VLAN ou le nom de VLAN soit configuré sur le commutateur agissant comme un authentificateur 802.1X et qu’il corresponde à l’ID de VLAN ou au nom de VLAN envoyé par le serveur RADIUS lors de l’authentification. Si ni l’un ni l’autre n’existe, le terminal n’est pas authentifié. Si un VLAN invité est établi, le terminal non authentifié est automatiquement déplacé vers le VLAN invité.
Attributs de serveur RADIUS utilisés pour l’attribution dynamique de VLAN décrits dans la RFC 2868, Attributs RADIUS pour la prise en charge des protocoles de tunnel.
Tunnel-Type : défini comme type d’attribut RADIUS 64. La valeur doit être définie sur
VLAN
.Tunnel-Medium-Type : défini comme type d’attribut RADIUS 65. La valeur doit être définie sur
IEEE-802
.Tunnel-Private-Group-ID : défini comme type d’attribut RADIUS 81. La valeur doit être définie sur l’ID de VLAN ou le nom du VLAN.
Pour plus d’informations sur la configuration des VLAN dynamiques sur votre serveur RADIUS, reportez-vous à la documentation de votre serveur RADIUS.
Voir également
Configuration des groupes VLAN sur les commutateurs EX Series
La fonctionnalité de groupe VLAN vous permet de répartir les clients sur les VLAN. Lorsque vous activez cette fonctionnalité, vous pouvez aligner un seul LAN sans fil (WLAN) sur un seul VLAN ou sur plusieurs VLAN. Lorsque vous configurez un groupe de VLAN, un client est affecté à l’un des VLAN configurés. Cette fonctionnalité prend en charge l’équilibrage de charge dynamique des utilisateurs sur les VLAN d’un groupe de VLAN. Cette fonctionnalité suit l’algorithme Round-Robin pour affecter les utilisateurs au prochain VLAN disponible dans un groupe de VLAN.
Pour un équilibrage de charge VLAN dynamique, vous ajoutez le nom du groupe VLAN au lieu d’un ID VLAN standard ou d’un nom VLAN dans l’attribut (défini dans RFC Tunnel-Private-Group-ID
2868 comme type d’attribut RADIUS 81). Par la suite, vous envoyez ces informations dans la réponse RADIUS lorsqu’un demandeur demande une authentification 802.1X via le serveur RADIUS. Lorsque le commutateur reçoit le nom du groupe de VLAN, il affecte le point de terminaison à l’un des VLAN de ce groupe à l’aide de l’algorithme Round-Robin. Le groupe VLAN permet d’allouer un VLAN à partir d’une liste préconfigurée, réduisant ainsi la nécessité pour les administrateurs d’équilibrer la charge du réseau.
Lorsque vous configurez un groupe VLAN, notez que :
-
Vous pouvez configurer un maximum de 4096 groupes VLAN.
-
Vous devez créer un VLAN avant de l’allouer aux clients. Tout VLAN qui n’existe pas sur le commutateur est ignoré lors de l’allocation.
-
Un nom de VLAN ne peut pas être le même que le nom d’un groupe de VLAN.
-
Un VLAN VoIP ne doit pas faire partie d’un groupe de vlan. Un VLAN VoIP, s’il est présent, sera ignoré.
-
Lorsque vous supprimez un VLAN, toutes les sessions authentifiées 802.1X associées à ce VLAN sont résiliées.
-
Vous pouvez supprimer un groupe de VLAN sans perturber les clients qui ont déjà été alloués aux VLAN de ce groupe de VLAN.
-
Vous pouvez supprimer un VLAN d’un groupe de VLAN sans perturber les clients qui ont déjà été alloués à ce VLAN. Toutefois, un client peut être confronté à une perturbation si :
-
La session client expire.
-
Une réauthentification ou un changement de rôle est effectué à l’aide d’une demande de changement d’autorisation (CoA).
-
Pour configurer des groupes VLAN sur des commutateurs EX Series :
Voir également
Comprendre les VLAN invités pour 802.1X sur les commutateurs
Les VLAN invités peuvent être configurés sur des commutateurs qui utilisent l’authentification 802.1X pour fournir un accès limité, généralement uniquement à Internet, aux invités d’entreprise. Le VLAN invité est utilisé comme solution de secours dans les cas suivants :
Le demandeur n’est pas compatible 802.1X et ne répond pas aux messages EAP.
L’authentification MAC RADIUS n’a pas été configurée sur les interfaces de commutateur auxquelles le demandeur est connecté.
Le portail captif n’a pas été configuré sur les interfaces de commutateur auxquelles le demandeur est connecté.
Un VLAN invité n’est pas utilisé pour les demandeurs qui envoient des informations d’identification incorrectes. Ces demandeurs sont dirigés vers le VLAN de rejet du serveur à la place.
Pour les terminaux qui ne sont pas compatibles 802.1X, un VLAN invité peut autoriser un accès limité à un serveur à partir duquel le terminal non compatible 802.1X peut télécharger le logiciel demandeur et tenter à nouveau de s’authentifier.
Voir également
Exemple : Configuration des options de secours sur les commutateurs EX Series pour l’authentification EAP-TTLS et les clients d’accès Odyssey
Pour l’authentification utilisateur 802.1X, les commutateurs EX Series prennent en charge les serveurs d’authentification RADIUS qui utilisent le protocole EAP-TTLS (Extensible Authentication Protocol–Tunneled TLS) pour authentifier les demandeurs OAC (Odyssey Access Client). Le logiciel de mise en réseau du CAO s’exécute sur les ordinateurs terminaux (ordinateurs de bureau, ordinateurs portables, blocs-notes et appareils sans fil pris en charge) et fournit un accès sécurisé aux réseaux filaires et sans fil.
Cet exemple décrit comment configurer une interface compatible 802.1X sur le commutateur pour fournir une prise en charge de secours aux utilisateurs OAC qui ont entré des informations d’identification de connexion incorrectes :
Conditions préalables
Cet exemple utilise les composants logiciels et matériels suivants :
Cet exemple s’applique également aux commutateurs QFX5100.
Junos OS version 11.2 ou ultérieure pour les commutateurs EX Series
Un commutateur EX Series faisant office d’entité d’accès au port d’authentification (PAE). Les ports de l’authentificateur PAE forment une porte de contrôle qui bloque tout le trafic à destination et en provenance des demandeurs jusqu’à ce qu’ils soient authentifiés.
Un serveur d’authentification RADIUS compatible 802.1X. Le serveur d’authentification fait office de base de données principale et contient les informations d’identification des hôtes (demandeurs) autorisés à se connecter au réseau.
Un terminal OAC agissant en tant que suppliant.
Avant de commencer à configurer l’option de secours, assurez-vous que vous disposez des éléments suivants :
Établissez une connexion entre le commutateur et le serveur RADIUS. Voir l’exemple : Connexion d’un serveur RADIUS pour 802.1X à un commutateur EX Series.
Configuration EAP-TTLS sur le serveur - effectué. Reportez-vous à la documentation de votre serveur RADIUS.
Utilisateurs configurés sur le serveur RADIUS - effectué. Reportez-vous à la documentation de votre serveur RADIUS.
Vue d’ensemble et topologie
OAC est un logiciel de mise en réseau qui s’exécute sur les ordinateurs terminaux (ordinateurs de bureau, portables ou bloc-notes) et les périphériques sans fil pris en charge. Le CAO fournit une prise en charge complète du PAE, qui est requis pour un accès sécurisé au LAN sans fil.
Dans cette topologie, OAC est déployé avec un commutateur compatible 802.1X et un serveur RADIUS. Le commutateur fonctionne comme un point d’application dans l’architecture de sécurité du réseau. Cette topologie :
Garantit que seuls les utilisateurs autorisés peuvent se connecter.
Maintient la confidentialité des identifiants de connexion.
Préserve la confidentialité des données sur la liaison sans fil.
Cet exemple inclut la configuration d’un VLAN de rejet de serveur sur le commutateur, qui peut être utilisé pour empêcher le verrouillage accidentel pour les utilisateurs qui ont entré des identifiants de connexion incorrects. Ces utilisateurs peuvent bénéficier d’un accès LAN limité.
Toutefois, cette configuration de secours est compliquée par le fait que le demandeur OAC et le serveur RADIUS utilisent EAP-TTLS. EAP-TTLS crée un tunnel chiffré sécurisé entre le serveur et le terminal pour terminer le processus d’authentification. Lorsque l’utilisateur saisit des informations d’identification de connexion incorrectes, le serveur RADIUS envoie des messages d’échec EAP directement au client via ce tunnel. Le message d’échec EAP oblige le client à redémarrer la procédure d’authentification, de sorte que le processus d’authentification 802.1X du commutateur détruit la session qui a été établie avec le commutateur à l’aide du VLAN de rejet du serveur. Vous pouvez activer la connexion corrective pour qu’elle se poursuive en configurant :
eapol-block: activez le temporisateur de bloc EAPoL sur l’interface 802.1X configurée pour appartenir au VLAN de rejet du serveur. Le minuteur de blocage fait en sorte que l’entité d’accès au port d’authentification ignore les messages de démarrage EAP du client, ce qui tente de redémarrer la procédure d’authentification.
REMARQUE :Le temporisateur de bloc EAPoL n’est déclenché qu’une fois que le nombre configuré de nouvelles tentatives autorisées (à l’aide de l’option) sur l’interface retries 802.1X a été épuisé. Vous pouvez configurer retries pour spécifier le nombre de tentatives d’authentification du port par le commutateur après une défaillance initiale. La valeur par défaut est de trois tentatives.
block-interval: configurez la durée pendant laquelle vous souhaitez que le minuteur de bloc EAPoL continue d’ignorer les messages de démarrage EAP. Si vous ne configurez pas l’intervalle de blocage, le minuteur de blocage EAPoL est défini par défaut sur 120 secondes.
Lorsque l’interface 802.1X ignore les messages de démarrage EAP du client, le commutateur permet à la session de correction existante qui a été établie via le VLAN de rejet du serveur de rester ouverte.
Ces options de configuration s’appliquent aux modes d’authentification unique, à authentification sécurisée unique et à authentification multiple du demandeur. Dans cet exemple, l’interface 802.1X est configurée en mode demandeur unique.
Figure 3 montre un commutateur EX Series connectant un terminal OAC à un serveur RADIUS et indique les protocoles utilisés pour connecter les entités réseau.
Ce chiffre s’applique également aux commutateurs QFX5100.
Topologie
Tableau 4 décrit les composants de ce déploiement OAC :.
Propriété | Paramètres |
---|---|
Matériel de commutation |
Commutateur EX Series |
VLAN |
default server-reject-vlan: Le nom du VLAN est et l’ID du VLAN est remedial700 |
Interface 802.1X |
ge-0/0/8 |
Demandeur de l’OAC |
EAP-TTLS (en anglais seulement) |
Un serveur d’authentification RADIUS |
EAP-TTLS (en anglais seulement) |
Configuration
Procédure
Configuration rapide de l’interface de ligne de commande
Pour configurer rapidement les options de secours pour les demandeurs EAP-TTLS et OAC, copiez les commandes suivantes et collez-les dans la fenêtre du terminal du commutateur :
[edit] set vlans remedial vlan-id 700 set protocols dot1x authenticator interface ge-0/0/8 retries 4 set protocols dot1x authenticator interface ge-0/0/8 server-reject-vlan remedial set protocols dot1x authenticator interface ge-0/0/8 server-reject-vlan eapol-block set protocols dot1x authenticator interface ge-0/0/8 server-reject-vlan block-interval 130
Procédure étape par étape
Pour configurer les options de secours pour les demandeurs EAP-TTLS et OAC :
Dans cet exemple, le commutateur n’a qu’un seul VLAN de rejet de serveur. Par conséquent, la configuration spécifie eapol-block et block-interval directement après server-reject-vlan. Toutefois, si vous avez configuré plusieurs VLAN sur le commutateur, vous devez inclure le nom du VLAN ou l’ID de VLAN directement après server-reject-vlan pour indiquer quel VLAN est en cours de modification.
Configurez un VLAN qui fonctionnera comme le VLAN de rejet du serveur afin de fournir un accès LAN limité aux utilisateurs qui ont entré des identifiants de connexion incorrects :
[edit] user@switch# set vlans remedial vlan-id 700
Configurez le nombre de fois que le client doit être invité à entrer son nom d’utilisateur et son mot de passe avant qu’une connexion incorrecte ne soit dirigée vers le VLAN server-reject :
[edit protocols dot1x authenticator interface ge-0/0/8] user@switch# set retries 4
Configurez l’interface de l’authentificateur 802.1X pour utiliser le VLAN server-reject comme solution de secours en cas de connexion incorrecte :
[edit protocols dot1x authenticator interface ge-0/0/8] user@switch# set server-reject-vlan remedial
Activez le temporisateur de bloc EAPoL sur l’interface 802.1X configurée pour appartenir au VLAN de rejet du serveur.
[edit protocols dot1x authenticator interface ge-0/0/8] user@switch# set server-reject-vlan eapol-block
Configurez la durée pendant laquelle le bloc EAPoL doit rester actif :
[edit protocols dot1x authenticator interface ge-0/0/8] user@switch# set server-reject-vlan block-interval 130
Résultats
Vérifiez les résultats de la configuration :
user@switch> show configuration protocols { dot1x { authenticator { interface { ge-0/0/8.0 { supplicant single; retries 4; server-reject-vlan remedial block-interval 130 eapol-block; }
Vérification
Pour vérifier que la configuration et les options de secours fonctionnent correctement, effectuez la tâche suivante :
Vérification de la configuration de l’interface 802.1X
But
Vérifiez que l’interface 802.1X est configurée avec les options souhaitées.
Action
user@switch> show dot1x interface ge-0/0/8.0 detail ge-0/0/8.0 Role: Authenticator Administrative state: Auto Supplicant mode: Single Number of retries: 4 Quiet period: 60 seconds Transmit period: 30 seconds Mac Radius: Disabled Mac Radius Restrict: Disabled Reauthentication: Enabled Configured Reauthentication interval: 120 seconds Supplicant timeout: 30 seconds Server timeout: 30 seconds Maximum EAPoL requests: 2 Guest VLAN member: guest Number of connected supplicants: 1 Supplicant: tem, 2A:92:E6:F2:00:00 Operational state: Authenticated Backend Authentication state: Idle Authentication method: Radius Authenticated VLAN: remedial Session Reauth interval: 120 seconds Reauthentication due in 68 seconds
Sens
La show dot1x ge-0/0/8 detail
sortie de la commande indique que l’interface est dans l’état et qu’elle ge-0/0/8Authenticated utilise le remedial VLAN.
Surveillance de l’authentification 802.1X
But
Cette rubrique s’applique uniquement au package d’application J-Web.
Utilisez la fonction de surveillance pour afficher les détails des utilisateurs authentifiés et des utilisateurs qui ont échoué à l’authentification.
Action
Pour afficher les détails de l’authentification dans l’interface J-Web, sélectionnez Monitoring > > Security802.1X.
Pour afficher les détails de l’authentification dans l’interface de ligne de commande, entrez les commandes suivantes :
show dot1x interface detail | display xml
show dot1x interface detail <interface> | display xml
show dot1x auth-failed-users
Sens
Les détails affichés sont les suivants :
Liste des utilisateurs authentifiés.
Le nombre d’utilisateurs connectés.
Liste des utilisateurs dont l’authentification a échoué.
Vous pouvez également spécifier une interface pour laquelle les détails doivent être affichés.
Voir également
Vérification de l’authentification 802.1X
But
Vérifiez que les demandeurs sont authentifiés sur une interface d’un commutateur dont l’interface est configurée pour l’authentification 802.1X et affichez la méthode d’authentification utilisée.
Action
Affichez des informations détaillées sur une interface configurée pour 802.1X (ici, l’interface est ge-0/0/16) :
user@switch> show dot1x interface ge-0/0/16.0 detail ge-0/0/16.0 Role: Authenticator Administrative state: Auto Supplicant mode: Single Number of retries: 3 Quiet period: 60 seconds Transmit period: 30 seconds Mac Radius: Enabled Mac Radius Strict: Disabled Reauthentication: Enabled Reauthentication interval: 40 seconds Supplicant timeout: 30 seconds Server timeout: 30 seconds Maximum EAPOL requests: 1 Guest VLAN member: <not configured> Number of connected supplicants: 1 Supplicant: user5, 00:30:48:8C:66:BD Operational state: Authenticated Authentication method: Radius Authenticated VLAN: v200 Reauthentication due in 17 seconds
Sens
L’exemple de sortie de la commande montre que la show dot1x interface detail
Number of connected supplicants
valeur est 1. Le demandeur qui a été authentifié et qui est maintenant connecté au réseau local est connu sous le nom de user5 sur le serveur RADIUS et possède l’adresse MAC 00:30:48:8C:66:BD. Le demandeur a été authentifié à l’aide de la méthode d’authentification 802.1X appelée authentification RADIUS, comme indiqué dans Radius
la sortie. Lorsque l’authentification RADIUS est utilisée, le demandeur est configuré sur le serveur RADIUS, le serveur RADIUS le communique au commutateur et le commutateur ouvre un accès LAN sur l’interface à laquelle le demandeur est connecté. L’exemple de sortie montre également que le demandeur est connecté au VLAN v200.
Outre l’authentification RADIUS, les autres méthodes d’authentification 802.1X prises en charge sur les commutateurs EX Series sont :
VLAN invité : un hôte qui ne répond pas se voit accorder un accès au VLAN invité.
Rayon MAC—Un hôte qui ne répond pas est authentifié en fonction de son adresse MAC. L’adresse MAC est configurée comme autorisée sur le serveur RADIUS, le serveur RADIUS informe le commutateur que l’adresse MAC est une adresse autorisée et le commutateur accorde l’accès LAN à l’hôte qui ne répond pas sur l’interface à laquelle il est connecté.
Server-fail deny : si les serveurs RADIUS expirent, tous les demandeurs se voient refuser l’accès au réseau local, ce qui empêche le trafic du demandeur de traverser l’interface. Il s’agit de l’option par défaut.
Autorisation d’échec du serveur : lorsque le serveur RADIUS n’est pas disponible, un demandeur est toujours autorisé à accéder au réseau local comme s’il avait été authentifié avec succès par le serveur RADIUS.
Server-fail use-cache : si les serveurs RADIUS expirent lors de la réauthentification, les demandeurs précédemment authentifiés se voient accorder un accès au LAN, mais les nouveaux demandeurs se voient refuser l’accès au LAN.
VLAN d’échec du serveur : un demandeur est configuré pour être déplacé vers un VLAN spécifié si le serveur RADIUS n’est pas disponible pour authentifier à nouveau le demandeur. (Le VLAN doit déjà exister sur le commutateur.)
Voir également
Dépannage de l’authentification des terminaux sur les commutateurs EX Series
Problème
Description
Les terminaux configurés à l’aide d’adresses MAC statiques perdent la connexion au commutateur après l’exécution de la commande clear dot1x interface pour effacer toutes les adresses MAC apprises.
Avant d’effacer les adresses MAC :
user@switch# run show ethernet-switching table Ethernet-switching table: 3 entries, 1 learned, 0 persistent entries VLAN MAC address Type Age Interfaces vlan100 * Flood - All-members default * Flood - All-members default 00:a0:d4:00:03:00 Learn 0 ge-3/0/16.0 user@switch> show dot1x authentication-bypassed-users MAC address Interface VLAN 00:a0:d4:00:03:00 ge-3/0/16.0 configured/default
Pour effacer les adresses MAC :
user@switch> clear dot1x interface
Après avoir effacé les adresses MAC :
user@switch> show ethernet-switching table Ethernet-switching table: 2 entries, 0 learned, 0 persistent entries VLAN MAC address Type Age Interfaces vlan100 * Flood - All-members default * Flood - All-members user@switch> show dot1x authentication-bypassed-users
Notez qu’il n’y a pas de terminaux sur la liste de contournement de l’authentification.
La cause
Les adresses MAC statiques sont traitées de la même manière que les autres adresses MAC apprises sur une interface. Lorsque la commande clear dot1x interface est exécutée, elle efface toutes les adresses MAC apprises de l’interface, y compris la liste de contournement MAC statique (également connue sous le nom de liste d’exclusion).
Solution
Si vous exécutez la commande clear dot1x interfaces pour une interface dont les adresses MAC statiques sont configurées pour le contournement de l’authentification, ajoutez à nouveau les adresses MAC statiques à la liste de contournement MAC statique.
Voir également
Attributs RADIUS et attributs spécifiques aux fournisseurs (VSA) de Juniper Networks pris en charge par 802.1X
L’authentificateur (serveur d’accès réseau), le demandeur (client) et le serveur d’authentification sont tous impliqués dans l’authentification 802.1X (serveur RADIUS). Le protocole RADIUS est utilisé comme mécanisme de requête/réponse pour la communication entre le NAS et le serveur Radius. Il y a zéro ou plusieurs valeurs de longueur de type (TLV/attributs) dans les requêtes et les réponses.
L’accès de chaque demandeur peut être restreint à l’aide d’un ensemble standard de fonctionnalités définies et d’attributs spécifiques au fournisseur activés par la norme 802.1X. (client). Certains attributs peuvent être utilisés plusieurs fois afin de prendre en charge des valeurs plus longues, car l’attribut Radius Class a une taille maximale de 253 octets.
Avantages de l’utilisation des attributs standard RADIUS et des VSA
Pour se connecter à un serveur RADIUS externe à des fins d’authentification, d’autorisation et de comptabilisation des abonnés, des attributs standard RADIUS sont requis.
Les VSA permettent la mise en œuvre de nombreuses fonctionnalités utiles nécessaires à la gestion des abonnés et à la prise en charge des services, étendant ainsi les capacités du serveur RADIUS au-delà de ce qui est fourni par les attributs standard publics.
Attributs Radius et liste VSA pris en charge par la norme 802.1X
Type | Attribut |
---|---|
1 |
Nom d’utilisateur |
11 |
ID de filtre |
24 |
État |
25 |
Classe |
26 |
Spécifique au fournisseur |
27 |
Délai d’expiration de la session |
56 |
VLANID de sortie |
57 |
Nom du VLAN de sortie |
64 |
Type de tunnel |
+ de 65 |
Tunnel-Moyen-Type |
81 |
ID de groupe privé de tunnel |
85 |
Intervalle Acct-Interim |
102 |
EAP-Nom-clé |
ID du fournisseur | Nombre | VSA Juniper | VSA Microsoft | Cisco VSA |
---|---|---|---|---|
2636 | 48 | Filtre de commutation Juniper | ||
49 | Juniper-VoIP-VLAN | |||
50 | Juniper-CWA-Redirect-URL | |||
21 | Juniper-AV-Paire = Rebond de port |
|||
Juniper-AV-Pair = Juniper Ip-Mac-Session-Binding |
||||
Juniper-AV-Pair = No-Mac-Binding-Reauth |
||||
Juniper-AV-Pair = Mode demandeur-unique |
||||
Juniper-AV-Pair = Mode demandeur-Single-Secure |
||||
Juniper-AV-Pair = Retain-Mac-Aged-Session |
||||
311 | 16 | MS-MPPE-Send-Key | ||
17 | MS-MPPE-Recv-Key | |||
9 | 1 |
Cisco-AVPair = « subscriber :command=bounce-host-port » |
||
Cisco-AVPair = « subscriber :command=reauthenticate » |
||||
Cisco-AVPair = « subscriber :reauthenticate-type=rerun » |
||||
« subscriber :reauthenticate-type=last » | ||||
« redirection-url » |
Attributs RADIUS pris en charge par la norme 802.1X
Nom d’utilisateur :
Le nom de l’utilisateur qui doit être vérifié est indiqué par cet attribut. S’ils sont disponibles, les paquets Access-Request doivent être utilisés pour envoyer cet attribut. Le type RADIUS de cet attribut est 1.
ID de filtre :
Sur le serveur RADIUS, les stratégies utilisateur peuvent être soumises à un filtre de pare-feu. Le serveur RADIUS peut ensuite être utilisé pour spécifier les filtres de pare-feu à appliquer à chaque utilisateur qui soumet une demande d’authentification. Chaque commutateur doit être configuré avec des filtres de pare-feu.
You must set up firewall filter on the local switch in order to apply filter centrally from the RADIUS server.[root@freeradius]# cd /usr/local/pool/raddb vi users
Ajoutez le filtre pour chaque utilisateur concerné.
Filter-Id = Filter1
État :
Entre l’équipement et le serveur RADIUS, les informations d’état peuvent être conservées à l’aide de l’attribut String. Le type RADIUS de cet attribut est 24.
VLANID de sortie :
Un VLANID de sortie IEEE 802 autorisé pour ce port est représenté par l’attribut Egress-VLANID qui spécifie également si le VLANID est autorisé pour les trames balisées ou non étiquetées en plus de VLANID. L’attribut Egress-VLANID est défini dans la RFC 4675.
Les attributs Egress-VLANID des paquets Access-Request, Access-Accept ou CoA-Request peuvent inclure plusieurs valeurs. Aucune caractéristique ne peut inclure cette caractéristique : Access-Challenge, Access-Reject, Disconnect-Request, Disconnect-ACK, Disconnect-NAK, CoA-ACK ou CoA-NAK. Chaque attribut ajoute le VLAN fourni à la liste des VLAN de sortie autorisés du port.
Si les trames sur le VLAN sont étiquetées (0x31) ou non étiquetées (0x31), le champ Indication de balise, d’une longueur d’un octet, l’indique. Le VLANID a une longueur de 12 bits et contient la valeur VLAN VID.
Pour l’ID VLAN de sortie :
0x31 = tagged 0x32 = untagged
Par exemple, le profil RADIUS suivant comprend un VLAN balisé et un VLAN non balisé :
001094001177 Cleartext-Password := "001094001177" Tunnel-Type = VLAN, Tunnel-Medium-Type = IEEE-802, Egress-VLANID += 0x3100033, Egress-VLANID += 0x3200034,
Nom du VLAN de sortie :
Egress-VLAN-Name représente un VLAN autorisé pour ce port. Toutefois, comme pour l’attribut Egress-VLANID, au lieu d’utiliser l’ID VLAN, qui est défini ou connu, le nom de VLAN est utilisé pour identifier le VLAN au sein du système. La RFC 4675 contient une définition de l’attribut Egress-VLAN-Name.
Le nom du VLAN est la deuxième partie de l’attribut Egress-VLAN-Name en deux parties, qui spécifie également si les trames du VLAN pour ce port doivent être affichées au format balisé ou non.
Pour le nom du VLAN de sortie : 1 = étiqueté et 2 = non étiqueté
The example below shows that VLAN 1vlan-2 is tagged, while VLAN 2vlan-3 is not.001094001144 Cleartext-Password := "001094001144" Tunnel-Type = VLAN, Tunnel-Medium-Type = IEEE-802, Egress-VLAN-Name += 1vlan-2, Egress-VLAN-Name += 2vlan-3,
Type de tunnel :
Cet attribut spécifie soit le protocole de tunnelisation actuellement utilisé, soit le protocole de tunnelisation qui sera utilisé (dans le cas d’un initiateur de tunnel) (dans le cas d’une terminaison de tunnel). La RFC 2868 spécifie l’attribut Tunnel-Type. Le type RADIUS de cet attribut est 64
Tunnel-Private-Group-Id :
L’ID VLAN ou NAME de la session est affiché par l’attribut Tunnel-Medium-Type. L’équipement vérifie si la chaîne qu’il reçoit est un nom de VLAN ou un ID après avoir obtenu une valeur fournie pour l’attribut Tunnel-Private-Group-ID à partir du rayon et vérifie si l’équipement est configuré avec un VLAN.
Si un VLAN a été configuré, le port client est ajouté à ce VLAN. Dans le cas contraire, en raison d’un échec de la validation du VLAN, le client ne sera pas autorisé et sera maintenu dans un état en attente.
Le type RADIUS de cet attribut est 81, conformément à la RFC 2868.
[root@freeradius]# cat /usr/local/etc/raddb/users supplicant1 Auth-Type := EAP, User-Password == "supplicant1" Tunnel-Type = VLAN, Tunnel-Medium-Type = IEEE-802, Tunnel-Private-Group-Id = "1005",
Intervalle de compte intérimaire :
La valeur de l’attribut Acct-Interim-Interval représente l’intervalle de temps en secondes entre chaque transmission d’une mise à jour intermédiaire pour une session particulière. Le nombre de secondes qui se sont écoulées depuis le dernier message de mise à jour comptable est la valeur de cet attribut.
Une valeur minimale peut également être définie par un administrateur localement sur un client RADIUS, mais cette valeur est toujours prioritaire sur les valeurs Acct-Interim-Interval détectées dans un paquet Access-Accept. Le type RADIUS de cet attribut est 85.
VSA Juniper Networks
Filtre de commutation Juniper :
L’attribut Juniper-Switching-Filter du dictionnaire Juniper sur le serveur RADIUS vous permet de spécifier des critères de filtrage simples. Après cela, chaque fois qu’un nouvel utilisateur est autorisé avec succès, ces filtres sont livrés à un commutateur.
Les commutateurs qui utilisent le serveur RADIUS pour l’authentification des utilisateurs construisent et appliquent automatiquement les filtres sans nécessiter de configuration spécifique au commutateur. Entrez une ou plusieurs conditions de correspondance, actions et associations d’utilisateurs dans le serveur RADIUS pour configurer la propriété Juniper-Switching-Filter.
Pour des filtres de commutation plus longs, utilisez plusieurs instances de l’attribut Juniper-switching-filter avec une limite maximale de 20 conditions de correspondance et une taille totale maximale de 4 000 caractères. La longueur maximale d’un attribut radius est de 253 caractères. Chaque ligne de l’attribut « Juniper-switching-filter » doit également comporter moins de 253 caractères.
spirent123 Auth-Type := EAP, User-Password := "spirent123" Juniper-Switching-Filter = "match src-tag dst-port [ 80 25 443 ] src-port [5060 1025-2000] action allow ", Juniper-Switching-Filter += "match src-port 500 dst-port 600 src-tag [ 100, 200 ] action allow ", Juniper-Switching-Filter += "match ip-proto src-port 9090 ip-proto [ 25 17] action allow ", Juniper-Switching-Filter += "match src-port 100-120 200-220 300-320 src-tag ip-proto 26 18 action allow ", Juniper-Switching-Filter += "match ether-type [ 3000-4000 8000 ] ip-proto 240 action allow "
Les conditions de correspondance de filtre suivantes sont prises en charge :
· destination-mac / dst-mac · destination-port / dst-port · destination-ip / dst · ip-protocol / ip-proto · source-port / src-port · source-dot1q-tag / src-tag · ether-type
- Allow · Deny · GBP · Trap to CPU · Loss-Priority · Forwarding-Class
i) Vérifiez que le dictionnaire Juniper est bien chargé sur votre serveur RADIUS et qu’il inclut l’attribut de filtrage Juniper-Switching-Filter, ID d’attribut 48 :
[root@freeradius]# cat /usr/local/share/freeradius/dictionary.juniper # dictionary.juniper # $ # VENDOR Juniper 2636 BEGIN-VENDOR Juniper ATTRIBUTE Juniper-Local-User-Name 1 string ATTRIBUTE Juniper-Allow-Commands 2 string ATTRIBUTE Juniper-Deny-Commands 3 string ATTRIBUTE Juniper-Allow-Configuration 4 string ATTRIBUTE Juniper-Deny-Configuration 5 string ATTRIBUTE Juniper-Switching-Filter 48 string ATTRIBUTE Juniper-VoIP-Vlan 49 string ATTRIBUTE Juniper-CWA-Redirect 50 string ATTRIBUTE Juniper-AV-Pair 52 string END-VENDOR Juniper
ii) Entrez les conditions de match et les actions.
[root@freeradius]# cd /usr/local/etc/raddb vi users
Pour chaque utilisateur concerné, ajoutez l’attribut Juniper-Switching-Filter. Pour refuser ou autoriser l’accès en fonction de l’adresse MAC de destination, utilisez
Juniper-Switching-Filter = "Match Destination mac 00:00:00:01:02:03 Action allow",
Ou
Juniper-Switching-Filter = "Match Destination-mac 00:00:00:01:02:03 Action deny",
Pour refuser ou autoriser l’accès en fonction de l’adresse IP de destination :
Juniper-Switching-Filter = "match destination-ip 192.168.1.0/31 action deny"
Ou
Juniper-Switching-Filter = "match destination-ip 192.168.1.0/31 action allow"
Pour envoyer plusieurs filtres avec des correspondances et des actions différentes :
spirent123 Auth-Type := EAP, User-Password := "spirent123" Juniper-Switching-Filter += "Match Ip-protocol 1 Destination-port 53 Action allow,", Juniper-Switching-Filter += "Match ip-proto [ 17, 25 ] dst-port 53 Action allow,", Juniper-Switching-Filter += "Match Ip-protocol 2 src-port 67 Action allow,", Juniper-Switching-Filter += "match ether-type [ 3000-4000 8000] action deny,", Juniper-Switching-Filter += "Match destination-port 23 Action allow,", Juniper-Switching-Filter += "Match Ip-protocol 6 Destination-port 80 Action trap,",
Ou
Juniper-Switching-Filter = "Match Ip-protocol 6 Destination-port 53 Action allow , Match Ip-protocol [ 17 25] Destination-port 53 Action allow , Match Ether-type [2054-2070] Action deny, Match Ip-protocol 6 Destination-port 443 Action trap"
Pour définir la priorité de perte de paquets (PLP) sur élevée en fonction d’une adresse MAC de destination et du protocole IP :
Juniper-Switching-Filter = "match destination-mac 00:04:0f:fd:ac:fe, ip-protocol 2, forwarding-class high, action loss-priority high"
La classe de transfert doit être configurée sur le commutateur pour que l’option de classe de transfert soit prise en compte. Cette option n’est pas utilisée si elle n’est pas spécifiée sur le commutateur. La priorité de perte de paquets et la classe de transfert doivent être spécifiées.
Juniper-VoIP-Vlan :
Le vlan VOIP est récupéré à partir du serveur RADIUS à l’aide du VSA Juniper-VoIP-VLAN dans un message d’acceptation d’accès ou un message de demande de certificat d’authenticité. Cet attribut est le numéro 49.
Juniper-VoIP-Vlan = "voip_vlan"
La VoIP vous permet de connecter des téléphones IP au commutateur et de configurer l’authentification IEEE 802.1X pour les téléphones IP compatibles 802.1X.
Les réseaux locaux Ethernet sont protégés contre l’accès illégal des utilisateurs grâce à l’authentification 802.1X. Un protocole connu sous le nom de VoIP est utilisé pour transmettre la voix sur les réseaux à commutation de paquets. Une connexion réseau, par opposition à une ligne téléphonique analogique, est utilisée par la VoIP pour transmettre des appels vocaux. Lorsque la VoIP est utilisée avec 802.1X, le serveur RADIUS vérifie l’identité du téléphone, tandis que le protocole LLDP-MED (Link Layer Discovery Protocol-Media Endpoint Discovery) attribue au téléphone les paramètres de classe de service (CoS).
Juniper-CWA-Redirection :
Avec le VSA Juniper-CWA-Redirect, qui porte le numéro d’attribut 50 dans le dictionnaire RADIUS de Juniper, l’URL de redirection peut être configurée de manière centralisée sur le serveur AAA. Le filtre et l’URL du pare-feu dynamique sont tous deux remis par le serveur AAA au commutateur dans le même message RADIUS Access-Accept. En tant que mécanisme d’authentification de secours, l’authentification Web centrale (CWA) redirige le navigateur Web de l’hôte vers un serveur d’authentification Web central. L’utilisateur peut saisir un nom d’utilisateur et un mot de passe sur l’interface Web du serveur CWA. L’utilisateur est authentifié et dispose d’un accès au réseau si le serveur CWA accepte ses informations d’identification.
Lorsqu’un hôte échoue à l’authentification MAC RADIUS, l’authentification Web centralisée est utilisée. Le commutateur, agissant en tant qu’authentificateur, reçoit un message d’accès-acceptation RADIUS du serveur AAA qui contient un filtre de pare-feu dynamique et une URL de redirection pour l’authentification Web centrale.
Pour que la procédure d’authentification Web centrale soit activée, l’URL de redirection et le filtre de pare-feu dynamique doivent être présents. Pour utiliser Juniper-Switching-Filter VSA pour l’authentification Web centrale, vous devez configurer les termes de filtrage directement sur le serveur AAA. Le filtre doit inclure un terme pour faire correspondre l’adresse IP de destination du serveur CWA avec l’action autorisée.
Par exemple :
001122334455 Auth-Type := EAP, Cleartext-Password :="001122334455" Session-Timeout = "300", Juniper-CWA-Redirect-URL = "https://10.10.10.10", Juniper-Switching-Filter = "Match Destination-ip 10.10.10.10 Action allow, Match ip-protocol 17 Action allow, Match Destination-mac 00:01:02:33:44:55 Action deny"
Pour l’URL de redirection, le commutateur ne résout pas les requêtes DNS. Pour activer l’adresse IP de destination du serveur CWA, vous devez configurer la propriété Juniper-Switching-Filter.
Paire Juniper-AV :
L’attribut Juniper-AV-Pair est un attribut spécifique au fournisseur (VSA) de Juniper Networks. Afin de fournir de nombreuses fonctionnalités importantes requises pour la gestion des abonnés et la prise en charge des services, il est utilisé pour améliorer les capacités du serveur RADIUS au-delà de celles offertes par les attributs standard publics.
i) Port-Bounce :
Avec la commande CoA bounce host port, une session est terminée et le port est rejeté (lance un événement de liaison inactive suivi d’un événement de liaison montante). La demande est envoyée par le serveur RADIUS dans un message CoA Request typique avec le VSA répertorié ci-dessous :
Juniper-AV-Pair = "Port-Bounce".
Cette commande nécessite un ou plusieurs des attributs d’identification de session répertoriés dans la section « Identification de session », car elle est orientée session. L’appareil envoie un message CoA-NAK avec l’attribut de code d’erreur « Contexte de session introuvable » si la session est introuvable.
L’appareil ferme le port d’hébergement pendant 4 secondes, le réactive (rebond de port), puis renvoie un CoA-ACK si la session a été localisée.
ii) Liaison de session Ip-Mac :
Ceci est utilisé pour arrêter la session d’authentification de cet appareil d’être interrompue lorsque l’adresse MAC d’un appareil vieillit et doit être réapprise. Nous recevons cet attribut-valeur d’une paire AV Juniper VSA sur un message de demande d’accès-acceptation ou de COA.
Configurez le serveur RADIUS avec les deux paires attribut-valeur suivantes afin de maintenir la session d’authentification basée sur les liaisons IP-adresse MAC.
Juniper-AV-Pair = "IP-Mac-Session-Binding Juniper-AV-Pair = "No-Mac-Binding-Reauth"
iii) Pas de liaison Mac :
Ceci est utilisé pour bloquer la réauthentification du client et arrêter la session d’authentification lorsque l’adresse MAC d’un appareil devient obsolète. Cette valeur de propriété nous est envoyée par une paire d’antivirus VSA Juniper lors d’un message de demande d’accès-acceptation ou de COA.
Juniper-AV-Pair = "No-Mac-Binding-Reauth" Detailed information is provided in the document: Retain the Authentication Session Using IP-MAC Bindings
iv) Mode demandeur unique :
The device switches from the current set mode to single in response to receiving this attribute-value from a VSA Juniper-AV-Pair on an access-accept or COA request message.Juniper-AV-Pair = "Supplicant-Mode-Single"
v) Mode Supplicant-Single-Secure :
L’équipement passe du mode de définition actuel à la sécurité unique lorsqu’il reçoit cette valeur d’attribut d’une paire AV-VSA Juniper sur un message de demande d’accès-acceptation ou de COA.
Juniper-AV-Pair = "Supplicant-Mode-Single-Secure"
vi) Conserver-Mac-Aged-Session :
If this attribute-value is received from a VSA Juniper-AV-Pair on an access-accept message for an 802.11X client, the client stays active even if the mac has aged out, and the mac is re-learned.Juniper-AV-Pair = "Retain-Mac-Aged-Session"
MS-MPPE-Send-Key et MS-MPPE-Recv-Key :
These are the MACSEC CAK generation keys together with the EAP key name that are utilised in dynamic CAK scenarios.Cisco-AVPair :
Cisco Systems, IANA private enterprise number 9, uses a single VSA, Cisco-AVPair (26-1). Based on the values it has, this VSA transmits various pieces of information. In some subscriber access networks with a BNG connected to a RADIUS server and a Cisco BroadHop application that serves as the Policy Control and Charging Rules Function (PCRF) server for provisioning services using RADIUS change of authorization (CoA) messages, you can use this VSA in RADIUS messages to activate and deactivate services.Lorsque le BNG délivre des messages RADIUS, vous ne pouvez modifier aucune des propriétés des réponses de comptabilité, de CoA ou d’authentification.
i) Cisco-AVPair = « subscriber :command=bounce-host-port »
Une session est terminée et le port est renvoyé via la commande CoA bounce host port (déclenche un événement de liaison inactive suivi d’un événement de liaison montante). La demande est envoyée par le serveur AAA dans un message CoA Request typique avec le VSA répertorié ci-dessous.
Cisco:Avpair=“subscriber:command=bounce-host-port”
Cette commande nécessite un ou plusieurs des attributs d’identification de session répertoriés dans la section « Identification de session », car elle est orientée session. L’appareil envoie un message CoA-NAK avec l’attribut de code d’erreur « Contexte de session introuvable » si la session est introuvable. L’appareil ferme le port d’hébergement pendant 4 secondes, le réactive (rebond de port), puis renvoie un CoA-ACK si la session a été localisée.
ii) Commande de réauthentification Cisco-AVPair
Pour lancer l’authentification de session, le serveur AAA envoie un message CoA-Request standard contenant les VSA suivants :
Cisco:Avpair=“subscriber:command=reauthenticate” Cisco:Avpair=“subscriber:reauthenticate-type=<last | rerun>”
reauthenticate-type
définit si la demande de réauthentification CoA utilise la dernière méthode d’authentification qui a réussi sur la session ou si le processus d’authentification est complètement réexécuté.
"subscriber:command=reauthenticate"
doit être présent pour provoquer une réauthentification. L’action par défaut consiste à répéter la méthode d’authentification précédente utilisée pour la session si « subscriber :reauthenticate-type » n’est pas fourni. Si la méthode s’authentifie à nouveau, toutes les données d’autorisation précédentes sont remplacées par les données d’autorisation nouvellement authentifiées.
Ce n’est que lorsque « subscriber :command=reauthenticate » est également présent que « subscriber :reauthenticate-type » est valide. Le VSA n’est pas pris en compte s’il est contenu dans une autre commande CoA.
Tableau de l'historique des modifications
La prise en charge des fonctionnalités est déterminée par la plateforme et la version que vous utilisez. Utilisez l' Feature Explorer pour déterminer si une fonctionnalité est prise en charge sur votre plateforme.