Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
Sur cette page
 

Authentification 802.1X

La norme IEEE 802.1X pour le contrôle d’accès réseau basé sur les ports et protège les LAN Ethernet contre les accès non autorisés des utilisateurs. Il bloque tout le trafic vers et depuis un demandeur (client) au niveau de 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 commutateur arrête de bloquer l’accès et ouvre l’interface au demandeur. Lisez ce sujet pour plus d’informations.

Présentation du 802.1X pour commutateurs

Fonctionnement de l’authentification 802.1X

L’authentification 802.1X fonctionne en utilisant une entité d’accès au port d’authentificateur (le commutateur) pour bloquer le trafic entrant d’un demandeur (équipement 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.

L’équipement final est authentifié en single supplicant mode, single-secure supplicant mode ou multiple supplicant mode :

  • un seul demandeur : n’authentifie que l’équipement de première extrémité. Tous les autres équipements finaux qui se connectent ultérieurement au port bénéficient d’un accès complet sans aucune authentification supplémentaire. Ils s’articulent efficacement sur l’authentification du premier équipement final.

  • un seul demandeur sécurisé : permet de connecter un seul équipement d’extrémité au port. Aucun autre équipement final n’est autorisé à se connecter tant que le premier équipement ne se déconnecte pas.

  • multiple demandeur : permet de connecter plusieurs terminaux au port. Chaque équipement final est authentifié individuellement.

L’accès réseau peut être défini en outre à l’aide de VLAN et de filtres de pare-feu, qui agissent tous deux comme filtres pour séparer et faire correspondre des groupes d’équipements finaux aux zones du LAN dont ils ont besoin. Par exemple, vous pouvez configurer les VLAN pour gérer différentes catégories d’échecs d’authentification selon :

Présentation des fonctionnalités 802.1X

Les fonctionnalités 802.1X suivantes sont prises en charge sur les commutateurs Ethernet Juniper Networks :

  • VLAN invité : fournit un accès limité à un LAN, généralement uniquement à Internet, pour les équipements finaux non répondants qui ne sont pas compatibles 802.1X lorsque l’authentification MAC RADIUS n’est pas configurée sur les interfaces du 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é fournit un accès uniquement à Internet et aux équipements finaux des autres invités.

  • VLAN de rejet du serveur : fournit un accès limité à un LAN, généralement uniquement à Internet, pour les équipements finaux réactifs compatibles 802.1X mais qui ont envoyé les informations d’identification erronées. Si l’équipement final authentifié à l’aide du VLAN de rejet du serveur est un téléphone IP, le trafic vocal n’est pas autorisé.

  • VLAN avec défaillance du serveur : fournit un accès limité à un LAN, généralement uniquement à Internet, pour les terminaux 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. L’implémentation 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 équipement compatible 802.1X est connecté à son port de données, cet équipement est authentifié, et le trafic VoIP peut alors circuler vers et depuis le téléphone (à condition que l’interface soit configurée en mode demandeur unique et non en mode demandeur unique sécurisé).

    REMARQUE :

    La configuration d’un VLAN VoIP sur des interfaces VLAN privées (PVLAN) n’est pas prise en charge.

  • Comptabilité RADIUS : envoie des informations de comptabilité au serveur de comptabilité RADIUS. Les informations de comptabilité 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 de serveur RADIUS pour 802.1X : Juniper-Switching-Filter il s’agit d’un attribut spécifique au fournisseur (VSA) qui peut être configuré sur le serveur RADIUS pour définir davantage l’accès d’un demandeur pendant le processus d’authentification 802.1X. La configuration centralisée des attributs sur le serveur d’authentification élimine le besoin de configurer ces mêmes attributs sous la forme de filtres de pare-feu sur chaque commutateur du LAN auquel le demandeur peut se connecter au LAN. Cette fonctionnalité est basée sur RLI 4583, AAA RADIUS BRAS VSA Support.

Les fonctionnalités suivantes sont prises en charge pour authentifier les équipements qui ne sont pas compatibles avec 802.1X :

  • Contournement MAC statique : fournit un mécanisme de contournement permettant d’authentifier les équipements qui ne sont pas compatibles avec la version 802.1X (comme les imprimantes). Le contournement MAC statique connecte ces équipements aux ports compatibles 802.1X, contournant ainsi l’authentification 802.1X.

  • Authentification MAC RADIUS : permet aux hôtes qui ne sont pas compatibles 802.1X d’accéder au LAN. MAC-RADIUS simule la fonctionnalité requise de l’équipement client, en utilisant l’adresse MAC du client comme nom d’utilisateur et mot de passe.

Authentification 802.1X sur les ports de tronc

À partir de la version 18.3R1 de Junos OS, vous pouvez configurer l’authentification 802.1X sur les interfaces de tronc, ce qui permet à l’équipement d’accès réseau (NAS) d’authentifier un point d’accès (AP) ou un autre équipement 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 central. L’activation de l’authentification 802.1X sur l’interface de tronc protège le NAS contre une faille de sécurité dans laquelle un attaquant peut déconnecter le point d’accès 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 de tronc.

  • Seuls les modes de requêtes uniques et sécurisés sont pris en charge sur les interfaces de tronc.

  • Vous devez configurer l’authentification 802.1X localement sur l’interface de tronc. Si vous configurez l’authentification 802.1X globalement à l’aide de la set protocol dot1x interface all commande, la configuration n’est pas appliquée à l’interface de tronc.

  • Les VLAN dynamiques ne sont pas pris en charge sur les interfaces de tronc.

  • Le VLAN invité et le VLAN de rejet de serveur ne sont pas pris en charge sur les interfaces de tronc.

  • Les clients VoIP ne sont pas pris en charge sur les interfaces de tronc (server-fail-voip).

  • L’authentification sur port de tronc n’est pas prise en charge par le portail captif.

  • L’authentification sur port de tronc 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 la version 20.2R1 de Junos OS, 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 des 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 set protocol dot1x interface all commande, la configuration n’est pas appliquée aux interfaces de couche 3.

  • La prise en charge des interfaces de couche 3 n’inclut ni IRB ni sous-interfaces.

  • Le VLAN invité, le VLAN de rejet du serveur et le VLAN défaillant par serveur ne sont pas pris en charge.

  • Les clients VoIP ne sont pas pris en charge (server-fail-voip).

  • Seuls les attributs suivants sont acceptés du serveur d’authentification dans le cadre des messages d’acceptation d’accès RADIUS ou coA pour les clients authentifiés sur des interfaces de couche 3 :

    • Nom d’utilisateur

    • Délai d’expiration des sessions

    • Id de station d’appel

    • Acct-Session-ID

    • ID de port NAS

    • Port-Bounce

Authentification 802.1X sur les interfaces de couche 2

À partir de la version 22.3R1 de Junos OS Evolved, vous pouvez configurer l’authentification 802.1X sur les interfaces de couche 2. Suivez les mises en garde pour l’authentification 802.1X sur les interfaces de couche 2.

  • Fonctionnalités non prises en charge :

    • VLAN invité, VLAN de rejet de serveur et VLAN à échec serveur

    • Serveur de secours pour les clients VoIP (serveur-fail-voip)

    • VLAN dynamique

    • Authentification sur des interfaces de couche 2 à l’aide d’un portail captif et d’une authentification Web centrale (CWA).

  • Les attributs non pris en charge par le serveur d’authentification des messages d’acceptation d’accès RADIUS ou coA pour les clients authentifiés sur des interfaces de couche 2 sont les suivants :

    • Liaison session Ip-Mac

    • Redirection vers Juniper-CWA

    • Filtre de commutation Juniper

    • Id de filtre

    • Tunnel de type moyen

    • Juniper-VoIP-VLAN

    • Nom sortant-VLAN

    • ID sortant

    • Type de tunnel

    • Tunnel-Private-Group-Id

  • Si l’IRB est dans le domaine du pont, les ports compatibles 802.1x n’abandonnent pas le trafic routé pour un seul mode sécurisé et plusieurs modes demandeurs, même si l’utilisateur n’est pas authentifié. Ports compatibles 802.1x sur le trafic routé de l’interface de couche 2 uniquement pour une configuration en mode demandeur unique.

Configuration de plusieurs ports source et de destination sur une seule ligne

À partir de La version 22.4R1 de Junos OS Evolved, vous pouvez configurer plusieurs ports source et de destination (ou plages de ports) au sein d’une seule ligne sans avoir à répéter la condition de correspondance. Cette fonctionnalité permet de raccourcir les longueurs 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’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

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 LAN Ethernet contre les accès non autorisés des utilisateurs en bloquant tout le trafic vers et en provenance d’un demandeur (client) au niveau de l’interface jusqu’à ce que les informations d’identification du demandeur soient présentées et appariées sur le authentication server (un serveur RADIUS). Lorsque le demandeur est authentifié, le commutateur arrête de bloquer l’accès et ouvre l’interface au demandeur.

REMARQUE :

Avant de commencer, spécifiez le ou les serveurs RADIUS à utiliser comme serveur d’authentification. Voir Spécification des connexions serveur RADIUS sur les commutateurs (procédure CLI).

Pour configurer 802.1X sur une interface :

  1. Configurez le mode demandeur comme single (authentifie le premier demandeur), single-secure (authentifie un seul demandeur) ou multiple (authentifie plusieurs demandeurs) :
    REMARQUE :

    Le mode multi-demandeur n’est pas pris en charge sur les interfaces de tronc.

  2. Activez la réauthentification et spécifiez l’intervalle de réauthentification :
  3. Configurez la valeur de délai d’expiration de l’interface pour la réponse du demandeur :
  4. Configurez le délai d’expiration de l’interface avant qu’elle renvoie une demande d’authentification au serveur RADIUS :
  5. Configurez la durée d’attente de l’interface en quelques secondes avant de retransmettre les PDU initiaux d’EAPOL au demandeur :
  6. Configurez le nombre maximal de fois qu’un paquet de requête EAPOL est retransmis au demandeur avant que la session d’authentification n’arrive à s’arrêter :
  7. Configurez le nombre de tentatives d’authentification du port par le commutateur après une défaillance initiale. Le port reste en état d’attente pendant la période calme après la tentative d’authentification.
REMARQUE :

Si les serveurs d’authentification RADIUS deviennent indisponibles ou inaccessibles, le retour à échec du serveur est déclenché. Par défaut, l’option deny est configurée sous server-fail, ce qui force l’authentification du demandeur. Cependant, il existe d’autres options que vous pouvez configurer en tant qu’actions à entreprendre pour les équipements finaux en attente d’authentification lorsque le serveur arrive à expiration.

Pour plus d’informations, voir interface (802.1X)
REMARQUE :

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 par RADIUS à une session d’utilisateur autorisée

Lorsque vous utilisez un service d’authentification basé sur un modèle RADIUS client/serveur, les requêtes sont généralement lancées par le client et envoyées au serveur RADIUS. Dans certains cas, une demande peut être lancée par le serveur et envoyée au client afin de modifier dynamiquement une session d’utilisateur authentifiée déjà en cours. Le client qui reçoit et traite les messages est le commutateur, qui agit comme serveur d’accès réseau, ou NAS. Le serveur peut envoyer au commutateur un message de déconnexion demandant de mettre fin à une session, ou un message de modification d’autorisation (CoA) 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 n’accepte que les demandes provenant d’une source fiable. L’autorisation d’envoyer une demande de déconnexion ou de CoA est déterminée en fonction de l’adresse source et du secret partagé correspondant, qui doit être configuré 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 l’exemple : Connexion d’un serveur RADIUS pour 802.1X à un commutateur EX Series.

Messages de déconnexion

Le serveur RADIUS envoie un message de déconnexion-demande au commutateur afin de mettre fin à une session utilisateur et de supprimer 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 rejeté et que la session utilisateur n’est plus connectée, ou avec un paquet Disconnect-NAK si la demande échoue, c’est-à-dire que l’authentificateur n’est pas en mesure de déconnecter la session et de supprimer tout le contexte de session associé.

Dans les messages de déconnexion-demande, 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 inclus dans le message doit correspondre à au moins une session pour que la demande soit réussie ; dans le cas contraire, le commutateur répond par un message Disconnect-NAK. Un message de demande de déconnexion ne peut contenir que des attributs NAS et d’identification de session ; si d’autres attributs sont inclus, le commutateur répond par un message Disconnect-NAK.

Messages de changement d’autorisation

Les messages de modification d’autorisation (CoA) contiennent des informations permettant de modifier dynamiquement les attributs d’autorisation d’une session utilisateur afin de modifier le niveau d’autorisation. Cela se produit dans le cadre d’un processus d’authentification en deux étapes, au cours duquel le point de terminaison est d’abord authentifié à l’aide de l’authentification MAC RADIUS, puis est profilé en fonction du type d’équipement. Le message CoA est utilisé pour appliquer une stratégie d’application adaptée à l’équipement, 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 d’autorisation est réussie, ou avec un message CoA-NAK si la modification est infructueuse. 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. La combinaison des attributs d’identification NAS et des attributs d’identification de session inclus dans le message doit correspondre aux attributs d’identification d’au moins une session pour que la demande soit réussie . dans le cas contraire, le commutateur répond par un message CoA-NAK.

Les paquets CoA-Request comprennent é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 reste inchangée.

  • ID de filtre

  • Tunnel-Private-Group-ID

  • Filtre de commutation Juniper

  • Juniper-VoIP-VLAN

  • Délai d’expiration des sessions

Rebond de port de demande CoA

Lorsqu’un message CoA est utilisé pour modifier le VLAN pour un hôte authentifié, les équipements finaux tels que les imprimantes ne disposent pas d’un mécanisme permettant de détecter la modification du VLAN, de sorte qu’ils ne renouvellent pas le bail de leur adresse DHCP dans le nouveau VLAN. À partir de la version 17.3 de Junos OS, la fonctionnalité de rebond de port peut être utilisée pour forcer l’équipement final à engager une renégociation DHCP en provoquant un rabat de liaison sur le port authentifié.

La commande de rebondissement du port est envoyée depuis le serveur RADIUS à l’aide d’un attribut VSA (fournisseur spécifique à Juniper Networks). Le port est rebondis si la paire attribut/valeur VSA suivante est reçue dans le message CoA du serveur RADIUS :

  • Paire Av Juniper = « Port-Bounce »

Pour activer la fonctionnalité de rebond de port, vous devez mettre à jour le fichier du dictionnaire Junos (juniper.dct) sur le serveur RADIUS avec le VSA Juniper-AV-Pair. Localisez le fichier du dictionnaire et ajoutez le texte suivant au fichier :

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 hiérarchique [edit protocols dot1x authenticator interface interface-name]

Codes de cause d’erreur

En cas d’échec d’une déconnexion ou d’une opération coA, un attribut Cause d’erreur (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 n’est pas mappée à l’une des valeurs d’attribut Error-Cause prises en charge, le routeur envoie le message sans attribut cause d’erreur. Consultez Tableau 1 les descriptions des codes de cause d’erreur pouvant être inclus dans les messages de réponse envoyés par le NAS.

Tableau 1 : Codes de cause d’erreur (attribut RADIUS 101)

Code

Valeur

Description

201

Suppression du contexte de session résiduel

Envoyé en réponse à un message de déconnexion-demande si une ou plusieurs sessions utilisateur ne sont plus actives, mais que le contexte de session résiduel a été détecté et supprimé avec succès. Ce code est envoyé uniquement 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

Il manque un attribut critique (par exemple, l’attribut d’identification de session) dans une demande.

403

Incompatibilité d’identification DU 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 demande 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 (un NAS ou un proxy RADIUS) ne prend pas en charge les requêtes lancé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

Administrativement interdit

Le NAS est configuré de manière à interdire le respect des messages De déconnexion-Request ou CoA-Request 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 les attributs de la demande appartient à un composant qui n’est pas pris en charge. Ce code n’est envoyé que dans un message Disconnect-NAK.

506

Ressources indisponibles

Une demande n’a pas pu être honorée en raison du manque de ressources NAS disponibles (telles que la mémoire).

507

Demande lancé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 requête 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-Commutation-Filter. L’attribut Juniper-Switching-Filter est un attribut spécifique au fournisseur (VSA) répertorié sous l’ID d’attribut numéro 48 dans le dictionnaire Juniper sur le serveur RADIUS. Utilisez ce VSA pour configurer des conditions de filtre simples pour les utilisateurs authentifiés 802.1X. Rien n’est à configurer sur le commutateur; toute la configuration est sur le serveur RADIUS.

  • Configurez un filtre de pare-feu local sur chaque commutateur et appliquez ce filtre de pare-feu 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 l’authentification des utilisateurs à l’aide de l’authentification 802.1X, la session d’authentification 802.1X établie doit être terminée et rétablie pour que les modifications de 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

Vous pouvez configurer des conditions de filtre simples à l’aide de l’attribut Juniper-Commutation-Filtre dans le dictionnaire Juniper sur le serveur RADIUS. Ces filtres sont envoyés à un commutateur chaque fois qu’un nouvel utilisateur est authentifié avec succès. Les filtres sont créés et appliqués sur tous les commutateurs EX Series qui authentifient les utilisateurs via ce serveur RADIUS sans avoir à configurer quoi que ce soit sur chaque commutateur individuel.

REMARQUE :

Cette procédure décrit l’utilisation du logiciel FreeRADIUS pour configurer le VSA de commutation Juniper. Pour plus d’informations sur la configuration de votre serveur, consultez la documentation AAA fournie avec votre serveur.

Pour configurer l’attribut Juniper-Commutation-Filter, saisissez un ou plusieurs termes de filtre à l’aide de l’interface CLI du serveur RADIUS. Chaque terme de filtre est constitué de conditions de correspondance avec une action correspondante. Saisissez les termes du filtre entre guillemets (« ») à l’aide de la syntaxe suivante :

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 du filtre. Par exemple, le terme de filtre suivant nécessite qu’un paquet corresponde à la fois à l’adresse IP de destination et à l’adresse MAC de destination pour répondre aux critères de terme :

Plusieurs termes de filtre doivent être séparés par des virgules, par exemple :

Consultez les conditions et actions vsA du filtre de commutation Juniper pour obtenir les définitions des conditions et des actions de correspondance.

REMARQUE :

Sur les commutateurs EX9200 et dans un Junos Fusion Enterprise avec EX9200 comme équipement d’agrégation, 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 en tant qu’ADRESSE IP de destination seront supprimés selon les règles de filtre. Cela inclut tous les paquets de protocole IP, tels que les paquets DHCP, IGMP et ARP.

Pour configurer des conditions de correspondance sur le serveur RADIUS :

  1. Vérifiez que le dictionnaire Juniper est chargé sur votre serveur RADIUS et qu’il inclut l’attribut Juniper-Switching-Filter de filtrage (ID d’attribut 48) :
  2. Saisissez les conditions et les actions des correspondances. Par exemple :

    • Pour refuser l’authentification basée sur la balise 802.1Q (ici, la balise 802.1Q est 10) :

      Pour chaque utilisateur concerné, ajoutez l’attribut Juniper-Switching-Filter :

    • Pour refuser l’accès en fonction d’une adresse IP de destination :

      Pour chaque utilisateur concerné, ajoutez l’attribut Juniper-Switching-Filter :

    • Pour définir la priorité de perte de paquets (PLP) en fonction d’une high adresse MAC de destination et du protocole IP :

      Pour chaque utilisateur concerné, ajoutez l’attribut Juniper-Switching-Filter :

      REMARQUE :

      Pour que l’option forwarding-class soit appliquée, la classe de transfert doit être configurée sur le commutateur et la priorité de perte de paquet spécifiée. Si elle n’est pas configurée sur le commutateur, cette option est ignorée. Vous devez spécifier à la fois la classe de transfert et la priorité de perte de paquets.

  3. Arrêtez et redémarrez le processus RADIUS pour activer la configuration.

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 qui doivent être appliqués à chaque utilisateur qui demande l’authentification, réduisant ainsi le besoin 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 différentes conditions 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, consultez La 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 depuis le serveur RADIUS :

REMARQUE :

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 ont priorité 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.

  1. Créez le filtre de pare-feu sur le commutateur local. Voir Configuration des filtres de pare-feu (procédure CLI) pour plus d’informations sur la configuration d’un filtre de pare-feu de port.
  2. Sur le serveur RADIUS, ouvrez le users fichier pour afficher les profils d’utilisateurs locaux des équipements finaux auxquels vous souhaitez appliquer le filtre :

  3. Appliquez le filtre à chaque profil utilisateur en ajoutant l’attribut Filter-ID avec le nom du filtre comme valeur d’attribut :

    Par exemple, le profil d’utilisateur ci-dessous supplicant1 inclut l’attribut Filter-ID avec le nom filter1du filtre :

    REMARQUE :

    Les filtres multiples ne sont pas pris en charge sur une interface unique. Toutefois, vous pouvez prendre en charge plusieurs filtres pour plusieurs utilisateurs connectés au commutateur sur la même interface en configurant un seul filtre avec des stratégies pour chacun de ces utilisateurs.

  4. Arrêtez et redémarrez le processus RADIUS pour activer la configuration.

Voir également

Exemple : Connexion d’un serveur RADIUS pour 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). Vous utilisez 802.1X pour contrôler l’accès au réseau. Seuls les utilisateurs et les équipements fournissant des informations d’identification vérifiées par rapport à une base de données d’utilisateurs peuvent 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 RADIUS MAC.

Cet exemple explique 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 agissant comme une entité d’accès aux ports d’authentificateur (PAE). Les ports de l’authentificateur PAE forment une porte de contrôle qui bloque tout le trafic vers et depuis les demandeurs jusqu’à ce qu’ils soient authentifiés.

  • Un serveur d’authentification RADIUS prenant en charge 802.1X. Le serveur d’authentification fait office de base de données back-end et contient des informations d’identification pour les hôtes (demandeurs) qui ont l’autorisation de se connecter au réseau.

Avant de connecter le serveur au commutateur, assurez-vous d’avoir :

Présentation et topologie

Le commutateur EX Series agit comme un authentificateur PAE. Il bloque tout le trafic et agit comme une porte de contrôle jusqu’à ce que le demandeur (client) soit authentifié par le serveur. Tous les autres utilisateurs et équipements se voient refuser l’accès.

Figure 1 affiche un commutateur EX4200 connecté aux équipements répertoriés dans Tableau 2.

Figure 1 : Topologie de configurationTopologie de configuration
Tableau 2 : Composants de la topologie
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 seul serveur RADIUS

Base de données back-end avec une adresse 10.0.0.100 connectée au commutateur au niveau du 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 comme l’authentificateur et transfère les informations d’identification du demandeur à la base de données utilisateur 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.

REMARQUE :

Pour plus d’informations sur les services d’authentification, d’autorisation et de comptabilité (AAA), consultez le Guide de configuration de base du système Junos OS.

Configuration

Procédure

Configuration rapide cli

Pour connecter rapidement le serveur RADIUS au commutateur, copiez les commandes suivantes et collez-les dans la fenêtre du terminal du commutateur :

Procédure étape par étape

Pour connecter le serveur RADIUS au commutateur :

  1. Définissez l’adresse des serveurs et configurez le mot de passe secret. Le mot de passe secret du commutateur doit correspondre au mot de passe secret du serveur :

  2. Configurez l’ordre d’authentification en faisant radius la première méthode d’authentification :

  3. Configurez une liste d’adresses IP de serveur à essayer par ordre séquentiel pour authentifier le demandeur :

Résultats

Affichez les résultats de la configuration :

Vérification

Pour vérifier que la configuration fonctionne correctement, effectuez les tâches 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

Ping au serveur RADIUS pour vérifier la connexion entre le commutateur et le serveur :

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 pour vérifier que le commutateur et le serveur sont connectés.

Voir également

Comprendre les 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 l’authentification via ce serveur. Les attributs du serveur RADIUS sont des champs en texte clair encapsulés dans les messages Access-Accept envoyés du 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. Des filtres dynamiques peuvent être appliqués à plusieurs ports du même commutateur ou à plusieurs commutateurs qui utilisent le même serveur d’authentification, ce qui permet un contrôle d’accès centralisé pour le réseau.

Vous pouvez définir des filtres de pare-feu directement sur le serveur RADIUS à l’aide de l’attribut Juniper-Commutation-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, Service RADIUS (Remote Authentication Dial in User Service ). Le VSA de Juniper-Switching-Filter est répertorié sous l’ID d’attribut numéro 48 dans le dictionnaire Juniper sur le serveur RADIUS, l’ID du fournisseur étant défini sur l’ID Juniper Networks numéro 2636. À l’aide de cet attribut, vous définissez des filtres sur le serveur d’authentification, qui sont appliqués sur 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 du commutateur qui a été authentifié pour le demandeur. Utilisez cette méthode lorsque le filtre de pare-feu présente des conditions complexes, ou si vous souhaitez utiliser différentes conditions 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 ne sont pris en charge que pour les configurations 802.1X mono-demandeur et les configurations multiples.

Voir également

Comprendre l’attribution dynamique de VLAN à l’aide des attributs RADIUS

Les VLAN peuvent être assignés dynamiquement par un serveur RADIUS aux demandeurs qui demandent l’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 du 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. Selon les résultats de l’authentification, un demandeur qui a commencé l’authentification dans un VLAN peut être assigné à un autre VLAN.

Une authentification réussie nécessite que l’ID VLAN ou le nom du VLAN soit configuré sur le commutateur agissant comme authentificateur 802.1X et qu’il corresponde à l’ID VLAN ou au nom VLAN envoyé par le serveur RADIUS lors de l’authentification. Si aucun des deux n’existe, l’équipement final n’est pas authentifié. Si un VLAN invité est établi, l’équipement final 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 du protocole Tunnel.

  • Tunnel-Type : défini comme attribut RADIUS de type 64. La valeur doit être définie sur VLAN.

  • Tunnel-Medium-Type : défini comme l’attribut RADIUS de type 65. La valeur doit être définie sur IEEE-802.

  • Tunnel-Private-Group-ID : défini comme attribut RADIUS de type 81. La valeur doit être définie sur l’ID VLAN ou le nom du VLAN.

Pour plus d’informations sur la configuration de VLAN dynamiques sur votre serveur RADIUS, consultez la documentation de votre serveur RADIUS.

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 offrir un accès limité aux invités de l’entreprise , généralement uniquement à Internet. Le VLAN invité sert de secours lorsque :

  • 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 du commutateur auxquelles le demandeur est connecté.

  • Le portail captif n’a pas été configuré sur les interfaces de commutation 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 équipements finaux qui ne sont pas compatibles avec la norme 802.1X, un VLAN invité peut autoriser un accès limité à un serveur à partir duquel l’équipement final non compatible 802.1X peut télécharger le logiciel demandeur et tenter de nouveau l’authentification.

Voir également

Exemple : Configuration des options d’authentification 802.1X lorsque le serveur RADIUS n’est pas disponible sur un commutateur EX Series

Le basculement de défaillance du serveur vous permet de spécifier comment les demandeurs 802.1X connectés au commutateur sont pris en charge si le serveur d’authentification RADIUS devient indisponible.

Vous utilisez 802.1X pour contrôler l’accès au réseau. Seuls les utilisateurs et les équipements (demandeurs) fournissant des informations d’identification vérifiées par rapport à une base de données d’utilisateurs peuvent accéder au réseau. Vous utilisez un serveur RADIUS comme base de données utilisateur.

Cet exemple décrit comment configurer une interface pour déplacer un demandeur vers un VLAN en cas de délai d’expiration du serveur RADIUS :

Conditions préalables

Cet exemple utilise les composants logiciels et matériels suivants :

REMARQUE :

Cet exemple s’applique également aux commutateurs QFX5100.

  • Junos OS version 9.3 ou ultérieure pour les commutateurs EX Series

  • Un commutateur EX Series agissant comme une entité d’accès aux ports d’authentificateur (PAE). Les ports de l’authentificateur PAE forment une porte de contrôle qui bloque tout le trafic vers et depuis les demandeurs jusqu’à ce qu’ils soient authentifiés.

  • Un serveur d’authentification RADIUS prenant en charge 802.1X. Le serveur d’authentification fait office de base de données back-end et contient des informations d’identification pour les hôtes (demandeurs) qui ont l’autorisation de se connecter au réseau.

Avant de connecter le serveur au commutateur, assurez-vous d’avoir :

Présentation et topologie

Un délai d’expiration du serveur RADIUS se produit si aucun serveur RADIUS d’authentification n’est accessible lorsqu’un demandeur se connecte et tente d’accéder au LAN. À l’aide de la solution de secours par échec du serveur, vous configurez d’autres options pour les demandeurs qui tentent d’accéder au LAN. Vous pouvez configurer le commutateur pour accepter ou refuser l’accès aux demandeurs ou pour maintenir l’accès déjà accordé aux demandeurs avant le délai d’expiration du serveur RADIUS. En outre, vous pouvez configurer le commutateur pour déplacer les demandeurs vers un VLAN spécifique si un délai RADIUS survient.

Figure 2 montre la topologie utilisée pour cet exemple. Le serveur RADIUS est connecté au commutateur EX4200 sur le port d’accès ge-0/0/10. Le commutateur agit comme l’entité d’accès de port d’authentificateur (PAE) et transfère les informations d’identification du demandeur à la base de données des utilisateurs sur le serveur RADIUS. Le commutateur bloque tout le trafic et agit comme une porte de contrôle jusqu’à ce que le demandeur soit authentifié par le serveur d’authentification. Un demandeur est connecté au commutateur via l’interface ge-0/0/1.

REMARQUE :

Ce chiffre s’applique également aux commutateurs QFX5100.

Figure 2 : Topologie pour la configuration des options 802.1XTopologie pour la configuration des options 802.1X

Tableau 3 décrit les composants de cette topologie.

Tableau 3 : Composants de la topologie
Propriété Paramètres

Matériel de commutation

Commutateur d’accès EX4200, 24 ports Gigabit Ethernet : 16 ports non PoE et 8 ports PoE.

Noms VLAN

default VLAN

vlan-sf VLAN

Supplicant

Tentative d’accès du demandeur sur l’interface ge-0/0/1

Un seul serveur RADIUS

Base de données back-end avec une adresse 10.0.0.100 connectée au commutateur au niveau du port ge-0/0/10

Dans cet exemple, configurez l’interface ge-0/0/1 pour déplacer un demandeur qui tente d’accéder au LAN pendant un délai RADIUS vers un autre VLAN. Un délai RADIUS empêche l’échange normal de messages EAP qui transportent des informations du serveur RADIUS vers le commutateur et permettent l’authentification d’un demandeur. Le VLAN par défaut est configuré sur l’interface ge-0/0/1. Lorsqu’un délai RADIUS se produit, les demandeurs sur l’interface sont déplacés du VLAN par défaut vers le VLAN nommé vlan-sf.

topologie

Configuration

Procédure

Configuration rapide cli

Pour configurer rapidement la secours d’échec du serveur sur le commutateur, copiez les commandes suivantes et collez-les dans la fenêtre du terminal du commutateur :

Procédure étape par étape

Pour configurer une interface de manière à détourner les demandeurs vers un VLAN spécifique lorsqu’un délai RADIUS survient (ici, le VLAN est vlan-sf) :

  1. Définissez le VLAN vers lequel les demandeurs sont déviés :

Résultats

Affichez les résultats de la configuration :

Vérification

Pour vérifier que la configuration fonctionne correctement, effectuez les tâches suivantes :

Vérifier que les demandeurs sont déplacés vers un autre VLAN pendant un délai RADIUS

But

Vérifiez que l’interface déplace les demandeurs vers un autre VLAN pendant un délai RADIUS.

REMARQUE :

Sur les commutateurs exécutant Junos OS pour EX Series avec prise en charge d’ELS, la sortie de la show vlans commande contient des informations supplémentaires. Si votre commutateur exécute un logiciel prenant en charge ELS, consultez afficher les vlans. Pour plus de détails sur ELS, voir Utilisation de l’interface cli logicielle de couche 2 améliorée

Action

Affichez les VLAN configurés sur le commutateur ; l’interface ge-0/0/1.0 est membre du default VLAN :

Affichez les informations du protocole 802.1X sur le commutateur pour afficher les demandeurs authentifiés sur l’interface ge-0/0/1.0:

Un délai d’expiration du serveur RADIUS se produit. Affichez le tableau de commutation Ethernet pour montrer que le demandeur avec l’adresse 00:00:00:00:00:01 MAC accédant précédemment au LAN via le default VLAN est maintenant appris sur le VLAN nommé vlan-sf:

Affichez les informations du protocole 802.1X pour montrer que l’interface ge-0/0/1.0 se connecte et ouvrira l’accès LAN aux demandeurs :

Sens

La show vlans commande affiche l’interface ge-0/0/1.0 en tant que membre du default VLAN. La show dot1x interface brief commande indique qu’un demandeur (abc) est authentifié sur l’interface ge-0/0/1.0 et possède l’adresse 00:00:00:00:00:01MAC . Un délai d’expiration du serveur RADIUS se produit et le serveur d’authentification ne peut pas être atteint par le commutateur. La show-ethernet-switching table commande indique que l’adresse 00:00:00:00:00:01 MAC est apprise sur VLAN vlan-sf. Le demandeur a été déplacé du default VLAN vers le vlan-sf VLAN. Le demandeur est ensuite connecté au LAN via le VLAN nommé vlan-sf.

Voir également

Exemple : Configuration des options de repli sur les commutateurs EX Series pour l’authentification EAP-TTLS et les clients Odyssey Access

Pour l’authentification des utilisateurs 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 Odyssey Access Client (OAC). Le logiciel de mise en réseau OAC s’exécute sur les terminaux (ordinateurs de bureau, ordinateurs portables ou bloc-notes et équipements 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 afin de fournir une prise en charge de secours aux utilisateurs de L’OAC qui ont entré des informations d’identification incorrectes :

Conditions préalables

Cet exemple utilise les composants logiciels et matériels suivants :

REMARQUE :

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 agissant comme une entité d’accès aux ports d’authentificateur (PAE). Les ports de l’authentificateur PAE forment une porte de contrôle qui bloque tout le trafic vers et depuis les demandeurs jusqu’à ce qu’ils soient authentifiés.

  • Un serveur d’authentification RADIUS prenant en charge 802.1X. Le serveur d’authentification fait office de base de données back-end et contient des informations d’identification pour les hôtes (demandeurs) qui ont l’autorisation de se connecter au réseau.

  • Un équipement final OAC agissant en tant que demandeur.

Avant de commencer à configurer l’option de repli, assurez-vous que vous avez :

Présentation et topologie

L’OAC est un logiciel de mise en réseau qui s’exécute sur les terminaux (ordinateurs de bureau, ordinateurs portables ou bloc-notes) et les équipements sans fil pris en charge. OAC fournit une prise en charge complète de l’EAP, qui est nécessaire pour un accès LAN sans fil sécurisé.

Dans cette topologie, l’OAC est déployé avec un commutateur compatible 802.1X et un serveur RADIUS. Le commutateur fonctionne comme un point de contrôle dans l’architecture de sécurité du réseau. Cette topologie :

  • Garantit que seuls les utilisateurs autorisés peuvent se connecter.

  • Préserve la confidentialité des informations d’identification.

  • Maintient la confidentialité des données sur la liaison sans fil.

Cet exemple inclut la configuration d’un VLAN de refus de serveur sur le commutateur, qui peut être utilisé pour empêcher le verrouillage accidentelle des utilisateurs qui ont entré des informations d’identification incorrectes. Ces utilisateurs peuvent avoir un accès LAN limité.

Cependant, cette configuration de repli est compliquée par le fait que le demandeur d’OAC et le serveur RADIUS utilisent EAP-TTLS. EAP-TTLS crée un tunnel chiffré sécurisé entre le serveur et l’équipement final pour terminer le processus d’authentification. Lorsque l’utilisateur saisit des informations d’identification incorrectes, le serveur RADIUS envoie des messages de défaillance EAP directement au client via ce tunnel. Le message d’échec EAP provoque le client à redémarrer la procédure d’authentification, de sorte que le processus d’authentification 802.1X du commutateur retire la session qui a été établie avec le commutateur à l’aide du VLAN de rejet du serveur. Vous pouvez activer la connexion corrective pour continuer en configurant :

  • eapol-block: activez le timer de blocage EAPoL sur l’interface 802.1X configurée pour appartenir au VLAN de rejet du serveur. Le timer de blocage oblige l’entité d’accès au port d’authentification à ignorer les messages de départ EAP du client, tentant de redémarrer la procédure d’authentification.

    REMARQUE :

    Le compteur de blocage EAPoL n’est déclenché qu’une fois que le nombre configuré de réattempts autorisés (à l’aide de l’option retries ) sur l’interface 802.1X ont été épuisés. Vous pouvez configurer retries pour spécifier le nombre de fois que le commutateur tente d’authentifier le port après une défaillance initiale. La valeur par défaut est de trois tentatives.

  • block-interval— Configurez le temps que vous souhaitez que le bloqueur EAPoL continue d’ignorer les messages de départ EAP. Si vous ne configurez pas l’intervalle de blocage, le timer de blocage EAPoL est par défaut de 120 secondes.

Lorsque l’interface 802.1X ignore les messages de départ EAP du client, le commutateur permet à la session de correction existante établie via le VLAN de rejet du serveur de rester ouverte.

Ces options de configuration s’appliquent aux modes d’authentification uniques, sécurisés et multiples pour les demandeurs. Dans cet exemple, l’interface 802.1X est configurée en mode demandeur unique.

Figure 3 affiche un commutateur EX Series qui connecte un équipement de fin d’OAC à un serveur RADIUS, et indique les protocoles utilisés pour connecter les entités réseau.

REMARQUE :

Ce chiffre s’applique également aux commutateurs QFX5100.

Figure 3 : Commutateur EX Series connectant l’OAC au serveur RADIUS à l’aide de l’authentification EAP-TTLSCommutateur EX Series connectant l’OAC au serveur RADIUS à l’aide de l’authentification EAP-TTLS

topologie

Tableau 4 décrit les composants de ce déploiement d’OAC :.

Tableau 4 : Composants du déploiement de l’OAC
Propriété Paramètres

Matériel de commutation

commutateur EX Series compatible

VLAN

default

server-reject-vlan: Le nom du VLAN est remedial et l’ID VLAN est 700

Interface 802.1X

ge-0/0/8

Demandeur du CAE

EAP-TTLS

Un serveur d’authentification RADIUS

EAP-TTLS

Configuration

Procédure

Configuration rapide cli

Pour configurer rapidement les options de repli pour les demandeurs EAP-TTLS et OAC, copiez les commandes suivantes et collez-les dans la fenêtre du terminal du commutateur :

Procédure étape par étape

Pour configurer les options de repli pour les demandeurs EAP-TTLS et OAC :

Conseil :

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 ou l’ID VLAN directement après server-reject-vlan pour indiquer quel VLAN est en cours de modification.

  1. 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 informations d’identification incorrectes :

  2. Configurez le nombre de fois où le client doit être invité pour le nom d’utilisateur et le mot de passe avant qu’une connexion incorrecte ne soit dirigée vers le VLAN de rejet du serveur :

  3. Configurez l’interface de l’authentificateur 802.1X pour utiliser le VLAN de rejet du serveur comme solution de secours pour les connexions incorrectes :

  4. Activez le timer de blocage EAPoL sur l’interface 802.1X configurée pour appartenir au VLAN de rejet du serveur.

  5. Configurez le temps nécessaire pour que le bloc EAPoL reste en vigueur :

Résultats

Vérifiez les résultats de la configuration :

Vérification

Pour vérifier que la configuration et les options de repli fonctionnent correctement, effectuez cette tâche :

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
Sens

La show dot1x ge-0/0/8 detail sortie de commande indique que l’interface ge-0/0/8 est dans l’état Authenticated et qu’elle utilise le remedial VLAN.

Voir également

Surveillance de l’authentification 802.1X

But

REMARQUE :

Cette rubrique s’applique uniquement au package d’application J-Web.

Utilisez la fonctionnalité de surveillance pour afficher les détails des utilisateurs authentifiés et des utilisateurs qui ont échoué.

Action

Pour afficher les détails de l’authentification dans l’interface J-Web, sélectionnez Monitoring > Security > 802.1X.

Pour afficher les détails d’authentification dans la CLI, saisissez 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 :

  • Une liste d’utilisateurs authentifiés.

  • Le nombre d’utilisateurs connectés.

  • Liste des utilisateurs qui n’ont pas réussi à s’authentifier.

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 sur un commutateur avec l’interface 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) :

Sens

L’exemple de sortie de la show dot1x interface detail commande montre que le Number of connected supplicants est 1. Le demandeur qui a été authentifié et est maintenant connecté au LAN est connu comme user5 sur le serveur RADIUS et possède l’adresse 00:30:48:8C:66:BDMAC . Le demandeur a été authentifié au moyen de la méthode d’authentification 802.1X appelée authentification RADIUS, comme indiqué Radius dans la sortie. Lorsque l’authentification RADIUS est utilisée, le demandeur est configuré sur le serveur RADIUS, le serveur RADIUS la communique au commutateur et le commutateur ouvre un accès LAN sur l’interface à laquelle le demandeur est connecté. La sortie de l’échantillon 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 par les commutateurs EX Series sont les suivantes :

  • VLAN invité : un hôte qui ne répond pas se voit accorder un accès Invité-VLAN.

  • RAYON MAC : un hôte non-répondeur est authentifié en fonction de son adresse MAC. L’adresse MAC est configurée comme autorisé sur le serveur RADIUS, le serveur RADIUS informe le commutateur que l’adresse MAC est une adresse autorisée, et le commutateur accorde un accès LAN à l’hôte non responsable sur l’interface à laquelle il est connecté.

  • Refus d’échec du serveur : si les serveurs RADIUS s’arrêtent, tous les demandeurs se voient refuser l’accès au LAN, ce qui empêche le trafic du demandeur de passer par l’interface. C’est la valeur par défaut.

  • Autorisation d’échec du serveur : lorsque le serveur RADIUS n’est pas disponible, un demandeur peut toujours accéder au LAN comme si le demandeur avait été authentifié avec succès par le serveur RADIUS.

  • Cache d’utilisation avec échec du serveur : si les serveurs RADIUS s’arrêtent pendant la réauthentification, les demandeurs précédemment authentifiés bénéficient d’un accès LAN, mais les nouveaux demandeurs se voient refuser l’accès LAN.

  • VLAN échec du serveur : un demandeur est configuré pour être déplacé vers un VLAN spécifié si le serveur RADIUS n’est pas en capacité de ré-authentification du 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

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 de supprimer les adresses MAC :

Pour effacer les adresses MAC :

Après avoir nettoyé les adresses MAC :

Notez qu’aucun équipement final n’est sur la liste de contournement de l’authentification.

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 appelée 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 contourner l’authentification, ajoutez à nouveau les adresses MAC statiques à la liste de contournement MAC statique.

Voir également

Rubriques connexes

Tableau de l'historique des versions
Version
Description
20.2R1
À partir de la version 20.2R1 de Junos OS, vous pouvez configurer l’authentification 802.1X sur des interfaces de couche 3
18.4R1
À partir de la version 18.3R1 de Junos OS, vous pouvez configurer l’authentification 802.1X sur les interfaces de tronc, ce qui permet à l’équipement d’accès réseau (NAS) d’authentifier un point d’accès (AP) ou un autre équipement de couche 2 connecté.
17.3R1
À partir de la version 17.3 de Junos OS, la fonctionnalité de rebond de port peut être utilisée pour forcer l’équipement final à engager une renégociation DHCP en provoquant un rabat de liaison sur le port authentifié.