SUR CETTE PAGE
Spécification des connexions du serveur RADIUS sur les commutateurs (procédure CLI)
Comprendre les requêtes RADIUS Round-Robin basées sur les sessions
Configuration de MS-CHAPv2 pour la prise en charge des changements de mot de passe (procédure CLI)
Configuration de MS-CHAPv2 pour la prise en charge des changements de mot de passe
Comprendre la reprise en cas de défaillance serveur et l’authentification sur les commutateurs
Configuration de la procédure de secours en cas d’échec du serveur RADIUS (procédure CLI)
Configuration du serveur RADIUS pour l’authentification
Les commutateurs Ethernet de Juniper Networks utilisent l’authentification 802.1X, MAC RADIUS ou de portail captif pour contrôler l’accès aux appareils ou aux utilisateurs. Lorsque les authentifications 802.1X, MAC RADIUS ou de portail captif sont configurées sur le commutateur, les équipements finaux sont évalués lors de la connexion initiale par un serveur d’authentification (RADIUS). Pour utiliser l’authentification 802.1X ou MAC RADIUS, vous devez spécifier les connexions sur le commutateur pour chaque serveur RADIUS auquel vous souhaitez vous connecter. Lisez ce sujet pour plus d’informations.
Spécification des connexions du serveur RADIUS sur les commutateurs (procédure CLI)
L’authentification IEEE 802.1X et l’authentification MAC RADIUS assurent toutes deux une sécurité de périphérie du réseau, protégeant les LAN Ethernet contre tout accès utilisateur non autorisé en bloquant tout le trafic à destination et en provenance des périphériques à l’interface jusqu’à ce que les informations d’identification ou l’adresse MAC du demandeur soient présentées et mises en correspondance sur le authentication server (un serveur RADIUS). Lorsque le demandeur est authentifié, le commutateur cesse de bloquer l’accès et ouvre l’interface au demandeur.
Pour utiliser l’authentification 802.1X ou MAC RADIUS, vous devez spécifier les connexions sur le commutateur pour chaque serveur RADIUS auquel vous allez vous connecter.
Pour configurer plusieurs serveurs RADIUS, incluez plusieurs radius-server instructions. Lorsque plusieurs serveurs sont configurés, les serveurs sont accessibles par ordre de configuration, par défaut. Le premier serveur configuré est le serveur principal. Si le serveur principal est inaccessible, le routeur tente d’atteindre le deuxième serveur configuré, et ainsi de suite. Vous pouvez équilibrer la charge des demandes en configurant la méthode round-robin. Les serveurs sont mis à l’essai dans l’ordre et de manière circulaire jusqu’à ce qu’une réponse valide soit reçue de l’un des serveurs, ou jusqu’à ce que toutes les limites de nouvelles tentatives configurées soient atteintes.
Il n’est pas recommandé d’utiliser la méthode d’accès Round-Robin avec les commutateurs EX Series.
Vous pouvez également configurer un nom de domaine complet (FQDN) qui se résout en une ou plusieurs adresses IP. Reportez-vous à la section Spécification des connexions au serveur RADIUS sur les commutateurs (procédure CLI).
Pour configurer un serveur RADIUS sur le commutateur :
Configuration d’un serveur RADIUS à l’aide d’un nom de domaine complet
Vous pouvez configurer un nom de domaine complet (FQDN) qui se résout en une ou plusieurs adresses IP. Configurez un serveur RADIUS à l’aide d’un nom de domaine complet au niveau de la hiérarchie [edit access radius-server-name hostname]. Lorsqu’un nom de domaine complet est résolu en plusieurs adresses, les serveurs sont accessibles par ordre de configuration, par défaut. La première adresse résolue est le serveur principal. Si le serveur principal est inaccessible, le routeur tente d’atteindre le deuxième serveur, et ainsi de suite. Vous pouvez équilibrer la charge des demandes en configurant la méthode round-robin. Les serveurs sont mis à l’essai dans l’ordre et de manière circulaire jusqu’à ce qu’une réponse valide soit reçue de l’un des serveurs, ou jusqu’à ce que toutes les limites de nouvelles tentatives configurées soient atteintes.
Voir aussi
Comprendre les requêtes RADIUS Round-Robin basées sur les sessions
À partir de la version 22.4R1 de Junos OS, les services d’authentification (authentification) sont orientés sessions lorsque l’algorithme Round-Robin est configuré de sorte que la demande d’accès correspondante est envoyée au même serveur RADIUS en réponse à une demande d’accès du serveur RADIUS, ce qui aboutit à une authentification réussie.
Conformément au comportement existant, à la réception d’une demande d’accès et d’un attribut d’état provenant de l’un des serveurs RADIUS, la demande d’accès correspondante est envoyée au serveur RADIUS suivant à l’aide de l’algorithme Round-Robin. Étant donné que le serveur RADIUS suivant n’a pas d’enregistrement de cette session, il rejette la demande d’accès, ce qui entraîne un échec d’authentification. Avec la nouvelle fonctionnalité, l’algorithme correspondant est configuré de manière à ce que la demande d’accès respective soit envoyée au même serveur RADIUS en réponse à la demande d’accès du serveur RADIUS, ce qui aboutit à une authentification réussie. Si le serveur RADIUS ne répond pas à une demande d’accès, il accepte ou rejette la demande. Pour la demande d’authentification suivante, les demandes sont envoyées au serveur RADIUS suivant selon la méthode Round-robin. Le serveur RADIUS peut envoyer un nombre illimité de défis d’accès en réponse à chaque demande d’accès, et authd répond au même serveur RADIUS jusqu’à ce que la demande soit acceptée ou rejetée par le serveur RADIUS.
Notez que cette fonctionnalité n’est prise en charge que pour les clients authd-lite (dot1x, etc.) et non pour les clients à large bande qui utilisent le protocole PPP (Point-to-Point Protocol), car cela n’est pas pris en charge sur les clients à large bande. De plus, les messages de défi d’accès sont échangés entre le client RADIUS et le serveur RADIUS uniquement en cas d’authentification, et non pour la comptabilité.
Configuration de MS-CHAPv2 pour la prise en charge des changements de mot de passe (procédure CLI)
Junos OS pour les commutateurs EX Series vous permet de configurer l’implémentation Microsoft Corporation du protocole MS-CHAPv2 (Challenge Handshake Authentication Protocol version 2) sur le commutateur afin de prendre en charge la modification du mot de passe. La configuration de MS-CHAPv2 sur le commutateur offre aux utilisateurs accédant à un commutateur la possibilité de modifier le mot de passe lorsque le mot de passe expire, est réinitialisé ou est configuré pour être modifié lors de la prochaine connexion.
Pour plus d’informations sur MS-CHAP, consultez RFC 2433, Extensions CHAP Microsoft PPP.
Avant de configurer MS-CHAPv2 pour prendre en charge les changements de mot de passe, assurez-vous que vous disposez des éléments suivants :
Authentification du serveur RADIUS configurée. Configurez les utilisateurs sur le serveur d’authentification et définissez l’option de premier essai dans l’ordre d’authentification sur radius. Voir Exemple : Connexion d’un serveur RADIUS pour 802.1X à un commutateur EX Series.
Pour configurer MS-CHAPv2, spécifiez les éléments suivants :
[edit system radius-options] user@switch# set password-protocol mschap-v2
Vous devez disposer de l’autorisation d’accès requise sur le commutateur pour pouvoir modifier votre mot de passe.
Voir aussi
Configuration de MS-CHAPv2 pour la prise en charge des changements de mot de passe
Avant de configurer MS-CHAPv2 pour la prise en charge des changements de mot de passe, assurez-vous d’avoir effectué les opérations suivantes :
Configurez les paramètres d’authentification du serveur RADIUS.
Définissez la première option essayée dans l’ordre d’authentification sur Serveur RADIUS.
Vous pouvez configurer l’implémentation Microsoft du protocole d’authentification Challenge Handshake version 2 (MS-CHAPv2) sur le routeur ou le commutateur pour prendre en charge le changement de mot de passe. Cette fonctionnalité offre aux utilisateurs accédant à un routeur ou à un commutateur la possibilité de modifier le mot de passe lorsque le mot de passe expire, est réinitialisé ou configuré pour être modifié lors de la prochaine connexion.
Pour configurer MS-CHAP-v2, incluez les instructions suivantes au niveau de la [edit system radius-options] hiérarchie :
[edit system radius-options] password-protocol mschap-v2;
L’exemple suivant montre des instructions pour configurer le protocole de mot de passe MS-CHAPv2, l’ordre d’authentification du mot de passe et les comptes d’utilisateur :
[edit]
system {
authentication-order [ radius password ];
radius-server {
192.168.69.149 secret "$9$G-j.5Qz6tpBk.1hrlXxUjiq5Qn/C"; ## SECRET-DATA
}
radius-options {
password-protocol mschap-v2;
}
login {
user bob {
class operator;
}
}
}
Comprendre la reprise en cas de défaillance serveur et l’authentification sur les commutateurs
Les commutateurs Ethernet de Juniper Networks utilisent l’authentification pour mettre en œuvre le contrôle d’accès dans un réseau d’entreprise. Si 802.1X, MAC RADIUS ou l’authentification de portail captif sont configurés sur le commutateur, les équipements finaux sont évalués lors de la connexion initiale par un serveur d’authentification (RADIUS). Si l’appareil final est configuré sur le serveur d’authentification, l’appareil est autorisé à accéder à l’LAN et le commutateur EX Series ouvre l’interface pour autoriser l’accès.
Le secours en cas de défaillance du serveur vous permet de spécifier la manière dont les périphériques finaux connectés au commutateur sont pris en charge si le serveur d’authentification RADIUS devient indisponible. Le repli en cas de défaillance du serveur est le plus souvent déclenché lors de la réauthentification, lorsque le serveur RADIUS déjà configuré et en cours d’utilisation devient inaccessible. Toutefois, le repli après échec serveur peut également être déclenché par la première tentative d’authentification d’un terminal via le serveur RADIUS.
Le secours en cas de défaillance du serveur vous permet de spécifier l’une des quatre actions à effectuer pour les périphériques finaux en attente d’authentification lorsque le serveur a expiré. Le commutateur peut accepter ou refuser l’accès aux demandeurs ou conserver l’accès déjà accordé aux demandeurs avant l’expiration du délai d’expiration de RADIUS. Vous pouvez également configurer le commutateur pour déplacer les demandeurs vers un VLAN spécifique. Le VLAN doit déjà être configuré sur le commutateur. Le nom du VLAN configuré remplace tous les attributs envoyés par le serveur.
-
Permit L’authentification, qui permet au trafic de circuler de l’équipement final via l’interface comme si l’appareil final avait été authentifié avec succès par le serveur RADIUS.
-
Deny l’authentification, qui empêche le trafic de circuler de l’appareil final via l’interface. Il s’agit de l’option par défaut.
-
Move le périphérique final vers un VLAN spécifié si le commutateur reçoit un message d’accès-rejet RADIUS. Le nom du VLAN configuré remplace tous les attributs envoyés par le serveur. (Le VLAN doit déjà exister sur le commutateur.)
-
Sustain les terminaux authentifiés disposant déjà d’un accès LAN et deny les terminaux non authentifiés. Si les serveurs RADIUS expirent lors de la réauthentification, les terminaux précédemment authentifiés sont réauthentifiés et les nouveaux utilisateurs se voient refuser l’accès au réseau LAN.
Lorsqu’un VLAN est configuré avec la VoIP en cas d’échec du serveur et que le serveur tombe en panne, un domaine de pont d’interface (IFBD) est créé pour ce VLAN lors de l’authentification du client. Cela permet au commutateur de déplacer les clients VoIP vers un VLAN de secours si le serveur d’authentification est inaccessible ou expire, garantissant ainsi la continuité du trafic vocal. L’instruction server-fail-voip gère spécifiquement les actions de repli du trafic balisé VLAN vocal, telles que l’autorisation d’accès, le refus d’accès ou le déplacement des clients vers un VLAN désigné déjà configuré sur le commutateur. Si l’instruction est configurée, le commutateur l’utilise pour isoler et gérer le trafic client VoIP en cas de défaillance du serveur, ce qui permet de maintenir la server-fail-voip disponibilité du service vocal même lorsque l’authentification ne peut pas être effectuée.
Voir aussi
Configuration de la procédure de secours en cas d’échec du serveur RADIUS (procédure CLI)
Vous pouvez configurer des options de secours d’authentification pour spécifier comment les terminaux connectés à un commutateur sont pris en charge si le serveur d’authentification RADIUS devient indisponible.
Lorsque vous configurez l’authentification 802.1X ou MAC RADIUS sur le commutateur, vous spécifiez un serveur d’authentification principal et un ou plusieurs serveurs d’authentification de secours. Si le serveur d’authentification principal est inaccessible par le commutateur et que les serveurs d’authentification secondaires sont également inaccessibles, un délai d’expiration du serveur RADIUS se produit. Si cela se produit, étant donné que c’est le serveur d’authentification qui accorde ou refuse l’accès aux appareils finaux en attente d’authentification, le commutateur ne reçoit pas d’instructions d’accès pour les appareils finaux qui tentent d’accéder au LAN et l’authentification normale ne peut pas être effectuée.
Vous pouvez configurer la fonctionnalité de secours en cas de défaillance du serveur pour spécifier une action que le commutateur applique aux périphériques finaux lorsque les serveurs d’authentification ne sont pas disponibles. Le commutateur peut accepter ou refuser l’accès aux demandeurs ou conserver l’accès déjà accordé aux demandeurs avant l’expiration du délai d’expiration de RADIUS. Vous pouvez également configurer le commutateur pour déplacer les demandeurs vers un VLAN spécifique.
Vous pouvez également configurer la fonctionnalité de secours de rejet de serveur pour les périphériques finaux qui reçoivent un message de rejet d’accès RADIUS du serveur d’authentification. La fonctionnalité de secours contre le rejet de serveur fournit un accès limité à un réseau LAN, généralement uniquement à Internet, pour les terminaux réactifs compatibles 802.1X mais qui ont envoyé des informations d’identification incorrectes.
Le repli après échec serveur est pris en charge pour le trafic vocal à partir de la version 14.1X53-D40 et de la version 15.1R4. Pour configurer les actions de secours en cas de défaillance du serveur pour les clients VoIP qui envoient du trafic vocal, utilisez l’instruction server-fail-voip . Pour tout le trafic de données, utilisez l’instruction server-fail . Le commutateur détermine la méthode de repli à utiliser en fonction du type de trafic envoyé par le client. Les trames de données non balisées sont soumises à l’action configurée avec server-fail, même si elles sont envoyées par un client VoIP. Les trames VLAN VoIP balisées sont soumises à l’action configurée avec server-fail-voip. Si server-fail-voip n’est pas configuré, le trafic vocal est abandonné.
Le repli des rejets serveur n’est pas pris en charge pour le trafic balisé VLAN VoIP. Si un client VoIP démarre l’authentification en envoyant du trafic de données non balisé à un VLAN alors que le repli de rejet du serveur est actif, le client VoIP est autorisé à accéder au VLAN de secours. Si le même client envoie par la suite du trafic vocal balisé, le trafic vocal est abandonné.
Si un client VoIP démarre l’authentification en envoyant du trafic vocal balisé alors que le revirement de rejet du serveur est en vigueur, le client VoIP se voit refuser l’accès au VLAN de secours.
Vous pouvez utiliser la procédure suivante pour configurer les actions d’échec du serveur pour les clients de données. Pour configurer le secours après échec serveur pour les clients VoIP envoyant du trafic vocal, utilisez l’instruction à la server-fail-voip place de l’instruction server-fail .
Pour configurer les actions de secours en cas d’échec du serveur :
Vous pouvez configurer une interface qui reçoit un message de rejet d’accès RADIUS du serveur d’authentification pour déplacer les périphériques finaux qui tentent LAN accéder sur l’interface vers un VLAN de rejet de serveur, un VLAN spécifié déjà configuré sur le commutateur.
Pour configurer un VLAN de secours rejeté par un serveur :
-
[edit protocols dot1x authenticator] user@switch# set interface interface-name server-reject-vlan vlan-sf
Voir aussi
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’explorateur de fonctionnalités pour déterminer si une fonctionnalité est prise en charge sur votre plateforme.