Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Authentification 802.1X

Norme IEEE 802.1X pour le contrôle d’accès réseau basé sur les ports et protège les réseaux locaux Ethernet contre les accès non autorisés des utilisateurs. Il bloque tout le trafic à destination et en provenance d’un demandeur (client) à l’interface jusqu’à ce que les informations d’identification du demandeur soient présentées et mises en correspondance sur le serveur d’authentification (un serveur RADIUS). Lorsque le demandeur est authentifié, le serveurcesse de bloquer l’accès et ouvre l’interface au demandeur. Lisez cette rubrique pour plus d’informations.

Présentation de la norme 802.1X pour les commutateurs

Fonctionnement de l’authentification 802.1X

L’authentification 802.1X fonctionne à l’aide d’une entité d’accès au port d’authentification (le commutateur) pour bloquer le trafic entrant d’un demandeur (périphérique final) au niveau du port jusqu’à ce que les informations d’identification du demandeur soient présentées et correspondent sur le serveur d’authentification (un serveur RADIUS). Une fois authentifié, le commutateur cesse de bloquer le trafic et ouvre le port au demandeur.

Le terminal est authentifié en single supplicant mode, single-secure supplicant mode ou multiple supplicant mode :

  • demandeur unique : authentifie uniquement le premier périphérique final. Tous les autres terminaux qui se connectent ultérieurement au port sont autorisés à accéder à l’intégralité du port sans autre authentification. Ils se greffent en fait sur l’authentification du premier terminal.

  • single-secure supplicant : n’autorise qu’un seul terminal à se connecter au port. Aucun autre terminal n’est autorisé à se connecter tant que le premier appareil n’est pas déconnecté.

  • multiple supplicant : permet à plusieurs terminaux de se connecter au port. Chaque terminal est authentifié individuellement.

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

Présentation des fonctionnalités 802.1X

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

  • VLAN invité : fournit un accès limité à un réseau local, généralement uniquement à Internet, pour les périphériques finaux qui ne répondent pas et qui ne sont pas compatibles 802.1X lorsque l’authentification MAC RADIUS n’est pas configurée sur les interfaces de commutateur auxquelles les hôtes sont connectés. En outre, un VLAN invité peut être utilisé pour fournir un accès limité à un LAN pour les utilisateurs invités. En règle générale, le VLAN invité permet d’accéder uniquement à Internet et aux terminaux des autres invités.

  • VLAN à rejet par le serveur : fournit un accès limité à un réseau local, généralement uniquement à Internet, pour les terminaux réactifs qui sont compatibles 802.1X, mais qui ont envoyé des informations d’identification incorrectes. Si le terminal authentifié à l’aide du VLAN de rejet du serveur est un téléphone IP, le trafic vocal n’est pas autorisé.

  • VLAN en cas d’échec du serveur : fournit un accès limité à un réseau local, généralement uniquement à Internet, pour les périphériques finaux 802.1X pendant un délai d’expiration du serveur RADIUS.

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

  • VLAN privé : permet de configurer l’authentification 802.1X sur les interfaces membres de VLAN privés (PVLAN).

  • Modifications dynamiques d’une session utilisateur : permet à l’administrateur du commutateur de mettre fin à une session déjà authentifiée. Cette fonctionnalité est basée sur la prise en charge du message de déconnexion RADIUS défini dans la RFC 3576.

  • VLAN VoIP : prend en charge les téléphones IP. La mise en œuvre d’un VLAN vocal sur un téléphone IP est spécifique au fournisseur. Si le téléphone est compatible 802.1X, il est authentifié comme n’importe quel autre demandeur. Si le téléphone n’est pas compatible 802.1X, mais qu’un autre appareil compatible 802.1X est connecté à son port de données, cet appareil est authentifié, puis le trafic VoIP peut circuler vers et depuis le téléphone (à condition que l’interface soit configurée en mode demandeur unique et non en mode demandeur sécurisé unique).

    REMARQUE :

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

  • Comptabilité RADIUS : envoie les informations comptables au serveur de comptabilité RADIUS. Les informations comptables sont envoyées au serveur chaque fois qu’un abonné se connecte ou se déconnecte et chaque fois qu’un abonné active ou désactive un abonnement.

  • Attributs du serveur RADIUS pour 802.1X : il Juniper-Switching-Filter s’agit d’un attribut spécifique au fournisseur (VSA) qui peut être configuré sur le serveur RADIUS pour définir plus précisément l’accès d’un demandeur pendant le processus d’authentification 802.1X. La configuration centralisée des attributs sur le serveur d’authentification évite d’avoir à configurer ces mêmes attributs sous la forme de filtres de pare-feu sur chaque commutateur du réseau local auquel le demandeur peut se connecter au réseau local. Le Juniper-Switching-Filter est équivalent à la règle NAS-Filter-Rule référencée dans l’attribut 92 de RFC4849.

  • Micro et macrosegmentation avec GBP à l’aide de Mist Access Assurance : vous pouvez appliquer la microsegmentation et la macrosegmentation dans une architecture VXLAN (Virtual Extensible LAN) à l’aide d’une stratégie basée sur des groupes (GBP). GBP s’appuie sur la technologie VXLAN sous-jacente pour fournir un contrôle d’accès indépendant de l’emplacement des terminaux. La GBP vous permet de mettre en uvre des politiques de sécurité cohérentes sur l’ensemble des domaines du réseau de l’entreprise. Vous évitez ainsi de configurer un grand nombre de filtres de pare-feu sur tous vos commutateurs et simplifiez la configuration de votre réseau. Le contrôle d’accès réseau (NAC) du cloud Juniper Mist attribue dynamiquement des balises GBP lors d’une transaction RADIUS. Grâce à l’authentification RADIUS 802.1X, les opérateurs réseau peuvent authentifier et autoriser automatiquement un utilisateur ou un équipement et le laisser entrer dans le réseau. Juniper Mist Access Assurance utilise l’identité de l’utilisateur et de l’équipement pour déterminer le rôle et le segment réseau que le réseau attribue à chaque utilisateur. Le réseau utilise VLAN ou GBP pour regrouper les utilisateurs en segments de réseau. Juniper Mist Access Assurance applique ensuite les politiques réseau associées à chaque segment

    Cette fonctionnalité est actuellement prise en charge sur les châssis virtuels EX4100, EX4400, EX4650, QFX5120-32C, QFX5120-48Y et sur les châssis virtuels QFX5120-48Y.

    Pour plus d’informations, voir, Example: Micro and Macro Segmentation using Group Based Policy in a VXLAN

Les fonctionnalités suivantes sont prises en charge pour authentifier les périphériques qui ne sont pas compatibles 802.1X :

  • Contournement MAC statique : fournit un mécanisme de contournement pour authentifier les périphériques qui ne sont pas compatibles 802.1X (tels que les imprimantes). Le contournement MAC statique connecte ces périphériques aux ports compatibles 802.1X, en contournant l’authentification 802.1X.

  • Authentification MAC RADIUS : permet d’autoriser les hôtes qui ne sont pas compatibles 802.1X à accéder au réseau local. MAC-RADIUS simule la fonctionnalité de demandeur de l’appareil client, en utilisant l’adresse MAC du client comme nom d’utilisateur et mot de passe.

Authentification 802.1X sur les ports trunk

À partir de Junos OS version 18.3R1, vous pouvez configurer l’authentification 802.1X sur les interfaces trunk, ce qui permet au périphérique d’accès réseau (NAS) d’authentifier un point d’accès (AP) ou un autre périphérique de couche 2 connecté. Un point d’accès ou un commutateur connecté au NAS prend en charge plusieurs VLAN et doit donc se connecter à un port trunk. L’activation de l’authentification 802.1X sur l’interface trunk protège le NAS d’une faille de sécurité dans laquelle un attaquant pourrait déconnecter l’AP et connecter un ordinateur portable pour obtenir un accès gratuit au réseau pour tous les VLAN configurés.

Veuillez noter les mises en garde suivantes lors de la configuration de l’authentification 802.1X sur les interfaces trunk.

  • Seuls les modes de demande unique et mono-sécurisé sont pris en charge sur les interfaces trunk.

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

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

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

  • La solution de secours contre échec serveur pour les clients VoIP n’est pas prise en charge sur les interfaces trunk (server-fail-voip).

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

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

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

