Actions
Bug #10197
closedfreeRADIUS virtual-server-default: modules daily, weekly, monthly, forever in authorize section prevent virtual server from loading
Start date:
01/22/2020
Due date:
% Done:
100%
Estimated time:
Plus Target Version:
Affected Version:
2.4.4-p3
Affected Plus Version:
Affected Architecture:
All
Description
When using freeRADIUS 3 package with mysql enabled for accounting only and using pfsense gui for users/authorization, the generated virtual-server-default file (/usr/local/etc/raddb/sites-enabled/default) authorize section looks like:
authorize {
# filter_username
# filter_password
preprocess
# operator-name
# cui
##### AUTHORIZE FOR PLAIN MAC-AUTH IS DISABLED #####
# auth_log
chap
mschap
digest
# wimax
# IPASS
suffix
ntdomain
eap {
ok = return
# updated = return
}
# unix
files
### sql DISABLED ###
daily
weekly
monthly
forever
# smbpasswd
### ldap ###
# Formerly checkval
if (&request:Calling-Station-Id == &control:Calling-Station-Id) {
ok
}
expiration
logintime
pap
Autz-Type Status-Server {
}
}
I believe since I am not using mysql for authorization, the daily, weekly, monthly, and forever modules are failing to load and causing the virtual server to fail to load. Relevant system log lines:
Jan 22 00:05:00 radiusd 16279 Failed to load virtual server default
Jan 22 00:05:00 radiusd 16279 /usr/local/etc/raddb/sites-enabled/default[24]: Errors parsing authorize section.
Jan 22 00:05:00 radiusd 16279 /usr/local/etc/raddb/sites-enabled/default[46]: Please verify that the configuration exists in /usr/local/etc/raddb/mods-enabled/daily.
Jan 22 00:05:00 radiusd 16279 /usr/local/etc/raddb/sites-enabled/default[46]: Failed to find "daily" as a module or policy.
Manually changing the authorize section in /usr/local/etc/raddb/sites-enabled/default as below fixes the problem (the modules are ignored and everything seems to work):
authorize {
..............
### sql DISABLED ###
-daily
-weekly
-monthly
-forever
# smbpasswd
### ldap ###
...............
}
I believe prepending the '-' causing the modules to only be loaded if they are configured. This should probably be how they are generated by the webconfigurator.
Thanks in advance for looking into this, you all do amazing work!
Related issues
Actions