- Freeradius-Users - lists.freeradius.org

WARNING! for check item
by A.L.M.Buxey＠lboro.ac.uk 22 Feb '13

22 Feb '13

hi, quick query with some outout I see when radiusd starts uo (this is 3.x HEAD). I see the following message when attr_filter modules are being loaded up: reading pairlist file /etc/raddb/attrs [/etc/raddb/attrs]:134 WARNING! Check item "Local-Priv-Level" found in filter list for realm "DEFAULT". sure, there is an item in DEFAULT section of attrs: Called-Station-Id =* ANY, Operator-Name =* ANY, Port-Limit <= 2, Local-Priv-Level =* ANY, Session-Timeout <= 28800 and the entry in dictionary is: ATTRIBUTE Local-Priv-Level 3069 string what exactly is wrong here that is triggering this WARNING ? many thanks alan

2 1

segfault
by David Peterson 21 Feb '13

21 Feb '13

I had a bit of code cause a segfault in 3.0.0. Post-Auth-Type REJECT { attr_filter.access_reject update reply { EAP-Message = "0x04040004" Message-Authenticator = "%{Message-Authenticator}" } } Is there any reason I could not add this to sites-enabled/default? Here is the entry in syslog: Feb 21 11:18:59 freeradius1 kernel: [6021244.475983] radiusd[8535]: segfault at 80 ip 0000000000410ad7 sp 00007fff32516300 error 4 in radiusd[400000+57000] David Peterson

3 8

rlm_perl RAD_REQUEST
by Derek Wuelfrath 21 Feb '13

21 Feb '13

EHLO list! We're running into a strange issue here and would like the input of the FreeRADIUS community. Using rlm_perl with our own perl module for post_auth, everything is running smoothly until, for an unknown reason, it looks like the RAD_REQUEST hash is becoming "empty". Here's a snippet of the module (the important part for this particular issue). our (%RAD_REQUEST, %RAD_REPLY, %RAD_CHECK); sub post_auth { my $mac = clean_mac($RAD_REQUEST{'Calling-Station-Id'}); if (length($mac) != 17) { &radiusd::radlog(L_INFO, "MAC address is empty or invalid in this request. " . "It could be normal on certain radius calls"); &radiusd::radlog(L_INFO, "Our values. RAD_REQUEST-CallingStationId:" . $RAD_REQUEST{'Calling-Station-Id'} . " | MAC after clean_mac:" . $mac); return RLM_MODULE_OK; } ... } Here's the output when the issue occurs. Info: rlm_perl: MAC address is empty or invalid in this request. It could be normal on certain radius calls Info: rlm_perl: Our values. RAD_REQUEST-CallingStationId: | MAC after clean_mac:0 (The clean_mac thing is a method in our libraries that sanitize the MAC address itself... shouldn't have any incidence here) Any insight ? Somewhere to look ? Thanks! Derek -- dwuelfrath(a)inverse.ca :: +1.514.447.4918 (x110) :: www.inverse.ca Inverse inc. :: Leaders behind SOGo (www.sogo.nu) and PacketFence (www.packetfence.org)

1 0

DEFAULT realm proxy fail over
by Bertalan Voros 21 Feb '13

21 Feb '13

Hello All, I would like to get help with the following. There is a freeradius server that is proxying every mschapv2 request to a homeserver using the DEFAULT realm. The same server is also handling EAP requests and then proxying the inner request through the DEFAULT realm. Is is possible to set up fail-over using two home servers in this scenario? Thank you and best regards, Bertalan Voros

2 1

echo module creating zombies
by steffo76＠gmx.de 21 Feb '13

21 Feb '13

