- Freeradius-Users - lists.freeradius.org

Freeradius 3.0.19 and 3.0.21 can not find proto_acc.so and proto_auth.so.
by CpServiceSPb . 19 Apr '20

19 Apr '20

I had 3.0.19 before and now have installed 3.0.21. But for both versions I got and get: Loading library using linker search path(s) Defaults : /lib:/usr/lib Failed with error: proto_auth.so: cannot open shared object file: No such file or directory listen { type = "auth" ipaddr = 192.168.0.254 port = 1812 limit { max_connections = 16 lifetime = 0 idle_timeout = 30 } } Loading proto_acct with path: /usr/lib/freeradius/proto_acct.so Loading proto_acct failed: /usr/lib/freeradius/proto_acct.so: cannot open shared object file: No such file or directory - No such file or directory Loading library using linker search path(s) Defaults : /lib:/usr/lib Failed with error: proto_acct.so: cannot open shared object file: No such file or directory listen { type = "acct" ipaddr = 192.168.0.254 port = 0 limit { max_connections = 16 lifetime = 0 idle_timeout = 30 } } As I saw at freeradius site there are only 2 proto_ modules - proto_ and proto_dhcp. Is it normal and does not it affect anythingor not ? Should I change my setting to avoid it or what is necessary to do ? Or it does not affect to anything and should be forgotten.

2 3

New sqlippool under accounting breaks (FreeRADIUS 3.0.21)
by Houman 19 Apr '20

19 Apr '20

Hello, I'm using the latest FreeRADIUS Version 3.0.21 that is released for Ubuntu LTS 18.04. And it seems there is a breaking change, that I haven't seen before. /etc/freeradius/sites-enabled/default[687]: Failed to find "sqlippool" as a module or policy. Apr 19 08:44:15 d-4 freeradius[2774]: /etc/freeradius/sites-enabled/default[687]: Please verify that the configuration exists in /etc/freeradius/mods-enabled/sqlippool. Apr 19 08:44:15 d-4 freeradius[2774]: /etc/freeradius/sites-enabled/default[661]: Errors parsing accounting section. There is no file at /etc/freeradius/mods-enabled/sqlippool But I can see a new module called sqlippool under accounting in /etc/freeradius/sites-enabled/default. May someone point me into the right direction what this is and how to configure it? Thank you, Houman

3 2

freeradius 3.0.21 rlm_sql_freetds problem
by Ali Arslan 17 Apr '20

17 Apr '20

Hello, I have installed freeradius 3.0.21 on ubuntu 18.04 server. I wanted to use mssql as radius database server, so i installed freetds as apt-get install freetds-dev freetds-bin tdsodbc and configured /etc/freetds/freetds.conf file as [RadiusSqlServer] host = sqlserver_ip_address port = 1433 tds version = 7.0 and configured /etc/freeradius/mods-available/sql file to use rlm_sql_freetds as deriver. But I got error: Could not link driver rlm_sql_freetds: : cannot open shared object file: No such file or directory Make sure it (and all its dependent libraries!) are in the search path of your system's ld /etc/freeradius/mods-enabled/sql[27]: Instantiation failed for module "sql" Installation of freeradius does not create file /usr/lib/freeradius/rlm_sql_freetds.so.To create this file i first install freeradius 3.0.16 (standard on ubuntu 18.04) then copy file to another location and uninstall freeradius 3.0.16 and install 3.0.21 and copy file back to/usr/lib/freeradius/ folder. Is this a bug in freeradius 3.0.21 package?

4 6

New ODBC Howto
by Alan DeKok 17 Apr '20

17 Apr '20

Thanks to Terry Burton, we now have a new ODBC Howto on the wiki: https://wiki.freeradius.org/modules/Rlm_sql_unixodbc The documentation has been tested to work on a number of different systems. Alan DeKok.

1 0

new error message spotted in FR logs
by Alex Sharaz 17 Apr '20

17 Apr '20

