Configuration Architecture 802.1x & Vlan via Radius

[LouD]

Bonjour,

Ceci étant mon premier post sur le forum, je tiens déja à vous féliciter pour le travail que vous fournissez et le dynanisme des gens qui le gère.

Je fais appel à vous car je me retrouve face à une problématique de configuration d'un réseau 802.1x.

La maquette que je monte est constituée de Bornes Cisco 1131, d'un WLSE et d'un serveur Radius StealBelted.
Le type d'authentification est du TLS.

En ce qui concerne les certificats, l'authentification et le paramétrage basique des bornes aucun soucis, tout fonctionne je suis aujourd'ui capable d'ouvrir un accès en wifi en étant correctement authentifié.

La grosse problématique concerne l'attribution des Vlans.
J'ai du un premier temps configuré des SSID bridgés sur des Vlans, ceci fonctionne également cependant pour plus de souplesse je souhaiterais mettre en place une attribution automatique des Vlans en fonction des users.

Le serveur Radius a été configuré a priori avec les bons attributs:

. Tunnel Type (064) : VLAN
. Tunnel-medium-Type (065) : 802
. Tunnel-Private6group-ID (081) : Nom du Vlan

Maintenant cela ne fonctionne pas et je pense qu'il faut faire une confniguration particulière sur la borne, mais je ne trouve pas d'info la dessus.

Si quelqu'un à une idée, un lien avec des informations ou des conseilsje suis preneur

Merci.

[ploum]

Hello,

Tres joli sujet, l'idée est bonne mais cela me parait difficile. A moins que tous tes users se connectent au même SSID puis se fassent attribuer ensuite un vlan selon leur groupe (AD ou autre..).
J'ai déjà bossé avec les "mobility network" sur des AP tu peux spécifier des sortes d'ID sur tes SSID puis les matcher avec d'autre matériel (WLSM, ACS..) avec le SeatBelt je ne sais pas si ça peut fonctionner. Cherche de ce coté mais à priori il te faudra quelquechose en plus pour que cela puisse fonctionner en vlan dynamique si cela est possible.

Bon courage.
_________________
Nicolas Papin
\"On n'arrête pas le progrès, même en se mettant devant !\"

[Ketchupy]

[Matt]

Je confirme ce que dis Ketchupy. Il faut que tu sniffe côté serveur et côté client pour savoir si tes paramèters arrivent proprement.

Attention à l'attribut Tunnel-Private6group-ID (081). Il faut parfois mettre le numéro du VLAN et chez d'autres contructeur mettre le nom du VLAN. A vérifier.

[LouD]

Bonjour,

Merci à ceux qui ont essayé d'apporter une réponse.

Aujourd'hui je n'ai toujours pas réussi à attribuer automatiquement les Vlans par le radius mais j'ai contourné le problème.
L'attribution des Vlans par Radius a été pensé pour contourner des éventuels problèmes de sécurité ( A savoir qu'un utilisateur ne puisse pas choisir le SSID sur lequel il se connecte, mais que celui-ci soit imposé. La meilleure solution semblait donc l'envoie des attribues par le Radius. )

Ce qui a été mis en place est un check par le Radius des attributs AVPAIRS Cisco. On vérifie le SSID depuis lequel le user essaie de se connecter. Si le SSID en question et la méthode d'authentification n'est pas celle attendue la connexion est refusée.

Je relance donc le débat, concernant le renvoie d'attribue pour Radius.
En gros ce que l'on cherche à mettre en place est l'inverse de la solution en prod.