Hello list, I have a problem regarding the echo module which on my system creates zombie processes. I am using the following settings for echo: wait = no program = "/bin/true" (just for testing purposes) packet_type = Access-Accept After echo execs the program in question there is an undead child process left behind: 13467 ? Ssl 0:00 /usr/local/freeradius/sbin/radiusd 14258 ? Z 0:00 \_ [true] <defunct> This is pretty much everything strace has to say: 14258 execve("/bin/true", ["/bin/true", "asdf"], [/* 6 vars */]) = 0 14258 brk(0) = 0x85c6000 14258 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7787000 14258 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) 14258 open("/etc/ld.so.cache", O_RDONLY) = 3 14258 fstat64(3, {st_mode=S_IFREG|0644, st_size=67227, ...}) = 0 14258 mmap2(NULL, 67227, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7776000 14258 close(3) = 0 14258 open("/lib/i686/libc.so.6", O_RDONLY) = 3 14258 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\0h\1\0004\0\0\0\320\366\24\0\0\0\0\0004\0 \0\n\0(\0D\0C\0\6\0\0\0004\0\0\0004\0\0\0004\0\0\0@\1\0\0@\1\0\0\5\0\0\0\4\0\0\0\3\0\0\0`z\23\0`z\23\0`z\23\0\23\0\0\0\23\0\0\0\4\0\0\0\1\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0P\272\24\0P\272\24\0\5\0\0\0\0\20\0\0\1\0\0\0\344\301\24\0\344\301\24\0\344\301\24\0\230'\0\0lT\0\0\6\0\0\0\0\20\0\0\2\0\0\0|\335\24\0|\335\24\0|\335\24\0\360\0\0\0\360\0\0\0\6\0\0\0\4\0\0\0\4\0\0\0t\1\0\0t\1\0\0t\1\0\0 \0\0\0 \0\0\0\4\0\0\0\4\0\0\0\7\0\0\0\344\301\24\0\344\301\24\0\344\301\24\0\10\0\0\0@\0\0\0\4\0\0\0\4\0\0\0P\345tdtz\23\0tz\23\0tz\23\0\314+\0\0\314+\0\0\4\0\0\0\4\0\0\0Q\345td\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\6\0\0\0\4\0\0\0R\345td\344\301\24\0\344\301\24\0\344\301\24\0\34\36\0\0\34\36\0\0\4\0\0\0\1\0\0\0\4\0\0\0\20\0\0\0\1\0\0\0GNU\0\0\0\0\0\2\0\0\0\6\0\0\0\t\0\0\0\363\3\0\0\t\0\0\0\0\2\0\0\16\0\0\0\2400\20D\200 \2\1\214\3\346\220AE\210\0\204\0\10\0A\200\0@\300\200\0\f\2\f\0! \0010\0\10@\"\10\246\4\210H6l\240\0260\0&\204\200\216\4\10B$\2\f\246\244\32\6c\310\0\302 \1\300\0R\0!\201\10\4\n \250\24\0\24(`\0\0P\240\312DB", 512) = 512 14258 fstat64(3, {st_mode=S_IFREG|0755, st_size=1376624, ...}) = 0 14258 mmap2(NULL, 1381968, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7624000 14258 mmap2(0xb7770000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x14c) = 0xb7770000 14258 mmap2(0xb7773000, 9808, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7773000 14258 close(3) = 0 14258 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7623000 14258 set_thread_area({entry_number:-1 -> 6, base_addr:0xb76236c0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0 14258 mprotect(0xb7770000, 8192, PROT_READ) = 0 14258 mprotect(0x804f000, 4096, PROT_READ) = 0 14258 mprotect(0xb77a3000, 4096, PROT_READ) = 0 14258 munmap(0xb7776000, 67227) = 0 14258 brk(0) = 0x85c6000 14258 brk(0x85e7000) = 0x85e7000 14258 close(1) = 0 14258 close(2) = 0 14258 exit_group(0) = ? Any ideas why the zombies occur ? Thanks Stephan

3 8

HuntGroup check in radgroupcheck
by Lorenzo Milesi 21 Feb '13

21 Feb '13

Hi. I'm trying to manage Huntgroup checking into radgroupcheck table, but doesn't seem to work. Given the following properties: radcheck: F000001 MD5-Password := somemd5hash radusergroup F000001 HuntGroup01 radgroupcheck F000001 Huntgroup-Name =~ nas04|nas05 the user is always authenticated, even if the connection comes from a nas which is not nas04 or nas05. If I place the Huntgroup-Name property in the radcheck the user is correctly limited to the selected NASes. Output of the accounting session of "freeradius -X" attached here: https://dl.dropbox.com/u/706934/check01.gz The results of the ran queries: SELECT id, username, attribute, value, op FROM radcheck WHERE username = 'F0000001' ORDER BY id F000001 Md5-Password := xxx SELECT id, username, attribute, value, op FROM radreply WHERE username = 'F0000001' ORDER BY id (empty) SELECT groupname FROM usergroup WHERE username = 'F0000001' ORDER BY id huntgroup01 SELECT id, groupname, attribute, Value, op FROM radgroupcheck WHERE groupname = 'huntgroup01' OR groupname = 'nas04' ORDER BY id huntgroup01 Huntgroup-Name nas01|nas02 =~ The final query correctly returns the list of nases the user is allowed to login to, but apparently it's not considered. Why this? what am I missing? In addition to that, can I set a certain property (i.e. WISPr-Session-Terminate-Time) only if the user connects to a specific huntgroup? thanks -- Lorenzo Milesi - lorenzo.milesi(a)yetopen.it GPG/PGP Key-Id: 0xE704E230 - http://keyserver.linux.it

2 1

freeradius-proxy with Rlm_cache
by Dominique Frise 21 Feb '13

21 Feb '13

Hi, We would like to configure a freeradius proxy-server v. 2.2.0 under RHEL6 with users caching. The scenario we would like to achieve is the following: 1. client sends username/OTP to freeradius-proxy that relays to central radius server. Central radius server accepts and replies to freeradius-proxy that relays to client. 2. client sends same username/OTP within TTL to freeradius-proxy that accepts and replies to client. This should be possible using Rlm_cache module but we did not find a proper how-to for configuring this. Any help much appreciated. Dominique

2 5

RADIUS-Proxy before MAC Auth
by Oliver Warda 21 Feb '13

21 Feb '13

> Is there a way to proxy requests based on realms before checking the MAC > address? > Yes. You can check if the User-Name contains an "@" character. If > so, proxy. For example: > if (User-Name =~ /@/) { > suffix > if (updated) { > handled > } > mac-checks... > That should stop processing the request as soon as it's marked "to be > proxied". Thank you for this quick reply. We are using EAP-TLS computer-only authentication and additional MAC Auth. Both Common Name of certificates contain "@" characters, like machine-name@realm-local machine-name@realm-to-proxy Is it possible to use the realm instead and should this be placed within the users file? e.g. if (realm =~ /realm-to-proxy/) { suffix if (updated) { handled } mac-checks... Thank you very much for your support. Oliver

2 1

strange DHCP behavior
by Igor Smitran 21 Feb '13

21 Feb '13

Server: up2date Centos 6.3 x64 Software: freeradius 2.2.0 configured by ./configure, generated by GNU Autoconf 2.61, with options \"'--prefix=/usr/local/freeradius' '--with-dhcp' '--with-rlm_mysql=no' '--with-rlm_perl=no' --enable-ltdl-install\" radiusd -X starts OK, and then, after first DHCP discover is received: Listening on authentication address * port 1812 Listening on accounting address * port 1813 Listening on command file /usr/local/freeradius/var/run/radiusd/radiusd.sock Listening on authentication address 127.0.0.1 port 18120 as server inner-tunnel Listening on dhcp interface eth1 address * port 67 as server dhcp Listening on proxy address * port 1814 Ready to process requests. Received DHCP-Discover of id 08f11b15 from 10.21.192.1:67 to 0.0.0.0:67 Parse error Parse error or name in attributein attributein ode" Dropping packet without response. Going to the next request Waking up in 0.9 seconds. -------------------------- It is happening with default dhcp config. Only what is changed is: port = 67 ipaddr = ***** (ommited) interface = eth0 This is entirely new server, installed only for dhcp testing. Mysql and perl will be added later. Any idea?

1 1

Re: Free Radius 2.1.1 showing clear text password at the debug mode
by Danny Kurniawan 21 Feb '13

21 Feb '13

Hi Oliver, Thanks a lot. So could you please let me know how can i disabled the output (which conf file and what need to be added). Also by saying echo it do i need to put something into a config file or just echo command while i'm at radiusd - X debug mode? Thanks Danny -- Best Regards, Danny

3 2