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

SQL Auth Logging
by Kev Pearce 03 Jun '14

03 Jun '14

Hi all, I'm sure this has been asked many times before but I can't seem to find an answer to it. Is it possible to log to an SQL server when an unknown client attempts to authenticate against a virtual server and also to log then a good client tries but with an incorrect secret? I've got good and bad auth attempts logging to SQL nicely with (to my own postauth_table) and a bit of decoration in my UI: postauth_query = "INSERT INTO ${postauth_table} \ (src_ip_address, nas_ip_address, dest_port, username, password, \ reply, reason, auth_timestamp) \ VALUES \ ('%{Packet-Src-IP-Address}', \ '%{NAS-IP-Address}', \ '%{Packet-Dst-Port}', \ '%{User-Name}', \ '%{%{User-Password}:-%{Chap-Password}}', \ '%{reply:Packet-Type}', \ '%{Module-Failure-Message}', \ '%S')" I'm trying to do this so the users of my web interface can spot incorrectly configured clients/client entries. I'm not just trying to trouble shoot just one particular client. I'm trying to create a fully web interfaced system to manage and troubleshoot FreeRADIUS clients and users, Great product by the way, keep it up, Cheers Kev/.

2 1

Android 2.3.5 supplicants failing after upgrade to FreeRADIUS 2.2.5 from 2.2.0
by Robert Franklin 02 Jun '14

02 Jun '14