Authentification 802.1X sur les interfaces de couche 3

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

  • Seuls les clients compatibles EAP sont pris en charge.

  • Seul le mode demandeur unique est pris en charge.

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

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

  • Le VLAN invité, le VLAN de rejet de serveur et le VLAN d’échec de serveur ne sont pas pris en charge.

  • La solution de secours en cas d’échec serveur pour les clients VoIP n’est pas prise en charge (server-fail-voip).

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

    • Nom d’utilisateur

    • Délai d’expiration de la session

    • ID de la station d’appel

    • Acct-Session-ID

    • ID de port NAS

    • Rebond de port

Prise en charge 802.1X sur le logiciel Junos OS Evolved

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

  • Les fonctionnalités non prises en charge sont les suivantes :

    • VLAN invité, VLAN de rejet de serveur et VLAN d’échec de serveur

    • Reprise de secours contre l’échec du serveur pour les clients VoIP (server-fail-voip)

    • VLAN dynamique

    • Authentification sur les interfaces de couche 2 à l’aide du portail captif et de l’authentification Web centrale (CWA).

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

    • ip-mac-session-binding

    • Juniper-CWA-Redirect

    • Filtre de commutation Juniper

    • ID de filtre

    • Tunnel-Moyen-Type

    • VoIP-VLAN Juniper

    • Nom du VLAN de sortie

    • ID VLAN de sortie

    • Type de tunnel

    • ID de groupe privé de tunnel

  • Si l’IRB se trouve dans le domaine de pont, les ports compatibles 802.1x n’abandonnent pas le trafic acheminé pour les modes de demande unique sécurisé et multiple, même si l’utilisateur n’est pas authentifié. Les ports compatibles 802.1x sur l’interface de couche 2 acheminent le trafic uniquement pour la configuration en mode demandeur unique.

Configuration des paramètres de l’interface 802.1X (procédure CLI)

L’authentification IEEE 802.1X assure la sécurité de la périphérie du réseau, protégeant les réseaux locaux Ethernet contre tout accès non autorisé des utilisateurs en bloquant tout le trafic à destination et en provenance d’un demandeur (client) à l’interface jusqu’à ce que les informations d’identification du demandeur soient présentées et mises en correspondance sur le authentication server serveur RADIUS. Lorsque le demandeur est authentifié, le commutateur cesse de bloquer l’accès et ouvre l’interface au demandeur.

REMARQUE :

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

Pour configurer le protocole 802.1X sur une interface :

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

    Le mode de demande multiple n’est pas pris en charge sur les interfaces trunk.

  2. Activez la réauthentification et spécifiez l’intervalle de réauthentification :
  3. Configurez la valeur du 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 ne renvoie une demande d’authentification au serveur RADIUS :
  5. Configurez la durée, en secondes, pendant laquelle l’interface attend avant de retransmettre les PDU EAPOL initiales au demandeur :
  6. Configurez le nombre maximal de fois qu’un paquet de requête EAPOL est retransmis au demandeur avant l’expiration de la session d’authentification :
  7. Configurez le nombre de tentatives d’authentification du port par le commutateur après une défaillance initiale. Le port reste dans un état d’attente pendant la période de silence qui suit la tentative d’authentification.
REMARQUE :

Si les serveurs d’authentification RADIUS deviennent indisponibles ou inaccessibles, la solution de secours en cas d’échec du serveur est déclenchée. Par défaut, l’option est configurée sous server-fail, ce qui force l’échec de l’authentification deny du demandeur. Toutefois, il existe d’autres options que vous pouvez configurer en tant qu’actions à effectuer pour les terminaux en attente d’authentification lorsque le serveur expire.

Pour plus d’informations, reportez-vous à la section Interface (802.1X)

REMARQUE :

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

Comprendre les modifications apportées à une session d’utilisateur autorisé par RADIUS

Lors de l’utilisation d’un service d’authentification basé sur un modèle RADIUS client/serveur, les requêtes sont généralement initiées par le client et envoyées au serveur RADIUS. Il existe des cas dans lesquels une requête peut être initiée par le serveur et envoyée au client afin de modifier dynamiquement une session d’utilisateur authentifié déjà en cours. Le client qui reçoit et traite les messages est le commutateur, qui fait office de serveur d’accès réseau (NAS). Le serveur peut envoyer au commutateur un message de déconnexion lui demandant de mettre fin à une session ou un message de changement d’autorisation (CoA) lui demandant de modifier les attributs d’autorisation de session.

Le commutateur écoute les requêtes RADIUS non sollicitées sur le port UPD 3799 et accepte uniquement les demandes provenant d’une source fiable. L’autorisation d’envoi d’une demande de déconnexion ou de CoA est déterminée en fonction de l’adresse source et du secret partagé correspondant, qui doivent être configurés sur le commutateur ainsi que sur le serveur RADIUS. Pour plus d’informations sur la configuration de l’adresse source et du secret partagé sur le commutateur, consultez Exemple : Connexion d’un serveur RADIUS pour 802.1X à un commutateur EX Series.

Messages de déconnexion

Le serveur RADIUS envoie un message de demande de déconnexion au commutateur afin de mettre fin à une session utilisateur et d’ignorer tout le contexte de session associé. Le commutateur répond à un paquet Disconnect-Request par un message Disconnect-ACK si la demande réussit, c’est-à-dire que tout le contexte de session associé est ignoré et que la session utilisateur n’est plus connectée, ou par un paquet Disconnect-NAK si la demande échoue, c’est-à-dire que l’authentificateur ne peut pas déconnecter la session et ignorer tout le contexte de session associé.

Dans les messages de demande de déconnexion, les attributs RADIUS sont utilisés pour identifier de manière unique le commutateur (NAS) et la session utilisateur. La combinaison des attributs d’identification NAS et des attributs d’identification de session incluse dans le message doit correspondre à au moins une session pour que la demande aboutisse ; sinon, le commutateur répond par un message Disconnect-NAK. Un message de demande de déconnexion ne peut contenir que des attributs d’identification de session et de NAS ; si d’autres attributs sont inclus, le commutateur répond par un message Disconnect-NAK.

Modification des messages d’autorisation

Les messages de changement d’autorisation (CoA) contiennent des informations permettant de modifier dynamiquement les attributs d’autorisation d’une session utilisateur afin de changer le niveau d’autorisation. Cela se produit dans le cadre d’un processus d’authentification en deux étapes, dans lequel le point de terminaison est d’abord authentifié à l’aide de l’authentification MAC RADIUS, puis est profilé en fonction du type d’appareil. Le message CoA permet d’appliquer une stratégie d’application adaptée à l’appareil, généralement en modifiant les filtres de données ou le VLAN.

Le commutateur répond à un message CoA par un message CoA-ACK si la modification de l’autorisation réussit, ou un message avec CoA-NAK si la modification échoue. Si une ou plusieurs modifications d’autorisation spécifiées dans un message CoA-Request ne peuvent pas être effectuées, le commutateur répond par un message CoA-NAK.

Dans les messages CoA-Request, les attributs RADIUS sont utilisés pour identifier de manière unique le commutateur (agissant comme le NAS) et la session utilisateur. Pour que la demande aboutisse, la combinaison des attributs d’identification NAS et des attributs d’identification de session incluse dans le message doit correspondre aux attributs d’identification d’au moins une session. sinon, le commutateur répond par un message CoA-NAK.

Les paquets CoA-Request incluent également les attributs d’autorisation de session qui seront modifiés si la demande est acceptée. Les attributs d’autorisation de session pris en charge sont répertoriés ci-dessous. Le message CoA peut contenir tout ou partie de ces attributs. Si un attribut n’est pas inclus dans le message CoA-Request, le NAS suppose que la valeur de cet attribut doit rester inchangée.

  • ID de filtre

  • ID de groupe privé de tunnel

  • Filtre de commutation Juniper

  • VoIP-VLAN Juniper

  • Délai d’expiration de la session

Rebond de port de demande CoA

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

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

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

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

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

