Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Authentification 802.1X

IEEE norme 802.1X pour le contrôle d’accès réseau basé sur les ports et protège les réseaux Ethernet des accès non autorisés des utilisateurs. Il bloque l’ensemble du trafic à l’interface et en provenance d’un demandeur (client) jusqu’à ce que les informations d’identification du demandeur soient présentées et assorties sur le serveur d’authentification (RADIUS serveur). Lorsque le demandeur est authentifié, le commutateur cesse de bloquer l’accès et ouvre l’interface au demandeur. Pour plus d’informations, lisez ce sujet.

Présentation du 802.1X pour les commutateurs

Fonctionnement de l’authentification 802.1X

L’authentification 802.1X fonctionne en utilisant une entité d’accès authentifiée au port (le commutateur) pour bloquer le trafic d’entrée 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 (serveur RADIUS). Une fois authentifié, le commutateur bloque le trafic et ouvre le port au demandeur.

L’équipement final est authentifié en mode demandeur unique, en mode demandeur unique sécurisé ou en mode demandeur multiple:

  • demandeur unique: authentifier uniquement le premier équipement final. Tous les autres équipements finaux qui se connectent ultérieurement au port sont autorisés à accéder intégralement sans aucune authentification supplémentaire. Ils se basent en effet sur l’authentification du premier équipement final.

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

  • demandeurs multiples: permet à plusieurs équipements finaux de se connecter au port. Chaque terminal est authentifié individuellement.

L’accès réseau peut être davantage défini à l’aide de VLANs et de filtres de pare-feu qui agissent tous deux comme des filtres pour séparer et assortir les groupes de terminaux aux zones du réseau local qu’ils nécessitent. Par exemple, vous pouvez configurer des VLAN pour gérer différentes catégories de défaillances d’authentification selon:

  • Que l’équipement final soit ou non activé en 802.1X.

  • Que l’authentification MAC RADIUS soit configurée sur les interfaces de commuter à laquelle les hôtes sont connectés.

  • Que le serveur RADIUS d’authentification ne soit plus disponible ou qu’il envoie RADIUS un message de refus d’accès. Voir Configurer la RADIUS échec d’un serveur (CLI).

Présentation des fonctionnalités du 802.1X

Les fonctionnalités 802.1X suivantes sont prise en charge sur Juniper Networks Commutateurs Ethernet:

  • VLAN invité: fournit un accès limité à un réseau lan, généralement uniquement sur Internet, pour les équipements finaux non réponsibles qui ne sont pas activés en 802.1X lorsque l’authentification MAC RADIUS n’est pas configurée sur les interfaces de commuter à laquelle les hôtes sont connectés. En outre, un VLAN invité peut être utilisé pour fournir un accès limité à un réseau lan pour les utilisateurs invités. En règle générale, le VLAN invité n’offre un accès qu’à Internet et aux terminaux des autres invités.

  • Rejeter le serveur VLAN: fournit un accès limité à un réseau lan, généralement uniquement via Internet, pour les équipements finaux réactifs qui sont 802.1X et qui ont envoyé les données d’identification erronées. Si l’équipement final authentifié à l’aide du VLAN rejeter le serveur est un téléphone IP, le trafic voix n’est pas autorisé.

  • VLAN sans serveur: fournit un accès limité à un réseau lan, généralement uniquement via Internet, pour les équipements finaux 802.1X lors d’RADIUS d’un serveur.

  • VLAN dynamique: permet à l’équipement final, après l’authentification, d’être membre d’un VLAN de manière dynamique.

  • VLAN privé: permet la configuration de 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 RADIUS Déconnexion défini dans le 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 à un fournisseur. Si le téléphone est 802.1X, il est authentifié comme tout autre demandeur. Si le téléphone n’est pas compatible 802.1X et qu’un autre équipement 802.1X est connecté à son port de données, l’équipement est authentifié. Le trafic VoIP peut ensuite être reçu et utilisé depuis le téléphone (à condition que l’interface soit configurée en mode demandeur unique et non en mode demandeur unique).

    Remarque :

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

  • RADIUS comptabilisation: envoie des informations de comptabilisation au RADIUS de comptabilité. Les informations de comptabilisation sont envoyées au serveur dès qu’un abonné se connecte ou se déconnecte, et lorsqu’un abonné active ou désactive un abonnement.

  • attributs de serveur RADIUS 802.1X: il s’agit d’un attribut spécifique au fournisseur (VSA) qui peut être configuré sur le serveur RADIUS pour définir plus en détail Juniper-Switching-Filter l’accès d’un demandeur lors du processus d’authentification 802.1X. La configuration centralisée des attributs sur le serveur d’authentification dévie de la nécessité de les configurer sous la forme de filtres de pare-feu sur chaque commutateur du réseau lan auquel le demandeur peut se connecter. Cette fonctionnalité est basée sur la prise en charge de RLI 4583, AAA RADIUS BRAS VSA.

Les fonctionnalités suivantes sont prise en charge pour authentifier les équipements non 802.1X:

  • Dérivation MAC statique: fournit un mécanisme de dérivation pour authentifier les équipements non 802.1X (comme les imprimantes). La dérivation MAC statique connecte ces équipements aux ports 802.1X, contournant ainsi l’authentification 802.1X.

  • Authentification RADIUS MAC: fournit un moyen d’autoriser les hôtes non 802.1X à accéder au réseau lan. MAC-RADIUS simule la fonctionnalité de demandeur 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 trunks