Just been browsing our FR log files having migrated a server to Ununtu 18.06 from 16.04 and noticed the following error message ERROR: Couldn't get issuer_cert for eapoltest2020(a)york.ac.uk epoltest2020(a)york.ac.uk is a test client cert generated using our local pki manually pused to FR via eapol_test. We've been using a version of that to perform health checks for TLS validation for years and I've only just noticed the above message ( running 3.0.22 from git) doesn't matter whether I use pem files or p.12 flles in the wpa_supplicant .conf file still get the message. On the server, in our /etc/freeradius/mods-enabled/eap file I have a ca_file set to a file with a list of all the root/ intermediate CAs that might issue a client certificate. ... again that hasn't changed for a long time. TBH these servers have been fit and forget for a long time, so the error message might have been there for a while. The client successfully auths via an OCSP validation so its not causing any problems ..... other than its there and I feel it shouldn't be, the ca_file specified has an extension of .chain ... but that shouldn't matter should it ? Rgds Alex

2 2

Instantiation of python module fails on 3.0.21
by Christian Strauf 17 Apr '20

17 Apr '20

Hi all! We've been running FreeRADIUS 3.0.20 successfully on several Ubuntu 18.04.4 LTS machines. We make use of the rlm_python module. We compile the packages according to https://wiki.freeradius.org/building/Debian-and-Ubuntu For test purposes we install the packages on the same machine that we compile them on. We've recently built packages for FreeRADIUS 3.0.21, took the sample configuration that comes with it and modified it to our local needs (there were hardly any changes necessary between 3.0.20 and 3.0.21). However, when running version 3.0.21, "freeradius -X" gives us: --------8<--------8<--------8<--------8<--------8<-------- [...] # Instantiating module "python" from file /etc/freeradius/mods-enabled/python Python version: 2.7.17 (default, Nov 7 2019, 10:07:09) [GCC 7.4.0] <type 'exceptions.SystemError'> (null argument to internal routine) /etc/freeradius/mods-enabled/python[9]: Instantiation failed for module "python" --------8<--------8<--------8<--------8<--------8<-------- The python version mentioned is correct. Also, rlm_python.so is properly linked against the correct python version: --------8<--------8<--------8<--------8<--------8<-------- # ldd rlm_python.so linux-vdso.so.1 (0x00007ffd10b5f000) libpython2.7.so.1.0 => /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0 (0x00007fcefce5e000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fcefca6d000) /lib64/ld-linux-x86-64.so.2 (0x00007fcefd5e3000) libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fcefc850000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fcefc631000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fcefc42d000) libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x00007fcefc22a000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fcefbe8c000) --------8<--------8<--------8<--------8<--------8<-------- To rule out configuration migration problems we installed the configuration that runs with version 3.0.20, tested it with 3.0.20, removed version 3.0.20 and installed packages for 3.0.21 while preserving the configuration that is verified to run. The result is the same, the instantiation of the python module fails for 3.0.21 while it works with the same configuration for 3.0.20. As a workaround I was considering building rlm_python3, however, in the 3.0.21 it's not marked as stable in src/modules/stable and it doesn't build by default in the Debian/Ubuntu package build process without modifications. Would other FreeRADIUS admins recommend using rlm_python3? Please let me know if more debugging info is needed. I ran an "strace" but other than the above error message it doesn't seem to yield more usable information. Thanks for your help! Kind regards, Christian Strauf -- Dipl.-Math. Christian Strauf Head of Network Services Department Clausthal Univ. of Technology E-Mail: strauf(a)rz.tu-clausthal.de Rechenzentrum Web: www.rz.tu-clausthal.de Erzstraße 18 Tel.: +49-5323-72-2086 Fax: -992086 D-38678 Clausthal-Zellerfeld

3 8

Reject Users who are expired in DS 389( Based on LDAP V3)
by luckydog xf 17 Apr '20

17 Apr '20

Hi,list, Currently I'm using FreeIPA (Based on DS389 ) as backend and LDAP module to do AAA. Users's password in DS389 may be expired and the weird thing is that user can still login on NAS( VPN.etc). There only exists an attribute named 'krbPasswordExpiration' and its value is something like 20201022032134Z. So once user logins on, I will extract this value and compare with current date ( Guess this is a runtime variable, "%l ") to decide whether to continue or reject it immediately. I tried to set in the ../module-enabled/ldap ---- control:Password-With-Header += 'userPassword' control: += ' krbPasswordExpiration ' --- It always throws an exception. So how to resolve this? Thanks. Regards

3 8

need help for the errors in the log
by Rong Wang 16 Apr '20

16 Apr '20