Vous pouvez désactiver la fonctionnalité en configurant l’instruction ignore-port-bounce au niveau de la hiérarchie [edit protocols dot1x authenticator interface interface-name].

Codes d’erreur et de cause

Lorsqu’une opération de déconnexion ou de CoA échoue, un attribut Erreur-Cause (attribut RADIUS 101) peut être inclus dans le message de réponse envoyé par le NAS au serveur pour fournir des détails sur la cause du problème. Si l’erreur détectée ne correspond pas à l’une des valeurs d’attribut Erreur-Cause prises en charge, le routeur envoie le message sans attribut erreur-cause. Reportez-vous à la section Tableau 1 pour obtenir une description des codes de cause d’erreur qui peuvent être inclus dans les messages de réponse envoyés à partir du NAS.

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 demande de déconnexion si une ou plusieurs sessions utilisateur ne sont plus actives, mais que le contexte de session résiduel a été trouvé et supprimé avec succès. Ce code n’est envoyé que dans un message Disconnect-ACK.

401

Attribut non pris en charge

La requête contient un attribut qui n’est pas pris en charge (par exemple, un attribut tiers).

402

Attribut manquant

Un attribut critique (par exemple, l’attribut d’identification de session) est manquant dans une requête.

403

Incompatibilité d’identification NAS

La demande contient un ou plusieurs attributs d’identification NAS qui ne correspondent pas à l’identité du NAS qui reçoit la demande.

404

Demande non valide

Un autre aspect de la requête n’est pas valide, par exemple si un ou plusieurs attributs ne sont pas correctement formatés.

405

Service non pris en charge

L’attribut Service-Type inclus dans la demande contient une valeur non valide ou non prise en charge.

406

Extension non prise en charge

L’entité qui reçoit la demande (NAS ou proxy RADIUS) ne prend pas en charge les requêtes initiées par RADIUS.

407

Valeur d’attribut non valide

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

501

Interdiction administrative

Le NAS est configuré pour interdire le respect des messages de demande de déconnexion ou de demande CoA pour la session spécifiée.

503

Contexte de session introuvable

Le contexte de session identifié dans la demande n’existe pas sur le NAS.

504

Contexte de session non amovible

L’abonné identifié par des attributs dans la requête appartient à un composant qui n’est pas pris en charge. Ce code n’est envoyé que dans un message Disconnect-NAK.

506

Ressources non disponibles

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

507

Demande initiée

Le message CoA-Request inclut un attribut Service-Type avec la valeur Autoriser uniquement.

508

Sélection de plusieurs sessions non prise en charge

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

Filtrage des demandeurs 802.1X à l’aide des attributs du serveur RADIUS

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

  • Incluez un ou plusieurs termes de filtre dans l’attribut Juniper-Switching-Filter. L’attribut Juniper-Switching-Filter est un attribut spécifique au fournisseur (VSA) répertorié sous l’attribut numéro 48 dans le dictionnaire Juniper sur le serveur RADIUS. Utilisez ce VSA pour configurer des conditions de filtrage simples pour les utilisateurs authentifiés 802.1X. Rien n’a besoin d’être configuré sur le commutateur ; toute la configuration se trouve sur le serveur RADIUS.

  • Configurez un filtre de pare-feu local sur chaque commutateur et appliquez-le aux utilisateurs authentifiés via le serveur RADIUS. Utilisez cette méthode pour les filtres plus complexes. Le filtre de pare-feu doit être configuré sur chaque commutateur.

    REMARQUE :

    Si la configuration du filtre de pare-feu est modifiée après que les utilisateurs ont été authentifiés à l’aide de l’authentification 802.1X, la session d’authentification 802.1X établie doit être interrompue et rétablie pour que les modifications apportées à la configuration du filtre de pare-feu prennent effet.

Cette rubrique comprend les tâches suivantes :

Configuration des filtres de pare-feu sur le serveur RADIUS

À partir de Junos OS Evolved version 22.4R1, vous pouvez configurer plusieurs ports source et de destination (ou plages de ports) sur une même ligne sans avoir à répéter la condition de correspondance. Cette fonctionnalité permet de raccourcir la longueur des VSA et de réduire la taille des paquets de réponse RADIUS.

Le filtre de commutation permet de provisionner une liste de valeurs pour le type d’éther, l’adresse IP, la balise source, le port source et le port de destination.

Juniper-Switching-Filter = match dst-port [ 80 25 443 ] src-port [5060 1025-2000] action allow

Juniper-Switching-Filter = match dst-port 500 source-tag [ 100, 200 ] action allow

Juniper-Switching-Filter = match src-port 9090 ip-proto [ 25 17] action allow

Juniper-Switching-Filter = match ether-type [ 3000-4000 8000 ] action allow

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

REMARQUE :

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

Pour configurer l’attribut Juniper-Switching-Filter, saisissez un ou plusieurs termes de filtre à l’aide de l’interface de ligne de commande du serveur RADIUS. Chaque terme de filtre se compose de conditions de correspondance avec une action correspondante. Saisissez les termes de filtre entre guillemets ( » « ) en utilisant la syntaxe suivante :

Plusieurs conditions de correspondance peuvent être incluses dans un terme de filtre. Lorsque plusieurs conditions sont spécifiées dans un terme de filtre, elles doivent toutes être remplies pour que le paquet corresponde au terme de filtre. Par exemple, le terme de filtre suivant exige qu’un paquet corresponde à la fois à l’adresse IP de destination et à l’adresse MAC de destination pour répondre aux critères du terme :

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

Reportez-vous à la section Conditions et actions de correspondance VSA de Juniper-Switching-Filter pour obtenir la définition des conditions de correspondance et des actions.

REMARQUE :

Sur les commutateurs EX9200 et dans un Junos Fusion Enterprise avec EX9200 comme périphérique agrégé, le filtre de pare-feu dynamique est strictement appliqué à tous les paquets IP. Si le filtre est configuré pour n’autoriser qu’une adresse IP de destination spécifique, les paquets avec d’autres adresses IP comme adresse IP de destination seront abandonnés conformément aux règles de filtrage. Cela inclut tous les paquets de protocole IP, tels que les paquets DHCP, IGMP et ARP.

Pour configurer les conditions de correspondance sur le serveur RADIUS :

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

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

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

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

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

      Pour chaque utilisateur pertinent, 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 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 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 à appliquer à chaque utilisateur qui demande une authentification, ce qui réduit la nécessité de configurer le même filtre de pare-feu sur plusieurs commutateurs. Utilisez cette méthode lorsque le filtre de pare-feu contient un grand nombre de conditions ou que vous souhaitez utiliser des conditions différentes pour le même filtre sur différents commutateurs. Les filtres de pare-feu doivent être configurés sur chaque commutateur.

Pour plus d’informations sur les filtres de pare-feu, reportez-vous à Présentation des filtres de pare-feu pour commutateurs EX Series.

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

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 sont prioritaires s’ils entrent en conflit avec les filtres de pare-feu de port configurés localement. S’il n’y a pas de conflit, ils sont fusionnés.

  1. Créez le filtre de pare-feu sur le commutateur local. Reportez-vous à la section 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 fichier pour afficher les profils d’utilisateurs locaux des terminaux auxquels vous souhaitez appliquer le users 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 utilisateur ci-dessous inclut supplicant1 l’attribut Filter-ID avec le nom filter1du filtre :

    REMARQUE :

    Plusieurs filtres ne sont pas pris en charge sur une seule interface. Toutefois, 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’un serveur RADIUS 802.1X à un commutateur EX Series

802.1X est la norme IEEE pour le contrôle d’accès réseau basé sur les ports (PNAC). La norme 802.1X vous permet de contrôler l’accès au réseau. Seuls les utilisateurs et les appareils fournissant des informations d’identification vérifiées par rapport à une base de données d’utilisateurs sont autorisés à accéder au réseau. Vous pouvez utiliser un serveur RADIUS comme base de données utilisateur pour l’authentification 802.1X, ainsi que pour l’authentification MAC RADIUS.

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

