J’ai testé pour vous: 802.1X et la possibilité d’assigner des VLANs différents sur un même port
6 min read
Il arrive qu’on doive connecter derrière un seul port d’un commutateur d’accès plusieurs terminaux. Nous voyons ça le plus souvent quand on place un petit switch/hub dans une salle de réunion, ou bien quand des VM sont connectées bien évidemment par le même port physique du serveur. Une demande qui surgit parfois est de pouvoir placer chacun de ces usagers dans des VLANs différents. Une des réponses à ce problème consiste à aller au plus près du terminal et de faire le contrôle à ce niveau là:
- Commutateurs compacts qui fournissent l’instrumentation ad-hoc (+NEAT / NDAC+MACSEC…)
- Nexus 1000v qui supporte également le 802.1X (Pour les solutions VDI entre autres)
Si c’est certainement ce qui est le plus propre d’un point de vue architecture et sécurité on ne peut malheureusement pas être partout tout le temps et on est rattrapés par une réalité du terrain… Aussi certains seront peut-être contents de savoir que l’on peut sur un commutateur distant de l’usager également faire cette opération grâce au récent mode de configuration “Session Aware Netwoking” disponible aujourd’hui sur Catalyst 3850 et qui devrait s’étendre rapidement sur l’ensemble de nos plateformes. L’idée est d’apporter toujours plus de flexibilité dans les règles de configuration 802.1X, MAB, WebAuth… et permettre une meilleure auto-configuration des ports, c’est-à-dire l’application de tout paramètre depuis un serveur radius, de préférence ISE 🙂
Mettons tout cela en musique maintenant…
Diagramme du lab
Le design est simple: j’ai mis sur le port Gi 1/0/9 de mon catalyst 3850 un serveur avec 2 VM et bien évidemment on a le vswitch intermédiaire qui retransmettra les trames EAPOL start multicast envoyées par les VMs. Ces dernières arriveront donc sur le 3850 qui lui se chargera de faire le bon provisionning selon les terminaux (ici de mettre chaque terminal dans le VLAN qui va bien). Je n’ai pas fait apparaître le serveur ISE 1.2 qui va bien évidemment jouer un rôle très important dans toutes ces opérations.
Un peu de théorie
Le nouveau mode de configuration 802.1X présent sur le 3850 définit des service-templates qui vont regrouper l’ensemble des paramètres de configuration que l’on va vouloir mettre en oeuvre. Ces service-templates peuvent être définies directement sur le commutateur mais aussi sur le serveur ISE 1.2. Au moment de la phase d’autorisation, ISE va pouvoir envoyer non pas les AV-pairs radius habituels mais à la place c’est le nom du service-template à appliquer qui va être poussé au commutateur.
A ce moment là 2 scenarios sont possibles: soit le service-template est défini sur le commutateur et ce sont les paramètres locaux qui sont appliqués. Soit rien n’est configuré en local (cas qui colle le plus à la réalité) et le commutateur va ensuite demander à ISE les attributs associés à ce service-template (AV-pairs ou autres…) Ce sont ces 2 cas de figure que je démontre plus bas.
Configuration sur ISE
Sur ISE je configure 2 “Authorization Profiles” pour les profils Finance et Marketing. Ci-dessous une capture d’écran de mon profil finance_template: notez bien que “Service Template” est coché (4eme ligne). C’est indispensable pour permettre le mode de fonctionnement décrit plus haut. Dans cet exemple je me contente d’associer à mon template un numéro de VLAN mais j’aurais pu aussi configurer d’autres attributs habituels.
Je fais la même chose pour un groupe marketing (définition d’un merkating_template) et je vous épargne la capture d’écran. J’appelle simplement les 2 service-templates depuis mes règles d’autorisation sur ISE selon le groupe renvoyé par l’Active-Directory.
Le reste ne change pas par rapport à une configuration ordinaire.
Configuration du commutateur
Ici je ne configure rien non plus de particulier: je ne définis pas de service-template en local puisque je veux que celui-ci soit récupéré depuis ISE. Je fais donc une configuration très basique (du coup certainement incomplète par rapport à ce que l’on trouvera en production). Ceux qui veulent une configuration 802.1X/MAB etc validée pourront se référer à la bible en la matière: Cisco Trustsec 2.0 universal switch configuration
interface GigabitEthernet1/0/9 description TEST PER-USER VLAN ASSIGNMENT switchport access vlan 666 switchport mode access authentication host-mode multi-auth authentication open authentication port-control auto dot1x pae authenticator end ! aaa new-model ! aaa group server radius ISE-Group server name ISE ! aaa authentication dot1x default group ISE-Group aaa authorization network default group ISE-Group aaa accounting dot1x default start-stop group ISE-Group ! aaa server radius dynamic-author client 10.10.10.10 server-key cisco ! radius-server attribute 6 on-for-login-auth radius-server attribute 6 support-multiple radius-server attribute 8 include-in-access-req radius-server attribute 25 access-request include ! radius server ISE address ipv4 10.10.10.10 auth-port 1812 acct-port 1813 key cisco
Notez que l’utilisation des service-templates ne nécessite pas d’utiliser le nouveau modèle de configuration 802.1X. Je reviendrai la-dessus plus tard, chaque chose en son temps.
Résultats des tests
Tout d’abord regardons dans le détail ce qu’il se passe sur le port en question. On voit bien les 2 adresses MAC des 2 terminaux (virtuels). On note clairement qu’ils sont bien autorisés à se connecter au réseau (méthode 802.1X) avec les templates et VLANs associés.
Cat-3850-A#sh authentication sessions int gi 1/0/9 details
Interface: GigabitEthernet1/0/9
IIF-ID: 0x108F9C000000080
MAC Address: 000c.298b.45b1
IPv6 Address: Unknown
IPv4 Address: 10.153.200.4
User-Name: BNLAB-FR\christophe
Status: Authorized
Domain: DATA
Oper host mode: multi-auth
Oper control dir: both
Session timeout: N/A
Common Session ID: 0A960109000010598A346FB6
Acct Session ID: 0x00001065
Handle: 0xCB000026
Current Policy: POLICY_Gi1/0/9
Server Policies:
Template: finance_template (priority 100)
Vlan Group: Vlan: 21
Method status list:
Method State
dot1x Authc Success
----------------------------------------
Interface: GigabitEthernet1/0/9
IIF-ID: 0x105EEC000000081
MAC Address: 000c.29b0.0218
IPv6 Address: Unknown
IPv4 Address: 10.153.201.5
User-Name: BNLAB-FR\muriel
Status: Authorized
Domain: DATA
Oper host mode: multi-auth
Oper control dir: both
Session timeout: N/A
Common Session ID: 0A9601090000105A8A346FB6
Acct Session ID: 0x00001066
Handle: 0xD9000027
Current Policy: POLICY_Gi1/0/9
Server Policies:
Template: marketing_template (priority 100)
Vlan Group: Vlan: 22
Method status list:
Method State
dot1x Authc Success
Vous noterez les adresses IP sur des subnets distincts. Mais pour lever tout doute voici un aperçu de la table des VLANs sur le commutateur.
Cat-3850-A#sh vlan | i marketing|finance 21 finance active Gi1/0/9 22 marketing active Gi1/0/9
Vous voyez bien les VLANs 21 et 22 associés au même port Gi1/0/9. Tout se passe bien comme prévu.
Faisons un petit détour maintenant sur mes logs ISE pour voir les différentes étapes:
On voit bien les 2 authentifications des users muriel et christophe (lignes 4 et 6) avec pour chacun d’eux l’appel des profils d’autorisation définis précédemment comme service-templates. On voit ensuite sur les lignes 1 et 2 que le commutateur fait une demande d’information pour connaître le contenu des service-templates précédemment envoyées. On peut maintenant regarder le détail de la requête pour le service-template “marketing_template”
Ne nous attardons pas sur les détails: regardons juste les 3 dernières lignes et notons que nous avons ici des AV-pairs radius traditionnelles qui sont envoyées.
Deuxième test: définition d’un service-template en local
Ici je configure sur le switch le service-template finance_template
identity policy finance_template vlan 666
Et j’observe les conséquences. Ici une parenthèse pour indiquer que la configuration “identity policy” évolue en “service-template” quand on adopte le nouveau mode de configuration 802.1X.
On voit bien sur le port que, contrairement à l’exemple précédent, l’un des terminaux est placé dans le VLAN 666 localement défini et non plus dans le VLAN 21 configuré sur ISE.
Cat-3850-A#sh authentication sessions interface gi 1/0/9 details
Interface: GigabitEthernet1/0/9
IIF-ID: 0x107D38000000082
MAC Address: 000c.29b0.0218
IPv6 Address: Unknown
IPv4 Address: 10.153.201.5
User-Name: BNLAB-FR\muriel
Status: Authorized
Domain: DATA
Oper host mode: multi-auth
Oper control dir: both
Session timeout: N/A
Common Session ID: 0A9601090000105C8A5035AC
Acct Session ID: 0x0000106B
Handle: 0xE5000028
Current Policy: POLICY_Gi1/0/9
Server Policies:
Template: marketing_template (priority 100)
Vlan Group: Vlan: 22
Method status list:
Method State
dot1x Authc Success
----------------------------------------
Interface: GigabitEthernet1/0/9
IIF-ID: 0x10172C000000083
MAC Address: 000c.298b.45b1
IPv6 Address: Unknown
IPv4 Address: 10.153.200.4
User-Name: BNLAB-FR\christophe
Status: Authorized
Domain: DATA
Oper host mode: multi-auth
Oper control dir: both
Session timeout: N/A
Common Session ID: 0A9601090000105D8A5035AC
Acct Session ID: 0x0000106A
Handle: 0xD7000029
Current Policy: POLICY_Gi1/0/9
Server Policies:
Template: finance_template (priority 100)
Vlan Group: Vlan: 666
Method status list:
Method State
dot1x Authc Success
La table des VLANs confirme tout cela: les vlans 22 et 666 sont bien maintenant tous les 2 actifs pour le port Gi1/0/9:
Cat-3850-A#sh vlan | i finance|marketing|TEST 21 finance active 22 marketing active Gi1/0/9 666 TEST active Gi1/0/9
Et on voit bien dans les logs ISE que le commutateurs ne demande plus à recevoir les informations pour le service-template finance_template:
Conclusion
Ce petit test aura permis de montrer l’étendue des possibilités 802.1X sur les switchs Cisco et de vous donner un avant-goût des évolutions à venir qui offriront toujours plus de flexibilité quant à la connexion des usagers.
Un grand merci à Christophe Sarrazin, consultant sécurité, pour son aide précieuse lors de ce test!
Authors
1 commentaires
Bonjour,
J’ai pu tester cette méthode avec un Switch Cisco SF500 + Radius sur pfSense. Tout marche nickel sur postes Windows 7 (les utilisateurs se retrouvent dans le bon VLAN en fonction de leur authentif.), sauf quand il doit y avoir ouverture de session avec AD. Dans ce cas, il semble, malgré la configuration de la carte, qu’elle ne se connecte pas au réseau physique avant le démarrage de session, empêchant cette dernière de s’ouvrir (on doit donc s’authentifier en utilisateur local).