Hello, I need some help. I am running Freeradius server version 3.0.15. Today I started to notice some errors in radius.log file. Here is one of them. "Thu Apr 16 11:46:32 2020 : Error: (1247) Ignoring duplicate packet from client cisco-3 port 1645 - ID: 103 due to unfinished request in component authorize module ldap" Could you please shed some light on this? Thanks, Rong Wang -- Rong Wang, CISSP Network Engineer Santa Clara University (408)551-7107

2 2

Unwanted Debug Output
by Doug Wussler 16 Apr '20

16 Apr '20

On Apr 15, 2020, at 3:25 PM, Doug Wussler <doug.wussler(a)fsu.edu> wrote: >> >> My debug output always includes Status-Server requests, even though I restrict the debug output by using a condition, e.g., radmin; debug condition 'User-Name =~ /^Bob/' >> or, raddebug -u Bob. >> >> Is this something I have misconfigured, or, is there a way to exclude it? The requests are made every minute and it's an annoyance to filter it out while working on a debug. > Which version of the server is this? > From what I can see, it should only do debugging when the debug condition matches. I'm not sure why it's also doing that for Status-Server. There's nothing in the code which specifically enables debugging doe Status-Server. > Alan DeKok. Yes, I should have included that info. We are using version 3.0.20 but this was also occurring on previous releases. (RHEL 7.8, fully patched). We are using the freeradius-snmp.pl script, which looks like it is the trigger for that debug output if it runs while debugging is occurring. Doug

1 0

Unwanted Debug Output
by Doug Wussler 15 Apr '20

15 Apr '20