Conditions préalables

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

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

  • Un commutateur EX Series faisant office d’entité d’accès au port d’authentification (PAE). Les ports de l’authentificateur PAE forment une porte de contrôle qui bloque tout le trafic à destination et en provenance des demandeurs jusqu’à ce qu’ils soient authentifiés.

  • Un serveur d’authentification RADIUS compatible 802.1X. Le serveur d’authentification fait office de base de données principale et contient les informations d’identification des hôtes (demandeurs) autorisés à se connecter au réseau.

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

Vue d’ensemble et topologie

Le commutateur EX Series agit comme un PAE d’authentification. Il bloque tout le trafic et agit comme une porte de contrôle jusqu’à ce que le demandeur (client) soit authentifié par le serveur. L’accès est refusé à tous les autres utilisateurs et appareils.

Figure 1montre un commutateur EX4200 connecté aux périphériques répertoriés à la .Tableau 2

Figure 1 : Topologie pour la configurationTopologie pour la 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 serveur RADIUS

Base de données principale avec une adresse 10.0.0.100 connectée au commutateur sur le port ge-0/0/10

Dans cet exemple, connectez le serveur RADIUS au port d’accès ge-0/0/10 du commutateur EX4200. Le commutateur agit en tant qu’authentificateur et transmet les informations d’identification du demandeur à la base de données des utilisateurs sur le serveur RADIUS. Vous devez configurer la connectivité entre l’EX4200 et le serveur RADIUS en spécifiant l’adresse du serveur et en configurant le mot de passe secret. Ces informations sont configurées dans un profil d’accès sur le commutateur.

REMARQUE :

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

Configuration

Procédure

Configuration rapide de l’interface de ligne de commande

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

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 sur le commutateur doit correspondre au mot de passe secret sur le serveur :

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

  3. Configurez une liste d’adresses IP de serveur à essayer dans l’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 opérations suivantes :

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

But

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

Action

Envoyez une requête ping au serveur RADIUS pour vérifier la connexion entre le commutateur et le serveur :

Sens

Les paquets de demande d’écho ICMP sont envoyés du commutateur au serveur cible à l’adresse 10.0.0.100 pour vérifier si le serveur est accessible sur le réseau IP. Les réponses d’écho ICMP sont renvoyées par le serveur, ce qui permet de vérifier que le commutateur et le serveur sont connectés.

Présentation des filtres dynamiques basés sur les attributs RADIUS

Vous pouvez utiliser les attributs de serveur RADIUS pour implémenter des filtres de pare-feu de port sur un serveur d’authentification RADIUS. Ces filtres peuvent être appliqués dynamiquement aux demandeurs qui demandent une authentification via ce serveur. Les attributs de serveur RADIUS sont des champs en texte clair encapsulés dans les messages d’accès-acceptation envoyés par le serveur d’authentification au commutateur lorsqu’un demandeur connecté au commutateur est authentifié avec succès. Le commutateur, agissant en tant qu’authentificateur, utilise les informations des attributs RADIUS pour appliquer les filtres associés au demandeur. Les filtres dynamiques peuvent être appliqués à plusieurs ports d’un même commutateur ou à plusieurs commutateurs utilisant le même serveur d’authentification, assurant ainsi un contrôle d’accès centralisé au réseau.

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

Vous pouvez également appliquer un filtre de pare-feu de port à plusieurs ports sur le même commutateur à l’aide de l’attribut Filter-ID, qui est l’ID d’attribut RADIUS numéro 11. Pour utiliser l’attribut Filter-ID, vous devez d’abord configurer un filtre sur le commutateur, puis ajouter le nom du filtre aux stratégies utilisateur sur le serveur RADIUS en tant que valeur de l’attribut Filter-ID. Lorsqu’un demandeur défini dans l’une de ces stratégies est authentifié par le serveur RADIUS, le filtre est appliqué au port de commutation qui a été authentifié pour le demandeur. Utilisez cette méthode lorsque le filtre de pare-feu comporte des conditions complexes ou si vous souhaitez utiliser des conditions différentes pour le même filtre sur différents commutateurs. Le filtre nommé dans l’attribut Filter-ID doit être configuré localement sur le commutateur au niveau de la hiérarchie [edit firewall family ethernet-switching filter].

Les VSA sont pris en charge uniquement pour les configurations 802.1X à demandeur unique et les configurations à demandeurs multiples.

Présentation de l’affectation dynamique de VLAN à l’aide des attributs RADIUS

Les VLAN peuvent être attribués dynamiquement par un serveur RADIUS aux demandeurs demandant une authentification 802.1X via ce serveur. Vous configurez le VLAN sur le serveur RADIUS à l’aide des attributs de serveur RADIUS, qui sont des champs en texte clair encapsulés dans les messages envoyés par le serveur d’authentification au commutateur lorsqu’un demandeur connecté au commutateur demande l’authentification. Le commutateur, agissant en tant qu’authentificateur, utilise les informations des attributs RADIUS pour attribuer le VLAN au demandeur. En fonction des résultats de l’authentification, un demandeur qui a commencé à s’authentifier dans un VLAN peut être affecté à un autre VLAN.

Pour réussir l’authentification, il faut que l’ID de VLAN ou le nom de VLAN soit configuré sur le commutateur agissant comme un authentificateur 802.1X et qu’il corresponde à l’ID de VLAN ou au nom de VLAN envoyé par le serveur RADIUS lors de l’authentification. Si ni l’un ni l’autre n’existe, le terminal n’est pas authentifié. Si un VLAN invité est établi, le terminal non authentifié est automatiquement déplacé vers le VLAN invité.

Attributs de serveur RADIUS utilisés pour l’attribution dynamique de VLAN décrits dans la RFC 2868, Attributs RADIUS pour la prise en charge des protocoles de tunnel.

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

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

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

Pour plus d’informations sur la configuration des VLAN dynamiques sur votre serveur RADIUS, reportez-vous à la documentation de votre serveur RADIUS.

Configuration des groupes VLAN sur les commutateurs EX Series

La fonctionnalité de groupe VLAN vous permet de répartir les clients sur les VLAN. Lorsque vous activez cette fonctionnalité, vous pouvez aligner un seul LAN sans fil (WLAN) sur un seul VLAN ou sur plusieurs VLAN. Lorsque vous configurez un groupe de VLAN, un client est affecté à l’un des VLAN configurés. Cette fonctionnalité prend en charge l’équilibrage de charge dynamique des utilisateurs sur les VLAN d’un groupe de VLAN. Cette fonctionnalité suit l’algorithme Round-Robin pour affecter les utilisateurs au prochain VLAN disponible dans un groupe de VLAN.

Pour un équilibrage de charge VLAN dynamique, vous ajoutez le nom du groupe VLAN au lieu d’un ID VLAN standard ou d’un nom VLAN dans l’attribut (défini dans RFC Tunnel-Private-Group-ID 2868 comme type d’attribut RADIUS 81). Par la suite, vous envoyez ces informations dans la réponse RADIUS lorsqu’un demandeur demande une authentification 802.1X via le serveur RADIUS. Lorsque le commutateur reçoit le nom du groupe de VLAN, il affecte le point de terminaison à l’un des VLAN de ce groupe à l’aide de l’algorithme Round-Robin. Le groupe VLAN permet d’allouer un VLAN à partir d’une liste préconfigurée, réduisant ainsi la nécessité pour les administrateurs d’équilibrer la charge du réseau.

Lorsque vous configurez un groupe VLAN, notez que :

  • Vous pouvez configurer un maximum de 4096 groupes VLAN.

  • Vous devez créer un VLAN avant de l’allouer aux clients. Tout VLAN qui n’existe pas sur le commutateur est ignoré lors de l’allocation.

  • Un nom de VLAN ne peut pas être le même que le nom d’un groupe de VLAN.

  • Un VLAN VoIP ne doit pas faire partie d’un groupe de vlan. Un VLAN VoIP, s’il est présent, sera ignoré.

  • Lorsque vous supprimez un VLAN, toutes les sessions authentifiées 802.1X associées à ce VLAN sont résiliées.

  • Vous pouvez supprimer un groupe de VLAN sans perturber les clients qui ont déjà été alloués aux VLAN de ce groupe de VLAN.

  • Vous pouvez supprimer un VLAN d’un groupe de VLAN sans perturber les clients qui ont déjà été alloués à ce VLAN. Toutefois, un client peut être confronté à une perturbation si :

    • La session client expire.

    • Une réauthentification ou un changement de rôle est effectué à l’aide d’une demande de changement d’autorisation (CoA).

