Guide de déploiement du contournement de l'authentification MAC

Une fois que le commutateur a appris l'adresse MAC source, il rejette le paquet. Ensuite, le commutateur crée un paquet de demande d'accès RADIUS. Un exemple de paquet de demande d'accès RADIUS MAB est présenté dans la trace du renifleur à la figure 3.

Figure 3. Exemple de paquet de demande d'accès RADIUS pour MAB

Par défaut, le message de demande d'accès est une demande d'authentification PAP (Password Authentication Protocol). La demande inclut l'adresse MAC source dans trois attributs: Attribut 1 (Nom d'utilisateur), Attribut 2 (Mot de passe) et Attribut 31 (Calling Station). Id). Bien que l'adresse MAC soit la même dans chaque attribut, le format de l'adresse est différent. Cette fonctionnalité est importante car différents serveurs RADIUS peuvent utiliser différents attributs pour valider l'adresse MAC. Certains serveurs RADIUS peuvent examiner uniquement l'attribut 31 (Calling-Station-Id), tandis que d'autres vérifieront le nom d'utilisateur et le mot de passe dans les attributs 1 et 2.

Le tableau 1 récapitule le format de l'adresse MAC pour chaque attribut.

Tableau 1. Formats d'adresse MAC dans les attributs RADIUS

Etant donné que MAB utilise l'adresse MAC comme nom d'utilisateur et mot de passe, vous devez vous assurer que le serveur RADIUS peut différencier les demandes MAB des autres types de demandes d'accès au réseau. Cette précaution empêchera d'autres clients d'essayer d'utiliser une adresse MAC comme identifiant valide. Les commutateurs Cisco identifient de manière unique les demandes MAB en définissant l'attribut 6 (type de service) sur 10 (vérification d'appel) dans un message de demande d'accès MAB. Par conséquent, vous pouvez utiliser l'attribut 6 pour filtrer les demandes MAB sur le serveur RADIUS.

En option, les commutateurs Cisco peuvent être configurés pour exécuter MAB en tant qu'authentification EAP-MD5, auquel cas l'attribut Service-Type sera défini sur 1 (encadré). Cependant, étant donné que l'adresse MAC est envoyée en clair dans l'attribut 31 (Calling-Station-Id), MAB EAP n'offre aucune sécurité supplémentaire en chiffrant l'adresse MAC dans le mot de passe. Sachez également que, comme le type de service pour EAP MAB est identique à une demande IEEE 802.1X, le serveur RADIUS ne sera pas en mesure de différencier facilement les demandes EAB MAB des demandes IEEE 802.1X.

2.2.4 Autorisation de session

