Le problème a été (au moins partiellement) résolu. Peut-être minato6 fera t-il un petit feedback plus détaillé ici.
Pour résumer:
faire fonctionner le portail captif avec LDAP (ce qui est cahier des charges initial) nécessite d'empiler, avec des configurations cohérentes, pfSense, le portail captif, un serveur Radius et un serveur LDAP (qui en l’occurrence n'est pas AD ;))
il y avait des soucis dans le fonctionnement du serveur LDAP (avec comme je l'ai signalé, des messages de type bad checksum)
il fallait, dans le cadre de cette configuration de lab, apprendre un minimum de choses sur le fonctionnement de LDAP. Bien que le protocole soit simple, en partant de zéro ça peut paraître compliqué :-\
Une fois ces différents points adressés, ça fonctionne suffisamment pour démontrer la faisabilité et les conditions de réalisation, encore une fois "pour un exercice de labo". Avant une mise en production éventuelle, il reste plein de points à adresser. Par exemple le déploiement d'un serveur LDAP est un projet à part entière qui est au coeur d'une problématique de type "gestion des identité" (mais pas uniquement).
Pour compléter, d'un point de vue LDAP, le point soulevé par Florian22:
le login LDAP peut être n'importe quel attribut de l'entré, pour autant que celui-ci est unique dans la branche recherché. Avec un serveur LDAP classique, on utilise très généralement l'attribut UID qui est également souvent le RDN de l'entrée.
Microsoft, comme à son habitude, a un peu perverti les choses en
=> utilisant CN comme RDN :o :o :o
=> n'utilisant pas UID mais SamAccoutnName comme attribut contenant le login équivalent à l'UID
par ailleurs, la généralisation de la notion de domaine (au sens Windows du terme) avec, et ce point est dans le principe très positif, la généralisation de l'utilisation de Kerberos fait que le mécanisme d'authentification est souvent basé sur Kerberos qui demande un login dans le cadre d'un contexte (domaine), d'où la confusion, entretenue par le fait qu'il existe un attribut dans AD qui associé CN et domaine et permet donc de s'authentifier en s'appuyant sur LDAP mais avec cette notion de domaine "incluse".
Je vous invite à faire attention à ce point lors de la configuration, pour ceux qui l'utiliserait du package FreeRadius dans sa partie LDAP: la section qui décrit le "stripping around @" adresse exactement ce point.
Pour l'utilisateur final, la difficulté est qu'il ne sait pas nécessairement si l’authentification qui lui est demandé est LDAP ou Kerberos (et ce n'est pas son problème ;D)
@minato6: si le problème est, comme je l'écris, "résolu", je t'invite à éditer ton premier post et à préfixer le titre avec [RESOLU] ;)