Pour configurer des groupes VLAN sur des commutateurs EX Series :

  1. Configurez vlans vlan-groups vlan_group_name. Utilisez la commande suivante :
  2. Validez la configuration et quittez le mode de configuration.
  3. Pour vérifier les résultats de la configuration sur un commutateur :

Comprendre les VLAN invités pour 802.1X sur les commutateurs

Les VLAN invités peuvent être configurés sur des commutateurs qui utilisent l’authentification 802.1X pour fournir un accès limité, généralement uniquement à Internet, aux invités d’entreprise. Le VLAN invité est utilisé comme solution de secours dans les cas suivants :

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

  • L’authentification MAC RADIUS n’a pas été configurée sur les interfaces de commutateur auxquelles le demandeur est connecté.

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

Un VLAN invité n’est pas utilisé pour les demandeurs qui envoient des informations d’identification incorrectes. Ces demandeurs sont dirigés vers le VLAN de rejet du serveur à la place.

Pour les terminaux qui ne sont pas compatibles 802.1X, un VLAN invité peut autoriser un accès limité à un serveur à partir duquel le terminal non compatible 802.1X peut télécharger le logiciel demandeur et tenter à nouveau de s’authentifier.

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

La solution de secours contre les échecs de 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.

La norme 802.1X vous permet de contrôler l’accès au réseau. Seuls les utilisateurs et les appareils (demandeurs) fournissant des informations d’identification vérifiées par rapport à une base de données d’utilisateurs sont autorisés à accéder au réseau. Vous 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 d’un 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 faisant office d’entité d’accès au port d’authentification (PAE). Les ports de l’authentificateur PAE forment une porte de contrôle qui bloque tout le trafic à destination et en provenance des demandeurs jusqu’à ce qu’ils soient authentifiés.

  • Un serveur d’authentification RADIUS compatible 802.1X. Le serveur d’authentification fait office de base de données principale et contient les informations d’identification des hôtes (demandeurs) autorisés à se connecter au réseau.

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

Vue d’ensemble et topologie

Un délai d’expiration du serveur RADIUS se produit si aucun serveur RADIUS d’authentification n’est joignable lorsqu’un demandeur se connecte et tente d’accéder au réseau local. À l’aide de la solution de secours contre échec de serveur, vous configurez d’autres options pour les demandeurs qui tentent d’accéder au réseau local. Vous pouvez configurer le commutateur pour qu’il accepte ou refuse l’accès aux demandeurs ou pour qu’il conserve 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 d’expiration RADIUS se produit.

Figure 2 montre la topologie utilisée pour cet exemple. Le serveur RADIUS est connecté au commutateur EX4200 sur le port ge-0/0/10d’accès . Le commutateur joue le rôle d’entité d’accès au port d’authentification (PAE) et transmet les informations d’identification du demandeur à la base de données utilisateur 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 configurer les options 802.1XTopologie pour configurer les 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

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

Un serveur RADIUS

Base de données principale avec l’adresse de 10.0.0.100 connecté au commutateur sur le 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 réseau local pendant un délai d’expiration RADIUS vers un autre VLAN. Un délai d’expiration RADIUS empêche l’échange normal des messages EAP qui transportent les 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 d’expiration 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 de l’interface de ligne de commande

Pour configurer rapidement la solution de secours en cas 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 afin de rediriger les demandeurs vers un VLAN spécifique lorsqu’un délai d’expiration RADIUS se produit (ici, le VLAN est vlan-sf) :

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

Résultats

Affichez les résultats de la configuration :

Vérification

Pour vérifier que la configuration fonctionne correctement, effectuez les opérations suivantes :

Vérification du déplacement des demandeurs vers un autre VLAN lors d’un délai d’expiration RADIUS

But

Vérifiez que l’interface déplace les demandeurs vers un autre VLAN lors d’un délai d’expiration 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 qui prend en charge ELS, consultez show vlan. Pour plus d’informations sur ELS, reportez-vous à la section Utilisation de l’interface de ligne de commande 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’attente du serveur RADIUS se produit. Affichez le tableau de commutation Ethernet pour montrer que le demandeur avec l’adresse MAC 00:00:00:00:00:01 accédant précédemment au LAN via le VLAN est maintenant en cours d’apprentissage sur le default VLAN nommé vlan-sf:

Affichez les informations du protocole 802.1X pour indiquer que l’interface ge-0/0/1.0 est en cours de connexion et ouvrira l’accès LAN aux demandeurs :

Sens

La show vlans commande affiche l’interface ge-0/0/1.0default en tant que membre du 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 MAC 00:00:00:00:00:01. 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 MAC 00:00:00:00:00:01 est apprise sur le VLAN vlan-sf. Le demandeur a été déplacé du default VLAN vers le vlan-sf VLAN. Le demandeur est ensuite connecté au réseau local via le VLAN nommé vlan-sf.

Exemple : Configuration des options de secours sur les commutateurs EX Series pour l’authentification EAP-TTLS et les clients d’accès Odyssey

Pour l’authentification utilisateur 802.1X, les commutateurs EX Series prennent en charge les serveurs d’authentification RADIUS qui utilisent le protocole EAP-TTLS (Extensible Authentication Protocol–Tunneled TLS) pour authentifier les demandeurs OAC (Odyssey Access Client). Le logiciel de mise en réseau du CAO s’exécute sur les ordinateurs terminaux (ordinateurs de bureau, ordinateurs portables, blocs-notes et appareils sans fil pris en charge) et fournit un accès sécurisé aux réseaux filaires et sans fil.

Cet exemple décrit comment configurer une interface compatible 802.1X sur le commutateur pour fournir une prise en charge de secours aux utilisateurs OAC qui ont entré des informations d’identification de connexion incorrectes :

Conditions préalables

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

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 faisant office d’entité d’accès au port d’authentification (PAE). Les ports de l’authentificateur PAE forment une porte de contrôle qui bloque tout le trafic à destination et en provenance des demandeurs jusqu’à ce qu’ils soient authentifiés.

  • Un serveur d’authentification RADIUS compatible 802.1X. Le serveur d’authentification fait office de base de données principale et contient les informations d’identification des hôtes (demandeurs) autorisés à se connecter au réseau.

  • Un terminal OAC agissant en tant que suppliant.

Avant de commencer à configurer l’option de secours, assurez-vous que vous disposez des éléments suivants :

  • Établissez une connexion entre le commutateur et le serveur RADIUS. Voir l’exemple : Connexion d’un serveur RADIUS pour 802.1X à un commutateur EX Series.

  • Configuration EAP-TTLS sur le serveur - effectué. Reportez-vous à la documentation de votre serveur RADIUS.

  • Utilisateurs configurés sur le serveur RADIUS - effectué. Reportez-vous à la documentation de votre serveur RADIUS.

Vue d’ensemble et topologie

OAC est un logiciel de mise en réseau qui s’exécute sur les ordinateurs terminaux (ordinateurs de bureau, portables ou bloc-notes) et les périphériques sans fil pris en charge. Le CAO fournit une prise en charge complète du PAE, qui est requis pour un accès sécurisé au LAN sans fil.

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

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

  • Maintient la confidentialité des identifiants de connexion.

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