My debug output always includes Status-Server requests, even though I restrict the debug output by using a condition, e.g., radmin; debug condition 'User-Name =~ /^Bob/' or, raddebug -u Bob. Is this something I have misconfigured, or, is there a way to exclude it? The requests are made every minute and it's an annoyance to filter it out while working on a debug. Doug Wussler Florida State University (50750) Wed Apr 15 15:18:10 2020: Debug: Received Status-Server Id 39 from x to y length 50 (50750) Wed Apr 15 15:18:10 2020: Debug: Message-Authenticator = 0x12e9ef829fe0bb34e0d19f9abb1e6fb0 (50750) Wed Apr 15 15:18:10 2020: Debug: FreeRADIUS-Statistics-Type = All (50750) Wed Apr 15 15:18:10 2020: Debug: # Executing group from file /usr/local/etc/raddb/sites-enabled/fsu-status (50750) Wed Apr 15 15:18:10 2020: Debug: Autz-Type Status-Server { (50750) Wed Apr 15 15:18:10 2020: Debug: [ok] = ok (50750) Wed Apr 15 15:18:10 2020: Debug: } # Autz-Type Status-Server = ok (50750) Wed Apr 15 15:18:10 2020: Debug: Sent Access-Accept Id 39 from y to x length 0 (50750) Wed Apr 15 15:18:10 2020: Debug: FreeRADIUS-Total-Access-Requests = 50733 (50750) Wed Apr 15 15:18:10 2020: Debug: FreeRADIUS-Total-Access-Accepts = 5237 (50750) Wed Apr 15 15:18:10 2020: Debug: FreeRADIUS-Total-Access-Rejects = 1778 (50750) Wed Apr 15 15:18:10 2020: Debug: FreeRADIUS-Total-Access-Challenges = 43278 (50750) Wed Apr 15 15:18:10 2020: Debug: FreeRADIUS-Total-Auth-Responses = 50293 (50750) Wed Apr 15 15:18:10 2020: Debug: FreeRADIUS-Total-Auth-Duplicate-Requests = 0 (50750) Wed Apr 15 15:18:10 2020: Debug: FreeRADIUS-Total-Auth-Malformed-Requests = 0 (50750) Wed Apr 15 15:18:10 2020: Debug: FreeRADIUS-Total-Auth-Invalid-Requests = 0 (50750) Wed Apr 15 15:18:10 2020: Debug: FreeRADIUS-Total-Auth-Dropped-Requests = 0 (50750) Wed Apr 15 15:18:10 2020: Debug: FreeRADIUS-Total-Auth-Unknown-Types = 0 (50750) Wed Apr 15 15:18:10 2020: Debug: FreeRADIUS-Total-Accounting-Requests = 18 (50750) Wed Apr 15 15:18:10 2020: Debug: FreeRADIUS-Total-Accounting-Responses = 18 (50750) Wed Apr 15 15:18:10 2020: Debug: FreeRADIUS-Total-Acct-Duplicate-Requests = 0 (50750) Wed Apr 15 15:18:10 2020: Debug: FreeRADIUS-Total-Acct-Malformed-Requests = 0 (50750) Wed Apr 15 15:18:10 2020: Debug: FreeRADIUS-Total-Acct-Invalid-Requests = 0 (50750) Wed Apr 15 15:18:10 2020: Debug: FreeRADIUS-Total-Acct-Dropped-Requests = 0 (50750) Wed Apr 15 15:18:10 2020: Debug: FreeRADIUS-Total-Acct-Unknown-Types = 0 (50750) Wed Apr 15 15:18:10 2020: Debug: FreeRADIUS-Total-Proxy-Access-Requests = 1115 (50750) Wed Apr 15 15:18:10 2020: Debug: FreeRADIUS-Total-Proxy-Access-Accepts = 48 (50750) Wed Apr 15 15:18:10 2020: Debug: FreeRADIUS-Total-Proxy-Access-Rejects = 0 (50750) Wed Apr 15 15:18:10 2020: Debug: FreeRADIUS-Total-Proxy-Access-Challenges = 1067 (50750) Wed Apr 15 15:18:10 2020: Debug: FreeRADIUS-Total-Proxy-Auth-Responses = 1115 (50750) Wed Apr 15 15:18:10 2020: Debug: FreeRADIUS-Total-Proxy-Auth-Duplicate-Requests = 0 (50750) Wed Apr 15 15:18:10 2020: Debug: FreeRADIUS-Total-Proxy-Auth-Malformed-Requests = 0 (50750) Wed Apr 15 15:18:10 2020: Debug: FreeRADIUS-Total-Proxy-Auth-Invalid-Requests = 0 (50750) Wed Apr 15 15:18:10 2020: Debug: FreeRADIUS-Total-Proxy-Auth-Dropped-Requests = 0 (50750) Wed Apr 15 15:18:10 2020: Debug: FreeRADIUS-Total-Proxy-Auth-Unknown-Types = 0 (50750) Wed Apr 15 15:18:10 2020: Debug: FreeRADIUS-Total-Proxy-Accounting-Requests = 0 (50750) Wed Apr 15 15:18:10 2020: Debug: FreeRADIUS-Total-Proxy-Accounting-Responses = 0 (50750) Wed Apr 15 15:18:10 2020: Debug: FreeRADIUS-Total-Proxy-Acct-Duplicate-Requests = 0 (50750) Wed Apr 15 15:18:10 2020: Debug: FreeRADIUS-Total-Proxy-Acct-Malformed-Requests = 0 (50750) Wed Apr 15 15:18:10 2020: Debug: FreeRADIUS-Total-Proxy-Acct-Invalid-Requests = 0 (50750) Wed Apr 15 15:18:10 2020: Debug: FreeRADIUS-Total-Proxy-Acct-Dropped-Requests = 0 (50750) Wed Apr 15 15:18:10 2020: Debug: FreeRADIUS-Total-Proxy-Acct-Unknown-Types = 0 (50750) Wed Apr 15 15:18:10 2020: Debug: FreeRADIUS-Stats-Start-Time = "Apr 15 2020 08:02:57 EDT" (50750) Wed Apr 15 15:18:10 2020: Debug: FreeRADIUS-Stats-HUP-Time = "Apr 15 2020 08:02:57 EDT" (50750) Wed Apr 15 15:18:10 2020: Debug: FreeRADIUS-Queue-Len-Internal = 0 (50750) Wed Apr 15 15:18:10 2020: Debug: FreeRADIUS-Queue-Len-Proxy = 0 (50750) Wed Apr 15 15:18:10 2020: Debug: FreeRADIUS-Queue-Len-Auth = 0 (50750) Wed Apr 15 15:18:10 2020: Debug: FreeRADIUS-Queue-Len-Acct = 0 (50750) Wed Apr 15 15:18:10 2020: Debug: FreeRADIUS-Queue-Len-Detail = 0 (50750) Wed Apr 15 15:18:10 2020: Debug: FreeRADIUS-Queue-PPS-In = 0 (50750) Wed Apr 15 15:18:10 2020: Debug: FreeRADIUS-Queue-PPS-Out = 0 (50750) Wed Apr 15 15:18:10 2020: Debug: Finished request (50750) Wed Apr 15 15:18:14 2020: Debug: Cleaning up request packet ID 39 with timestamp +26113

2 1