Sur cette page
Spécification des connexions serveur RADIUS sur les commutateurs (procédure CLI)
Configuration de MS-CHAPv2 pour la prise en charge du changement de mot de passe
Comprendre la secours et l’authentification des serveurs sur les commutateurs
Configuration de la secours d’échec du serveur RADIUS (procédure CLI)
Configuration du serveur RADIUS pour l’authentification
Les commutateurs Ethernet Juniper Networks utilisent 802.1X, MAC RADIUS ou l’authentification du portail captif pour fournir un contrôle d’accès aux équipements ou aux utilisateurs. Lorsque les authentifications 802.1X, MAC RADIUS ou portail captif sont configurées sur le commutateur, les équipements finaux sont évalués à 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 serveur RADIUS sur les commutateurs (procédure CLI)
Les authentifications IEEE 802.1X et MAC RADIUS assurent tous deux la sécurité de la périphérie du réseau, protégeant les LAN Ethernet contre les accès non autorisés des utilisateurs en bloquant tout le trafic en provenance et en provenance des équipements à l’interface jusqu’à ce que les informations d’identification ou l’adresse MAC du demandeur soient présentées et appariées sur le authentication server (un serveur RADIUS). Lorsque le demandeur est authentifié, le commutateur arrête de bloquer l’accès et ouvre l’interface au demandeur.
Pour utiliser l’authentification 802.1X ou MAC RADIUS, vous devez spécifier les connexions sur le commutateur pour chaque serveur RADIUS auquel vous vous connecterez.
Pour configurer plusieurs serveurs RADIUS, incluez plusieurs radius-server
déclarations. 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 requêtes en configurant la méthode round-robin. Les serveurs sont essayés dans l’ordre et de manière round-robin jusqu’à ce qu’une réponse valide soit reçue de l’un des serveurs, ou jusqu’à ce que toutes les limites de tentative configurées soient atteintes.
La méthode d’accès round-robin n’est pas recommandée pour les commutateurs EX Series.
Vous pouvez également configurer un nom de domaine complet (FQDN) qui se résout en une ou plusieurs adresses IP. Voir Spécification des connexions 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 FQDN
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 FQDN au niveau de la hiérarchie [edit access radius-server-name hostname
]. Lorsqu’un FQDN se résout à 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 requêtes en configurant la méthode round-robin. Les serveurs sont essayés dans l’ordre et de manière round-robin jusqu’à ce qu’une réponse valide soit reçue de l’un des serveurs, ou jusqu’à ce que toutes les limites de tentative configurées soient atteintes.
Voir également
Comprendre les requêtes RADIUS Round-Aware Round-Robin
À partir de la version 22.4R1 de Junos OS, les services d’authentification (authd) sont conscients des sessions lorsque l’algorithme de round-robin est configuré, de sorte que la demande d’accès correspondante est envoyée au même serveur RADIUS en réponse au problème d’accès du serveur RADIUS, ce qui entraîne une authentification réussie.
Selon le comportement existant, dès réception de la contestation d’accès et de l’attribut d’état 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. Comme 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 de l’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 au problème d’accès du serveur RADIUS, ce qui se traduit par une authentification réussie. Si le serveur RADIUS ne répond pas par un défi d’accès, il accepte ou rejette la demande. Pour la prochaine demande d’authentification, les requêtes sont envoyées au serveur RADIUS suivant selon la méthode Round-robin. Chaque demande d’accès peut être envoyée par le serveur RADIUS pour répondre à chaque demande d’accès et l’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 haut débit qui utilisent le protocole PPP (Point-to-Point Protocol), car elle n’est pas prise en charge sur les clients haut débit. En outre, des 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 fournir une prise en charge du changement de mot de passe (procédure CLI)
Junos OS pour commutateurs EX Series vous permet de configurer l’implémentation par Microsoft Corporation du protocole d’authentification Challenge Handshake 2 (MS-CHAPv2) sur le commutateur afin de prendre en charge le changement de mot de passe. La configuration de MS-CHAPv2 sur le commutateur offre aux utilisateurs accédant à un commutateur la possibilité de changer le mot de passe lorsque le mot de passe expire, est réinitialisé ou configuré pour être modifié lors de la prochaine connexion.
Voir RFC 2433, Microsoft PPP CHAP Extensions, pour plus d’informations sur MS-CHAP.
Avant de configurer MS-CHAPv2 pour prendre en charge le changement de mot de passe, assurez-vous que vous avez :
Authentification du serveur RADIUS configurée. Configurez les utilisateurs sur le serveur d’authentification et définissez l’option de première tentative dans l’ordre d’authentification sur radius. Voir l’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 changer votre mot de passe.
Voir également
Configuration de MS-CHAPv2 pour la prise en charge du changement de mot de passe
Avant de configurer MS-CHAPv2 pour la prise en charge du changement de mot de passe, assurez-vous que vous avez effectué les opérations suivantes :
Paramètres d’authentification du serveur RADIUS configurés.
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 MS-CHAPv2 (Challenge Handshake Authentication Protocol version 2) sur le routeur ou le commutateur pour prendre en charge la modification des mots de passe. Cette fonctionnalité offre aux utilisateurs accédant à un routeur ou un commutateur la possibilité de changer 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 déclarations suivantes au niveau de la [edit system radius-options]
hiérarchie :
[edit system radius-options] password-protocol mschap-v2;
L’exemple suivant illustre les instructions de configuration du protocole de mot de passe MS-CHAPv2, de l’ordre d’authentification des mots de passe et des comptes 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 secours et l’authentification des serveurs sur les commutateurs
Les commutateurs Ethernet Juniper Networks utilisent l’authentification pour mettre en œuvre le contrôle d’accès dans un réseau d’entreprise. Si l’authentification 802.1X, MAC RADIUS ou portail captif est configurée sur le commutateur, les équipements finaux sont évalués à la connexion initiale par un serveur d’authentification (RADIUS). Si l’équipement final est configuré sur le serveur d’authentification, l’équipement obtient l’accès au LAN et le commutateur EX Series ouvre l’interface pour autoriser l’accès.
La secours de défaillance du serveur vous permet de spécifier la manière dont les terminaux connectés au commutateur sont pris en charge si le serveur d’authentification RADIUS n’est pas disponible. Lors de la réauthentification, la secours par échec du serveur est le plus souvent déclenchée lorsque le serveur RADIUS déjà configuré et en cours d’utilisation devient inaccessible. Toutefois, la secours par échec du serveur peut également être déclenchée par la première tentative d’authentification d’un équipement final via le serveur RADIUS.
La reprise de défaillance du serveur vous permet de spécifier l’une des quatre actions à effectuer pour les équipements finaux en attente d’authentification lorsque le serveur est hors délai. Le commutateur peut accepter ou refuser l’accès aux demandeurs ou maintenir l’accès déjà accordé aux demandeurs avant que le délai RADIUS ne s’est produit. 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 VLAN configuré remplace tous les attributs envoyés par le serveur.
Permit l’authentification, permettant au trafic de passer de l’équipement final à travers l’interface comme si l’équipement final avait été authentifié avec succès par le serveur RADIUS.
Deny l’authentification, empêchant le trafic de circuler de l’équipement final à travers l’interface. C’est la valeur par défaut.
Move l’équipement final vers un VLAN spécifié si le commutateur reçoit un message d’accès-rejet RADIUS. Le nom 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 qui disposent déjà d’un accès LAN et deny d’équipements finaux non authentifiés. Si les serveurs RADIUS s’arrêtent pendant la réauthentification, les équipements finaux précédemment authentifiés sont réauthentificationné et les nouveaux utilisateurs se voient refuser l’accès LAN.
Voir également
Configuration de la secours d’échec du serveur RADIUS (procédure CLI)
Vous pouvez configurer des options de repli d’authentification pour spécifier comment les terminaux connectés à un commutateur sont pris en charge si le serveur d’authentification RADIUS n’est plus disponible.
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 commutateur ne peut pas atteindre le serveur d’authentification principal et que les serveurs d’authentification secondaires sont également inaccessibles, un délai d’expiration du serveur RADIUS survient. Si cela se produit, parce que c’est le serveur d’authentification qui accorde ou refuse l’accès aux équipements finaux en attente d’authentification, le commutateur ne reçoit pas d’instructions d’accès pour les équipements 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 avec échec du serveur pour spécifier une action que le commutateur applique aux équipements terminaux lorsque les serveurs d’authentification ne sont pas disponibles. Le commutateur peut accepter ou refuser l’accès aux demandeurs ou maintenir l’accès déjà accordé aux demandeurs avant que le délai RADIUS ne s’est produit. 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 du serveur pour les équipements finaux qui reçoivent un message d’accès-rejet RADIUS du serveur d’authentification. La fonctionnalité de repli de refus du serveur offre un accès limité à un LAN, généralement uniquement à Internet, pour les équipements finaux réactifs compatibles 802.1X mais qui ont envoyé les informations d’identification erronées.
Le secours de défaillance du serveur est pris en charge pour le trafic vocal à partir des versions 14.1X53-D40 et 15.1R4. Pour configurer les actions de secours 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 mises en place 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
elle n’est pas configurée, le trafic vocal est interrompu.
Le secours de rejet du serveur n’est pas pris en charge pour le trafic balisé VLAN VoIP. Si un client VoIP commence l’authentification en envoyant un trafic de données non marqué à un VLAN alors que le secours de rejet du serveur est en vigueur, le client VoIP est autorisé à accéder au VLAN de repli. Si le même client envoie par la suite du trafic vocal balisé, le trafic vocal est supprimé.
Si un client VoIP commence l’authentification en envoyant un trafic vocal balisé alors que le serveur est en vigueur, le client VoIP se voit refuser l’accès au VLAN de repli.
Vous pouvez utiliser la procédure suivante pour configurer les actions d’échec du serveur pour les clients de données. Pour configurer le serveur de secours pour les clients VoIP qui envoient du trafic vocal, utilisez l’instruction server-fail-voip
à la place de l’instruction server-fail
.
Pour configurer les actions de secours de défaillance du serveur :
Vous pouvez configurer une interface qui reçoit un message d’accès RADIUS-rejet du serveur d’authentification pour déplacer les équipements finaux qui tentent d’accéder au LAN 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 repli serveur :
[edit protocols dot1x authenticator] user@switch# set interface interface-name server-reject-vlan vlan-sf