Cet exemple inclut la configuration d’un VLAN de rejet de serveur sur le commutateur, qui peut être utilisé pour empêcher le verrouillage accidentel pour les utilisateurs qui ont entré des identifiants de connexion incorrects. Ces utilisateurs peuvent bénéficier d’un accès LAN limité.

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

  • eapol-block: activez le temporisateur de bloc EAPoL sur l’interface 802.1X configurée pour appartenir au VLAN de rejet du serveur. Le minuteur de blocage fait en sorte que l’entité d’accès au port d’authentification ignore les messages de démarrage EAP du client, ce qui tente de redémarrer la procédure d’authentification.

    REMARQUE :

    Le temporisateur de bloc EAPoL n’est déclenché qu’une fois que le nombre configuré de nouvelles tentatives autorisées (à l’aide de l’option) sur l’interface retries 802.1X a été épuisé. Vous pouvez configurer retries pour spécifier le nombre de tentatives d’authentification du port par le commutateur après une défaillance initiale. La valeur par défaut est de trois tentatives.

  • block-interval: configurez la durée pendant laquelle vous souhaitez que le minuteur de bloc EAPoL continue d’ignorer les messages de démarrage EAP. Si vous ne configurez pas l’intervalle de blocage, le minuteur de blocage EAPoL est défini par défaut sur 120 secondes.

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

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

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

REMARQUE :

Ce chiffre s’applique également aux commutateurs QFX5100.

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

Topologie

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

Tableau 4 : Composantes du déploiement du CAO
Propriété Paramètres

Matériel de commutation

Commutateur EX Series

VLAN

default

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

Interface 802.1X

ge-0/0/8

Demandeur de l’OAC

EAP-TTLS (en anglais seulement)

Un serveur d’authentification RADIUS

EAP-TTLS (en anglais seulement)

Configuration

Procédure

Configuration rapide de l’interface de ligne de commande

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

Procédure étape par étape

Pour configurer les options de secours 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 du VLAN ou l’ID de 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 identifiants de connexion incorrects :

  2. Configurez le nombre de fois que le client doit être invité à entrer son nom d’utilisateur et son mot de passe avant qu’une connexion incorrecte ne soit dirigée vers le VLAN server-reject :

  3. Configurez l’interface de l’authentificateur 802.1X pour utiliser le VLAN server-reject comme solution de secours en cas de connexion incorrecte :

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

  5. Configurez la durée pendant laquelle le bloc EAPoL doit rester actif :

Résultats

Vérifiez les résultats de la configuration :

Vérification

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

Vérification de la configuration de l’interface 802.1X

But

Vérifiez que l’interface 802.1X est configurée avec les options souhaitées.

Action
Sens

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

Surveillance de l’authentification 802.1X

But

REMARQUE :

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

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

Action

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

Pour afficher les détails de l’authentification dans l’interface de ligne de commande, entrez les commandes suivantes :

  • show dot1x interface detail | display xml

  • show dot1x interface detail <interface> | display xml

  • show dot1x auth-failed-users

Sens

Les détails affichés sont les suivants :

  • Liste des utilisateurs authentifiés.

  • Le nombre d’utilisateurs connectés.

  • Liste des utilisateurs dont l’authentification a échoué.

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

Vérification de l’authentification 802.1X

But

Vérifiez que les demandeurs sont authentifiés sur une interface d’un commutateur dont l’interface est configurée pour l’authentification 802.1X et affichez la méthode d’authentification utilisée.

Action

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

Sens

L’exemple de sortie de la commande montre que la show dot1x interface detailNumber of connected supplicants valeur est 1. Le demandeur qui a été authentifié et qui est maintenant connecté au réseau local est connu sous le nom de user5 sur le serveur RADIUS et possède l’adresse MAC 00:30:48:8C:66:BD. Le demandeur a été authentifié à l’aide de la méthode d’authentification 802.1X appelée authentification RADIUS, comme indiqué dans Radius la sortie. Lorsque l’authentification RADIUS est utilisée, le demandeur est configuré sur le serveur RADIUS, le serveur RADIUS le communique au commutateur et le commutateur ouvre un accès LAN sur l’interface à laquelle le demandeur est connecté. L’exemple de sortie montre également que le demandeur est connecté au VLAN v200.

Outre l’authentification RADIUS, les autres méthodes d’authentification 802.1X prises en charge sur les commutateurs EX Series sont :

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

  • Rayon MAC—Un hôte qui ne répond pas est authentifié en fonction de son adresse MAC. L’adresse MAC est configurée comme autorisée sur le serveur RADIUS, le serveur RADIUS informe le commutateur que l’adresse MAC est une adresse autorisée et le commutateur accorde l’accès LAN à l’hôte qui ne répond pas sur l’interface à laquelle il est connecté.

  • Server-fail deny : si les serveurs RADIUS expirent, tous les demandeurs se voient refuser l’accès au réseau local, ce qui empêche le trafic du demandeur de traverser l’interface. Il s’agit de l’option par défaut.

  • Autorisation d’échec du serveur : lorsque le serveur RADIUS n’est pas disponible, un demandeur est toujours autorisé à accéder au réseau local comme s’il avait été authentifié avec succès par le serveur RADIUS.

  • Server-fail use-cache : si les serveurs RADIUS expirent lors de la réauthentification, les demandeurs précédemment authentifiés se voient accorder un accès au LAN, mais les nouveaux demandeurs se voient refuser l’accès au LAN.

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

Dépannage de l’authentification des terminaux sur les commutateurs EX Series

Problème

Description

Les terminaux configurés à l’aide d’adresses MAC statiques perdent la connexion au commutateur après l’exécution de la commande clear dot1x interface pour effacer toutes les adresses MAC apprises.

Avant d’effacer les adresses MAC :

Pour effacer les adresses MAC :

Après avoir effacé les adresses MAC :

Notez qu’il n’y a pas de terminaux sur la liste de contournement de l’authentification.

La cause

Les adresses MAC statiques sont traitées de la même manière que les autres adresses MAC apprises sur une interface. Lorsque la commande clear dot1x interface est exécutée, elle efface toutes les adresses MAC apprises de l’interface, y compris la liste de contournement MAC statique (également connue sous le nom de liste d’exclusion).

Solution

Si vous exécutez la commande clear dot1x interfaces pour une interface dont les adresses MAC statiques sont configurées pour le contournement de l’authentification, ajoutez à nouveau les adresses MAC statiques à la liste de contournement MAC statique.

Attributs RADIUS et attributs spécifiques aux fournisseurs (VSA) de Juniper Networks pris en charge par 802.1X

L’authentificateur (serveur d’accès réseau), le demandeur (client) et le serveur d’authentification sont tous impliqués dans l’authentification 802.1X (serveur RADIUS). Le protocole RADIUS est utilisé comme mécanisme de requête/réponse pour la communication entre le NAS et le serveur Radius. Il y a zéro ou plusieurs valeurs de longueur de type (TLV/attributs) dans les requêtes et les réponses.

L’accès de chaque demandeur peut être restreint à l’aide d’un ensemble standard de fonctionnalités définies et d’attributs spécifiques au fournisseur activés par la norme 802.1X. (client). Certains attributs peuvent être utilisés plusieurs fois afin de prendre en charge des valeurs plus longues, car l’attribut Radius Class a une taille maximale de 253 octets.

Avantages de l’utilisation des attributs standard RADIUS et des VSA

Pour se connecter à un serveur RADIUS externe à des fins d’authentification, d’autorisation et de comptabilisation des abonnés, des attributs standard RADIUS sont requis.

Les VSA permettent la mise en œuvre de nombreuses fonctionnalités utiles nécessaires à la gestion des abonnés et à la prise en charge des services, étendant ainsi les capacités du serveur RADIUS au-delà de ce qui est fourni par les attributs standard publics.

Attributs Radius et liste VSA pris en charge par la norme 802.1X

Tableau 5 lists the RADIUS Attributes and VSAs supported by 802.1X.
Tableau 5 : Attributs Radius et liste VSA pris en charge par la norme 802.1X
Type Attribut

1

Nom d’utilisateur

11

ID de filtre

24

État

25

Classe

26

Spécifique au fournisseur

27

Délai d’expiration de la session

56

VLANID de sortie

57

Nom du VLAN de sortie

64

Type de tunnel

+ de 65

Tunnel-Moyen-Type

81

ID de groupe privé de tunnel

85

Intervalle Acct-Interim

102

EAP-Nom-clé
Tableau 6lists the Vendor IDs and Juniper VSAs.
Tableau 6 : ID de fournisseurs et VSA Juniper
ID du fournisseur Nombre VSA Juniper VSA Microsoft Cisco VSA
2636 48 Filtre de commutation Juniper    
49 Juniper-VoIP-VLAN
50 Juniper-CWA-Redirect-URL
21 Juniper-AV-Paire =