Hello, We've suddenly started having reports of problems authenticating to our eduroam 802.1X service from users with Android 2.3.5 phones since an upgrade of FreeRADIUS on Tuesday morning this last week. As far as we're aware, no other body of users are affected, including newer Android devices: our Service Desk are just noticing this OS as a significant pattern. We were running FreeRADIUS 2.2.0, running on SLES 11 SP2, but upgraded to 2.2.5 and SLES 11 SP3, as far as we're aware, no other changes were made to the configuration, nor certificates. This is aside from a period of about 45 minutes following the upgrade where a mistake in the RPM caused the sites-available/default and inner-tunnel files to be overwritten with the default ones, before our local copies were reinstated. This obviously trashed much of our local configuration, causing authentication to fail for a period. We know at least one user affected tried to connect during this time but are unsure if all the affected users also did so, nor if other Android 2.3.5 users are successful (I'm trying to lay my hands on one which didn't). This situation may have upset the phones but we've tried removing the configuration from them, restarting them and then re-entering everything, but still they cannot connect. I have tried the same username/password on a Windows 7 laptop, also using EAP/PEAP and that connects fine. Looking at the debug (with raddebug on the Calling-Station-Id of an affected device's MAC address; a '-X' is a little busy) it seems to engage in an EAP dialogue with FreeRADIUS but then stops partway through. I've attached a gzipped copy of the raddebug -- I could send "radiusd -X" but I don't think there'll be anything pertinent in there as all the other supplicants are working, but I'm happy to, if necessary. The big lumps of hex in the EAP stuff doesn't make sense to me (I'm hoping it does to someone else!) but I have compared it with a successful device (an iPhone with a different username) to see where they differ. Everything seems OK up to request 21021170 (which finishes on line 646 of the file), where an Access-Challenge goes back to the supplicant. The following Access-Request has a very short EAP-Message compared to the successful iPhone, which makes me think EAP is aborting/restarting or broken somehow. On the iPhone, after two more packets, peap reports that TUNNEL ESTABLISHED, whereas the Android device never does. Please let me know if you need anything else. There may be something else that has broken on the server, or a bit of configuration that has been corrupted, but it's odd it's just (apparently) affecting this class of device, but we don't think we've changed certificates or anything else. The weird thing here is why just Android 2.3.5 (or possibly everything < version 3?) is failing, following the upgrade. I can't spot anything has changed in the FreeRADIUS release notes that I might need to change, nor any reports of similar problems. Thanks in advance for any help, - Bob -- Bob Franklin rcf34(a)cam.ac.uk / +44 1223 748479 Networks, University Information Services, University of Cambridge

4 5

Reply attribute in access-accept while doing eap-mschapv2
by free.aaa 02 Jun '14

02 Jun '14

Hi all! It seems like a missed some basic concepts about eap in freeradius. How to make freeradius return attribute for a specific user? I'm using freeradius-3.0.3. I created user in mysql (radcheck) as usual: test Cleartext-Password := test And add to radreply table: test Class = temp_class And when I do eap-mschapv2 I did not receive Class attribute. I need help to clarify this concept and advice how to include this attribute in the reply. PS: As one try I added to my default config in the post-auth section the following: update reply { Class = "%{Class}" } and after that the Class attribute appeared in the access-accept but it was empty. Thanks in advance! Best regards, Alex

5 14

[ANN] Release 3.0.4 rc1
by Arran Cudbard-Bell 02 Jun '14

02 Jun '14

A preview release of 3.0.4 is available here: https://github.com/FreeRADIUS/freeradius-server/archive/release_3_0_4_rc1.t… We’re creating a second release candidate for 3.0.4 to verify defects in the last release candidate have been fixed, and that no new issues have crept in. Some changes since the last RC: Compile time type checking ------------------------------------- In response to the particularly nasty subtle corruption of memory in FreeRADIUS 3.0.3 caused by mismatched variable/configuration directive types and the configuration parser, we’ve added compile time checking. https://github.com/FreeRADIUS/freeradius-server/blob/master/src/include/con… This has involved a large amount of code churn as field types in module configuration structs have been altered to match exactly the configuration directive type. The most use visible part of these changes is that integer type configuration directives will, in most cases, no longer accept negative values. If you find a particular integer type configuration directive that you feel should accept negative integers, let us known and we'll correct it. Client / homeserver / listener changes ------------------------------------------------- One of the other changes forced by compile time type checking was for IP/IPv4/IPv6 types. All addresses and prefixes in modules and the server core, are now represented as fr_ipaddr_t. This means some places which would only accept IPv4 addresses before now accept IPv4 prefixes and IPv6 addresses/prefixes. Internal attribute numbering ------------------------------------- Following the same theme of preventing mismatches within the server, the internal macros used for attribute numbering are now auto-generated at build time. This should prevent mismatches occurring between the shipped dictionary and the header files, and allows users building from src to renumber internal attributes (if they really want to) by editing the share/dictionary.freeradius.internal dictionary and recompiling. rlm_cache behaviour changes ---------------------------------------- One of the things that has prevented people using the rlm_cache module is it’s perceived complexity. To make things similar we’ve introduced a couple of behaviour changes. Firstly the module will consume any of the control attributes used to configure it after each call. The second change was to add the Cache-Read-Only attribute, which will allow merging of existing cache entries but will prevent new ones being created. For caching attributes from LDAP you’d now do something like: update control { Cache-Read-Only := yes } cache # Consumes Cache-Read-Only if (notfound) { ldap cache } Which is a little simpler than: update control { Cache-Status-Only := yes } cache update control { Cache-Status-Only := no } if (notfound) { ldap } cache It’s also more efficient as for cached entries there’s only a single lookup. This shouldn’t affect the majority of installations already using rlm_cache, for most, it will just make some update blocks redundant. If you run into any issues log a report at http://bugs.freeradius.org, or post to the list. -Arran

4 4

Problems building 2.2.5
by Jonathan Gazeley 02 Jun '14

02 Jun '14

I'm trying to build a 2.2.5 RPM on and for CentOS 6 x86_64 using the spec file included in the source distribution. Build always fails at the end when packaging the files with this error: RPM build errors: Installed (but unpackaged) file(s) found: /etc/raddb/panic.gdb The file /etc/raddb/panic.gdb contains the following: [jg4461@build64 raddb]$ cat panic.gdb info locals info args thread apply all bt full quit I can't find any other reference in the output from the build process that would seem to explain this. Anyone got any pointers (no pun intended) for tracking this one down? I'm a sysadmin, not a developer, and I'm not particularly familiar with C or gdb. Thanks, Jonathan

3 3

MS-CHAP
by Muruganandam C 02 Jun '14

02 Jun '14

Hi , Can you anyone sned me a configuration example for MS-CHAP(simple) for Free radius Thanks Muruganandam

2 1

3.0.3 Compile Error
by Aydın Demirel 01 Jun '14

01 Jun '14

Hi everybody, I'm trying to compile version 3.0.3 While its compiling, I'm getting the following error: scripts/boiler.mk:594: recipe for target 'build/lib/local/ libfreeradius-radius.la' failed make: *** [build/lib/local/libfreeradius-radius.la] Error 1 How can I solve this problem? Regards *Aydın Demirel--------------------------*

2 4