À partir de Junos OS Release 18.3R1, vous pouvez configurer l’authentification 802.1X sur les interfaces trunk, ce qui permet au dispositif d’accès réseau (NAS) d’authentifier un point d’accès (AP) ou un autre équipement de couche 2 connecté. Un AP ou un commutateur connecté au NAS qui prendra en charge plusieurs VLANs, doit donc se connecter à un port d’trunk. L’authentification 802.1X sur l’interface d’trunk protège le NAS d’une faille de sécurité au cours de laquelle un attaquant peut déconnecter le AP et connecter un ordinateur portable pour accéder gratuitement au réseau pour tous les réseaux VLA configurés.

Veuillez noter les avertissements suivants lors de la configuration de l’authentification 802.1X sur les interfaces d’trunk.

  • Seuls les modes de demandeur unique et sécurisé sont pris en charge sur les interfaces d’tronc.

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

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

  • Les VLAN invités et les VLAN refusant les serveurs ne sont pas pris en charge sur les interfaces d’tronc.

  • La repli sur serveur pour les clients VoIP n’est pas prise en charge sur les interfaces d’tronc ( server-fail-voip ).

  • L’authentification sur le port trunk n’est pas prise en charge à l’aide d’un portail captif.

  • L’authentification sur le port d’agrégation n’est pas prise en charge sur les interfaces agrégées.

  • La configuration de l’authentification 802.1X sur les interfaces membres de réseaux VLAN privés (PVLANs) n’est pas prise en charge sur les ports trunk.

Authentification 802.1X sur les interfaces de couche 3

À partir Junos OS version 20.2R1, vous pouvez configurer l’authentification 802.1X sur les interfaces de couche 3. Veuillez noter les avertissements suivants lors de la configuration de l’authentification 802.1X sur les interfaces de couche 3:

  • Seuls les clients EAP sont pris en charge.

  • Seul le mode de 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 couche set protocol dot1x interface all 3.

  • La prise en charge des interfaces de couche 3 n’inclut pas l’IRB ou les sous-interfaces.

  • Le VLAN invité, le VLAN refuser par serveur et le VLAN à échec serveur ne sont pas pris en charge.

  • La récupération après échec serveur pour les clients VoIP n’est pas prise en charge ( server-fail-voip ).

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

    • Nom de l’utilisateur

    • Temps d’ouverture des sessions

    • ID d’appel et de station

    • ID d’accès aux sessions

    • NAS-port-Id

    • Non-pointage de port

Configuration des paramètres d’interface 802.1X (CLI)

IEEE l’authentification 802.1X assure la sécurité en périphérie du réseau et protège les réseaux Ethernet des accès non autorisés de l’utilisateur en bloquant tout le trafic à l’entrée 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 assorties sur le serveur d’authentification (serveur RADIUS). Lorsque le demandeur est authentifié, le commutateur cesse de bloquer l’accès et ouvre l’interface au demandeur.

Remarque :
  • 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. Voir Configurer la dérivation MAC statique de 802.1Xet l’authentification RADIUS MAC (CLI procédure) .

  • Vous ne pouvez pas configurer l’authentification utilisateur 802.1X sur les interfaces activées pour la tunneling Q-in-Q.

Avant de commencer, indiquez le serveur ou RADIUS serveur d’authentification à utiliser. Consultez la RADIUS connexions de serveur sur les commutateurs (CLI).

Pour configurer 802.1X sur une interface:

  1. Configurez le mode de demandeur sous la forme (authentifier le premier demandeur), (authentifier un seul demandeur) ou singlesingle-secure (authentifier plusieurs multiple demandeurs):
    Remarque :

    Le mode demandeur multiple n’est pas pris en charge sur les interfaces d’tronc.

  2. Activez la réauthentisation et spécifiez l’intervalle de réauthence:
  3. Configurez la valeur de délai d’utilisation de l’interface pour la réponse du demandeur:
  4. Configurez le délai d’utilisation de l’interface avant qu’elle ne renvoye une demande d’authentification au RADIUS serveur:
  5. Configurez combien de temps, en secondes, l’interface attend avant de retransmettre au demandeur les PDU EAPOL initiales:
  6. Configurez le nombre maximal de fois qu’un paquet de demande EAPOL est retransmis au demandeur avant l’heure de la session d’authentification:
  7. Configurez le nombre de fois que le commutateur tente d’authentifier le port en cas de panne initiale. Le port reste en état d’attente pendant la période de quiétude après la tentative d’authentification.
  8. Définissez server-fail l’infirmer de sorte que le serveur ne soit pas défa1.
Remarque :

Ce paramètre spécifie le nombre de tentatives avant que le commutateur ne place l’interface dans un état HELD.

Compréhension RADIUS des modifications initiées par une session utilisateur autorisée

Lorsque vous utilisez un service d’authentification basé sur un modèle de RADIUS client/serveur, les requêtes sont généralement lancées par le client et envoyées au RADIUS serveur. Certaines instances peuvent être lancées par le serveur et envoyées au client afin de modifier de manière dynamique une session utilisateur authentifiée déjà en cours. Le client qui reçoit et traite les messages est le commutateur, qui agit comme le 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 de sécurité non sollicitées RADIUS 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 et sur le serveur RADIUS serveur. Pour plus d’informations sur la configuration de l’adresse source et sur le secret partagé sur le commutateur, consultez l’exemple: Connexion d’RADIUS serveur 802.1X à un EX Series réseau .

Déconnexion des messages