Rebond de port

Juniper-AV-Pair = Juniper Ip-Mac-Session-Binding

Juniper-AV-Pair = No-Mac-Binding-Reauth

Juniper-AV-Pair = Mode demandeur-unique

Juniper-AV-Pair = Mode demandeur-Single-Secure

Juniper-AV-Pair = Retain-Mac-Aged-Session

311 16   MS-MPPE-Send-Key  
17 MS-MPPE-Recv-Key
9 1    

Cisco-AVPair =

« subscriber :command=bounce-host-port »

Cisco-AVPair = « subscriber :command=reauthenticate »

Cisco-AVPair =

« subscriber :reauthenticate-type=rerun »

« subscriber :reauthenticate-type=last »
« redirection-url »

Attributs RADIUS pris en charge par la norme 802.1X

Nom d’utilisateur :

Le nom de l’utilisateur qui doit être vérifié est indiqué par cet attribut. S’ils sont disponibles, les paquets Access-Request doivent être utilisés pour envoyer cet attribut. Le type RADIUS de cet attribut est 1.

ID de filtre :

Sur le serveur RADIUS, les stratégies utilisateur peuvent être soumises à un filtre de pare-feu. Le serveur RADIUS peut ensuite être utilisé pour spécifier les filtres de pare-feu à appliquer à chaque utilisateur qui soumet une demande d’authentification. Chaque commutateur doit être configuré avec des filtres de pare-feu.

You must set up firewall filter on the local switch in order to apply filter centrally from the RADIUS server.

Ajoutez le filtre pour chaque utilisateur concerné.

Filter-Id = Filter1

To activate the configuration, restart the RADIUS server now.
REMARQUE : Les VSA sont prioritaires sur les filtres si des filtres de pare-feu de port sont également spécifiés localement pour l’interface. Les VSA et les filtres de pare-feu de port local sont intégrés s’ils n’entrent pas en conflit. De plus, il n’est pas possible d’implémenter plus d’un filtre sur une même interface. Toutefois, en établissant un filtre unique avec des stratégies pour chacun de ces utilisateurs, vous pouvez prendre en charge plusieurs filtres pour de nombreux utilisateurs connectés au commutateur sur la même interface.

État :

Entre l’équipement et le serveur RADIUS, les informations d’état peuvent être conservées à l’aide de l’attribut String. Le type RADIUS de cet attribut est 24.

VLANID de sortie :

Un VLANID de sortie IEEE 802 autorisé pour ce port est représenté par l’attribut Egress-VLANID qui spécifie également si le VLANID est autorisé pour les trames balisées ou non étiquetées en plus de VLANID. L’attribut Egress-VLANID est défini dans la RFC 4675.

Les attributs Egress-VLANID des paquets Access-Request, Access-Accept ou CoA-Request peuvent inclure plusieurs valeurs. Aucune caractéristique ne peut inclure cette caractéristique : Access-Challenge, Access-Reject, Disconnect-Request, Disconnect-ACK, Disconnect-NAK, CoA-ACK ou CoA-NAK. Chaque attribut ajoute le VLAN fourni à la liste des VLAN de sortie autorisés du port.

Si les trames sur le VLAN sont étiquetées (0x31) ou non étiquetées (0x31), le champ Indication de balise, d’une longueur d’un octet, l’indique. Le VLANID a une longueur de 12 bits et contient la valeur VLAN VID.

Pour l’ID VLAN de sortie :

Par exemple, le profil RADIUS suivant comprend un VLAN balisé et un VLAN non balisé :

Nom du VLAN de sortie :

Egress-VLAN-Name représente un VLAN autorisé pour ce port. Toutefois, comme pour l’attribut Egress-VLANID, au lieu d’utiliser l’ID VLAN, qui est défini ou connu, le nom de VLAN est utilisé pour identifier le VLAN au sein du système. La RFC 4675 contient une définition de l’attribut Egress-VLAN-Name.

Le nom du VLAN est la deuxième partie de l’attribut Egress-VLAN-Name en deux parties, qui spécifie également si les trames du VLAN pour ce port doivent être affichées au format balisé ou non.

Pour le nom du VLAN de sortie : 1 = étiqueté et 2 = non étiqueté

The example below shows that VLAN 1vlan-2 is tagged, while VLAN 2vlan-3 is not.

Type de tunnel :

Cet attribut spécifie soit le protocole de tunnelisation actuellement utilisé, soit le protocole de tunnelisation qui sera utilisé (dans le cas d’un initiateur de tunnel) (dans le cas d’une terminaison de tunnel). La RFC 2868 spécifie l’attribut Tunnel-Type. Le type RADIUS de cet attribut est 64

Tunnel-Private-Group-Id :

L’ID VLAN ou NAME de la session est affiché par l’attribut Tunnel-Medium-Type. L’équipement vérifie si la chaîne qu’il reçoit est un nom de VLAN ou un ID après avoir obtenu une valeur fournie pour l’attribut Tunnel-Private-Group-ID à partir du rayon et vérifie si l’équipement est configuré avec un VLAN.

Si un VLAN a été configuré, le port client est ajouté à ce VLAN. Dans le cas contraire, en raison d’un échec de la validation du VLAN, le client ne sera pas autorisé et sera maintenu dans un état en attente.

Le type RADIUS de cet attribut est 81, conformément à la RFC 2868.

Intervalle de compte intérimaire :

La valeur de l’attribut Acct-Interim-Interval représente l’intervalle de temps en secondes entre chaque transmission d’une mise à jour intermédiaire pour une session particulière. Le nombre de secondes qui se sont écoulées depuis le dernier message de mise à jour comptable est la valeur de cet attribut.

Une valeur minimale peut également être définie par un administrateur localement sur un client RADIUS, mais cette valeur est toujours prioritaire sur les valeurs Acct-Interim-Interval détectées dans un paquet Access-Accept. Le type RADIUS de cet attribut est 85.

VSA Juniper Networks

Filtre de commutation Juniper :

L’attribut Juniper-Switching-Filter du dictionnaire Juniper sur le serveur RADIUS vous permet de spécifier des critères de filtrage simples. Après cela, chaque fois qu’un nouvel utilisateur est autorisé avec succès, ces filtres sont livrés à un commutateur.

Les commutateurs qui utilisent le serveur RADIUS pour l’authentification des utilisateurs construisent et appliquent automatiquement les filtres sans nécessiter de configuration spécifique au commutateur. Entrez une ou plusieurs conditions de correspondance, actions et associations d’utilisateurs dans le serveur RADIUS pour configurer la propriété Juniper-Switching-Filter.

Pour des filtres de commutation plus longs, utilisez plusieurs instances de l’attribut Juniper-switching-filter avec une limite maximale de 20 conditions de correspondance et une taille totale maximale de 4 000 caractères. La longueur maximale d’un attribut radius est de 253 caractères. Chaque ligne de l’attribut « Juniper-switching-filter » doit également comporter moins de 253 caractères.

Les conditions de correspondance de filtre suivantes sont prises en charge :

The following filter actions are supported: To configure match conditions on the RADIUS server:

i) Vérifiez que le dictionnaire Juniper est bien chargé sur votre serveur RADIUS et qu’il inclut l’attribut de filtrage Juniper-Switching-Filter, ID d’attribut 48 :

ii) Entrez les conditions de match et les actions.

Pour chaque utilisateur concerné, ajoutez l’attribut Juniper-Switching-Filter. Pour refuser ou autoriser l’accès en fonction de l’adresse MAC de destination, utilisez

Ou

Pour refuser ou autoriser l’accès en fonction de l’adresse IP de destination :

Ou

Pour envoyer plusieurs filtres avec des correspondances et des actions différentes :

Ou

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

REMARQUE :

La classe de transfert doit être configurée sur le commutateur pour que l’option de classe de transfert soit prise en compte. Cette option n’est pas utilisée si elle n’est pas spécifiée sur le commutateur. La priorité de perte de paquets et la classe de transfert doivent être spécifiées.

iii) For the configuration to take effect, stop and restart the RADIUS process.

