FreeRadius3.X + CaptivePortal + Active directory
-
Bonjour,
Suite à une "merveilleuse" manipulation d'un de mes collègues. J'ai l'un de mes Pfsense sur mes sites distants qui c'est retrouvé totalement HS.
Après avoir effectué une réinstallation basique, je me suis retrouvé confronté à un problème. tout mes autres serveur sont en 2.3.4 avec freeradius2.Sur ce nouveaux serveur j'ai donc fait exactement la même configuration mais avec pfsense 2.4 et Freeradius3 et la malheureusement je me retrouve sans authentification sur mon portail captif.
je vous met un log d'une tentative de connexion en mode debug
Ready to process requests
(0) Received Access-Request Id 201 from X.X.X.X:53980 to Y.Y.Y.Y:1812 length 137
(0) NAS-IP-Address = Y.Y.Y.Y
(0) NAS-Identifier = "pfSense_Boulogne.localdomain"
(0) User-Name = "wifisk"
(0) User-Password = "ZZZZZZZZ"
(0) Service-Type = Login-User
(0) NAS-Port-Type = Ethernet
(0) NAS-Port = 2000
(0) Framed-IP-Address = X.X.X.X
(0) Called-Station-Id = "Y.Y.Y.Y"
(0) Calling-Station-Id = "TTTTTTTTTTT"
(0) # Executing section authorize from file /usr/local/etc/raddb/sites-enabled/default
(0) authorize {
(0) [preprocess] = ok
(0) [chap] = noop
(0) [mschap] = noop
(0) [digest] = noop
(0) suffix: Checking for suffix after "@"
(0) suffix: No '@' in User-Name = "wifisk", skipping NULL due to config.
(0) [suffix] = noop
(0) ntdomain: Checking for prefix before ""
(0) ntdomain: No '' in User-Name = "wifisk", skipping NULL due to config.
(0) [ntdomain] = noop
(0) eap: No EAP-Message, not doing EAP
(0) [eap] = noop
(0) [files] = noop
rlm_counter: Entering module authorize code
rlm_counter: Could not find Check item value pair
(0) [daily] = noop
rlm_counter: Entering module authorize code
rlm_counter: Could not find Check item value pair
(0) [weekly] = noop
rlm_counter: Entering module authorize code
rlm_counter: Could not find Check item value pair
(0) [monthly] = noop
rlm_counter: Entering module authorize code
rlm_counter: Could not find Check item value pair
(0) [forever] = noop
(0) redundant {
rlm_ldap (ldap): 0 of 0 connections in use. You may need to increase "spare"
rlm_ldap (ldap): Opening additional connection (0), 1 of 16 pending slots used
rlm_ldap (ldap): Connecting to ldap://R.R.R.R:389
rlm_ldap (ldap): Waiting for bind result…
rlm_ldap (ldap): Bind successful
rlm_ldap (ldap): Reserved connection (0)
(0) ldap: EXPAND (|(userprincipalname=%{User-Name})(samaccountname=%{User-Name}))
(0) ldap: --> (|(userprincipalname=wifisk)(samaccountname=wifisk))
(0) ldap: Performing search in "dc=YYYYY,dc=asso,dc=fr" with filter "(|(userprincipalname=wifisk)(samaccountname=wifisk))", scope "sub"
(0) ldap: Waiting for search result...
(0) ldap: User object found at DN "CN=WIFISK,OU=Etudiants,DC=YYYYY,DC=asso,DC=fr"
(0) ldap: Processing user attributes
(0) ldap: WARNING: No "known good" password added. Ensure the admin user has permission to read the password attribute
(0) ldap: WARNING: PAP authentication will NOT work with Active Directory (if that is what you were trying to configure)
rlm_ldap (ldap): Released connection (0)
Need 15 more connections to reach min connections (16)
rlm_ldap (ldap): Opening additional connection (1), 1 of 15 pending slots used
rlm_ldap (ldap): Connecting to ldap://R.R.R.R:389
rlm_ldap (ldap): Waiting for bind result...
rlm_ldap (ldap): Bind successful
(0) [ldap] = ok
(0) } # redundant = ok
(0) if (&request:Calling-Station-Id == &control:Calling-Station-Id) {
(0) ERROR: Failed retrieving values required to evaluate condition
(0) [expiration] = noop
(0) [logintime] = noop
(0) pap: WARNING: No "known good" password found for the user. Not setting Auth-Type
(0) pap: WARNING: Authentication will fail unless a "known good" password is available
(0) [pap] = noop
(0) } # authorize = ok
(0) ERROR: No Auth-Type found: rejecting the user via Post-Auth-Type = Reject
(0) Failed to authenticate the user
(0) Using Post-Auth-Type Reject
(0) # Executing group from file /usr/local/etc/raddb/sites-enabled/default
(0) Post-Auth-Type REJECT {
(0) attr_filter.access_reject: EXPAND %{User-Name}
(0) attr_filter.access_reject: –> wifisk
(0) attr_filter.access_reject: Matched entry DEFAULT at line 11
(0) [attr_filter.access_reject] = updated
(0) [eap] = noop
(0) policy remove_reply_message_if_eap {
(0) if (&reply:EAP-Message && &reply:Reply-Message) {
(0) if (&reply:EAP-Message && &reply:Reply-Message) -> FALSE
(0) else {
(0) [noop] = noop
(0) } # else = noop
(0) } # policy remove_reply_message_if_eap = noop
(0) } # Post-Auth-Type REJECT = updated
(0) Login incorrect (Failed retrieving values required to evaluate condition): [wifisk] (from client portailcaptif port 2000 cli b8:ac:6f:35:2d:55)
(0) Delaying response for 1.000000 secondsEn configuration Freeradius:
Default EAP Type : TLS
Enable LDAP For authorization
Enable LDAP For authenticationLe compte de service pour interrogé l'AD est le même sur tout les serveurs
Active directory compatibility Enable.
Voila si vous connaissez des subtilité entre freeradius3 et freeradius2 je suis preneur (je suis dessus depuis quelques heures maintenant)
si vous avez besoin de précisions n'hésitez pas non plus.Et si en dernier recours vous connaissez un moyen de récupérer le package freeradius2 je suis preneur également.
merci à vous
-
Bon finalement j'ai été obligé d'éditer les fichiers de conf de radius. Sur le site de freeradius pour ceux que ça intéresse.
Vous pensez qu'il y a des risques ?
"
rlm_ldap authenticationIn 2.x.x the LDAP module had a set_auth_type configuration item that forced Auth-Type := ldap. This was removed in 3.x.x as it often did not work and was not consistent with the rest of the server. It is generally recommended that LDAP should be used as a database and that FreeRADIUS should do authentication.
The only reason to use Auth-Type := ldap is when the LDAP server will not supply the "known good" password to FreeRADIUS and when the Access-Request contains User-Password. This situation happens only for Active Directory. Forcing Auth-Type := ldap in other situations is very likely to be wrong.
The following is an example of what should be inserted into the authorize {} and authenticate {} sections of the relevant virtual-servers to get functionality equivalent to v2.x:
authorize {
…
ldap
if ((ok || updated) && User-Password) {
update control {
Auth-Type := ldap
}
}
...
}authenticate {
...
Auth-Type ldap {
ldap
}
...
}
" -
Je ne vais pas t'aider directement sur ton problème (d'autant que tu sembles l'avoir au moins partiellement résolu par tout seul) mais commenter un point de "détail": je vois dans ton log que tu te connectes à un serveur LDAP sur le port 389… pourquoi pas, si c'est une connexion en mode anonyme mais en l'occurence, je ne pense pas que ce soit le cas.
Tout ce qui est en mode authentifié nécessite d'être executé sur le port 636 en LDAPS car la commande ldapbind envoie le mot de passe en base64, c'est à dire en clair !
-
Bonjour,
je suis tombé sur le même problème et ai pu le résoudre grâce à la modification de code proposée dans :
/usr/local/etc/raddb/sites-enabled/defaultauthorize { ... ldap if ((ok || updated) && User-Password) { update control { Auth-Type := ldap } } ... } authenticate { ... Auth-Type ldap { ldap } ... }
Merci pour le tuyau ;-)
Cependant, à chaque redémarrage de la machine, le réglage saute.
Savez vous pourquoi et comment régler celà ?D'avance merci !
-
Cependant, à chaque redémarrage de la machine, le réglage saute.
Savez vous pourquoi et comment régler celà ?C'est comme ça que pfSense fonctionne !
Quand on configure un service - avec le GUI - le fichier de configuration est paramétré en conséquence, et le service est démarré ou redémarré si nécessaire.
Au démarrage de pfSense, toutes les fichiers de config de toutes les services sont crées suivant ce seul fichier : le /conf/config.xml. -
Tout ce qui est en mode authentifié nécessite d'être executé sur le port 636 en LDAPS car la commande ldapbind envoie le mot de passe en base64, c'est à dire en clair !
Je dirais même port 3269 (global catalog, en mode ssl) du moment que l'active directory possède plus d'un site (ce qui bien souvent le cas).