VLan affect based on ldap attribute freeradius v3

[jehan procaccia INT]

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 at 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