Bonjour à tous, Je vous fais un retour rapide de sorte à ce que si quelqu’un retombe sur ces messages ultérieurement, il aura au moins une piste.
Après avoir posté sur le forum d’Aruba, nous avons eu accès à leur support et ils nous ont aidé à troubleshooter tout ca. Le résultat est que c’est un bug dans le firmware et ils vont le réparer. La nouvelle version sortira mi-Mars et devrait résoudre ce bug. Bonne journée, Antoine > On 29 Feb 2016, at 17:30, Antoine Benkemoun <antoine.benkem...@gmail.com> > wrote: > > Bonjour à tous, > > Cette requête serait idéalement dirigée vers le support Aruba/HP mais nous > sommes en train d'essayer de nous démêler au niveau de nos contrats avec > eux et donc nous sommes coincés en attendant. C'est assez fou comment > obtenir du support pour des équipements achetés par les canaux officiels du > constructeur peut être compliqué... Bref. > > Nous avons 5 bornes Aruba IAP-205 qui vont remplacer nos bornes Cisco > Aironet 2609. Une de ces bornes est master des autres. > > Nous avons fait la configuration du freeradius pour qu'il fasse > l'authentification des clients en 802.1X via le NTLM et qu'il fasse ensuite > un lookup LDAP pour envoyer des attributs en fonction de la présence de > l'utilisateur dans un groupe donné. On a essayé d'utiliser les attributs > vendor-specific Aruba-User-Vlan et Aruba-User-Role ainsi que les attributs > Tunnel de Microsoft. > > Cette partie-là fonctionne car dans le freeradius -X les attributs > s'affichent correctement et sur la capture Wireshark les attributs sont > bien présents dans les paquets. > > Néanmoins, lorsque l'Aruba reçoit ces attributs, il n'en fait rien 2 fois > sur 3. Avec certains utilisateurs, 2 de leurs équipements sont dans le VLAN > par défaut et 1 équipement est dans le bon VLAN. Pour les autres, c'est > apparemment aléatoire. > > On a sorti le débug des AP et on remarque que lorsque ca fonctionne on a la > ligne suivante : > > <501142> <DBUG> <172.17.16.2 84:D4:7E:C0:A0:FA> Derive user vlan: > 98:e0:d9:ae:83:29 Derive user Vlan 1700 from VSA > > Lorsque ca ne fonctionne pas, on a quelque chose comme ca à la place : > > <172.17.16.2 84:D4:7E:C0:A0:FA> stm[1852]: > VLAN_HIGHER_PRECEDENCE_THAN_STORED: 1064: vlan_rule_index=ff, > sap_sta->vlanhow=ff, precedence_result=1 > <172.17.16.2 84:D4:7E:C0:A0:FA> stm[1852]: __HIGHER_PRECEDENCE_COMPARE: > 1041: matched_rule_index=37fff, sap_sta->acl_rule_index=0, > precedence_result=1 > stm[1852]: <501146> <DBUG> <172.17.16.2 84:D4:7E:C0:A0:FA> Derive user > role: cc:20:e8:b9:45:43 Match user role acl 136 rule_index 0x37fff > > On dirait donc qu'il trouve le rôle ailleurs lorsque ca ne fonctionne pas > mais la question est où ? > > Évidemment quand on faisait les tests dans le lab, ça fonctionnait tout à > fait correctement sinon c'est pas rigolo ! > > Si quelqu'un a déjà rencontré ce problème ou un problème similaire, nous > sommes donc preneurs de retour :-) > > Merci par avance, > > Antoine > > --------------------------- > Liste de diffusion du FRnOG > http://www.frnog.org/ --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
