FreeRadius is not sending attributes to the Wireless Controller on the Access-Accept package

[Manny_Dayz]

We have configured a FreeRadius to work along with an IdentiFi Wireless Controller, but even when it is authenticating correctly, the FreeRadius server it's not sending the attributes on the Access-Accept package. We are trying to send specifically the Filter-Id attribute in order to have one single SSID and send the users to their respective VLAN or Topology matching the Roles with the Filter-Id.

When doing a packet capture from the controller, we see that none attribute is sent from the FreeRadius server to the Controller on the Access-Accept message, therefore the users are note getting redirected to the right Role and Topology.

Seems that the issue might be on the FreeRadius server but we haven't figured how to solve it.

We would appreciate any comment you may have.

Thank you.

[cunz]

Hello,

I know that this thread is a bit old 🙂 , but I solved in this way:

“The solution is to move the "files" module to before "eap". Edit sites-enabled/default. Look at the "authorize" section.”

That works. Excerpt of edited sites-enabled/default:

#  
#  This module takes care of EAP-MD5, EAP-TLS, and EAP-LEAP  
#  authentication.  
#  
#  It also sets the EAP-Type attribute in the request  
#  attribute list to the EAP type from the packet.  
#  
#  The EAP module returns "ok" or "updated" if it is not yet ready  
#  to authenticate the user.  The configuration below checks for  
#  "ok", and stops processing the "authorize" section if so.  
#  
#  Any LDAP and/or SQL servers will not be queried for the  
#  initial set of packets that go back and forth to set up  
#  TTLS or PEAP.  
#  
#  The "updated" check is commented out for compatibility with  
#  previous versions of this configuration, but you may wish to  
#  uncomment it as well; this will further reduce the number of  
#  LDAP and/or SQL queries for TTLS or PEAP.  
#  
files  
eap {  
    ok = return  
#       updated = return  
}  

#  
#  Pull crypt'd passwords from /etc/passwd or /etc/shadow,  
#  using the system API's to get the password.  If you want  
#  to read /etc/passwd or /etc/shadow directly, see the  
#  mods-available/passwd module.  
#  
# unix  

#  
#  Read the 'users' file.  In v3, this is located in  
#  raddb/mods-config/files/authorize  
#   files  

[Glissie_G]

Hi Manuel,

Did you get the filter-id in Radius-Accept packet working? Thanks!

[Doug]

I'm not sure about any default setting I needed to change the last time I had this working. I couldn't find anything in any of our databases either.

[Manny_Dayz]

Hello Doug,

Thank you for your reply, even though I have already tried that but with no luck. It seems that I must do something with the file "default" on the "post-auth" section for it to send the attributes I am defining for the users, included the Filter-Id.