Nous souhaitons lors de la phase d'authentification & de connexion, que le serveur radius renvoie les attributs de Vlans propre au user.
Je ne pense pas me tromper sur les attributs configurés cependant je ne vois rien passer ( Effectivement c le n° du Vlan et pas le nom c'était une erreur dans mon texte ).

J'ai peut-être une piste : les attributs sont bien envoyés par le Radius, mais ils sont encapsulés dans le tunnel EAP et du coup la borne Wireless ne les voit pas.

Si cette hypothèse est correct il faut trouver le moyen de sortir du tunnel EAP les attribus renvoyés par le Radius ( Je rappel que j'utilise un Steel Belted ).

Voila je soumet cette nouvelle problématique ^^

Merci

[vseb62]

Hello,

Je me suis intéressé aussi à ce problème. Et j'ai finalement réussi à faire marcher l'ensemble sur une maquette. Je me suis basé sur diverses informations disponibles sur l'Internet qui sont la plupart du temps incomplètes. Même chez Cisco, les principes généraux sont listés mais sans détails sur la mise en œuvre.
Ma config est la suivante :
AP Cisco 1131BG
FreeRadius 1.1.3 sure Fedora core x, Mysql server
PKI Windows.

Ce que j'ai retenu de la configuration du Point d'accès :
- Définir un SSID qui sera le seul visible (beacon mode=single, guest ssid=ce SSID)
- Définir autant de Vlan que de SSID et les associer, c'est une contrainte de la config CISCO, mais c'est le server radius qui a le dernier mot.
- Associer la bonne encryption et authentification (j'ai un VLAN en AES CCMP, 2 en TKIP), tous les SSID sont en Open Authentication : EAP. Ce dernier cas est important pour le SSID visible, car c'est lui qui sera utilisé pour l'authentification.
- Le point d'acces récupere bien les infos encapsulés dans EAP.
- Une fois le PC (windoze) connecté, on le voit connecté au SSID visible, mais en réalité est connecté sur le VLAN associé à l'utilisateur.

Le serveur Radius.
Je n'avais que Freeradius sous la main et c'est ce que j'utilise déjà. Je pense que le problème se situe dans la manière d'envoyer les infos au point d'accès et non au niveau du serveur radius.
Mon serveur radius est configuré pour EAP-TLS, que j'ai testé avant, auquel j'ai ajoute le support de mysql pour la base utilisateur que je n'utilise pas dans le cas d'EAP-TLS.
J'ai utilise le schéma propose par radius pour mysql, avec l'interface dialup_admin (web), mais on peut créer soi-même quelques entrées sous mysql directement. Et j'ai créé un groupe, un utilisateur du même nom que le certificat appartenant a ce groupe. J'ai ensuite renseigné la table radgroupreply avec les attributs à renvoyer au point d'accès par Radius. Ces informations sont récupérées par radius lors de la phase "authorize" consécutifs à l'authentification si elle est réussie.
Il s'agit dont des 3 biens connus sauf que dans le cas des points d'accès CISCO, il faut renvoyer les valeurs spécifiées par la RFC 2868. Les valeurs listes dans vos posts précédents font référence à la signification et non a la valeur attendu par le point d'accès et qui aura cette signification. Donc :
- Tunnel-Type doit être renseigne avec la valeur 13 qui veut dire VLAN
- Tunnel-Medium-Type doit être renseigne avec la valeur 6 qui veut dire 802
- Tunnel-Private-Group doit être renseigne avec le vlan-id et pas le nom.

On peut voir comment réagit le point d'accès, en forçant le mode debug sur l'authentification. Si on met les valeurs 802, ou VLAN dans les attributs, ils ne sont pas traduits dans les logs. alors qu'avec les valeurs indiquées dans la RFC, le log affiche la signification de la valeur.
Pour passer le Point d'accès en debug sur l'authentification, à partir du mode command, en enable (http://www.cisco.com/en/US/products/hw/wireless/ps430/products_tech_note09186a008024aa4f.shtml):
debug radius authentication
debug dot11 aaa authenticator process
debug dot11 aaa authenticator state-machine .
Consulter ensuite le syslog, ou le log bufférisé.

Si vous passez le cap, je cherche pour ma part à configurer un seul SSID visible, et pouvoir basculer sur 2 vlans différents : utilisateurs locaux , et visiteurs. Pour les locaux pas de problèmes, pour les visiteurs je cherche un moyen simple de faire passer un login/mdp à partir du client standard.

[guitch]

Hello,
pour moi j'utilise l'affectioant de vlan par radius assez souvent, en effet cela permet de forcer via le serveur radius (qui est autoritaire en quelque sorte) le vlan.
Par contre comme deja dit au dessus, je met l'ID du vlan et non pas le Nom du vlan dans le champ pvt-group-ID
Sinon le steelbelt n'est un radius "facile a prendre en main" à mon sens => pour PEAP par exemple : nécessité d'aller éditer les fichiers de conf en texte ...
mais perso je l'ai deja fait marcher en clientelle.
J'ajouterai qu'il faut toujours prendre la derniere version stable ...
Si c'est sur du ex-airespace (4400 genre) on peut mettre le nom du vlan, mais pour les switchs et les AP aironet (1100, 1200) le numero de vlan est le bon paramètre à mon sens.
Un sniff réseau des trames radius n'est pas évident (TLS), et je pense qu'il est préférable (bien que peut lisible qd meme) de mettre le serveur steelbelted en debug niveau 5 ou 9 je me souviens plus trop) pour avoir des traces des trames.

Mesqage pour vseb62 : un meme SSId implique obligatoirement une meme méthode d'authentification + cryptage (802.1X + WPA ou WPA2 par exemple)
Si j'ai bien suivi ce que tu voulais =
1 seul SSID
¤ pour les utilisateurs internes (locaux) = leur login/pwd radius pour se logguer
¤ pour les visiteurs une configuration plus simple ...
c'est ca ou j'ai mal compris ?
en tout cas si c'est ce cas, je ne pense pas que ca soit possible.

De plus, dans le cas du Wifi, il n'est pas possible (en tout cas pour le moment me semble-t-il) d'avoir une notion de "Guest-Vlan" qui si l'auth 802.1x échoue permet d'accèder quand meme à certaines ressources (genre un Cisco BBSM ou autre portail captif) notamment de part le fait qu'un SSId = cryptage (en général) et donc authentification ...

A+ et bonne fin d'année !

Ps : Lou : tiens nous au courant !!