Le RADIUS envoie un message de déconnexion au commutateur afin de mettre fin à une session utilisateur et de supprimer tout le contexte de session associé. Le commutateur répond à un paquet Déconnexion-Demande avec un message Déconnexion-ACK en cas de réussite de la demande, c’est-à-dire que l’ensemble du contexte de session associé est écarté et que la session utilisateur n’est plus connectée, ou avec un paquet Disconnect-NAK en cas d’échec de la demande, c’est-à-dire que l’authentifié ne peut pas déconnecter la session et supprimer tout le contexte de session associé.

Dans les messages de demande de RADIUS, les attributs de sécurité sont utilisés pour identifier de manière unique le commutateur (NAS) et la session utilisateur. La combinaison des attributs d NAS d’identification de session 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 de déconnexion. Un message de demande de déconnexion ne contient que NAS d’identification de session ; si d’autres attributs sont inclus, le commutateur répond avec un message Déconnexion-NAK.

Messages de modification d’autorisation

Les messages de modification d’autorisation (CoA) contiennent des informations pour la modification dynamique des attributs d’autorisation pour une session utilisateur afin de changer le niveau d’autorisation. Cette procédure se produit dans le cadre d’un processus d’authentification en deux étapes, au cours duquel le point final est d’abord authentifié à l’aide de l’authentification MAC RADIUS, puis 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 avec un message CoA-ACK si le changement d’autorisation est réussi, ou un message coA-NAK en cas d’échec de la modification. Si un ou plusieurs changements d’autorisation indiqués dans un message de Demande de CoA ne peuvent pas être réalisés, le commutateur répond avec un message CoA-NAK.

Dans les messages de demande de RADIUS, les attributs de sécurité sont utilisés pour identifier de manière unique le commutateur (qui agit en tant que NAS) et la session utilisateur. La combinaison des attributs d’identification de NAS et des attributs d’identification de session inclus dans le message doit correspondre aux attributs d’identification d’au moins une session pour la réussite de la demande ; dans le cas contraire, le commutateur répond avec 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 de demande de CoA, l’NAS part du principe que la valeur de cet attribut est de rester inchangée.

  • ID de filtre

  • Tunnel-Private-Group-ID

  • Juniper commutation-filtre

  • Juniper-VoIP-VLAN

  • Temps d’ouverture des sessions

Non-rebond du port de demande CoA

Lorsqu’un message Dea est utilisé pour modifier le VLAN d’un hôte authentifié, les équipements finaux tels que les imprimantes ne sont pas en mesure de détecter les changements de VLAN, de sorte qu’ils ne renouvellent pas le bail pour leur adresse DHCP dans le nouveau VLAN. À partir Junos OS version 17.3, la fonction de non-remis du port peut être utilisée pour forcer l’équipement final à engager une négociation DHCP en provoquent un battement de liaison sur le port authentifié.

La commande de non-bond du port est envoyée depuis le serveur RADIUS à l’aide Juniper Networks’attribut vsA (Vendor-Specific Attribute). Le port est non-envoyé si la paire VSA de valeur d’attribut suivante est reçue dans le message CoA envoyé par RADIUS serveur:

  • Juniper-AV-Pair = « Port-Bounce »

Pour activer la fonction de non-remise du port, vous devez mettre à jour le fichier du dictionnaire Junos ( ) sur le serveur RADIUS à l’Juniper juniper.dct VSA-PAIRE-AV. Localisez le fichier du dictionnaire et ajoutez le texte suivant au fichier:

Pour plus d’informations sur l’ajout du VSA, consultez la documentation relative au FreeRADIUS.

Vous pouvez désactiver la fonction en configurant l’instruction au niveau [ ] de mise en ignore-port-bounceedit protocols dot1x authenticator interface interface-name cache.

Codes de cause d’erreur

En cas de échec d’une déconnexion ou d’une opération CoA, un attribut de cause d’erreur (attribut RADIUS 101) peut être inclus dans le message de réponse envoyé par l’NAS au serveur afin de fournir des détails sur la cause du problème. Si l’erreur détectée n’est pas liée à l’une des valeurs de l’attribut de cause d’erreur prise en charge, le routeur envoie le message sans attribut de cause d’erreur. Vous pouvez voir les descriptions des codes de cause d’erreur qui peuvent être inclus dans les messages de réponse Tableau 1 envoyés par le NAS.

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

Code

Valeur

Description

201

Contexte de session de suppression

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 la session de dissocier a été trouvé et supprimé avec succès. Ce code n’est envoyé que dans un message Déconnexion-ACK.

401

Attribut non pris en place

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) manque dans une demande.

403

NAS ina pas d’identification

La requête contient un NAS d’identification qui ne correspondent pas à l’identité de l’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 service

L’attribut de type Service inclus dans la demande contient une valeur non valide ou non pris en compte.

406

Extension non pris en place

L’entité qui reçoit la demande (qu’elle NAS’un proxy ou RADIUS client) ne prend pas en charge RADIUS requêtes lancées.

407

Valeur d’attribut non valide

La requête contient un attribut dont la valeur n’est pas pris en compte.

501

Interdit sur le plan administratif

La NAS est configurée pour interdire l’honneur des messages de déconnexion ou de demande de coa pour la session spécifiée.

503

Contexte de session in found

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 non pris en charge. Ce code n’est envoyé que dans un message Déconnexion-NAK.

506

Ressources non disponibles

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

507

Demande lancée

Le message de demande de coa inclut un attribut de type service avec une valeur d’autorisation uniquement.

508

Sélection de plusieurs sessions non pris en

Les attributs d’identification de session inclus dans la requête correspondent à plusieurs sessions, mais l’NAS ne prend pas en charge les requêtes qui s’appliquent à plusieurs sessions.

