March 2014 - Freeradius-Users - lists.freeradius.org

radius server presenting itself as 127.0.0.1
by Morris, Andi 06 Mar '14

06 Mar '14

Hi all, I'm working on developing a high-availability setup PacketFence, which uses freeradius to authenticate users against our internal active directory server. I've just come to implement the production self-signed certificates as laid out in http://deployingradius.com/documents/configuration/ca_import.html and when I enable the "validate server certificate" box on my windows client I am asked to accept the certificate, which is expected as I haven't deployed the CA certificate yet, however I'm seeing "127.0.0.1" presented as the radius server name in the pop up box, rather than the actual hostname. I can't seem to find why this is happening, and I'd rather that have the server hostnames in the trusted radius server list than something generic like 127.0.0.1. Can anyone please point me in the right direction? Debug log attached. Cheers, Andi

4 8

pam module / freeradius permissions
by msheiny＠seas.upenn.edu 06 Mar '14

06 Mar '14

Hello, I'm running FreeRadius 2.2.0 and am looking for advice on resolving a permissions issue I am running into with a third-party pam module. As far as freeradius goes, I have it configured how I would like - radius authentication is being checked against PAM as I intended. The problem is that this pam module I am running currently requires root permissions but I would prefer to keep radiusd running as a restricted user. I've confirmed I can get around the issue by specifying radiusd to run as root but this is not desired. So my question - what would be the best way to run the freeradius pam sub-routine as root but keep the rest of the freeradius system runnning as my restricted user? I'm trying to avoid editing source code if I can help it. I realize this is not strictly related to freeradius but figured there may be a freeradius setting I'm not familiar here. Thanks in advance for any assistance. -- --Mike

5 5

FreeRADIUS 3.0: Segfault in rlm_detail
by Julius Plenz 06 Mar '14

06 Mar '14

