Cisco France Blog
Partager

J'ai testé pour vous: 802.1X et la possibilité d'assigner des VLANs différents sur un même port


26 August 2013


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

Lab-setup

 

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.

Profile

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.

ISE-auth

 

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:

Auth-logOn 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”

Log-service-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:

Auth-log2

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!

Tags:
Laisser un commentaire

1 commentaires

  1. 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).