Filtrage des demandeurs 802.1X en utilisant RADIUS-serveurs

Il existe deux façons de configurer un serveur d RADIUS avec des filtres de pare-feu de port (filtres de pare-feu de couche 2):

  • Inclure un ou plusieurs termes de filtre dans l’attribut Juniper-commutation-filtre. L Juniper-switching-filter est un attribut spécifique au fournisseur (VSA) répertorié sous l’ID d’attribut 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. Aucune configuration n’est nécessaire sur le commutateur. toutes les configurations sont sur le RADIUS serveur.

  • Configurez un filtre de pare-feu local sur chaque commutateur et appliquez ce filtre de pare-feu aux utilisateurs authentifiés via RADIUS serveur. Utilisez cette méthode pour obtenir des 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 résiliée et rétablie pour que les modifications de configuration du filtre de pare-feu prennent effet.

Ce sujet comprend les tâches suivantes:

Configuration des filtres de pare-feu sur le RADIUS serveur

Vous pouvez configurer des conditions de filtre simples en utilisant l’attribut Juniper-switching-filter dans le dictionnaire Juniper du 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 à tous les commutateurs EX Series authentifiés les utilisateurs via ce RADIUS sans que vous n’avez besoin de configurer quoi que ce soit sur chaque commutateur individuel.

Remarque :

Cette procédure décrit l’utilisation du logiciel FreeRADIUS pour configurer Juniper-switching-filter VSA. Pour des informations spécifiques sur la configuration de votre serveur, consultez la documentation relative AAA de votre serveur.

Pour configurer l’attribut de Juniper-commutation-filtre, saisissez un ou plusieurs termes de filtre en utilisant le CLI pour RADIUS serveur. Chaque terme de filtre comprend des conditions de correspondance avec une action correspondante. Saisissez les termes du filtre inclus dans les guillemets ( » « ) à l’aide de la syntaxe suivante:

Plusieurs conditions de correspondance peuvent être incluses dans un terme filtre. Lorsque plusieurs conditions sont spécifiées dans un terme filtre, elles doivent toutes être remplies pour que le paquet corresponde au terme de filtre. Par exemple, le terme de filtre suivant nécessite un paquet qui correspond à 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 Juniper-filtre de commutation VSA Assortir les conditions et les actions pour définir les conditions et actions de correspondance.

Remarque :

