The radius config parser will not load a duplicate named routine. You would need to change the name and then add a call to it either before or after the original routine call/s. However, if you are looking to see if a User-Name attribute exists, and then reject it if it does, your routine, when added will do it. Duplicate checking is handled in the sites-available configs, which you can either enable or disable. If you are using a database, then the sql code is included and can be used. Please read the instructions found in the config files for guidance. Thanks On 2024/11/03 23:05, Alex Zetaeffesse wrote:
Hi all,
I apologize if I don't use the right terminology. I'm playing/testing with 3.2.6 to better understand how freeradius behaves when finding duplicate definitions. I created a copy of the filter policy, calling it policy.d/filter2 and I defined the object/policy filter_username in this way:
filter_username { if (&User-Name) { reject } }
Now, when in the directory policy.d I only have the file filter2, I always get the expected Access-Reject, if I just have the default file filter I get Access-Accept (the user is correctly configured in the file users). If I have both files (filter and filter 2), when I launch radiusd -X I get, the file filter is loaded first and then the file filter2
...
*including configuration file /etc/freeradius/policy.d/filter <<<*including configuration file /etc/freeradius/policy.d/operator-name including configuration file /etc/freeradius/policy.d/eap including configuration file /etc/freeradius/policy.d/debug including configuration file /etc/freeradius/policy.d/accounting
*including configuration file /etc/freeradius/policy.d/filter2 <<<* ...
and I always get Access-Accept. How are duplicate objects treated? Is the first definition that's retained or the last? From my experiment it seems the first is retained. May you please confirm?
Regards,
Alex - List info/subscribe/unsubscribe? Seehttp://www.freeradius.org/list/users.html