Hello sucessfull reponses below ... Le 31/08/2018 à 14:59, Alan DeKok a écrit :
On Aug 31, 2018, at 4:45 AM, jehan procaccia INT <jehan.procaccia@int-evry.fr> wrote:
unfortunatly it fails, User-Category attribute fetch from ldap edupersonPrimaryAffiliation doesn't pass though different states/modules apparently Yes, it does. You should be able to tell what's going on by reading the debug output. *Or* by posting the ENTIRE debug output here, and letting someone else read it.
You're falling into a common trap. You're trying all kinds of random things. Without really understanding what's going on, or why. You're posting *small* bits of the debug output, in the hope that those bits are useful.
They're not.
Post the FULL DEBUG OUTPUT.
And make sure it's for ONE USER. We're not going to read through thousands of lines of logs about accounting packets, in order to solve an authentication issue. you're right, after a weekend reading thouroughly http://networkradius.com/doc/FreeRADIUS%20Technical%20Guide.pdf and wiki thingsget better now , althought it's not easy to get a single user debug output from production . fortunatly you gave me the right answer with
"use_tunneled_reply = yes" adding that not only (which was already set) to mods-enabled/eap section: eap { ttls { but moreover to peap { which is our prevalent method used, now makes the attribute correctly flowed in the process chapter 4.3 of the tech guide is important to understand the iteractive / recursive processing of the configuration sections and modules . the debug output seems very repetitive whitout that and https://wiki.freeradius.org/guide/radiusd-X helps a lot to . thanks for your help , now it work fine ;-) Regards PS my connection as an employee (ldap) and associated vlan accordingly : (86) prod: reply:Reply-Message := 'employee' (86) prod: reply:User-Category += 'employee' (86) Virtual server sending reply (86) Reply-Message := "employee" (86) User-Category += "employee" (86) eap_peap: Got tunneled reply RADIUS code 2 (86) eap_peap: Reply-Message := "employee" (86) eap_peap: User-Category += "employee" (88) eap_peap: Using saved attributes from the original Access-Accept (88) eap_peap: Reply-Message := "employee" (88) eap_peap: User-Category += "employee" (88) [eap] = ok (88) } # authenticate = ok (88) # Executing section post-auth from file /etc/raddb/sites-enabled/default (88) post-auth { (88) update { (88) No attributes updated (88) } # update = noop (88) reply_log: EXPAND /var/log/radius/radacct/%{%{Packet-Src-IP-Address}:-%{Packet-Src-IPv6-Address}}/reply-detail-%Y%m%d (88) reply_log: --> /var/log/radius/radacct/10.91.10.10/reply-detail-20180903 (88) reply_log: /var/log/radius/radacct/%{%{Packet-Src-IP-Address}:-%{Packet-Src-IPv6-Address}}/reply-detail-%Y%m%d (88) reply_log: EXPAND %t (88) reply_log: --> Mon Sep 3 09:24:23 2018 (88) [reply_log] = ok (88) [exec] = noop (88) policy remove_reply_message_if_eap { (88) if (&reply:EAP-Message && &reply:Reply-Message) { (88) if (&reply:EAP-Message && &reply:Reply-Message) -> TRUE (88) if (&reply:EAP-Message && &reply:Reply-Message) { (88) update reply { (88) &Reply-Message !* ANY (88) } # update reply = noop (88) } # if (&reply:EAP-Message && &reply:Reply-Message) = noop (88) ... skipping else: Preceding "if" was taken (88) } # policy remove_reply_message_if_eap = noop (88) policy debug_reply { (88) if ("%{debug_attr:reply:}" == '') { (88) Attributes matching "reply:" (88) &reply:User-Category += employee (88) &reply:Stripped-User-Name = procacci (88) if ("%{debug_attr:reply:}" == '') -> TRUE (88) if ("%{debug_attr:reply:}" == '') { (88) [noop] = noop (88) } # if ("%{debug_attr:reply:}" == '') = noop (88) } # policy debug_reply = noop (88) if (( &reply:User-Category == "employee") || (&reply:User-Category == "faculty") || (&reply:User-Category == "staff" ) || (&reply:User-Category == "researcher") || (&reply:User-Category == "member")) { (88) if (( &reply:User-Category == "employee") || (&reply:User-Category == "faculty") || (&reply:User-Category == "staff" ) || (&reply:User-Category == "researcher") || (&reply:User-Category == "member")) -> TRUE (88) if (( &reply:User-Category == "employee") || (&reply:User-Category == "faculty") || (&reply:User-Category == "staff" ) || (&reply:User-Category == "researcher") || (&reply:User-Category == "member")) { (88) update reply { (88) Tunnel-Private-Group-Id := 903
even with the usage of session-state (replacing "reply") it fails
here's a new radiusd -X experiment :
1) ldap does find the attribute and associated value (here employee)
rlm_ldap (prod): Reserved connection (7) (93) prod: reply:Reply-Message := 'employee' (93) prod: reply:User-Category += 'employee'
2) eap-peap has it
(93) post-auth { (93) if (0) { (93) if (0) -> FALSE (93) } # post-auth = noop (93) Login OK: [radu/<via Auth-Type = eap>] (from client prod port 0 via TLS tunnel) (93) } # server inner-tunnel (93) Virtual server sending reply (93) Reply-Message := "employee" (93) *User-Category += "employee"* (93) eap_peap: Got tunneled reply code 2 (93) eap_peap: Reply-Message := "employee" (93) eap_peap: *User-Category += "employee"* Note that's all in packet 93. AND in the "inner tunnel" virtual server.
3) eap_peap is success
(94)*eap_peap: Success* Which is packet 94. Note that "94" is NOT THE SAME as "93".
i.e. it's a different packet. So unless you made sure to get the attribute from packet 93 inner tunnel reply to packet 94 outer reply... the attribute won't be in packet 94.
should I see something like &reply:User-Category above No.
? not been present means it's already lost ? It hasn't been lost.
All you need to do is read mods-available/eap, and set "use_tunneled_reply = yes". And read the comments for that configuration item. They explain what it is, why you need it, and when you want to use it.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html