Hi, I'm trying to upgrade my config to FreeRADIUS 3.0, but I get reproducable segfaults in the `rlm_detail' module. I send a simple packet (User-Name, User-Password) via `radclient', and the server immediately crashes: $ bin/radiusd -xx -f -l /dev/stderr -t ... (0) auth_log : expand: "/server/devel/server/log/client/%{Client-IP-Address}/auth-%Y%m%d" -> '/server/devel/server/log/client/XXX.XXX.XX.XX/auth-20140304' (0) auth_log : /server/devel/server/log/client/%{Client-IP-Address}/auth-%Y%m%d expands to /server/devel/server/log/client/XXX.XXX.XX.XX/auth-20140304 (0) auth_log : Acquired filelock, tried 1 time(s) (0) auth_log : expand: "%S" -> '2014-03-04 14:41:14' Bad talloc magic value - unknown value [Backtrace follows] The auth_log is defined in the detail module config: $ cat etc/mods-enabled/detail ... detail auth_log { filename = ${radacctdir}/%{Client-IP-Address}/auth-%Y%m%d permissions = 0600 dir_permissions = 0700 locking = yes header = "%S" log_packet_header = yes suppress { User-Password } } ... Interesting part of GDB backtrace: #0 0x00007ffff5d891b5 in *__GI_raise (sig=<value optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #1 0x00007ffff5d8bfc0 in *__GI_abort () at abort.c:92 #2 0x00007ffff71380bc in ?? () from /usr/lib/libtalloc.so.2 #3 0x00007ffff7138221 in talloc_get_name () from /usr/lib/libtalloc.so.2 #4 0x00007ffff713b56b in _talloc_get_type_abort () from /usr/lib/libtalloc.so.2 #5 0x00007ffff79913b8 in vp_prints (out=0x7fffffffa751 "", outlen=1023, vp=0x7fffffffac20) at src/lib/print.c:868 #6 0x00007ffff799154a in vp_print (fp=0xd31870, vp=0x7fffffffac20) at src/lib/print.c:908 #7 0x00007ffff3523e7e in detail_write (out=0xd31870, inst=0xd16a50, request=0xd31060, packet=0xd30ee0, compat=false) at src/modules/rlm_detail/rlm_detail.c:249 #8 0x00007ffff35248c3 in detail_do (instance=0xd16a50, request=0xd31060, packet=0xd30ee0, compat=false) at src/modules/rlm_detail/rlm_detail.c:484 #9 0x00007ffff3524a5a in mod_authorize (instance=0xd16a50, request=0xd31060) at src/modules/rlm_detail/rlm_detail.c:533 #10 0x0000000000423915 in call_modsingle (component=RLM_COMPONENT_AUTZ, sp=0xd18bb0, request=0xd31060) at src/main/modcall.c:311 ... The file /server/devel/server/log/client/XXX.XXX.XX.XX/auth-20140304 is actually being created, but contains only this: 2014-03-04 14:41:14 Packet-Type = Access-Request So presumably FreeRADIUS crashes while trying to print out the Packet-Src-IP-Address...? Thanks in advance, Julius P.S.: I'm using the v3.0.x branch from a few days ago, namely 80eee20b9. Compiling against the tip of v3.0.x, eb3bfda, is not possible any more: $ make CC src/lib/cbuff.c In file included from <command-line>:0: /server/devel/src/freeradius/src/freeradius-devel/build.h:84:6: error: #error Failed determining endianness of system make: *** [build/objs/src/lib/cbuff.lo] Error 1

3 17

Anyone using Debian?
by Alan DeKok 06 Mar '14

06 Mar '14

FreeRADIUS has been removed from Debian "testing", for reasons that aren't clear. http://packages.qa.debian.org/f/freeradius.html Anyone willing to help? Alan DeKok.

4 4

User and group attributes
by Lorenzo Milesi 06 Mar '14

06 Mar '14

Hi. I know it's a stupid question but so far I couldn't manage to dig it out. I'm using FR2 with MySQL backend. All my users belong to one or more group. I usually set the Idle-Timeout attribute using the radgroupreply table, and it works great. For a minority of users I'd like to override this attribute to a different value, but I cannot have FR reply as I wish. Current situation: Radcheck: USERA MD5-Password := somemd5hash Radusergroup: USERA c_gvt 30 Radgroupreply c_gvt Idle-Timeout := 3800 This works fine and replies 3800. If I add USERA Idle-Timeout := 100 to radreply it will still reply 3800. Then I checked manpage of USERS [1] so I changed: Radreply: USERA Idle-Timeout := 100 Radgroupreply c_gvt Idle-Timeout = 3800 but the reply is always the same. What am I missing? thanks [1] http://freeradius.org/radiusd/man/users.html -- Lorenzo Milesi - lorenzo.milesi(a)yetopen.it YetOpen S.r.l. - http://www.yetopen.it/

3 5

dailycounter isnt started
by Sanity Computers 06 Mar '14

06 Mar '14

Hi All, I've tried the default FR2.x dailycounter code and loads of other examples yet. It seems the max-daily-session time is been ignored and debug shows no sign of the dailycounter. If I log out and log back in the counter does work and sends the timeout response, I can see the dailycounter lines in debug. So dailycounter works when there is at least 1 session which suggests most of the setup is correct. I suspected the dailycounter query is wrong but the query isn't even started. except on a second session. Can anyone see why it would not work on the very first login? Regards Jim

2 1

About proxy mode, when all home servers are dead
by regulus regulus 06 Mar '14

06 Mar '14

Dear All, I have a FreeRADIUS 2.2.3 run in proxy mode to 2 home RADIUS servers in failover mode. The problem I face now is that when both home RADIUS servers are dead, FreeRADIUS will send a reject to NAS >>ERROR: Failed to find live home server for realm net-yan.com>>There was no response configured: rejecting request 2 When NAS receive a reject, it won't failover to another redundant RADIUS. Is there a way to configure FreeRADIUS such that it will not send another response back to NAS when all home RADIUS are dead?I have been studying the "do_not_respond" policy, but not sure how to use it in this case.. NAS --> primary: my FreeRADIUS --> Home RADIUS --> secondary: another RADIUS --> Home RADIUS Thanks a lot! Regards,Leo

2 3

radtest works, connection via wlan fails
by Thorsten Bresges (web) 06 Mar '14

06 Mar '14

Hello, I am new to freeradius. I try to set up freeradius for an high school. I am using FreeRADIUS Version 2.1.12 for host x86_64-pc-linux-gnu on an debian system. Freeradius is working with the users file and clear text password. Now I would like to put the users in a myslq database. I insert two test accounts: One with an cleartext password and one with an MD5 password (test account "ilka"). I did the "guide/SQL HOWTO" - except I just entered the neccesary entries for "fredf" in the howto. When I try "radtest" everything works fine: The account in the users file and the twe accounts in mysql are accepted. Afterwards I tried to connect from my Mac over WLAN and an accesspoint to the freeradius server. It worked fine with the account in the users file. But when I tried it with the accounts that are stored in the mysql database: Neither the cleartext password nor the md5 password account works - even though this accounts worked with radtest. What do I wrong? Do I have the wrong idea? Here is a part of the freeradius debug log. First you see my test account is working with radtest. The second try it is not working via wlan and the access point. Thank you for your help. Thorsten --- SCHNIPP --- Ready to process requests. rad_recv: Access-Request packet from host 127.0.0.1 port 51600, id=236, length=74 User-Name = "ilka" User-Password = "1234" NAS-IP-Address = 127.0.1.1 NAS-Port = 1812 Message-Authenticator = 0xa68a5393568d346369bcef886a06435c # Executing section authorize from file /etc/freeradius/sites-enabled/default +- entering group authorize {...} ++[preprocess] returns ok [auth_log] expand: /var/log/freeradius/radacct/%{Client-IP-Address}/auth-detail-%Y%m%d -> /var/log/freeradius/radacct/127.0.0.1/auth-detail-20140301 [auth_log] /var/log/freeradius/radacct/%{Client-IP-Address}/auth-detail-%Y%m%d expands to /var/log/freeradius/radacct/127.0.0.1/auth-detail-20140301 [auth_log] expand: %t -> Sat Mar 1 14:59:11 2014 ++[auth_log] returns ok ++[chap] returns noop ++[mschap] returns noop ++[digest] returns noop [suffix] No '@' in User-Name = "ilka", looking up realm NULL [suffix] No such realm "NULL" ++[suffix] returns noop [eap] No EAP-Message, not doing EAP ++[eap] returns noop [sql] expand: %{User-Name} -> ilka [sql] sql_set_user escaped user --> 'ilka' rlm_sql (sql): Reserving sql socket id: 2 [sql] expand: SELECT id, username, attribute, value, op FROM radcheck WHERE username = '%{SQL-User-Name}' ORDER BY id -> SELECT id, username, attribute, value, op FROM radcheck WHERE username = 'ilka' ORDER BY id [sql] User found in radcheck table [sql] expand: SELECT id, username, attribute, value, op FROM radreply WHERE username = '%{SQL-User-Name}' ORDER BY id -> SELECT id, username, attribute, value, op FROM radreply WHERE username = 'ilka' ORDER BY id [sql] expand: SELECT groupname FROM radusergroup WHERE username = '%{SQL-User-Name}' ORDER BY priority -> SELECT groupname FROM radusergroup WHERE username = 'ilka' ORDER BY priority rlm_sql (sql): Released sql socket id: 2 ++[sql] returns ok ++[expiration] returns noop ++[logintime] returns noop [pap] Normalizing MD5-Password from hex encoding ++[pap] returns updated Found Auth-Type = PAP # Executing group from file /etc/freeradius/sites-enabled/default +- entering group PAP {...} [pap] login attempt with password "1234" [pap] Using MD5 encryption. [pap] User authenticated successfully ++[pap] returns ok # Executing section post-auth from file /etc/freeradius/sites-enabled/default +- entering group post-auth {...} ++[exec] returns noop Sending Access-Accept of id 236 to 127.0.0.1 port 51600 Finished request 2. Going to the next request Waking up in 4.9 seconds. Cleaning up request 2 ID 236 with timestamp +83 Ready to process requests. rad_recv: Access-Request packet from host 192.168.178.245 port 3072, id=0, length=121 User-Name = "ilka" NAS-IP-Address = 192.168.178.245 Called-Station-Id = "00259cade830" Calling-Station-Id = "109adda5aa6c" NAS-Identifier = "00259cade830" NAS-Port = 35 Framed-MTU = 1400 NAS-Port-Type = Wireless-802.11 EAP-Message = 0x0200000901696c6b61 Message-Authenticator = 0xd4c70ee0de14396c7387dd2ec67a2145 # Executing section authorize from file /etc/freeradius/sites-enabled/default +- entering group authorize {...} ++[preprocess] returns ok [auth_log] expand: /var/log/freeradius/radacct/%{Client-IP-Address}/auth-detail-%Y%m%d -> /var/log/freeradius/radacct/192.168.178.245/auth-detail-20140301 [auth_log] /var/log/freeradius/radacct/%{Client-IP-Address}/auth-detail-%Y%m%d expands to /var/log/freeradius/radacct/192.168.178.245/auth-detail-20140301 [auth_log] expand: %t -> Sat Mar 1 14:59:50 2014 ++[auth_log] returns ok ++[chap] returns noop ++[mschap] returns noop ++[digest] returns noop [suffix] No '@' in User-Name = "ilka", looking up realm NULL [suffix] No such realm "NULL" ++[suffix] returns noop [eap] EAP packet type response id 0 length 9 [eap] No EAP Start, assuming it's an on-going EAP conversation ++[eap] returns updated [sql] expand: %{User-Name} -> ilka [sql] sql_set_user escaped user --> 'ilka' rlm_sql (sql): Reserving sql socket id: 1 [sql] expand: SELECT id, username, attribute, value, op FROM radcheck WHERE username = '%{SQL-User-Name}' ORDER BY id -> SELECT id, username, attribute, value, op FROM radcheck WHERE username = 'ilka' ORDER BY id [sql] User found in radcheck table [sql] expand: SELECT id, username, attribute, value, op FROM radreply WHERE username = '%{SQL-User-Name}' ORDER BY id -> SELECT id, username, attribute, value, op FROM radreply WHERE username = 'ilka' ORDER BY id [sql] expand: SELECT groupname FROM radusergroup WHERE username = '%{SQL-User-Name}' ORDER BY priority -> SELECT groupname FROM radusergroup WHERE username = 'ilka' ORDER BY priority rlm_sql (sql): Released sql socket id: 1 ++[sql] returns ok ++[expiration] returns noop ++[logintime] returns noop [pap] Normalizing MD5-Password from hex encoding [pap] WARNING: Auth-Type already set. Not setting to PAP ++[pap] returns noop Found Auth-Type = EAP # Executing group from file /etc/freeradius/sites-enabled/default +- entering group authenticate {...} [eap] EAP Identity [eap] processing type tls [tls] Initiate [tls] Start returned 1 ++[eap] returns handled Sending Access-Challenge of id 0 to 192.168.178.245 port 3072 EAP-Message = 0x010100061520 Message-Authenticator = 0x00000000000000000000000000000000 State = 0x187e94c4187f81dcecdcfc091efa734e Finished request 3. Going to the next request Waking up in 4.9 seconds. rad_recv: Access-Request packet from host 192.168.178.245 port 3072, id=0, length=282 Cleaning up request 3 ID 0 with timestamp +122 User-Name = "ilka" NAS-IP-Address = 192.168.178.245 Called-Station-Id = "00259cade830" Calling-Station-Id = "109adda5aa6c" NAS-Identifier = "00259cade830" NAS-Port = 35 Framed-MTU = 1400 State = 0x187e94c4187f81dcecdcfc091efa734e NAS-Port-Type = Wireless-802.11 EAP-Message = 0x0201009815800000008e16030100890100008503015311e7d1dc8554b6d8115e4697cd1603911bf370128267e25a1674210431126000004a00ffc024c023c00ac009c007c008c028c027c014c013c011c012c026c025c02ac029c005c004c002c003c00fc00ec00cc00d003d003c002f000500040035000a0067006b00330039001601000012000a00080006001700180019000b00020100 Message-Authenticator = 0xd907ee8f95454e3d9fc6676763f874e4 # Executing section authorize from file /etc/freeradius/sites-enabled/default +- entering group authorize {...} ++[preprocess] returns ok [auth_log] expand: /var/log/freeradius/radacct/%{Client-IP-Address}/auth-detail-%Y%m%d -> /var/log/freeradius/radacct/192.168.178.245/auth-detail-20140301 [auth_log] /var/log/freeradius/radacct/%{Client-IP-Address}/auth-detail-%Y%m%d expands to /var/log/freeradius/radacct/192.168.178.245/auth-detail-20140301 [auth_log] expand: %t -> Sat Mar 1 14:59:50 2014 ++[auth_log] returns ok ++[chap] returns noop ++[mschap] returns noop ++[digest] returns noop [suffix] No '@' in User-Name = "ilka", looking up realm NULL [suffix] No such realm "NULL" ++[suffix] returns noop [eap] EAP packet type response id 1 length 152 [eap] Continuing tunnel setup. ++[eap] returns ok Found Auth-Type = EAP # Executing group from file /etc/freeradius/sites-enabled/default +- entering group authenticate {...} [eap] Request found, released from the list [eap] EAP/ttls [eap] processing type ttls [ttls] Authenticate [ttls] processing EAP-TLS TLS Length 142 [ttls] Length Included [ttls] eaptls_verify returned 11 [ttls] (other): before/accept initialization [ttls] TLS_accept: before/accept initialization [ttls] <<< TLS 1.0 Handshake [length 0089], ClientHello [ttls] TLS_accept: SSLv3 read client hello A [ttls] >>> TLS 1.0 Handshake [length 0039], ServerHello [ttls] TLS_accept: SSLv3 write server hello A [ttls] >>> TLS 1.0 Handshake [length 02e6], Certificate [ttls] TLS_accept: SSLv3 write certificate A [ttls] >>> TLS 1.0 Handshake [length 014b], ServerKeyExchange [ttls] TLS_accept: SSLv3 write key exchange A [ttls] >>> TLS 1.0 Handshake [length 0004], ServerHelloDone [ttls] TLS_accept: SSLv3 write server done A [ttls] TLS_accept: SSLv3 flush data [ttls] TLS_accept: Need to read more data: SSLv3 read client certificate A In SSL Handshake Phase In SSL Accept mode [ttls] eaptls_process returned 13 ++[eap] returns handled Sending Access-Challenge of id 0 to 192.168.178.245 port 3072 EAP-Message = 0x0102040015c00000048216030100390200003503015311e7d6bbba48cb775cb6265846550e61e890d08af06b0e3ed88165d96aec4a00c01400000dff01000100000b00040300010216030102e60b0002e20002df0002dc308202d8308201c0a003020102020900a7531dab918be73c300d06092a864886f70d010105050030243122302006035504031319776c616e636f6e74726f6c6c65722e67796d6f64656e2e6465301e170d3134303232323037333532305a170d3234303232303037333532305a30243122302006035504031319776c616e636f6e74726f6c6c65722e67796d6f64656e2e646530820122300d06092a864886f70d0101010500 EAP-Message = 0x0382010f003082010a0282010100cafae8f86e62cc377e19b89215293656ebb020e26592c2b6ee596bb9fa7f62067416a0f9ea7410cbeb8f6f13f5925c5c866dcc96a73deebcef47e14e28a2f3b5fb7f47b2fca298ebc26eb538d4363cd957cbdfcb6b76b527c3b06a53311f9170c028ec756f12540cef3ab0ed2dc34b5ad00fc74af18cbd0c955a7d329f3885e96be31980ff4eb15e2ac9284378138572136c64b4776ae9fc58e55d03305b06b382a3269e08612ea2e769c9ae477b4af3fb386272c0771cdd1adef260888056680731440f14f59e4b605e6052438362b1e5c3b5b9bb240426c268269fcdd4513b0ac36739e1430963ce7abc903c1ca1 EAP-Message = 0xa2808e5a412f7834ddc52ba2799cb618890203010001a30d300b30090603551d1304023000300d06092a864886f70d0101050500038201010052c575ba4a457b31556a3d3f21a567342a14ed91ab3ac489b13fdd481801823ec8903f599caa374b30e4a3e03fbc058e032aca619e77549dcee19a25eaa51e32cdb1c2ee7ebeb73577e4c1c05c88db81fc211f039b66fc055382ee34b9230549b3b42393f4cb2ee92f67f622cad7e3d1842ac2e5bca9117ee33963934d23fab4864bec38dd4de3792a82d3815e3459dbb01f5b1eb18fb408a6203e4be9303413c086f0ba387cfbe227989154000597c3a41955e6a2f9d62e4138c5bb7ba99ab3cadaa580 EAP-Message = 0x42323a8ca2e72b443c44c6b2c24d3a9f9b04c59698f36bbc0210b03b9313429ded6bbf239b6420b2ba607580d46b636eb24bce3e7ae0196e367d96e7160301014b0c0001470300174104dd9cfc7c693b2973e8bf4e46b3897033c0118e407c81c43a17f1ebdd4426d85a4184e6203f16fd86674810628fa5c118f9d13c0099b756684a8ff4f353a9cfc00100149df419c5b258e5c7eeaf3243c68dd89b0f5240de0427797ec6c85be39e7efe9aa4f462b44507ec1769bcf3f4847ebe445c0c724cc0a1c6bf6a70dac95533b20e0fd8bba1c9f911a9a1b77e072be725c8d4048dc794b5f3d5247f957ad7c4ebda0bfd29ff2b52e2955dbfacc13c69ef5f EAP-Message = 0x7d16449ec95a34c0d5e1b3d5 Message-Authenticator = 0x00000000000000000000000000000000 State = 0x187e94c4197c81dcecdcfc091efa734e Finished request 4. Going to the next request Waking up in 4.9 seconds. rad_recv: Access-Request packet from host 192.168.178.245 port 3072, id=0, length=136 Cleaning up request 4 ID 0 with timestamp +122 User-Name = "ilka" NAS-IP-Address = 192.168.178.245 Called-Station-Id = "00259cade830" Calling-Station-Id = "109adda5aa6c" NAS-Identifier = "00259cade830" NAS-Port = 35 Framed-MTU = 1400 State = 0x187e94c4197c81dcecdcfc091efa734e NAS-Port-Type = Wireless-802.11 EAP-Message = 0x020200061500 Message-Authenticator = 0x9ec402e1c00eab45c115006ac68cdfcf # Executing section authorize from file /etc/freeradius/sites-enabled/default +- entering group authorize {...} ++[preprocess] returns ok [auth_log] expand: /var/log/freeradius/radacct/%{Client-IP-Address}/auth-detail-%Y%m%d -> /var/log/freeradius/radacct/192.168.178.245/auth-detail-20140301 [auth_log] /var/log/freeradius/radacct/%{Client-IP-Address}/auth-detail-%Y%m%d expands to /var/log/freeradius/radacct/192.168.178.245/auth-detail-20140301 [auth_log] expand: %t -> Sat Mar 1 14:59:50 2014 ++[auth_log] returns ok ++[chap] returns noop ++[mschap] returns noop ++[digest] returns noop [suffix] No '@' in User-Name = "ilka", looking up realm NULL [suffix] No such realm "NULL" ++[suffix] returns noop [eap] EAP packet type response id 2 length 6 [eap] Continuing tunnel setup. ++[eap] returns ok Found Auth-Type = EAP # Executing group from file /etc/freeradius/sites-enabled/default +- entering group authenticate {...} [eap] Request found, released from the list [eap] EAP/ttls [eap] processing type ttls [ttls] Authenticate [ttls] processing EAP-TLS [ttls] Received TLS ACK [ttls] ACK handshake fragment handler [ttls] eaptls_verify returned 1 [ttls] eaptls_process returned 13 ++[eap] returns handled Sending Access-Challenge of id 0 to 192.168.178.245 port 3072 EAP-Message = 0x010300961580000004823aed29190c7500f30a8f6a790077ef4c34e44c6c245d91f78ff6bc61e52ae6892da296ce203846de62f3169209b21d494220ad013391859c59f4d91c8f0ede4fbd721be3f204db34341bdc0c053187170720660396d81f218e0b07803bdd207b888817303c298db0d39aec20b34e4d5bfc34f099ef6662ba0ab574941218a8d794161016030100040e000000 Message-Authenticator = 0x00000000000000000000000000000000 State = 0x187e94c41a7d81dcecdcfc091efa734e Finished request 5. Going to the next request Waking up in 4.9 seconds. rad_recv: Access-Request packet from host 192.168.178.245 port 3072, id=0, length=274 Cleaning up request 5 ID 0 with timestamp +122 User-Name = "ilka" NAS-IP-Address = 192.168.178.245 Called-Station-Id = "00259cade830" Calling-Station-Id = "109adda5aa6c" NAS-Identifier = "00259cade830" NAS-Port = 35 Framed-MTU = 1400 State = 0x187e94c41a7d81dcecdcfc091efa734e NAS-Port-Type = Wireless-802.11 EAP-Message = 0x02030090158000000086160301004610000042410461df8191b4e0ecbe550b73749c112174eec6dde5f5d612d6f09d1a673550656addd650cab4a509c918573ad466098eca4d5613ad60376a289e189248d24f0d6214030100010116030100307dbcb0b88561c84b293091d1839201bb38392127768f3a4b6d19a27fe1960045a4d04511c29d12ed3db70f9bc77d388c Message-Authenticator = 0x0672b82c9679eecab518628870e5a173 # Executing section authorize from file /etc/freeradius/sites-enabled/default +- entering group authorize {...} ++[preprocess] returns ok [auth_log] expand: /var/log/freeradius/radacct/%{Client-IP-Address}/auth-detail-%Y%m%d -> /var/log/freeradius/radacct/192.168.178.245/auth-detail-20140301 [auth_log] /var/log/freeradius/radacct/%{Client-IP-Address}/auth-detail-%Y%m%d expands to /var/log/freeradius/radacct/192.168.178.245/auth-detail-20140301 [auth_log] expand: %t -> Sat Mar 1 14:59:50 2014 ++[auth_log] returns ok ++[chap] returns noop ++[mschap] returns noop ++[digest] returns noop [suffix] No '@' in User-Name = "ilka", looking up realm NULL [suffix] No such realm "NULL" ++[suffix] returns noop [eap] EAP packet type response id 3 length 144 [eap] Continuing tunnel setup. ++[eap] returns ok Found Auth-Type = EAP # Executing group from file /etc/freeradius/sites-enabled/default +- entering group authenticate {...} [eap] Request found, released from the list [eap] EAP/ttls [eap] processing type ttls [ttls] Authenticate [ttls] processing EAP-TLS TLS Length 134 [ttls] Length Included [ttls] eaptls_verify returned 11 [ttls] <<< TLS 1.0 Handshake [length 0046], ClientKeyExchange [ttls] TLS_accept: SSLv3 read client key exchange A [ttls] <<< TLS 1.0 ChangeCipherSpec [length 0001] [ttls] <<< TLS 1.0 Handshake [length 0010], Finished [ttls] TLS_accept: SSLv3 read finished A [ttls] >>> TLS 1.0 ChangeCipherSpec [length 0001] [ttls] TLS_accept: SSLv3 write change cipher spec A [ttls] >>> TLS 1.0 Handshake [length 0010], Finished [ttls] TLS_accept: SSLv3 write finished A [ttls] TLS_accept: SSLv3 flush data [ttls] (other): SSL negotiation finished successfully SSL Connection Established [ttls] eaptls_process returned 13 ++[eap] returns handled Sending Access-Challenge of id 0 to 192.168.178.245 port 3072 EAP-Message = 0x0104004515800000003b1403010001011603010030910122ab1ddc0682e1fec8b6d60b215b6cfc74841376ce587d315c5d07458c8ef4f6405e73173084fc8261031bd86762 Message-Authenticator = 0x00000000000000000000000000000000 State = 0x187e94c41b7a81dcecdcfc091efa734e Finished request 6. Going to the next request Waking up in 4.9 seconds. rad_recv: Access-Request packet from host 192.168.178.245 port 3072, id=0, length=273 Cleaning up request 6 ID 0 with timestamp +122 User-Name = "ilka" NAS-IP-Address = 192.168.178.245 Called-Station-Id = "00259cade830" Calling-Station-Id = "109adda5aa6c" NAS-Identifier = "00259cade830" NAS-Port = 35 Framed-MTU = 1400 State = 0x187e94c41b7a81dcecdcfc091efa734e NAS-Port-Type = Wireless-802.11 EAP-Message = 0x0204008f15800000008517030100801c2b567e75b0dbfee155df74f8ba26ffc37432e78bbc38a99d2e29c58bd8531066cd4ec962a89fd76d2c7396f9782852aca6773ff20797845e08b2098b2c1197a39a1f20b718fcdbb4b6cba945810fc5751029112d17274251546f11410a0d8fded636f7c0b4c3a30044d992bb9891504ace80709104dfb1906028c0ca2ebf49 Message-Authenticator = 0xba7fbca76f78aa3404ad55cedae488e1 # Executing section authorize from file /etc/freeradius/sites-enabled/default +- entering group authorize {...} ++[preprocess] returns ok [auth_log] expand: /var/log/freeradius/radacct/%{Client-IP-Address}/auth-detail-%Y%m%d -> /var/log/freeradius/radacct/192.168.178.245/auth-detail-20140301 [auth_log] /var/log/freeradius/radacct/%{Client-IP-Address}/auth-detail-%Y%m%d expands to /var/log/freeradius/radacct/192.168.178.245/auth-detail-20140301 [auth_log] expand: %t -> Sat Mar 1 14:59:50 2014 ++[auth_log] returns ok ++[chap] returns noop ++[mschap] returns noop ++[digest] returns noop [suffix] No '@' in User-Name = "ilka", looking up realm NULL [suffix] No such realm "NULL" ++[suffix] returns noop [eap] EAP packet type response id 4 length 143 [eap] Continuing tunnel setup. ++[eap] returns ok Found Auth-Type = EAP # Executing group from file /etc/freeradius/sites-enabled/default +- entering group authenticate {...} [eap] Request found, released from the list [eap] EAP/ttls [eap] processing type ttls [ttls] Authenticate [ttls] processing EAP-TLS TLS Length 133 [ttls] Length Included [ttls] eaptls_verify returned 11 [ttls] eaptls_process returned 7 [ttls] Session established. Proceeding to decode tunneled attributes. [ttls] Got tunneled request User-Name = "ilka" MS-CHAP-Challenge = 0x92199b7bc988486a09233718da7e7ae8 MS-CHAP2-Response = 0x0c0036e851fc33bb681f9c2d67d1cf57fd3600000000000000002585c00a1ad283dc4e7d5cc8596d0531acbe42da3c8659f0 FreeRADIUS-Proxied-To = 127.0.0.1 [ttls] Sending tunneled request User-Name = "ilka" MS-CHAP-Challenge = 0x92199b7bc988486a09233718da7e7ae8 MS-CHAP2-Response = 0x0c0036e851fc33bb681f9c2d67d1cf57fd3600000000000000002585c00a1ad283dc4e7d5cc8596d0531acbe42da3c8659f0 FreeRADIUS-Proxied-To = 127.0.0.1 server inner-tunnel { # Executing section authorize from file /etc/freeradius/sites-enabled/inner-tunnel +- entering group authorize {...} ++[chap] returns noop [mschap] Found MS-CHAP attributes. Setting 'Auth-Type = mschap' ++[mschap] returns ok [suffix] No '@' in User-Name = "ilka", looking up realm NULL [suffix] No such realm "NULL" ++[suffix] returns noop ++[control] returns noop [eap] No EAP-Message, not doing EAP ++[eap] returns noop ++[files] returns noop ++[expiration] returns noop ++[logintime] returns noop ++[pap] returns noop Found Auth-Type = MSCHAP # Executing group from file /etc/freeradius/sites-enabled/inner-tunnel +- entering group MS-CHAP {...} [mschap] No Cleartext-Password configured. Cannot create LM-Password. [mschap] No Cleartext-Password configured. Cannot create NT-Password. [mschap] Creating challenge hash with username: ilka [mschap] Told to do MS-CHAPv2 for ilka with NT-Password [mschap] FAILED: No NT/LM-Password. Cannot perform authentication. [mschap] FAILED: MS-CHAP2-Response is incorrect ++[mschap] returns reject Failed to authenticate the user. } # server inner-tunnel [ttls] Got tunneled reply code 3 MS-CHAP-Error = "\014E=691 R=1" [ttls] Got tunneled Access-Reject [eap] Handler failed in EAP/ttls [eap] Failed in EAP select ++[eap] returns invalid Failed to authenticate the user. Using Post-Auth-Type Reject # Executing group from file /etc/freeradius/sites-enabled/default +- entering group REJECT {...} [attr_filter.access_reject] expand: %{User-Name} -> ilka attr_filter: Matched entry DEFAULT at line 11 ++[attr_filter.access_reject] returns updated Delaying reject of request 7 for 1 seconds Going to the next request Waking up in 0.9 seconds. Sending delayed reject for request 7 Sending Access-Reject of id 0 to 192.168.178.245 port 3072 EAP-Message = 0x04040004 Message-Authenticator = 0x00000000000000000000000000000000 Waking up in 4.9 seconds. Cleaning up request 7 ID 0 with timestamp +122 Ready to process requests.

2 2

2. Anyone using Debian? (Alan DeKok)
by Rui Ribeiro 05 Mar '14

05 Mar '14

On 5 March 2014 15:57, <freeradius-users-request(a)lists.freeradius.org>wrote: > > ------------------------------ > > Message: 2 > Date: Wed, 05 Mar 2014 15:43:54 +0000 > From: Alan DeKok <aland(a)deployingradius.com> > To: FreeRadius users mailing list > <freeradius-users(a)lists.freeradius.org> > Subject: Anyone using Debian? > Message-ID: <5317463A.8060306(a)deployingradius.com> > Content-Type: text/plain; charset=ISO-8859-1 > > FreeRADIUS has been removed from Debian "testing", for reasons that > aren't clear. > > http://packages.qa.debian.org/f/freeradius.html > > Anyone willing to help? > > Alan DeKok. > > > Hi Alan, I have been using FreeRadius in Debian for quite sometime. Been using v2 and thinking of starting testing v3. If I can help, I am available. Regards

1 0

Behavior of FreeRADIUS auth when SQL backend becomes inaccessible
by Patrick Wagner 05 Mar '14

05 Mar '14

Hello, we've got a problem with FreeRADIUS / rlm_sql behavior that prevents us from enjoying a fully redundant RADIUS service, consisting of 3 FreeRADIUS servers, probably because of compounded mistakes / misunderstandings in our configuration that I've attached at the bottom of this post. Setup: - each of the 3 servers consists of a FR instance and a MySQL instance that contains all auth data and the radacct table to store acct data - each FR instance connects to its local SQL instance only, there's no redundant or load-balance setup required - going that route and have FR try to connect to the SQL instance on one of the other nodes in case of errors with the local one would also solve our problem, but we deem it unnecessary if FR was able to handle a failed SQL connection "properly" - the SQL nodes are configured as Galera multi-master cluster, so any node is operating on the same set of data -> this means every node should work perfectly fine on its own, which is why we don't think we need to implement the redundancy options that FR offers. If SQL is unavailable before we start FR, FR refuses to start and exits immediately after it finds out it cannot connect to the local SQL instance, with "Instantiation failed for module sql_localhost". This behavior is perfectly fine because it means that any NAS client sending requests to that particular FR node will find that the node does not respond, and the client will retry the request with the other RADIUS servers it knows of and hopefully, at least one of them will answer. However, if we start FR while and subsequently shut down the SQL instance, rlm_sql returns a fail, "SQL query error; rejecting user", and FR subsequently sends a REJECT response to any NAS request it receives, which is not at all the behavior we'd like to see as it means that any NAS querying this particular FR node will deny all requests instead of retrying the request with another node. I've seen a post on this list by Alan DeKok suggesting that "fail = ok" (or = invalid or whatever we should use in this case) is proper unlang or at least was proper syntax back in 2007, but with FR 2.1 (the respective version packaged with Ubuntu 10.04 LTS and CentOS 6.5) I was unable to start FR with such a statement added in either the "authorize" or "post-auth" section, declaring "Unknown action 'invalid'" when parsing the config. Respective thread which I hoped would give me some pointers: http://lists.freeradius.org/pipermail/freeradius-users/2007-December/024055. html Reply by Alan DeKok which I went on to try, unsuccessfully, with the error message quoted above: http://lists.freeradius.org/pipermail/freeradius-users/2007-December/024059. html Actually, FR's current behavior is a bit more irritating to us because we need to use a custom huntgroup SQL query that we placed in an "update request" section right before we (try to) query SQL for auth in the "authorize" section, but instead of two times "fail" we get two different error codes from the two statements when SQL is unavailable: - "++ [request] returns notfound" and later - " ++[sql_localhost] returns fail" Do we need to suppress / rewrite both of them? Suppressing the first one is impossible, I think, because in "update request" apparently FR doesn't differentiate between a query that was executed returned but returned an empty result, and a failed query (because SQL was unavailable). The invocation of sql_localhost, right below, does differentiate, as it returns fail instead of notfound. What is the proper way to allow the NAS clients to fail over to another FR node altogether instead of getting misleading and in most cases outright wrong information ("Invalid user" is what FR tells the NAS) from FR? Can we make FR just not reply to the request at all in these cases, or send a request that signals to the NAS that it should try the FR node next door instead because this FR node is unable to make any definitive statement? And finally, we're forwarding exactly one particular realm to another RADIUS server outside of our administrative control, and while any information FR needs to be able identify these requests as "to-be-proxied" is configured in plaintext files and thus should continue to work if SQL fails, requests for this realm also fail as soon as we shut down SQL, because the explicit REJECT from SQL makes FR not even proxy the request to the home server before telling the NAS that the Login request should be denied. Why does FR try to run the query against SQL (i.e. its own authorize section) at all if it knows from config that it should simply forward the request (unmodified even, we don't use pre-proxy or post-proxy at all) and wait for the reply of the home server for this particular realm? The last issue doesn't occur if we put a redundant {sql_localhost; handled} block instead of the single "sql_localhost" statement in the auth section, but I don't know WHY it works (it probably causes side effects we don't want), or rather, I figured that somehow the reseller request always gets checked against the local SQL database first (which it shouldn't or at least doesn't need to waste any CPU cycles on as it will never find anything in there about the reseller's customers), no matter whether the SQL connections works or doesn't work, but somehow a "notfound" from SQL leads FR to finally proxy the request to the reseller RADIUS server and get a proper answer, while a "fail" from SQL somehow skips the proxying step and outright denies the request. Obviously we don't want the proxy requests to ever get checked locally - this would solve this issue completely. I've attached the configuration we use currently below - if you need radius -X output for a particular scenario, let me know. - Patrick Wagner __________________________ Configuration of the only sites-enabled/ site document: authorize { update request { Huntgroup-Name := "%{sql_localhost:select groupname from radhuntgroup where nasipaddress=\"%{NAS-IP-Address}\"}" } preprocess chap mschap realmraute # realms are differentiated by #suffix eap { ok = return } sql_localhost # the following allows reseller requests to get proxied to the correct home server, but with unknown side effects # redundant { # sql_localhost # handled # } expiration logintime pap } authenticate { Auth-Type PAP { pap } Auth-Type CHAP { chap } Auth-Type MS-CHAP { mschap } unix eap } preacct { preprocess acct_unique realmraute } accounting { detail { fail = 1 } unix radutmp sql_localhost attr_filter.accounting_response } session { sql_localhost } post-auth { exec Post-Auth-Type REJECT { attr_filter.access_reject } } pre-proxy { } post-proxy { } ______________________ Configuration of radiusd.conf: prefix = /usr exec_prefix = /usr sysconfdir = /etc localstatedir = /var sbindir = ${exec_prefix}/sbin logdir = /var/log/freeradius raddbdir = /etc/freeradius radacctdir = ${logdir}/radacct name = freeradius confdir = ${raddbdir} run_dir = ${localstatedir}/run/${name} db_dir = ${raddbdir} libdir = /usr/lib/freeradius pidfile = ${run_dir}/${name}.pid user = freerad group = freerad max_request_time = 30 cleanup_delay = 5 max_requests = 1024 listen { type = auth ipaddr = 2.2.2.2 port = 1645 } listen { ipaddr = 2.2.2.2 port = 1646 type = acct } listen { ipaddr = 192.168.5.2 port = 1645 type = auth } listen { ipaddr = 192.168.5.2 port = 1646 type = acct } hostname_lookups = no allow_core_dumps = no regular_expressions = yes extended_expressions = yes log { destination = files file = ${logdir}/radius.log syslog_facility = daemon stripped_names = no auth = no auth_badpass = no auth_goodpass = no } checkrad = ${sbindir}/checkrad security { max_attributes = 200 reject_delay = 1 status_server = yes } proxy_requests = yes $INCLUDE proxy.conf thread pool { start_servers = 5 max_servers = 50 min_spare_servers = 3 max_spare_servers = 10 max_requests_per_server = 0 } modules { $INCLUDE ${confdir}/modules/ $INCLUDE eap.conf $INCLUDE sql_localhost.conf $INCLUDE sql/mysql/counter.conf } instantiate { exec expr expiration logintime } $INCLUDE policy.conf $INCLUDE sites-enabled/ _________________ Configuration of proxy.conf: proxy server { synchronous = no retry_delay = 5 retry_count = 3 dead_time = 120 default_fallback = no post_proxy_authorize = no } realm resrealm(a)domain.tld <mailto:resrealm@domain.tld> { type = radius authhost = 10.10.10.10:1645 accthost = 10.10.10.10:1646 secret = respw nostrip } realm LOCAL { type = radius authhost = LOCAL accthost = LOCAL }

3 5