Sur EX9200 commutateurs et dans un Junos Fusion Enterprise avec EX9200 comme équipement agrégé, le filtre de pare-feu dynamique est appliqué strictement à tous les paquets IP. Si le filtre est configuré pour autoriser uniquement une adresse IP de destination spécifique, les paquets avec d’autres adresses IP comme adresse IP de destination seront abandonnés en respectant les règles du filtre. 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:

  1. Vérifiez que le dictionnaire Juniper est chargé sur votre RADIUS et inclut l’attribut de filtrage Juniper-Switching-Filter (ID d’attribut 48):
  2. Saisissez les conditions et actions de la correspondance. Quelques chiffres clés :
    • Pour refuser l’authentification basée sur la balise 802.1Q (ici, la balise 802.1Q 10 est:

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

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

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

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

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

      Remarque :

      Pour que l’option soit appliquée, la classe de transfert doit être configurée sur le commutateur et la priorité de perte forwarding-class de paquets 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 forwarding et la priorité de perte de paquet.

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

Application d’un filtre de pare-feu configuré localement à partir du RADIUS serveur

Vous pouvez appliquer un filtre de pare-feu de port (filtre de pare-feu de couche 2) aux stratégies des utilisateurs de manière centralisée depuis RADIUS serveur. Le RADIUS peut ensuite spécifier les filtres de pare-feu à appliquer à chaque utilisateur qui demande une authentification, ce qui réduit 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 EX Series pare-feu.

Pour appliquer un filtre de pare-feu de port de manière centralisée depuis RADIUS serveur:

Remarque :

Si les filtres de pare-feu de port sont également configurés localement pour l’interface, alors les filtres de pare-feu configurés avec les vsA ont priorité en cas de conflit avec les filtres de pare-feu de port configurés localement. En l’absence de conflit, ils sont fusionnés.

  1. Créez le filtre de pare-feu sur le commutateur local. Consultez la procédure Configuring Firewall Filters (CLI) pour plus d’informations sur la configuration d’un filtre de pare-feu de port.
  2. Sur le RADIUS, ouvrez le fichier pour afficher les profils d’utilisateurs locaux des terminaux sur lesquels vous souhaitez users appliquer le filtre:

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

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

    Remarque :

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

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

Exemple: Connexion d’RADIUS serveur 802.1X à un EX Series réseau

La norme 802.1X IEEE pour le contrôle d’accès réseau basé sur les ports (PNAC). Vous utilisez le 802.1X pour contrôler l’accès au réseau. Seuls les utilisateurs et équipements fournissant des informations d’identification vérifiées par rapport à une base de données d’utilisateur 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 RADIUS MAC.

Cet exemple décrit comment connecter un serveur RADIUS à un commutateur d’EX Series et le configurer pour 802.1X:

Conditions préalables

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

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

  • Un commutateur EX Series agit comme une entité d’accès authentifiée authentifiée au port (PAE). Les ports du paE authentifié forment une porte de contrôle qui bloque l’ensemble du trafic à l’entrée et à l’sortie des demandeurs jusqu’à ce qu’ils soient authentifiés.

  • Un seul RADIUS d’authentification qui prend en charge la 802.1X. Le serveur d’authentification agit comme la 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 brancher le serveur sur le commutateur, assurez-vous d’avoir:

Présentation et topologie

Le commutateur EX Series agit comme un authentifié 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. Tout autre utilisateur et périphérique se fait refuser l’accès.

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

Figure 1 : Topologie pour la configurationTopologie pour la configuration
Tableau 2 : Composants de la topologie
Propriété Paramètres

Matériel de commutage

EX4200 d’accès, 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 RADIUS serveur

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

Dans cet exemple, connectez le serveur d RADIUS pour accéder au port ge-0/0/10 du commutateur EX4200 port. Le commutateur joue le rôle d’authentifier et transfert les informations d’identification du demandeur vers la base de données des utilisateurs du RADIUS serveur. Vous devez configurer la connectivité entre le EX4200 et le serveur RADIUS en spécifier l’adresse du serveur et en configurant le mot de passe secret. Ces informations sont configurées dans un profil d’accès du commutateur.

Remarque :

Pour plus d’informations sur les services d’authentification, d’autorisation et de comptabilisation (AAA), consultez le Junos OS System Basics Configuration Guide.

Configuration

Procédure

CLI configuration rapide

Pour connecter rapidement le serveur RADIUS au commutateur, copiez les commandes suivantes et collez-les dans la fenêtre de borne 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 sur le serveur:

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

  3. Configurez une liste d’adresses IP de serveur à essayer afin d’authentifier le demandeur:

Résultats

Afficher les résultats de la configuration:

Vérification

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

Vérifiez que le commutateur et RADIUS serveur sont correctement connectés

But

Vérifiez que le serveur RADIUS est connecté au commutateur sur le port spécifié.

Action

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

Sens

Les paquets de requête d’écho ICMP sont envoyés du commutateur au serveur cible à 10.0.0.100 afin de vérifier si le serveur est accessible sur l’ensemble du réseau IP. Les réponses d’écho ICMP sont renvoyées depuis le serveur pour vérifier que le commutateur et le serveur sont connectés.

Compréhension des filtres dynamiques basés sur RADIUS attributs

Vous pouvez utiliser des attributs RADIUS serveur pour implémenter des filtres de pare-feu de port sur RADIUS serveur d’authentification. Ces filtres peuvent être appliqués de façon dynamique aux demandeurs qui demandent une authentification via ce serveur. RADIUS serveur est un champ en texte clair encapsulé dans des messages d’acceptation d’accès envoyés du serveur d’authentification au commutateur lorsqu’un demandeur connecté au commutateur a réussi à authentifier. Le commutateur, qui joue le rôle d’authentifier, utilise les informations du RADIUS pour appliquer les filtres associés au demandeur. Les 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 centralisé des accès pour le réseau.

Vous pouvez définir des filtres de pare-feu directement sur le serveur RADIUS en utilisant l’attribut de filtre de commutation Juniper, qui est un attribut RADIUS spécifique à Juniper Networks, également connu sous le nom d’attribut spécifique au fournisseur (VSA). Les VSA sont décrits dans le RFC 2138, Remote Authentication Dial In User Service (RADIUS). Le vsA filtre à commutation Juniper est répertorié sous l’ID d’attribut 48 dans le dictionnaire Juniper du serveur RADIUS, avec l’ID du fournisseur sur le numéro Juniper Networks 2636. Grâce à cet attribut, vous définissez des filtres sur le serveur d’authentification, appliqués à tous les commutateurs qui authentifier les demandeurs via ce serveur. Cette méthode élimine la nécessité de configurer les mêmes filtres sur plusieurs commutateurs.

Vous pouvez également appliquer un filtre de pare-feu de port à plusieurs ports du même commutateur en utilisant l’attribut d’ID de filtre, qui RADIUS’ID d’attribut 11. Pour utiliser l’attribut d’ID de filtre, vous devez d’abord configurer un filtre sur le commutateur, puis ajouter le nom du filtre aux stratégies des utilisateurs sur le serveur RADIUS en tant que valeur de l’attribut Filtre-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 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 d’ID de filtre doit être configuré localement sur le commutateur au niveau de edit firewall family ethernet-switching filter [ ] hiérarchie.

Les vsA sont pris en charge uniquement pour les configurations 802.1X avec un demandeur unique et pour plusieurs configurations de demandeurs.

Compréhension de l’attribution de VLAN dynamique à RADIUS attributs

Les réseaux VLAN peuvent être attribués de façon dynamique par RADIUS aux demandeurs qui demandent l’authentification 802.1X par l’intermédiaire de ce serveur. Vous configurez le VLAN sur le serveur RADIUS en utilisant 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, qui joue le rôle d’authentifier, utilise les informations du 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 attribué à un autre VLAN.

L’authentification réussie nécessite que l’ID ou le nom VLAN du VLAN soit configuré sur le commutateur en tant qu’authentifié 802.1X et qu’il soit correspondance avec le nom VLAN ID ou VLAN envoyé par le serveur RADIUS lors de l’authentification. Si l’une d’elles n’existe pas, l’équipement final n’est pas authentifié. Si un VLAN invité est établi, l’équipement final non authentifié est automatiquement transféré vers le VLAN invité.

Les attributs RADIUS serveur utilisés pour l’attribution de VLAN dynamique décritsdans le RFC 2868, RADIUS pour la prise en charge du protocole de tunnel .

  • Type de tunnel: définition de RADIUS attribut de type 64. La valeur doit être définie selon VLAN .

  • Type tunnel-medium: défini RADIUS attribut de type 65. La valeur doit être définie selon IEEE-802 .

  • Tunnel-Private-Group-ID: définition de RADIUS 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 réseaux VLA dynamiques sur votre RADIUS, consultez la documentation relative à votre RADIUS réseau.

Understanding Guest VLANs for 802.1X on Switches

Les réseaux VLA invités peuvent être configurés sur les commutateurs utilisant l’authentification 802.1X pour fournir un accès limité, généralement uniquement à Internet, pour les invités d’entreprise. Le VLAN invité est utilisé comme arrière-arrière lorsque:

  • Le demandeur n’est pas conforme à la 802.1X et ne répond pas aux messages EAP.

  • L RADIUS d’authentification MAC n’a pas été configurée sur les interfaces de commutation à laquelle le demandeur est connecté.

  • Le portail captif n’a pas été configuré sur les interfaces de commutation à laquelle le demandeur est connecté.

Un VLAN invité n’est pas utilisé pour les demandeurs qui envoient des données d’identification incorrectes. Ces demandeurs sont dirigés vers le serveur, rejettent plutôt le VLAN.

Pour les équipements finaux non 802.1X, un VLAN invité peut autoriser un accès limité à un serveur à partir duquel l’équipement final non 802.1X peut télécharger le logiciel de demandeur et tenter de nouveau d’authentification.

Exemple: Configuration des options d’authentification 802.1X lorsque le serveur d’RADIUS n’est pas disponible pour un EX Series réseau

La récupération après échec 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 le 802.1X pour contrôler l’accès au réseau. Seuls les utilisateurs et équipements (demandeurs) fournissant des informations d’identification vérifiées au moyen d’une base de données d’utilisateur sont autorisés à 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 d’RADIUS d’un serveur:

Conditions préalables

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

Remarque :

Cet exemple s’applique également QFX5100 commutateurs.

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

  • Un commutateur EX Series agit comme une entité d’accès authentifiée authentifiée au port (PAE). Les ports du paE authentifié forment une porte de contrôle qui bloque l’ensemble du trafic à l’entrée et à l’sortie des demandeurs jusqu’à ce qu’ils soient authentifiés.

  • Un seul RADIUS d’authentification qui prend en charge la 802.1X. Le serveur d’authentification agit comme la 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 brancher le serveur sur le commutateur, assurez-vous d’avoir:

Présentation et topologie

Un RADIUS de temps d’accès au serveur est possible si aucune authentification RADIUS serveurs n’est atteinte lorsqu’un demandeur se connecte au réseau et tente d’accéder au réseau. À l’aide de la restauration après échec du serveur, vous configurez des options alternatives pour les demandeurs qui tentent d’accéder au réseau 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’RADIUS du serveur. En outre, vous pouvez configurer le commutateur pour déplacer les demandeurs vers un VLAN spécifique en cas RADIUS de temps d’arrêt.

Figure 2 montre la topologie utilisée dans cet exemple. Le RADIUS serveur est connecté au commutateur d’accès EX4200 du port ge-0/0/10 d’accès. Le commutateur joue le rôle d’entité d’accès authentifiée authentifiée au port (PAE) et transfert des données d’identification du demandeur vers la base de données des utilisateurs du RADIUS serveur. 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 QFX5100 commutateurs.

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 commutage

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

Noms des VLAN

default VLAN

vlan-sf VLAN

Supplicant

Demandeur tentant d’accéder à l’interface ge-0/0/1

Un RADIUS serveur

Base de données back-end avec adresse 10.0.0.100 de connexion au commutateur au port ge-0/0/10

Dans cet exemple, configurez l’interface ge-0/0/1 pour déplacer un demandeur tentant d’accéder au réseau sans fil pendant RADIUS’arrêt vers un autre VLAN. Un délai d’RADIUS permet d’échanger normalement des messages EAP qui transportent des informations du serveur RADIUS au commutateur et permettent l’authentification d’un demandeur. Le VLAN par défaut est configuré sur l’interface ge-0/0/1. En cas RADIUS temps d’arrêt, les demandeurs présents sur l’interface sont transférés du VLAN par défaut au VLAN nommé vlan-sf.

Topologie

Configuration

Procédure

CLI configuration rapide

Pour configurer rapidement la récupération après échec du serveur sur le commutateur, copiez les commandes suivantes et collez-les dans la fenêtre de borne du commutateur:

Procédure étape par étape

Pour configurer une interface afin de détourner les demandeurs vers un VLAN spécifique en cas RADIUS de délai d’arrêt (ici, le VLAN vlan-sf est):

  1. Définir le VLAN auquel les demandeurs sont détournés:

Résultats

Afficher les résultats de la configuration:

Vérification

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

S’assurer que les demandeurs sont transférés vers un VLAN alternatif pendant RADIUS temps d’arrêt

But

Vérifiez que l’interface déplace les demandeurs vers un VLAN alternatif pendant RADIUS temps d’arrêt.

Remarque :

Sur les commutateurs exécutant Junos OS pour EX Series la prise en charge d’ELS, le résultat de la commande show vlans contient des informations supplémentaires. Si votre commutateur exécute un logiciel qui prend en charge ELS, consultez « afficher vlans». Pour plus de détails sur ELS, consultez la version de l’application Enhanced Layer 2 Software CLI

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 ge-0/0/1.0 l’interface:

Un délai d RADIUS de temps entre les serveurs est en cours. Affichez la table de commutation Ethernet pour montrer que le demandeur avec l’adresse MAC qui accédait auparavant au réseau lan via le VLAN est maintenant en cours d’étude sur le 00:00:00:00:00:01default VLAN vlan-sf nommé:

Affichez les informations du protocole 802.1X pour démontrer que l’interface se connecte et ouvre l’accès ge-0/0/1.0 au réseau lan aux demandeurs:

Sens

La show vlans commande affiche l’interface ge-0/0/1.0 comme membre du default VLAN. La commande indique qu’un demandeur ( ) est authentifié sur show dot1x interface briefabc l’interface ge-0/0/1.0 et dispose de l’adresse 00:00:00:00:00:01 MAC. Un délai RADIUS de serveur est atteint et le commutateur ne peut pas atteindre le serveur d’authentification. La show-ethernet-switching table commande indique que l’adresse MAC est 00:00:00:00:00:01 apprise sur VLAN. vlan-sf Le demandeur a été transféré du VLAN au defaultvlan-sf VLAN. Le demandeur est ensuite connecté au réseau lan via le VLAN nommé vlan-sf .

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 sont RADIUS à prendre en charge les serveurs d’authentification qui utilisent le protocole EAP-TTLS (Extensible Authentication Protocol–Tunneled TLS) pour authentifier les demandeurs d’Odyssey Access Client (OAC). Le logiciel de mise en réseau OAC s’exécute sur les ordinateurs de point d’extrémité (ordinateurs de bureau, ordinateurs portables ou notepad et équipements sans fil pris en charge) et fournit un accès sécurisé aux réseaux câblés et sans fil.

Cet exemple décrit comment configurer une interface 802.1X sur le commutateur afin de fournir une prise en charge de repli pour les utilisateurs OAC ayant saisi des informations d’identification incorrectes:

Conditions préalables

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

Remarque :

Cet exemple s’applique également QFX5100 commutateurs.

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

  • Un commutateur EX Series agit comme une entité d’accès authentifiée authentifiée au port (PAE). Les ports du paE authentifié forment une porte de contrôle qui bloque l’ensemble du trafic à l’entrée et à l’sortie des demandeurs jusqu’à ce qu’ils soient authentifiés.

  • Un seul RADIUS d’authentification qui prend en charge la 802.1X. Le serveur d’authentification agit comme la 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 d’extrémité OAC agissant comme un demandeur.

Avant de commencer à configurer l’option de repli, assurez-vous d’avoir:

Présentation et topologie

OAC est un logiciel réseau qui s’exécute sur les ordinateurs de point d’extrémité (de bureau, portables ou notepad) et les équipements sans fil pris en charge. OAC assure la prise en charge complète du programme EAP, requis pour un accès sécurisé au réseau lan sans fil.

Dans cette topologie, OAC est déployé avec un commutateur 802.1X et RADIUS serveur. Le commutateur fait fonction de point d’application de l’architecture de sécurité du réseau. Cette topologie:

  • S’assure que seuls les utilisateurs autorisés peuvent se connecter.

  • Maintient la confidentialité des données d’identification de connexion.

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

Cet exemple inclut la configuration d’un VLAN rejeter par serveur sur le commutateur, qui peut être utilisé pour empêcher le verrouillage accidentel pour les utilisateurs ayant saisi des données d’identification incorrectes. Ces utilisateurs peuvent se voir donner un accès LAN limité.

Cependant, cette configuration de repli est complexe par le fait que le demandeur OAC et le serveur de 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 saisisse des données d’identification incorrectes, le serveur d’RADIUS envoie des messages de défaillance EAP directement au client par le biais de ce tunnel. Le message de défaillance de l’EAP provoque le redémarrage de la procédure d’authentification, de sorte que le processus d’authentification 802.1X du commutateur fait pleurer la session établie avec le commutateur à l’aide du VLAN de refuser le serveur. Vous pouvez activer la connexion corrective pour continuer en configurant:

  • eapol-block— Activez le programme de blocage EAPoL sur l’interface 802.1X configurée pour faire partie du VLAN rejeter le serveur. Le dispositif de blocage permet à l’entité d’accès au port d’authentification d’ignorer les messages de démarrage EAP envoyés par le client et tente de redémarrer la procédure d’authentification.

    Remarque :

    Le temps de blocage EAPoL n’est déclenché qu’une fois le nombre configuré de mesures de réattette autorisées (en utilisant l’option) sur retries l’interface 802.1X. Vous pouvez configurer pour spécifier le nombre de fois que le commutateur tente d’authentifier le port en cas retries de panne initiale. Il s’agit de trois tentatives par défaut.

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

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

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

Figure 3 montre un commutateur EX Series qui connecte un terminal OAC à un serveur RADIUS et indique les protocoles utilisés pour connecter les entités du réseau.

Remarque :

Ce chiffre s’applique également QFX5100 commutateurs.

Figure 3 : EX Series pour connecter OAC à RADIUS à l’aide de l’authentification EAP-TTLSEX Series pour connecter OAC à RADIUS à l’aide de l’authentification EAP-TTLS

Topologie

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

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

Matériel de commutage

commutateur EX Series compatible

VLAN

default

server-reject-vlan: Nom du VLAN remedial et ID VLAN est 700

Interface 802.1X

ge-0/0/8

Demandeur OAC

EAP-TTLS

Un seul RADIUS d’authentification

EAP-TTLS

Configuration

Procédure

CLI configuration rapide

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 de borne du commutateur:

Procédure étape par étape

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

Conseil :

Dans cet exemple, un seul VLAN de refus du serveur est sur le commutateur. La configuration est donc spécifiée eapol-block et block-interval directement server-reject-vlan après. Toutefois, si vous avez configuré plusieurs VLAN sur le commutateur, vous devez inclure le nom du VLAN ou l’ID VLAN directement après pour indiquer quel VLAN a été server-reject-vlan modifié.

  1. Configurer un VLAN qui fonctionne comme un VLAN rejeter le serveur afin de fournir un accès LAN limité aux utilisateurs ayant saisi des données d’identification incorrectes:

  2. Configurez le nombre de fois où le client doit être invité à obtenir un nom d’utilisateur et un mot de passe avant qu’une connexion incorrecte ne soit adressée au VLAN de rejeter le serveur:

  3. Configurez l’interface authentifiée 802.1X pour utiliser le VLAN de refus du serveur en tant que repli pour les connexions incorrectes:

  4. Activez le système de blocage EAPoL sur l’interface 802.1X configurée pour faire partie du VLAN refuser par serveur.

  5. Configurez le temps de blocage EAPoL pour qu’il reste en vigueur:

Résultats

Consultez les résultats de la configuration:

Vérification

Pour vérifier que la configuration et les options de repli fonctionnent correctement, exécutez 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

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

Surveillance de l’authentification 802.1X

But

Remarque :

Ce sujet s’applique uniquement au package d’applications J-Web.

Package applicatif J-Web Version 14.1X53-A2 ne prend pas en charge l’authentification 802.1X sur EX4600 commutateurs.

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

Action

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

Pour afficher les détails d’authentification dans CLI, saisissez les commandes suivantes:

  • show dot1x interface detail | display xml

  • show dot1x interface detail <interface> | display xml

  • show dot1x auth-failed-users

Sens

Parmi les détails affichés:

  • Une liste d’utilisateurs authentifiés.

  • Le nombre d’utilisateurs connectés.

  • Liste des utilisateurs qui ont échoué dans l’authentification.

Vous pouvez également spécifier une interface pour laquelle les détails doivent être affichés.

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 affichent la méthode d’authentification utilisée.

Action

Affichage d’informations détaillées sur une interface configurée pour 802.1X (ici, l’interface est ge-0/0/16):

Sens

La sortie de l’exemple à partir de show dot1x interface detail la commande indique que Number of connected supplicants l’échantillon est 1. Le demandeur authentifié qui est désormais connecté au LAN est appelé sur le serveur RADIUS et possède user5 l’adresse 00:30:48:8C:66:BD MAC. Le demandeur a été authentifié à l’aide de la méthode d’authentification 802.1X appelée RADIUS authentification, 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 l’accès au réseau lan sur l’interface à laquelle le demandeur est connecté. La sortie de l’exemple montre également que le demandeur est connecté au v200 VLAN.

Les autres méthodes d’authentification 802.1X EX Series prise en charge sur les commutateurs en plus RADIUS authentification:

  • VLAN invité: un hôte non-responsable peut accéder au VLAN invité.

  • MAC Radius: un hôte non-répondeur est authentifié en fonction de son adresse MAC. L’adresse MAC est configurée comme elle est 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 un accès LAN à l’hôte non réponsable sur l’interface à laquelle il est connecté.

  • Refus d’échec serveur: en cas de délai d’RADIUS du serveur, tous les demandeurs se voient refuser l’accès au réseau lan, ce qui empêche le trafic du demandeur de traverser l’interface. C’est le paramètre par défaut.

  • Licence d’échec de serveur: lorsqu’un serveur RADIUS n’est pas disponible, un demandeur peut toujours accéder au réseau lan comme si le demandeur avait réussi à authentifier le serveur RADIUS.

  • Mise en cache à l’aide d’un serveur: si les serveurs RADIUS sont désactivés pendant la réauthence, les demandeurs précédemment authentifiés se font accorder l’accès au LAN, mais les nouveaux demandeurs se voir refuser l’accès au LAN.

  • VLAN à échec serveur: un demandeur est configuré pour être transféré vers un VLAN spécifié si le serveur RADIUS n’est pas disponible pour authentifier le demandeur. (Le VLAN doit déjà exister sur le commutateur.)

Dépannage de l’authentification des équipements finaux sur EX Series commutateurs mobiles

Problème

Description

Les équipements finaux configurés à l’aide d’adresses MAC statiques perdent la connexion au commutateur après que la commande d’interface dot1x claire soit exécuté pour effacer toutes les adresses MAC apprises.

Avant de effacer les adresses MAC:

Pour effacer les adresses MAC:

Après avoir effacer les adresses MAC:

Notez qu’il n’y a aucun équipement final sur la liste de dérivation d’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 d’interface dot1x claire est exécuté, elle effacera toutes les adresses MAC apprises à partir de l’interface, y compris la liste de dérivation MAC statique (également connue sous le nom de liste d’exclusion).

Solution

Si vous exécutez la commande d’interfaces dot1x claire pour une interface avec des adresses MAC statiques configurées pour la dérivation de l’authentification, ajoutez à nouveau les adresses MAC statiques à la liste de dérivation MAC statique.

Tableau de l'historique des versions
Version
Description
20.2R1
À partir Junos OS version 20.2R1, vous pouvez configurer l’authentification 802.1X sur les interfaces de couche 3
18.4R1
À partir de Junos OS Release 18.3R1, vous pouvez configurer l’authentification 802.1X sur les interfaces trunk, ce qui permet au dispositif 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 Junos OS version 17.3, la fonction de non-remis du port peut être utilisée pour forcer l’équipement final à engager une négociation DHCP en provoquent un battement de liaison sur le port authentifié.
14.1X53-A2
Package applicatif J-Web Version 14.1X53-A2 ne prend pas en charge l’authentification 802.1X sur EX4600 commutateurs.