Si l'adresse MAC est valide, le serveur RADIUS renvoie un message RADIUS Access-Accept. Ce message indique au commutateur que le noeud final doit être autorisé à accéder au port. Le serveur RADIUS peut éventuellement inclure des instructions de stratégie d'accès réseau dynamique (par exemple, un réseau local virtuel dynamique ou une liste de contrôle d'accès). [ACL]) dans le message d'acceptation d'accès. En l'absence d'instructions de stratégie dynamiques, le commutateur ouvrira simplement le port. Aucune autre méthode d'authentification ne sera essayée si MAB réussit.

Si l'adresse MAC n'est pas valide ou n'est pas autorisée à accéder au réseau pour des raisons de stratégie, le serveur RADIUS renvoie un message RADIUS Access-Reject. Ce message indique au commutateur que le terminal ne doit pas être autorisé à accéder au port en fonction de l'adresse MAC. Selon la configuration du commutateur, plusieurs résultats différents sont possibles. Si d'autres méthodes d'authentification ou d'autorisation sont configurées, le commutateur peut tenter une authentification IEEE 802.1X ou Web, ou déployer le VLAN invité. L'interaction de MAB avec ces fonctionnalités est décrite dans la section 2.4.

Si aucune méthode d'authentification ou d'autorisation de secours n'est configurée, le commutateur arrêtera le processus d'authentification et le port restera non autorisé. Vous pouvez configurer le commutateur pour qu'il redémarre l'authentification après une tentative infructueuse de MAB en configurant
redémarrage du minuteur d'authentification sur l'interface. L'activation de ce minuteur signifie que les adresses MAC inconnues échouent périodiquement à l'authentification jusqu'à ce que le noeud final se déconnecte du commutateur ou que l'adresse soit ajoutée à une base de données MAC. Pour éviter le trafic inutile dans le plan de contrôle associé au redémarrage de sessions MAB ayant échoué, Cisco recommande généralement de quitter
redémarrage du minuteur d'authentification désactivée.

2.2.5 Comptabilité de session

Si le commutateur peut appliquer avec succès la stratégie d'autorisation, il peut envoyer un message RADIUS Accounting-Request au serveur RADIUS avec des détails sur la session autorisée.

2.2.6 Fin de session

La terminaison de session est une partie importante du processus d'authentification. Pour garantir l'intégrité de la session authentifiée, les sessions doivent être effacées lorsque le noeud final authentifié se déconnecte du réseau. Les sessions qui ne sont pas terminées immédiatement peuvent entraîner des violations de la sécurité et des failles de sécurité. Dans l'idéal, la fin de session a lieu dès que le noeud final est physiquement déconnecté, mais cela n'est pas toujours possible si le noeud final est connecté indirectement (par exemple, via un téléphone IP ou un concentrateur).

Plusieurs mécanismes de terminaison peuvent être nécessaires pour traiter tous les cas d'utilisation. Le tableau 2 résume les mécanismes et leurs applications.

Tableau 2. Mécanismes de terminaison et cas d'utilisation

Les sections suivantes décrivent plus en détail les différentes manières de terminer une session MAB.

2.2.6.1 Lien vers le bas

Le moyen le plus direct de terminer une session MAB consiste à débrancher le noeud final. Lorsque l'état de la liaison du port est arrêté, le commutateur efface complètement la session. Si le noeud final d'origine (ou un nouveau noeud final) se connecte, le commutateur redémarre l'authentification depuis le début.

2.2.6.2 Amélioration du protocole de découverte de Cisco pour la déconnexion du deuxième port

Pour les déploiements de téléphonie IP avec des téléphones IP Cisco, le meilleur moyen de s'assurer que toutes les sessions MAB sont terminées correctement est d'utiliser le protocole de découverte de Cisco. Les téléphones IP Cisco peuvent envoyer un message Cisco Discovery Protocol au commutateur indiquant que l'état de la liaison pour le port du point de terminaison de données est hors service, ce qui permet au commutateur d'effacer immédiatement la session authentifiée du point de terminaison de données.

2.2.6.3 Minuterie d'inactivité

Lorsque le minuteur d'inactivité est activé, le commutateur surveille l'activité à partir de points de terminaison authentifiés. Lorsque le délai d'inactivité expire, le commutateur supprime la session authentifiée.

Le temporisateur d'inactivité pour MAB peut être configuré de manière statique sur le port du commutateur ou affecté dynamiquement à l'aide de l'attribut RADIUS Idle-Timeout (attribut 28). Cisco recommande de définir le minuteur à l'aide de l'attribut RADIUS, car cette approche vous permet de contrôler les points d'extrémité soumis à ce minuteur et la durée du minuteur pour chaque classe de points d'extrémité. Par exemple, les points d'extrémité connus pour être silencieux pendant de longues périodes peuvent se voir attribuer une valeur de temporisateur d'inactivité plus longue que les points d'extrémité bavards.

Le minuteur d'inactivité est un mécanisme indirect que le commutateur utilise pour déduire qu'un noeud final s'est déconnecté. Un minuteur d'inactivité arrivé à expiration ne peut pas garantir qu'un ordinateur d'extrémité s'est déconnecté. Par conséquent, un point d'extrémité silencieux qui n'envoie pas de trafic pendant de longues périodes (par exemple, une imprimante réseau qui traite des demandes occasionnelles mais qui est par ailleurs silencieuse) peut voir sa session effacée même s'il est toujours connecté. Ce point d'extrémité devra alors envoyer du trafic avant de pouvoir être authentifié à nouveau et avoir accès au réseau.

2.2.6.4 Réauthentification et délai d'expiration de session absolu

La réauthentification ne peut pas être utilisée pour mettre fin aux points de terminaison authentifiés par MAB. Le délai d'expiration de session absolu ne doit être utilisé qu'avec prudence.

Le minuteur de réauthentification pour MAB est le même que pour IEEE 802.1X. Le temporisateur peut être configuré de manière statique sur le port du commutateur ou affecté dynamiquement en envoyant l'attribut Session-Timeout (attribut 27) et l'attribut RADIUS Termination-Action (attribut 29) avec une valeur de RADIUS-Request dans le champ Accès. Accepter le message du serveur RADIUS. Pour les points de terminaison IEEE 802.1X, le minuteur de réauthentification est parfois utilisé comme mécanisme keepalive. Cette fonctionnalité ne fonctionne pas pour MAB. Lors de la réauthentification MAB, le commutateur ne réapprend pas l'adresse MAC du noeud final connecté ni ne vérifie que celui-ci est toujours actif. il envoie simplement l'adresse MAC précédemment apprise au serveur RADIUS. Essentiellement, une opération nulle est effectuée.

Le temporisateur de session absolue peut être utilisé pour mettre fin à une session MAB, que le point de terminaison authentifié reste connecté ou non. Le minuteur de session utilise le même attribut RADIUS Session-Timeout (attribut 27) que le minuteur de réauthentification sur serveur décrit précédemment avec l'attribut RADIUS Termination-Action (attribut 29) défini sur Par défaut. Le commutateur met fin à la session après le nombre de secondes spécifié par l'attribut Session-Timeout et redémarre immédiatement l'authentification. Si IEEE 802.1X est configuré, le commutateur recommencera avec IEEE 802.1X et la connectivité réseau sera interrompue jusqu'à l'expiration du délai IEEE 802.1X et de la réussite du MAB. Ce processus peut entraîner une panne importante du réseau pour les points d'extrémité MAB. Au lieu du délai d'expiration de session absolu, envisagez de configurer un délai d'inactivité, comme décrit à la Section 2.2.6.3.

2.2.6.5 Changement d'Autorisation RADIUS

Le changement d'autorisation RADIUS (CoA) permet à un serveur RADIUS d'ordonner de manière dynamique au commutateur de modifier une session existante. Les commutateurs Cisco Catalyst prennent en charge quatre actions pour CoA: la réauthentification, la terminaison, l'arrêt du port et le rebond de port. Les actions de réauthentification et de fin mettent fin à la session authentifiée de la même manière que les actions de réauthentification et de délai d'expiration de session décrites à la Section 2.2.6.4. Les actions de port en panne et de rebond de port effacent la session immédiatement, car elles entraînent des événements de liaison.

2.3 Considérations de conception

Cette section traite des considérations de conception importantes que vous devez évaluer avant de déployer MAB.

2.3.1 Découverte d'adresse MAC

Avant de déployer MAB, vous devez déterminer les adresses MAC que vous souhaitez autoriser sur votre réseau. Il existe plusieurs approches pour collecter les adresses MAC qui seront utilisées pour renseigner votre base de données d'adresses MAC.

La méthode la plus simple et la plus économique consiste à rechercher des inventaires préexistants d’adresses MAC. Par exemple, dans certaines entreprises, le service des achats enregistre de manière rigoureuse l’adresse MAC de chaque appareil dont l’achat a déjà été approuvé. Une autre bonne source d’adresses MAC est toute application existante qui utilise une adresse MAC d’une manière ou d’une autre. Par exemple, Cisco Unified Communication Manager conserve une liste des adresses MAC de chaque téléphone IP enregistré sur le réseau. Les utilisateurs VMPS peuvent réutiliser les listes d'adresses MAC VMPS. Une fois que les inventaires existants d’adresses MAC ont été identifiés, ils peuvent être exportés du référentiel existant, puis importés dans une base de données MAB, comme indiqué à la section 4.

En l'absence d'inventaires d'adresses MAC existants, vous pourrez peut-être utiliser les informations du réseau pour découvrir les adresses MAC existantes sur votre réseau. Une option consiste à activer MAB dans un scénario de déploiement en mode moniteur. En mode de surveillance, le MAB est exécuté sur chaque noeud final, mais l'accès réseau du noeud final n'est pas affecté, que le MAB soit un échec ou non. De cette manière, vous pouvez collecter les adresses MAC de manière non intrusive en analysant les enregistrements d'authentification RADIUS. Voir Section 2.4.15.1 pour plus d'informations sur le mode moniteur. Les interruptions de notification d'adresse MAC, les syslogs et les outils de gestion de réseau tels que la solution de gestion de réseau local Cisco (LMS) de CiscoWorks peuvent également contenir des informations d'adresse MAC.

Une autre option consiste à utiliser les préfixes d'adresses MAC (ou caractères génériques) au lieu des adresses MAC réelles. Lors de l'attribution d'adresses MAC à des périphériques, les fournisseurs définissent les trois premiers octets sur une valeur spécifique appelée identificateur unique d'organisation (OUI). Les OUI sont attribués par l'IEEE et identifient de manière unique le fabricant d'un périphérique donné. Si un fournisseur de points de terminaison a une OUI (ou un ensemble d’OUI) affectée exclusivement à une classe de périphérique particulière, vous pouvez créer une règle générique dans votre stratégie de serveur RADIUS permettant à tout périphérique présentant une adresse MAC commençant par cette OUI être authentifié et autorisé.

À l'exception d'un inventaire préexistant, les approches décrites ici ne vous indiquent que les adresses MAC existantes sur votre réseau. Aucune méthode automatisée ne peut vous dire quels points d'extrémité sont des actifs valides appartenant à l'entreprise. Si cette distinction est nécessaire pour votre stratégie de sécurité, un type de processus manuel (tel qu'une exportation à partir d'un inventaire d'actifs existant) sera requis.

2.3.2 Bases de données MAB et serveurs RADIUS

Après avoir découvert et classé les adresses MAC autorisées pour votre réseau, vous devez les stocker dans une base de données accessible par le serveur RADIUS lors de la tentative de MAB. Le choix de stocker vos adresses MAC dépend de nombreux facteurs, notamment des capacités de votre serveur RADIUS. Les considérations de déploiement pour les bases de données internes, les bases de données LDAP (Lightweight Directory Access Protocol) externes et Microsoft Active Directory sont abordées dans cette section.

2.3.2.1 Bases de données internes

Un endroit évident pour stocker les adresses MAC est sur le serveur RADIUS lui-même. Avec certains serveurs RADIUS, vous entrez simplement les adresses MAC dans la base de données d'utilisateurs locale, en définissant le nom d'utilisateur et le mot de passe sur l'adresse MAC. D'autres serveurs RADIUS, tels que Cisco Secure Access Control (ACS) 5.0, sont plus sensibles au MAB. Le système Cisco Secure Access Control 5.0 stocke les adresses MAC dans une base de données d'hôte spéciale contenant uniquement les adresses MAC autorisées. Au lieu de traiter la demande MAB comme une authentification PAP, Cisco Secure ACS 5.0 reconnaît une demande MAB (par Attribute 6). [Service-Type] = 10) et compare l'adresse MAC de l'attribut Calling-Station-Id aux adresses MAC stockées dans la base de données hôte.

Avant de choisir de stocker les adresses MAC sur le serveur RADIUS, vous devez résoudre plusieurs problèmes. Premièrement, votre serveur RADIUS prend-il en charge une base de données d'hôtes interne? Par exemple, le service IAS (Microsoft Internet Authentication Service) et le serveur de stratégie réseau (NPS) n'ont pas le concept de base de données hôte interne (ils s'appuient sur Microsoft Active Directory en tant que magasin d'identité). Deuxièmement, quelle est la capacité de votre serveur RADIUS? Par exemple, Cisco Secure ACS 5.0 prend en charge jusqu'à 50 000 entrées dans sa base de données hôte interne. Si vous envisagez de prendre en charge plus de 50 000 périphériques sur votre réseau, une base de données externe sera nécessaire. Troisièmement, comment les adresses MAC seront-elles gérées? Si les adresses MAC sont stockées localement sur le serveur RADIUS, les personnes qui ont besoin d'ajouter, de modifier et de supprimer des adresses MAC doivent avoir un accès administratif au serveur RADIUS. Si cela pose un problème pour votre politique de sécurité, une base de données externe sera nécessaire.

2.3.2.2 Bases de données LDAP

Un choix courant pour une base de données MAC externe est un serveur Lightweight Directory Access Protocol. LDAP est un protocole largement utilisé pour stocker et récupérer des informations sur le réseau. Une fois toutes les adresses MAC collectées sur votre réseau, vous pouvez les importer sur le serveur d'annuaire LDAP et configurer votre serveur RADIUS pour qu'il interroge ce serveur.

Les bases de données externes étant des serveurs dédiés, ils peuvent évoluer vers un plus grand nombre d'adresses MAC que les bases de données internes. Ils peuvent également être gérés indépendamment du serveur RADIUS.

La première considération à prendre en compte est de savoir si votre serveur RADIUS peut interroger une base de données LDAP externe. Bien que LDAP soit un protocole très courant, tous les serveurs RADIUS ne peuvent pas exécuter de requêtes LDAP vers des bases de données externes. Par exemple, les serveurs Microsoft IAS et NPS ne peuvent pas interroger des bases de données LDAP externes.

La base de données LDAP étant externe au serveur RADIUS, vous devez également accorder une attention particulière à la disponibilité. La base de données LDAP étant essentielle au MAB, des systèmes redondants doivent être déployés pour garantir que le serveur RADIUS puisse contacter le serveur LDAP. Pour éviter que le serveur LDAP ne devienne complètement indisponible, le serveur RADIUS doit être configuré avec une stratégie de restauration appropriée (par exemple, échec d'ouverture ou de fermeture, en fonction de votre stratégie de sécurité).

2.3.2.3 Microsoft Active Directory

Microsoft Active Directory est un service d'annuaire largement déployé utilisé par de nombreuses organisations pour stocker les identités des utilisateurs et des ordinateurs de domaine. Si la centralisation de toutes les identités dans un seul magasin est importante pour vous, Active Directory peut être utilisé comme base de données MAC. En fait, dans certains cas, vous n’avez peut-être pas le choix. Pour Microsoft NPS et IAS, Active Directory est le seul choix possible pour le stockage d'adresses MAC. Quoi qu'il en soit, avant de déployer Active Directory en tant que base de données MAC, vous devez prendre en compte plusieurs considérations.

À partir de Microsoft Windows Server 2003 version 2 (R2) et de Windows Server 2008, Microsoft Active Directory fournit une classe d'objets spéciale pour les adresses MAC appelée ieee802Device. En utilisant cette classe d'objets, vous pouvez rationaliser le stockage des adresses MAC dans Active Directory et éviter les exigences en termes de complexité des mots de passe. Malheureusement, dans les versions antérieures d'Active Directory, la classe d'objets ieee802Device n'est pas disponible.

En l'absence de cette classe d'objets spéciale, vous pouvez stocker des adresses MAC en tant qu'utilisateurs dans Microsoft Active Directory. Malheureusement, cette méthode ajoute des attributs et des objets inutiles au groupe Utilisateurs et ne fonctionnera pas dans une forêt Active Directory dans laquelle une stratégie de complexité du mot de passe est activée. N'oubliez pas que pour MAB, nom d'utilisateur = mot de passe = adresse MAC, une situation intentionnellement interdite en raison des exigences de complexité du mot de passe dans Active Directory. Une autre option permettant d’éviter la complexité du mot de passe consiste à charger vos adresses MAC sous forme d’enregistrements de texte (TXT) dans une zone DNS (Domain Name System) stockée dans Active Directory.

Si vous envisagez de stocker des adresses MAC dans Microsoft Active Directory, assurez-vous que votre serveur RADIUS peut accéder aux informations de compte dans Active Directory. Microsoft IAS et NPS le font de manière native. Certains serveurs RADIUS, tels que Cisco Secure ACS, y parviennent en rejoignant le domaine Active Directory. Vous pouvez également créer une instance Active Directory légère à laquelle vous pouvez vous référer à l'aide de LDAP.

2.4 Interaction des fonctionnalités

2.4.1 IEEE 802.1X

Le MAB est une partie importante de la plupart des déploiements IEEE 802.1X. Le MAB est l’une des fonctionnalités fournies par Cisco pour prendre en charge les terminaux non IEEE 802.1X. Une fois que le délai IEEE 802.1X a expiré ou a échoué, le port peut passer à un état autorisé si le MAB réussit.

La figure 4 illustre le processus MAB à l'expiration du délai IEEE 802.1X car le noeud final ne peut pas effectuer l'authentification IEEE 802.1X.

La figure 4. MAB en tant que mécanisme de secours pour les points de terminaison non IEEE 802.1X

Lorsqu'il est configuré en tant que mécanisme de secours, le MAB est déployé après l'expiration du délai IEEE 802.1X. Si le processus PXE (Environnement de pré-exécution) du noeud final expire ou si le protocole DHCP (Dynamic Host Configuration Protocol) pénètre en profondeur dans le processus de suppression exponentielle avant l'expiration du délai, il est possible que le noeud final ne puisse pas communiquer même si le port a été ouvert. . Pour l'utilisateur final, il semblera que l'accès au réseau a été refusé. Il existe trois solutions possibles à ce problème:

• Réduisez la valeur du délai d'attente IEEE 802.1X. Voir la section 2.4.1.1.1 pour plus d’informations sur les temporisateurs pertinents.

• Utilisez un scénario de déploiement à faible impact qui autorise un trafic à temps critique tel que DHCP avant l'authentification. Voir la section 4 pour plus d'informations sur les scénarios de déploiement.

• Si votre réseau comporte de nombreux points d'extrémité non compatibles IEEE 802.1X nécessitant un accès instantané au réseau, vous pouvez utiliser le jeu de fonctions d'authentification flexible qui vous permet de configurer l'ordre et la priorité des méthodes d'authentification. Au lieu d'attendre l'expiration du délai IEEE 802.1X avant d'exécuter le MAB, vous pouvez configurer le commutateur pour qu'il effectue d'abord le MAB et qu'il se replie sur IEEE 802.1X uniquement en cas d'échec du MAB. Voir la section 4 pour plus d'informations sur l'authentification flexible.

MAB peut également être utilisé comme mécanisme de basculement si le système d'extrémité prend en charge IEEE 802.1X mais présente des informations d'identification non valides. La figure 5 illustre cette utilisation de MAB dans un environnement IEEE 802.1X.

La figure 5. MAB en tant que mécanisme de basculement pour les points de terminaison IEEE défaillants

Étant donné que MAB commence immédiatement après une défaillance IEEE 802.1X, il n'y a aucun problème de minutage. Toutefois, pour déclencher le MAB, le noeud final doit envoyer un paquet après l'échec IEEE 802.1X. En d'autres termes, le demandeur IEEE 802.1X sur l'ordinateur d'extrémité doit échouer en ouverture.

Voir la section 4 pour plus d'informations sur IEEE 802.1X.

2.4.1.1 Timers et Variables

Cette section décrit les temporisateurs du commutateur pertinents pour le processus d'authentification MAB dans un environnement compatible IEEE 802.1X.

2.4.1.1.1 point1x délai d'attente tx et dot1x max-reauth-req

Cette section décrit les temporisateurs qui contrôlent le délai d'attente et le comportement de tentative d'un port compatible MAB dans un environnement activé IEEE 802.1X.

Si IEEE 802.1X est activé en plus du MAB, le commutateur enverra une trame d'identité de demande EAP lors de la liaison. Le commutateur attendra une période définie par
point1x délai d'attente tx puis envoyez un autre cadre Request-Identity. Le nombre de fois qu'il renverra la trame Request-Identity est défini par
dot1x max-reauth-req.

La figure 6 montre l’effet de la
période de tx minuterie et le
max-reauth-req variable sur le temps total d'accès au réseau.

Figure 6. Période Tx, max-reauth-req et temps d'accès réseau

La combinaison de
période de tx et
max-reauth-req est particulièrement important pour les points de terminaison MAB dans un environnement activé par IEEE 802.1X. Les points de terminaison MAB doivent attendre l'expiration du délai IEEE 802.1X avant de tenter un accès réseau via un mécanisme de secours. Le temps total nécessaire à l'expiration du délai IEEE 802.1X est déterminé par la formule suivante:

Délai d'attente = (max-reauth-req +1) * tx-period

Les commutateurs Cisco Catalyst ont des valeurs par défaut de
période de tx = 30 secondes et
max-reauth-req = 2. En appliquant la formule, il faut 90 secondes par défaut au port pour démarrer MAB. En modifiant ces deux paramètres, vous pouvez réduire le délai total à une valeur minimale de 2 secondes.

Contrairement à IEEE 802.1X, il n'y a pas de délai d'attente associé à la phase d'apprentissage de l'adresse MAC. Le commutateur attend indéfiniment que le noeud final envoie un paquet. Ainsi, alors que le temps nécessaire à IEEE 802.1X pour expirer et revenir au MAB est déterminé précisément par la valeur de temporisation IEEE 802.1X configurée et le nombre de tentatives, le temps nécessaire pour que l'adresse MAC soit apprise est indéterminé, car le temps dépend le point final envoie une sorte de trafic. Par conséquent, le temps total écoulé entre la liaison et l'accès au réseau est également indéterminé. Pour les périphériques bavards qui envoient beaucoup de trafic, le MAB sera déclenché peu après l'expiration du délai IEEE 802.1X. Mais pour les périphériques silencieux, ou pour les périphériques qui sont devenus silencieux parce que, par exemple, le client DHCP a expiré avant IEEE 802.1X, le MAB peut ne pas se produire avant un certain temps.

En raison de l’impact sur les terminaux MAB, la plupart des clients modifient les valeurs par défaut de
période de tx et
max-reauth-req pour permettre un accès plus rapide au réseau. Lorsque vous modifiez ces valeurs, tenez compte des points suivants:

• Une minuterie trop courte peut exposer les points d'extrémité compatibles IEEE 802.1X à une technique d'authentification ou d'autorisation de secours. Bien que les points d'extrémité compatibles IEEE 802.1X puissent redémarrer IEEE 802.1X après un repli, vous pouvez toujours générer un trafic inutile dans le plan de contrôle. De plus, si le point de terminaison a été autorisé par une méthode de secours, ce dernier peut être temporairement adjacent aux périphériques invités qui ont été autorisés de la même manière. Si votre objectif est de vous assurer que vos actifs compatibles IEEE 802.1X sont toujours et exclusivement sur un réseau approuvé, vous devez vous assurer que la minuterie est longue pour permettre aux points de terminaison compatibles IEEE 802.1X de s'authentifier.

• Une minuterie trop longue peut entraîner des délais inutilement longs aux points d'accès MAB pour obtenir un accès réseau.

2.4.2 Web Authentication

MAB is compatible with Web Authentication (WebAuth). Cisco Catalyst switches can be configured to attempt WebAuth after MAB fails. Access to the network is granted based on the success or failure of WebAuth. The sequence of events is shown in Figure 7.

Figure 7. MAB and Web Authentication After IEEE 802.1X Timeout

See Section 4 for more information about Web Authentication.

2.4.3 Guest VLAN

MAB is compatible with the Guest VLAN feature (Figure 8). If IEEE 802.1X times out (or is not configured) and MAB fails, the port can be moved to the Guest VLAN, a configurable VLAN for which restricted access can be enforced. Using the Guest VLAN, you can tailor network access for endpoints without valid credentials. For example, the Guest VLAN can be configured to permit access only to the Internet.

Figure 8. MAB and Guest VLAN After IEEE 802.1X Timeout

2.4.4 Authentication Failure VLAN

After an IEEE 802.1X authentication failure, the switch can be configured to either deploy the Authentication Failure (AuthFail) VLAN or proceed to the next authentication method (MAB or WebAuth). Figure 9 illustrates this process.

Figure 9. AuthFail VLAN or MAB after IEEE 802.1X Failure

In this sense, AuthFail VLAN and MAB are mutually exclusive when IEEE 802.1X fails. However, you can configure the AuthFail VLAN for IEEE 802.1X failures (the client has a supplicant but presents an invalid credential as shown in Figure 9) and still retain MAB for IEEE 802.1X timeouts (the client has no supplicant as shown in Figures 7 and 8).

2.4.5 Dynamic Guest and Authentication Failure VLAN

Instead of using the locally configured Guest VLAN or AuthFail VLAN, another option is dynamic Guest and AuthFail VLANs, which rely on the RADIUS server to assign a VLAN when an unknown MAC address attempts to access the port after IEEE 802.1X times out or fails. In this scenario, the RADIUS server is configured to send an Access-Accept message with a dynamic VLAN assignment for unknown MAC addresses. The dynamically assigned VLAN would be one for which restricted access can be enforced. From the switch's perspective, MAB will pass even though the MAC address is unknown. The advantage of this approach over the local Guest VLAN and AuthFail VLAN is that the RADIUS server is aware of and in control of unknown endpoints. Centralized visibility and control make this approach preferable if your RADIUS server supports it.

2.4.6 Inaccessible RADIUS Server

When the RADIUS server is unavailable, MAB will fail and, by default, all endpoints will be denied access. In a highly available enterprise campus environment, it is reasonable to expect that a switch will always be able to communicate with the RADIUS server, so the default behavior may be acceptable. However, there may be some use cases (for example, a branch office with occasional WAN outages) in which the switch cannot reach the RADIUS server, but endpoints should be allowed access to the network.

If the switch already knows that the RADIUS server has failed (either through periodic probes or as the result of a previous authentication attempt), a port can be deployed in a configurable VLAN (sometimes called the critical VLAN) as soon as the link comes up. Because the switch has multiple mechanisms for learning that the RADIUS server has failed, this outcome is the most likely. If the switch determines that the RADIUS server has failed during a MAB authentication attempt (for example, if this is the first endpoint to connect to the switch after connectivity to the RADIUS server has been lost), then the port will be moved to the critical VLAN after the authentication times out. Previously authenticated endpoints will not be affected in any way; if a reauthentication timer expires when the RADIUS server is down, the reauthentication will be deferred until the switch determines that the RADIUS server has returned.

When the RADIUS server returns, the switch can be configured to reinitialize any endpoints in the critical VLAN. This behavior poses a potential problem for a MAB endpoint. When the MAB endpoint originally plugged in and the RADIUS server was unavailable, the endpoint received an IP address in the critical VLAN. Because the MAB endpoint is agentless, it has no knowledge of when the RADIUS server has returned or when it has been reinitialized. If the device is assigned a different VLAN as a result of the reinitialization, it will continue to use the old IP address-an IP address that is now invalid on the new VLAN.

There are several ways to work around the reinitialization problem. You can disable reinitialization, in which case, critical authorized endpoints will stay in the critical VLAN until they unplug and plug back in. You also can set the critical VLAN to the data VLAN (essentially a fail-open operation) so that the MAB endpoints maintain a valid IP address across reinitialization. If neither of those options is feasible, consider setting the DHCP lease time in the critical VLAN scope to a short time (for example, 5 minutes) so that a MAB endpoint will have an invalid address for a relatively short amount of time.

2.4.7 Dynamic ACL Assignment

MAB is compatible with ACLs that are dynamically assigned by the RADIUS server as the result of successful authentication.

2.4.8 Dynamic VLAN Assignment

MAB is compatible with VLANs that are dynamically assigned by the RADIUS server as the result of successful authentication. Be aware that MAB endpoints cannot recognize when a VLAN changes. Therefore, if a MAB endpoint initially has an IP address in VLAN A and is later assigned to VLAN B without an intervening link-down or link-up event (for example, as the result of reauthentication), the unsuspecting MAB endpoint will continue to use the IP address from the old VLAN and hence be unable to get access on the new VLAN.

2.4.9 Wake on LAN

Wake on LAN (WoL) is an industry-standard power management feature that allows you to remotely wake up a hibernating endpoint by sending a "magic packet" over the network. Most WoL endpoints flap the link when going into hibernation or standby mode, thus clearing any existing MAB-authenticated session. By default, traffic through the unauthorized port will be blocked in both directions, and the magic packet will never get to the sleeping endpoint.

To support WoL in a MAB environment, you can configure a Cisco Catalyst switch to modify the control direction of the port, allowing traffic to the endpoint while still controlling traffic from the endpoint. This approach allows the hibernating endpoint to receive the WoL packet while still preventing the unauthorized endpoint from sending any traffic to the network. After it is awakened, the endpoint can authenticate and gain full access to the network. Control direction works the same with MAB as it does with IEEE 802.1X.

Additionally, when a port is configured for open-access mode, magic packets are not blocked, even on unauthorized ports, so no special configuration for WoL endpoints is necessary.

2.4.10 Open Access

By default, the port drops all traffic prior to successful MAB (or IEEE 802.1X) authentication. This approach is sometimes referred to as closed mode. Cisco switches can also be configured for open access, which allows all traffic while still enabling MAB.

Open access has many applications, including increasing network visibility as part of a monitor mode deployment scenario. It can be combined with other features to provide incremental access control as part of a low-impact mode deployment scenario. For more information about these deployment scenarios, see Section 4.

2.4.11 Multiple Endpoints per Port

By default, a MAB-enabled port allows only a single endpoint per port. Any additional MAC addresses seen on the port will cause a security violation.

Frequently, the limitation of a single endpoint per port will not meet all the requirements of real-world networks. Cisco Catalyst switches allow you to address multiple use cases by modifying the default behavior. The host mode on a port determines the number and type of endpoints allowed on a port. The various host modes and their applications are discussed in this section.

Single-Host Mode

In single-host mode, only a single MAC or IP address can be authenticated (by any method) on a port. If a different MAC address is detected on the port after a endpoint has authenticated with MAB, then a security violation will be triggered on the port. This is the default behavior.

Multidomain Authentication Host Mode

Multidomain authentication was specifically designed to address the requirements of IP telephony. When multidomain authentication is configured, two endpoints are allowed on the port: one in the voice VLAN and one in the data VLAN. Either, both, or none of the endpoints can be authenticated with MAB. Additional MAC addresses will trigger a security violation.

Multi-Authentication Host Mode

If the port is configured for multi-authentication (multi-auth) host mode, then multiple endpoints can be authenticated in the data VLAN. Each new MAC address that appears on the port will be separately authenticated. Any, all, or none of the endpoints can be authenticated with MAB. Multi-auth host mode can be used for bridged virtual environments or to support hubs.

Multihost Mode

Unlike multi-auth host mode, which authenticates every MAC address, multihost mode authenticates the first MAC address and then allows an unlimited number of other MAC addresses. Because of the security implications of multihost mode, multi-auth host mode typically is a better choice than multihost mode.

2.4.12 IP Telephony

2.4.13 Cisco Catalyst Integrated Security Features

This section describes Cisco Catalyst integrated security features.

2.4.13.1 Port Security

In general, Cisco does not recommend enabling port security when MAB is also enabled. Since MAB enforces a single MAC address per port (or per VLAN when multidomain authentication is configured for IP telephony), port security is largely redundant and may in some cases interfere with the expected operation of MAB.

2.4.13.2 DHCP Snooping

DHCP snooping is fully compatible with MAB and should be enabled as a best practice.

2.4.13.3 Dynamic Address Resolution Protocol Inspection

Dynamic Address Resolution Protocol (ARP) Inspection (DAI) is fully compatible with MAB and should be enabled as a best practice.

2.4.13.4 IP Source Guard

IP source guard is compatible with MAB and should be enabled as a best practice.

2.4.14 RADIUS Accounting

RADIUS accounting is fully compatible with MAB and should be enabled as a best practice. RADIUS accounting provides detailed information about the authenticated session and enables you to correlate MAC address, IP address, switch, port, and use statistics.

2.4.15 Deployment Scenarios

When deploying MAB as part of a larger access-control solution, Cisco recommends a phased deployment model that gradually deploys identity-based access control to the network. The three scenarios for phased deployment are monitor mode, low-impact mode, and high-security mode. Each scenario identifies combinations of authentication and authorization techniques that work well together to address a particular set of use cases. The interaction of MAB with each scenario is described in the following sections.

2.4.15.1 Monitor Mode

MAB is fully supported and recommended in monitor mode.

The primary goal of monitor mode is to enable authentication without imposing any form of access control. This approach allows network administrators to see who is on the network and prepare for access control in a later phase without affecting endpoints in any way.

By enabling MAB in monitor mode, you get the highest level of visibility into devices that do not support IEEE 802.1X. In addition, by parsing authentication and accounting records for MAB in monitor mode, you can rapidly compile a list of existing MAC addresses on your network and use this list as a starting point for developing your MAC address database as described in Section 2.3.1.

2.4.15.2 Low-Impact Mode

MAB is fully supported in low-impact mode.

Low-impact mode builds on the ideas of monitor mode, gradually introducing access control in a completely configurable way. Instead of denying all access before authentication (as a traditional IEEE 802.1X or MAB deployment would require), low-impact mode allows you to use ACLs to selectively allow traffic before authentication. This approach is particularly useful for devices that rely on MAB to get access to the network. Waiting until IEEE 802.1X times out and falls back to MAB can have a negative effect on the boot process of these devices. Low-impact mode enables you to permit time-sensitive traffic prior to MAB, enabling these devices to function effectively in an IEEE 802.1X-enabled environment.

2.4.15.3 High-Security Mode

MAB is fully supported in high-security mode.

High-security mode is a more traditional deployment model for port-based access control, which denies all access prior to authentication. It also facilitates VLAN assignment for the data and voice domains. The primary design consideration for MAB endpoints in high-security mode is the lack of immediate network access if IEEE 802.1X is also configured. MAB endpoints that are not capable of IEEE 802.1X authentication will have to wait for IEEE 802.1X to time out and fall back to MAB before they get access to the network. To help ensure that MAB endpoints get network access in a timely way, you will need to adjust the default timeout value as described in Section 2.4.1.1. Alternatively, you can use Flexible Authentication to perform MAB before IEEE 802.1X authentication as described in Section 2.4.1

2.5 Deployment Summary for MAB

Table 3 summarizes the major design decisions that need to be addressed prior to deploying MAB.

Tableau 3. MAB Deployment Reference

3. Conclusion

MAB offers visibility and identity-based access control at the network edge for endpoints that do not support IEEE 802.1X. With the appropriate design and well-chosen components, you can meet the needs of your security policy while reducing the impact on your infrastructure and end users.

4. For More Information

5. Sample Configuration for Standalone MAB

This section includes a sample configuration for standalone MAB. For configuration examples of MAB as a fallback to IEEE 802.1X, see the IEEE 802.1X Deployment Scenarios Configuration Guide in Section 4.

MAB requires both global and interface configuration commands. Note that even though IEEE 802.1X is not enabled on the port, the global authentication, authorization, and accounting (AAA) configuration still uses the dot1x keyword.

aaa new-model

aaa authentication dot1x default group radius

aaa authorization network default group radius

aaa accounting dot1x default start-stop group radius

!

interface FastEthernet2/48

switchport access vlan 40

switchport mode access

authentication port-control auto

mab

spanning-tree portfast

spanning-tree bpduguard enable

!

radius-server host 10.200.1.52 key cisco123