Juniper-VoIP-Vlan :

Le vlan VOIP est récupéré à partir du serveur RADIUS à l’aide du VSA Juniper-VoIP-VLAN dans un message d’acceptation d’accès ou un message de demande de certificat d’authenticité. Cet attribut est le numéro 49.

La VoIP vous permet de connecter des téléphones IP au commutateur et de configurer l’authentification IEEE 802.1X pour les téléphones IP compatibles 802.1X.

Les réseaux locaux Ethernet sont protégés contre l’accès illégal des utilisateurs grâce à l’authentification 802.1X. Un protocole connu sous le nom de VoIP est utilisé pour transmettre la voix sur les réseaux à commutation de paquets. Une connexion réseau, par opposition à une ligne téléphonique analogique, est utilisée par la VoIP pour transmettre des appels vocaux. Lorsque la VoIP est utilisée avec 802.1X, le serveur RADIUS vérifie l’identité du téléphone, tandis que le protocole LLDP-MED (Link Layer Discovery Protocol-Media Endpoint Discovery) attribue au téléphone les paramètres de classe de service (CoS).

Juniper-CWA-Redirection :

Avec le VSA Juniper-CWA-Redirect, qui porte le numéro d’attribut 50 dans le dictionnaire RADIUS de Juniper, l’URL de redirection peut être configurée de manière centralisée sur le serveur AAA. Le filtre et l’URL du pare-feu dynamique sont tous deux remis par le serveur AAA au commutateur dans le même message RADIUS Access-Accept. En tant que mécanisme d’authentification de secours, l’authentification Web centrale (CWA) redirige le navigateur Web de l’hôte vers un serveur d’authentification Web central. L’utilisateur peut saisir un nom d’utilisateur et un mot de passe sur l’interface Web du serveur CWA. L’utilisateur est authentifié et dispose d’un accès au réseau si le serveur CWA accepte ses informations d’identification.

Lorsqu’un hôte échoue à l’authentification MAC RADIUS, l’authentification Web centralisée est utilisée. Le commutateur, agissant en tant qu’authentificateur, reçoit un message d’accès-acceptation RADIUS du serveur AAA qui contient un filtre de pare-feu dynamique et une URL de redirection pour l’authentification Web centrale.

Pour que la procédure d’authentification Web centrale soit activée, l’URL de redirection et le filtre de pare-feu dynamique doivent être présents. Pour utiliser Juniper-Switching-Filter VSA pour l’authentification Web centrale, vous devez configurer les termes de filtrage directement sur le serveur AAA. Le filtre doit inclure un terme pour faire correspondre l’adresse IP de destination du serveur CWA avec l’action autorisée.

Par exemple :

REMARQUE :

Pour l’URL de redirection, le commutateur ne résout pas les requêtes DNS. Pour activer l’adresse IP de destination du serveur CWA, vous devez configurer la propriété Juniper-Switching-Filter.

Paire Juniper-AV :

L’attribut Juniper-AV-Pair est un attribut spécifique au fournisseur (VSA) de Juniper Networks. Afin de fournir de nombreuses fonctionnalités importantes requises pour la gestion des abonnés et la prise en charge des services, il est utilisé pour améliorer les capacités du serveur RADIUS au-delà de celles offertes par les attributs standard publics.

i) Port-Bounce :

Avec la commande CoA bounce host port, une session est terminée et le port est rejeté (lance un événement de liaison inactive suivi d’un événement de liaison montante). La demande est envoyée par le serveur RADIUS dans un message CoA Request typique avec le VSA répertorié ci-dessous :

Cette commande nécessite un ou plusieurs des attributs d’identification de session répertoriés dans la section « Identification de session », car elle est orientée session. L’appareil envoie un message CoA-NAK avec l’attribut de code d’erreur « Contexte de session introuvable » si la session est introuvable.

L’appareil ferme le port d’hébergement pendant 4 secondes, le réactive (rebond de port), puis renvoie un CoA-ACK si la session a été localisée.

ii) Liaison de session Ip-Mac :

Ceci est utilisé pour arrêter la session d’authentification de cet appareil d’être interrompue lorsque l’adresse MAC d’un appareil vieillit et doit être réapprise. Nous recevons cet attribut-valeur d’une paire AV Juniper VSA sur un message de demande d’accès-acceptation ou de COA.

Configurez le serveur RADIUS avec les deux paires attribut-valeur suivantes afin de maintenir la session d’authentification basée sur les liaisons IP-adresse MAC.

iii) Pas de liaison Mac :

Ceci est utilisé pour bloquer la réauthentification du client et arrêter la session d’authentification lorsque l’adresse MAC d’un appareil devient obsolète. Cette valeur de propriété nous est envoyée par une paire d’antivirus VSA Juniper lors d’un message de demande d’accès-acceptation ou de COA.

iv) Mode demandeur unique :

The device switches from the current set mode to single in response to receiving this attribute-value from a VSA Juniper-AV-Pair on an access-accept or COA request message.

v) Mode Supplicant-Single-Secure :

L’équipement passe du mode de définition actuel à la sécurité unique lorsqu’il reçoit cette valeur d’attribut d’une paire AV-VSA Juniper sur un message de demande d’accès-acceptation ou de COA.

vi) Conserver-Mac-Aged-Session :

If this attribute-value is received from a VSA Juniper-AV-Pair on an access-accept message for an 802.11X client, the client stays active even if the mac has aged out, and the mac is re-learned.

MS-MPPE-Send-Key et MS-MPPE-Recv-Key :

These are the MACSEC CAK generation keys together with the EAP key name that are utilised in dynamic CAK scenarios.

Cisco-AVPair :

Cisco Systems, IANA private enterprise number 9, uses a single VSA, Cisco-AVPair (26-1). Based on the values it has, this VSA transmits various pieces of information. In some subscriber access networks with a BNG connected to a RADIUS server and a Cisco BroadHop application that serves as the Policy Control and Charging Rules Function (PCRF) server for provisioning services using RADIUS change of authorization (CoA) messages, you can use this VSA in RADIUS messages to activate and deactivate services.

Lorsque le BNG délivre des messages RADIUS, vous ne pouvez modifier aucune des propriétés des réponses de comptabilité, de CoA ou d’authentification.

i) Cisco-AVPair = « subscriber :command=bounce-host-port »

Une session est terminée et le port est renvoyé via la commande CoA bounce host port (déclenche un événement de liaison inactive suivi d’un événement de liaison montante). La demande est envoyée par le serveur AAA dans un message CoA Request typique avec le VSA répertorié ci-dessous.

Cette commande nécessite un ou plusieurs des attributs d’identification de session répertoriés dans la section « Identification de session », car elle est orientée session. L’appareil envoie un message CoA-NAK avec l’attribut de code d’erreur « Contexte de session introuvable » si la session est introuvable. L’appareil ferme le port d’hébergement pendant 4 secondes, le réactive (rebond de port), puis renvoie un CoA-ACK si la session a été localisée.

ii) Commande de réauthentification Cisco-AVPair

Pour lancer l’authentification de session, le serveur AAA envoie un message CoA-Request standard contenant les VSA suivants :

reauthenticate-type définit si la demande de réauthentification CoA utilise la dernière méthode d’authentification qui a réussi sur la session ou si le processus d’authentification est complètement réexécuté.

"subscriber:command=reauthenticate" doit être présent pour provoquer une réauthentification. L’action par défaut consiste à répéter la méthode d’authentification précédente utilisée pour la session si « subscriber :reauthenticate-type » n’est pas fourni. Si la méthode s’authentifie à nouveau, toutes les données d’autorisation précédentes sont remplacées par les données d’autorisation nouvellement authentifiées.

Ce n’est que lorsque « subscriber :command=reauthenticate » est également présent que « subscriber :reauthenticate-type » est valide. Le VSA n’est pas pris en compte s’il est contenu dans une autre commande CoA.

Tableau de l'historique des modifications

La prise en charge des fonctionnalités est déterminée par la plateforme et la version que vous utilisez. Utilisez l' Feature Explorer pour déterminer si une fonctionnalité est prise en charge sur votre plateforme.

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