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.

Remarque :

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 :

  1. Configurez l’adresse IP du serveur RADIUS, le numéro de port d’authentification du serveur RADIUS et le mot de passe secret. Le mot de passe secret sur le commutateur doit correspondre au mot de passe secret sur le serveur.
    Remarque :

    La spécification du port d’authentification est facultative et le port 1812 est le port par défaut. Cependant, nous vous recommandons de le configurer afin d’éviter toute confusion, car certains serveurs RADIUS peuvent faire référence à une valeur par défaut plus ancienne.

  2. (Facultatif) Spécifiez l’adresse IP par laquelle le commutateur est identifié par le serveur RADIUS. Si vous ne spécifiez pas l’adresse IP, le serveur RADIUS utilise l’adresse de l’interface qui envoie la requête RADIUS. Nous vous recommandons de spécifier cette adresse IP, car si la demande est déviée sur une autre route vers le serveur RADIUS, l’interface qui relaie la demande peut ne pas être une interface sur le commutateur.
  3. Configurez l’ordre d’authentification, en faisant radius de la première méthode d’authentification :
  4. (Facultatif) Configurez la méthode utilisée par le routeur pour accéder aux serveurs d’authentification et de comptabilité RADIUS lorsque plusieurs serveurs sont configurés :
    • direct: méthode par défaut, dans laquelle il n’y a pas d’équilibrage de charge. Le premier serveur configuré est le serveur principal ; Les serveurs sont accessibles par ordre de configuration. Si le serveur principal est inaccessible, le routeur tente d’atteindre le deuxième serveur configuré, et ainsi de suite.

    • round-robin: méthode qui assure l’équilibrage de charge en faisant pivoter les demandes de routeur parmi la liste des serveurs RADIUS configurés. Le serveur choisi pour l’accès fait l’objet d’une rotation en fonction du serveur utilisé en dernier. Le premier serveur de la liste est traité comme serveur principal pour la première demande d’authentification, mais pour la deuxième demande, le deuxième serveur configuré est traité comme principal, et ainsi de suite. Avec cette méthode, tous les serveurs configurés reçoivent à peu près le même nombre de requêtes en moyenne, de sorte qu’aucun serveur n’a à traiter toutes les requêtes.

      Remarque :

      Lorsqu’un serveur RADIUS de la liste Round-Robin devient inaccessible, le serveur accessible suivant dans la liste Round-Robin est utilisé pour la requête en cours. Ce même serveur est également utilisé pour la requête suivante car il est en tête de liste des serveurs disponibles. Par conséquent, après une panne de serveur, le serveur utilisé prend la charge de deux serveurs.

    • Pour configurer la méthode utilisée par le routeur pour accéder aux serveurs de comptabilité RADIUS :

    • Pour configurer la méthode utilisée par le routeur pour accéder aux serveurs d’authentification RADIUS :

  5. Indiquez si vous souhaitez que le serveur RADIUS inclue l’attribut Authentificateur de message dans les réponses aux messages de demande d’accès.
    • L’attribut Authentificateur de message offre une protection supplémentaire contre les attaques de l’homme du milieu. Nous vous recommandons d’activer cette fonctionnalité. Pour activer cette fonctionnalité :

    • Pour une rétrocompatibilité avec les serveurs RADIUS qui ne prennent pas en charge cet attribut, désactivez cette fonctionnalité comme suit :

    Remarque :

    Ces paramètres s’excluent mutuellement. Nous vous recommandons de définir explicitement l’un ou l’autre. Ne vous fiez pas aux valeurs par défaut.

  6. Créez un profil et spécifiez la liste des serveurs RADIUS à associer au profil. Par exemple, vous pouvez choisir de regrouper géographiquement vos serveurs RADIUS par ville. Cette fonctionnalité permet une modification facile chaque fois que vous souhaitez passer à un autre envoi de serveurs d’authentification.
  7. Spécifiez le groupe de serveurs à utiliser pour l’authentification 802.1X ou MAC RADIUS en identifiant le nom du profil :
  8. Configurez l’adresse IP du commutateur dans la liste des clients sur le serveur RADIUS. Pour plus d’informations sur la configuration du serveur RADIUS, consultez la documentation de votre serveur.

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.

  1. Configurez le nom de domaine complet du serveur RADIUS, le numéro de port d’authentification du serveur RADIUS et le mot de passe secret. Le mot de passe secret sur le commutateur doit correspondre au mot de passe secret sur le serveur.
    Remarque :

    La spécification du port d’authentification est facultative et le port 1812 est le port par défaut. Cependant, nous vous recommandons de le configurer afin d’éviter toute confusion, car certains serveurs RADIUS peuvent faire référence à une valeur par défaut plus ancienne.

  2. (Facultatif) Configurez l’intervalle de résolution d’un nom de domaine complet en tant qu’adresse de serveur. Le nom de domaine complet est résolu dynamiquement à intervalles fixes en fonction de la valeur configurée.
  3. (Facultatif) Spécifiez l’adresse IP par laquelle le commutateur est identifié par le serveur RADIUS. Si vous ne spécifiez pas l’adresse IP, le serveur RADIUS utilise l’adresse de l’interface qui envoie la requête RADIUS. Nous vous recommandons de spécifier cette adresse IP, car si la demande est déviée sur une autre route vers le serveur RADIUS, l’interface qui relaie la demande peut ne pas être une interface sur le commutateur.
  4. Configurez l’ordre d’authentification, en faisant radius de la première méthode d’authentification :
  5. (Facultatif) Configurez la méthode utilisée par le commutateur pour accéder aux serveurs d’authentification et de comptabilité RADIUS lorsque plusieurs serveurs sont configurés :
    • direct: méthode par défaut, dans laquelle il n’y a pas d’équilibrage de charge. Le premier serveur configuré est le serveur principal ; Les serveurs sont accessibles par ordre de configuration. Si le serveur principal est inaccessible, le routeur tente d’atteindre le deuxième serveur configuré, et ainsi de suite.

    • round-robin: méthode qui assure l’équilibrage de charge en faisant pivoter les demandes parmi la liste des serveurs RADIUS configurés. Le serveur choisi pour l’accès fait l’objet d’une rotation en fonction du serveur utilisé en dernier. Le premier serveur de la liste est traité comme serveur principal pour la première demande d’authentification, mais pour la deuxième demande, le deuxième serveur configuré est traité comme principal, et ainsi de suite. Avec cette méthode, tous les serveurs configurés reçoivent à peu près le même nombre de requêtes en moyenne, de sorte qu’aucun serveur n’a à traiter toutes les requêtes.

      Remarque :

      Lorsqu’un serveur RADIUS de la liste Round-Robin devient inaccessible, le serveur accessible suivant dans la liste Round-Robin est utilisé pour la requête en cours. Ce même serveur est également utilisé pour la requête suivante car il est en tête de liste des serveurs disponibles. Par conséquent, après une panne de serveur, le serveur utilisé prend la charge de deux serveurs.

    • Pour configurer la méthode utilisée par le commutateur pour accéder aux serveurs de comptabilité RADIUS :

    • Pour configurer la méthode utilisée par le commutateur pour accéder aux serveurs d’authentification RADIUS :

  6. Indiquez si vous souhaitez que le serveur RADIUS inclue l’attribut Authentificateur de message dans les réponses aux messages de demande d’accès.
    • L’attribut Authentificateur de message offre une protection supplémentaire contre les attaques de l’homme du milieu. Nous vous recommandons d’activer cette fonctionnalité. Pour activer cette fonctionnalité :

    • Pour une rétrocompatibilité avec les serveurs RADIUS qui ne prennent pas en charge cet attribut, désactivez cette fonctionnalité comme suit :

    Remarque :

    Ces paramètres s’excluent mutuellement. Nous vous recommandons de définir explicitement l’un ou l’autre. Ne vous fiez pas aux valeurs par défaut.

  7. Créez un profil et spécifiez la liste des serveurs RADIUS à associer au profil. Par exemple, vous pouvez choisir de regrouper géographiquement vos serveurs RADIUS par ville. Cette fonctionnalité permet une modification facile chaque fois que vous souhaitez passer à un autre ensemble de serveurs d’authentification.
  8. Spécifiez le groupe de serveurs à utiliser pour l’authentification 802.1X ou MAC RADIUS en identifiant le nom du profil :
  9. Configurez l’adresse IP du commutateur dans la liste des clients sur le serveur RADIUS. Pour plus d’informations sur la configuration du serveur RADIUS, consultez la documentation de votre serveur.

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 :

Pour configurer MS-CHAPv2, spécifiez les éléments suivants :

Vous devez disposer de l’autorisation d’accès requise sur le commutateur pour pouvoir modifier votre mot de passe.

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 :

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 :

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.

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

Remarque :

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 :

  • Configurez une interface pour permettre au trafic de circuler d’un demandeur vers le LAN si un délai d’expiration du serveur RADIUS se produit (comme si le périphérique final avait été authentifié avec succès par un serveur RADIUS) :
  • Configurez une interface pour empêcher le flux de trafic d’un périphérique final vers le LAN (comme si le périphérique final avait échoué à l’authentification et s’était vu refuser l’accès par le serveur RADIUS) :
  • Configurez une interface pour déplacer un équipement final vers un VLAN spécifié si un délai d’expiration du serveur RADIUS se produit :
  • Configurez une interface pour reconnaître les équipements finaux déjà connectés comme réauthentifiés en cas d’expiration du délai d’attente RADIUS lors de la réauthentification (les nouveaux terminaux se voient refuser l’accès) :

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 :

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.

Libération
Descriptif
14,1 X 53 À D40
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.