Android 2.3.5 supplicants failing after upgrade to FreeRADIUS 2.2.5 from 2.2.0
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@cam.ac.uk / +44 1223 748479 Networks, University Information Services, University of Cambridge
So not just FR update but also the OS updated too...so possible eg samba upgrade too If the RPM blatted your config like that then it may also have done something to your EAP config too - eg certificates (especially if the debug shows the clients failing at that point) . Did your windows client have correct/secure EAP settings or was it just 'user/password don't care about cert details' mode? alan -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
On 31 May 2014, at 10:35, Alan Buxey <A.L.M.Buxey@lboro.ac.uk> wrote:
So not just FR update but also the OS updated too...so possible eg samba upgrade too
I don't think anything majorly -- nothing like OpenSSL changing beyond some patches SuSE would have backported. Our password backend is a PostgreSQL server with Cleartext-Password being store; there is no Samba involved.
If the RPM blatted your config like that then it may also have done something to your EAP config too - eg certificates (especially if the debug shows the clients failing at that point) . Did your windows client have correct/secure EAP settings or was it just 'user/password don't care about cert details' mode?
I think the certs are all the same and being referenced the same -- we use a signed cert from the Janet Certificate Service and the chain all looks to be there (checking 'radiusd -X' output to see which files are read). My Windows 7 PC to test the same credentials is configured with the full 802.1X security setup - it only has the 'AddTrust External CA root' ticked, as well as the server name for the certificate as 'network.tokens.csx.cam.ac.uk'. If I change these settings on the PC to deliberately break them (such as ticket a different CA, or change the server name to 'network2.tokens.csx.cam.ac.uk') then the authentication fails (I do re-enter the credentials following this). So I think everything is being checked correctly. Also, that all the users of other platforms (>13,000 last week) are getting on without issue makes me think there's something odd here, like a chain certificate issue. I'm trying to lay my hands on a 2.3.5 device I can muck about with but it's proving tricky. Is there anything that can be determined from the raddebug output I sent (in terms of which end is stopping the EAP dialogue) or do I need to get more or a different type of output? - Bob -- Bob Franklin rcf34@cam.ac.uk / +44 1223 748479 Networks, University Information Services, University of Cambridge
On Sat, May 31, 2014 at 1:28 AM, Robert Franklin <rcf34@cam.ac.uk> wrote:
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.
The above might not be your main concern (since you've got it fixed), but I wonder where did you get the RPM from. The bundled suse specfile has %config(noreplace) %{_sysconfdir}/raddb/* which, in theory, should leave your config files alone. If you got the RPM from suse, then you should file a bug to them. -- Fajar
On 02/06/2014 12:18, Fajar A. Nugraha wrote:
The above might not be your main concern (since you've got it fixed), but I wonder where did you get the RPM from. The bundled suse specfile has
%config(noreplace) %{_sysconfdir}/raddb/*
which, in theory, should leave your config files alone.
If you got the RPM from suse, then you should file a bug to them.
I built the RPM using the openSUSE Build Service from the freeradius.spec file included within the freeradius-server-2.2.5.tar.bz2 file. What I didn't spot was that files in /etc/raddb/sites-available would be overwritten when installing the later RPM courtesy of %attr(640,root,radiusd) %{_sysconfdir}/raddb/sites-available/* whereas files in /etc/raddb/sites-enabled/ are not %attr(640,root,radiusd) %config(noreplace) %{_sysconfdir}/raddb/sites-enabled/* The difference being the absence/presence of "%config(noreplace)". Checking the latest freeradius.spec for SUSE @ https://raw.githubusercontent.com/FreeRADIUS/freeradius-server/v2.x.x/suse/f... shows this is still the case. The "%config(noreplace) %{_sysconfdir}/raddb/*" line you reference above would appear to be from the freeradius.spec for SUSE included with FreeRADIUS 3.0.x - we're using 2.2.5. Simon -- Simon Flood, Senior Systems Specialist, University Information Services, University of Cambridge
On Mon, Jun 2, 2014 at 8:25 PM, Simon Flood <S.M.Flood@uis.cam.ac.uk> wrote:
On 02/06/2014 12:18, Fajar A. Nugraha wrote:
The above might not be your main concern (since you've got it fixed), but I wonder where did you get the RPM from. The bundled suse specfile has
%config(noreplace) %{_sysconfdir}/raddb/*
which, in theory, should leave your config files alone.
If you got the RPM from suse, then you should file a bug to them.
I built the RPM using the openSUSE Build Service from the freeradius.spec file included within the freeradius-server-2.2.5.tar.bz2 file.
What I didn't spot was that files in /etc/raddb/sites-available would be overwritten when installing the later RPM courtesy of
%attr(640,root,radiusd) %{_sysconfdir}/raddb/sites-available/*
whereas files in /etc/raddb/sites-enabled/ are not
%attr(640,root,radiusd) %config(noreplace) %{_sysconfdir}/raddb/sites-enabled/*
The difference being the absence/presence of "%config(noreplace)".
Ouch. Sorry about that. Turned out it was partially my fault, partially suse's fault. That line was part of my pull request a long time ago to make FR's recipe closer to suse's own recipe. The problem is, turns out that even now, suse's own recipe on https://build.opensuse.org/package/view_file/network:aaa/freeradius-server/f... line 380 shows %attr(640,root,radiusd) %{_sysconfdir}/raddb/sites-available/*
Checking the latest freeradius.spec for SUSE @ https://raw.githubusercontent.com/FreeRADIUS/freeradius-server/v2.x.x/suse/f... shows this is still the case. The "%config(noreplace) %{_sysconfdir}/raddb/*" line you reference above would appear to be from the freeradius.spec for SUSE included with FreeRADIUS 3.0.x - we're using 2.2.5.
You are correct, I was looking at the wrong branch. I believe Alan just pushed a fix 12 minutes ago, so future 2.x.x builds should be OK. -- Fajar
participants (4)
-
Alan Buxey -
Fajar A. Nugraha -
Robert Franklin -
Simon Flood