I've put some preliminary tar files on: http://git.freeradius.org/pre/ If there are any issues, let me know now. Otherwise we'll release 2.1.10 on Monday. The changelog is *extensive*. There are a large number of minor bugs fixed, and a lot of minor new features added. But the result is that the server has taken a significant step ahead in usability and functionality. Thanks to everyone for testing intermediate releases. Alan DeKok.
Garber, Neal wrote:
Last call for 2.1.10
I haven't had a chance to rework the patch for saving replies after a PEAP/TTLS reject (been very busy at work). I'll try to get to it today; but, I assume it's too late for 2.1.10 at this point, right?
I'll take a look... but 2.1.10 has been pending for a long time. :( Alan DeKok.
On 22/09/10 14:15, Alan DeKok wrote:
I've put some preliminary tar files on:
http://git.freeradius.org/pre/
If there are any issues, let me know now. Otherwise we'll release 2.1.10 on Monday.
Can we squeeze one quick VSA update into dictionary.extreme: ATTRIBUTE Extreme-Netlogin-Extended-Vlan 211 string ...it's documented in the XOS concepts guide and we use it successfully here; format is: Uuntagged;Ttagged;..;TtaggedN
On 22/09/10 15:14, Phil Mayers wrote:
On 22/09/10 14:15, Alan DeKok wrote:
I've put some preliminary tar files on:
http://git.freeradius.org/pre/
If there are any issues, let me know now. Otherwise we'll release 2.1.10 on Monday.
Can we squeeze one quick VSA update into dictionary.extreme:
ATTRIBUTE Extreme-Netlogin-Extended-Vlan 211 string
...it's documented in the XOS concepts guide and we use it successfully here; format is:
Uuntagged;Ttagged;..;TtaggedN
Wait never mind; it's in there already!
On Wed, 2010-09-22 at 15:15 +0200, Alan DeKok wrote:
I've put some preliminary tar files on:
http://git.freeradius.org/pre/
If there are any issues, let me know now.
We have an issue but I am a little lost as to where things are going wrong. If I set the uid/gid and 'mode=rw' in control-socket, and then restart the radiusd process, all is okay. However, if I then run 'radmin -e hup', the radius log file shows the re-reading of the config file and modules being reloaded, but *some* of our users cannot then authenticate. The server provides authentication for both wireless users and VPN users. For wireless users the wireless lan controller talks to the radius server, and the server proxies the request on to a backed IAS server. This works fine in all instances. The VPN users take a slightly different route in that they use a PPTP connection, which calls a PPP radius.so object. This in turn accesses the radius server (which is running on the same host), and that proxies the request off as with wireless users. The problem seems to be that although the proxy server returns a 'Yes' reply (meaning the user is authenticated) for the VPN users, the pppd process does not seem to recognise it and treats it as a failed CHAP authentication. As such what we see is the radius log saying the user has authenticated okay, but the user receives a 691 (I think) code indicating that there is a problem with their userid/password. Why this only occurs when we use 'radmin -e hup' I don't know. I can only guess that maybe something isn't being reloaded. If we do not use the control-socket then it all works fine for all our users. I have - finally - got this working (or rather failing) on a test server. So I can try to tackle the problem without affecting our live servers. A small log file snippet from the server: The radius log shows (having just issued 'radmin -e hup'): ============================================================ Wed Sep 22 16:41:57 2010 : Info: Received HUP signal. Wed Sep 22 16:41:57 2010 : Info: HUP - Re-reading configuration files Wed Sep 22 16:41:57 2010 : Info: HUP - loading modules Wed Sep 22 16:41:57 2010 : Info: Module: Reloaded module "suffix" Wed Sep 22 16:41:57 2010 : Info: Module: Reloaded module "acct_log" Wed Sep 22 16:41:57 2010 : Info: Module: Reloaded module "attr_filter.post-proxy" Wed Sep 22 16:41:57 2010 : Info: Module: Reloaded module "radutmp" Wed Sep 22 16:41:57 2010 : Info: Module: Reloaded module "suffix" Wed Sep 22 16:41:57 2010 : Info: Module: Reloaded module "attr_filter.post-proxy" Wed Sep 22 16:41:57 2010 : Info: Module: Reloaded module "attr_filter.access_reject" Wed Sep 22 16:41:57 2010 : Info: Module: Reloaded module "attr_filter.accounting_response" Wed Sep 22 16:41:57 2010 : Info: Module: Reloaded module "radutmp" Wed Sep 22 16:41:57 2010 : Info: Module: Reloaded module "pap" Wed Sep 22 16:41:57 2010 : Info: Module: Reloaded module "files" Wed Sep 22 16:41:57 2010 : Info: Loaded virtual server inner-tunnel Wed Sep 22 16:41:57 2010 : Info: Loaded virtual server <default> Wed Sep 22 16:41:57 2010 : Info: ... closing socket command file /var/run/radiusd/radiusd.sock Wed Sep 22 16:42:38 2010 : Auth: Login OK: [jhorne] (from client localhost port 0 cli 141.163.60.7) ============================================================ However, our daemon log file shows: ============================================================ Sep 22 16:42:37 jhvm1 pppd[27048]: rcvd [CHAP Response id=0xd3 <4a95b44a8179d661b7dc7036d88274d00000000000000000b309bacedf503df09b5c81ed196320a2c3a6accc68c1f70600>, name = "jhorne"] Sep 22 16:42:38 jhvm1 pppd[27048]: Yes Sep 22 16:42:38 jhvm1 pppd[27048]: Peer jhorne failed CHAP authentication Sep 22 16:42:38 jhvm1 pppd[27048]: sent [CHAP Failure id=0xd3 "Yes\n"] Sep 22 16:42:38 jhvm1 pppd[27048]: sent [LCP TermReq id=0x2 "Authentication failed"] ============================================================ The 'Yes' is returned by the proxy server. For some reason pppd is logging this and treating it as a chap failure. Normally it does not log the reply as text, but instead sends a chap response: ============================================================ Sep 22 16:45:00 jhvm1 pppd[27176]: rcvd [CHAP Response id=0xc8 <ff1620e9777e6dcb8e906e0fa61ce86d00000000000000004fcd1bb474b5278994d471503893a392f3a596b66fb4532000>, name = "jhorne"] Sep 22 16:45:00 jhvm1 pppd[27176]: sent [CHAP Success id=0xc8 "S=B18D5D0EC139ECCB0D17EBADF2DE818BCD7DF55B"] ============================================================ Although this looks like a pppd problem, it only occurs after we have issued 'radmin -e hup'. If we don't use the control-socket, or just use it without issuing a 'hup', then pppd works fine. John. -- John Horne Tel: +44 (0)1752 587287 University of Plymouth, UK Fax: +44 (0)1752 587001
John Horne wrote:
The problem seems to be that although the proxy server returns a 'Yes' reply (meaning the user is authenticated)
What does that mean? There is no standard attribute to transport a "Yes".
Although this looks like a pppd problem, it only occurs after we have issued 'radmin -e hup'. If we don't use the control-socket, or just use it without issuing a 'hup', then pppd works fine.
Use tcpdump to see what the Access-Accepts look like before && after the HUP. Alan DeKok.
On Wed, 2010-09-22 at 18:53 +0200, Alan DeKok wrote:
John Horne wrote:
The problem seems to be that although the proxy server returns a 'Yes' reply (meaning the user is authenticated)
What does that mean? There is no standard attribute to transport a "Yes".
Sorry, the 'Yes' is just the reply-message from the proxy server.
Although this looks like a pppd problem, it only occurs after we have issued 'radmin -e hup'. If we don't use the control-socket, or just use it without issuing a 'hup', then pppd works fine.
Use tcpdump to see what the Access-Accepts look like before && after the HUP.
I ran radiusd -X instead and saw: For a working login: ===================================================== Login OK: [jhorne] (from client localhost port 0 cli 141.163.60.7) # Executing section post-auth from file /etc/raddb/sites-enabled/default +- entering group post-auth {...} ++[exec] returns noop Sending Access-Accept of id 24 to 127.0.0.1 port 59536 Framed-IP-Address = 141.163.192.64 MS-MPPE-Encryption-Types = 0x00000004 MS-MPPE-Encryption-Policy = 0x00000002 MS-CHAP2-Success = 0xdb533d43314635413343393031354536343336343346313837304135454345383546444545363443433432 Reply-Message = "Yes" MS-MPPE-Recv-Key = 0xdbeaf9748e2221f03f521d891346d33f MS-MPPE-Send-Key = 0xc346ea6996ae8388f9de48e0f2fa0434 Finished request 0. ===================================================== For a failed login: ===================================================== Login OK: [jhorne] (from client localhost port 0 cli 141.163.60.7) # Executing section post-auth from file /etc/raddb/sites-enabled/default +- entering group post-auth {...} ++[exec] returns noop Sending Access-Accept of id 27 to 127.0.0.1 port 53597 Framed-IP-Address = 141.163.192.64 MS-MPPE-Encryption-Types = 0x00000004 MS-MPPE-Encryption-Policy = 0x00000002 Reply-Message = "Yes" MS-MPPE-Recv-Key = 0xa6f4391a49e2df2088d8807bd929eef6 MS-MPPE-Send-Key = 0x1d8311b17d07f5a1be38f07abe1211e3 Finished request 3. ===================================================== The failed login has no MS-CHAP2-Success attribute being sent back. John. -- John Horne Tel: +44 (0)1752 587287 University of Plymouth, UK Fax: +44 (0)1752 587001
On Wed, 2010-09-22 at 18:02 +0100, John Horne wrote:
The failed login has no MS-CHAP2-Success attribute being sent back.
Okay. The problem is to do with attribute filtering, but that in turn seems to be caused by freeradius doing something unexpected when it receives the HUP. We define the file /etc/raddb/attrs.post-proxy which contains the following: plymouth.ac.uk MS-CHAP2-Success =* ANY, Fall-Through = Yes NULL MS-CHAP2-Success =* ANY, Fall-Through = Yes DEFAULT Service-Type == Framed-User, Service-Type == Login-User, Login-Service == Telnet, ... (other attributes/values) We also have the file /etc/raddb/modules-local/attr_filter which contains: attr_filter attr_filter.post-proxy { attrsfile = ${confdir}/attrs.post-proxy } So when freeradius starts up it reads this file, and uses the defined module in preference to the one in the file /etc/raddb/modules/attr_filter. Running 'radiusd -X' shows: =================================================================== Starting - reading configuration files ... ... including configuration file /etc/raddb/modules-local/attr_filter ... including configuration file /etc/raddb/modules/attr_filter ... Module: Checking post-proxy {...} for more modules to load Module: Instantiating module "attr_filter.post-proxy" from file /etc/raddb/modules-local/attr_filter attr_filter attr_filter.post-proxy { attrsfile = "/etc/raddb/attrs.post-proxy" key = "%{Realm}" } =================================================================== As can be seen the correct module file is used. Now lets do a HUP: =================================================================== ... new connection request on command socket. Listening on command file /var/run/radiusd/radiusd.sock Ready to process requests. radmin> hup Ready to process requests. Received HUP signal. HUP - Re-reading configuration files ... including configuration file /etc/raddb/modules-local/attr_filter ... including configuration file /etc/raddb/modules/attr_filter ... Module: Trying to reload module "attr_filter.post-proxy" attr_filter attr_filter.post-proxy { attrsfile = "/etc/raddb/attrs.post-proxy" key = "%{Realm}" } Module: Reloaded module "attr_filter.post-proxy" ... Module: Trying to reload module "attr_filter.post-proxy" attr_filter attr_filter.post-proxy { attrsfile = "/etc/raddb/attrs" key = "%{Realm}" } Module: Reloaded module "attr_filter.post-proxy" =================================================================== As can be seen, after the HUP freeradius loads the original file, but then reloads the default one (/etc/raddb/modules/attr_filter which uses "/etc/raddb/attrs"). This default filter file has no MS-CHAP2-Success entry, so that attribute would be filtered out. Looking at the processing of the access accept packet shows this too: =================================================================== rad_recv: Access-Accept packet from host 141.163.195.250 port 1812, id=137, length=194 Framed-IP-Address = 141.163.192.64 MS-MPPE-Encryption-Types = 0x00000004 MS-MPPE-Encryption-Policy = 0x00000002 MS-CHAP2-Success = 0x8c533d32373939374535323141364234394141453336314337343341313436383936323043393032433045 Reply-Message = "Yes" MS-MPPE-Recv-Key = 0xf6ee626fa0a9ceea0c565916916e4a5a MS-MPPE-Send-Key = 0x12c24a8d04f33b97b786c120f155aa4f Proxy-State = 0x3338 # Executing section post-proxy from file /etc/raddb/sites-enabled/default +- entering group post-proxy {...} [eap] No pre-existing handler found ++[eap] returns noop [files] users: Matched entry jhorne at line 213 [files] expand: %{User-Name} -> jhorne [files] expand: %{User-Name} -> jhorne [files] expand: %{User-Name} -> jhorne [files] expand: %{Calling-Station-Id} -> 141.163.60.243 [files] users: Matched entry DEFAULT at line 269 ++[files.authorize] returns ok [attr_filter.post-proxy] expand: %{Realm} -> NULL attr_filter: Matched entry DEFAULT at line 103 ++[attr_filter.post-proxy] returns updated =================================================================== The 'Matched entry DEFAULT at line 103' is from the file /etc/raddb/attrs, and so the MS-CHAP2-Success attribute is removed and the client see a failure/reject rather than a success. The 'radiusd -X' output when a HUP hasn't been given shows: =================================================================== [attr_filter.post-proxy] expand: %{Realm} -> NULL attr_filter: Matched entry NULL at line 5 attr_filter: Matched entry DEFAULT at line 9 ++[attr_filter.post-proxy] returns updated =================================================================== And the lines 5 and 9 correspond to our defined file which allow for the MS-CHAP2-Success attribute. So, I guess the question is why is freeradius reloading the post-proxy filter a second time after the HUP? John. -- John Horne, University of Plymouth, UK Tel: +44 (0)1752 587287 Fax: +44 (0)1752 587001
John Horne wrote:
We also have the file /etc/raddb/modules-local/attr_filter which contains:
Have you *deleted* the default configuration for the attr_filter.post-proxy module? If not, you have *two* copies of the module configuration. That's why it's having issues. It picks on the first time, and a different one the second time.
attr_filter attr_filter.post-proxy { attrsfile = ${confdir}/attrs.post-proxy }
So when freeradius starts up it reads this file, and uses the defined module in preference to the one in the file /etc/raddb/modules/attr_filter.
OK... so why do you still have the default one in the configuration? Delete it, or rename your module, and update the server configuration to use the new name.
So, I guess the question is why is freeradius reloading the post-proxy filter a second time after the HUP?
The question is why do you have two configurations for the same module? The only bug here is that the server should complain if you have two instances of the same module defined. That would prevent the server from starting in this case, and highlight the fact that the configuration is wrong. Alan DeKok.
On Thu, 2010-09-23 at 12:05 +0200, Alan DeKok wrote:
John Horne wrote:
So, I guess the question is why is freeradius reloading the post-proxy filter a second time after the HUP?
The question is why do you have two configurations for the same module?
The only bug here is that the server should complain if you have two instances of the same module defined. That would prevent the server from starting in this case, and highlight the fact that the configuration is wrong.
Ah, okay our mistake. Sorry about that. As far as I remember we created the module with the same name and it seemed to work. Obviously 'seemed to work' is not the same as 'works in all cases', and not necessarily the right way to do things. We will rename our local module. Thanks, John. -- John Horne, University of Plymouth, UK Tel: +44 (0)1752 587287 Fax: +44 (0)1752 587001
Hi,
The only bug here is that the server should complain if you have two instances of the same module defined. That would prevent the server from starting in this case, and highlight the fact that the configuration is wrong.
that would be the obvious and ideal way to deal with things...but I wouldnt advocate such a change occuring right now in 2.1.10 - we have no idea of how many installations have multiple copies of same module and they've got away with it.... alan
Alan Buxey wrote:
Hi,
The only bug here is that the server should complain if you have two instances of the same module defined. That would prevent the server from starting in this case, and highlight the fact that the configuration is wrong.
that would be the obvious and ideal way to deal with things...but I wouldnt advocate such a change occuring right now in 2.1.10 - we have no idea of how many installations have multiple copies of same module and they've got away with it....
Pretty much, yes. Maybe for 2.1.11 it could be a WARNING. Alan DeKok.
Alan DeKok <aland@deployingradius.com> writes:
I've put some preliminary tar files on:
http://git.freeradius.org/pre/
If there are any issues, let me know now. Otherwise we'll release 2.1.10 on Monday.
A little late into the game, but I just noticed this: bjorn@nemi:~$ radclient -v radclient: $Id$ built on Jun 18 2010 at 03:16:11 I guess the RCS keyword is leftover from when CVS was used. I propose replacing it with RADIUSD_VERSION. Will followup with a minimalistic patch shortly. Bjørn
RCS keywords don't make sense with git, so use the RADIUSD_VERSION macro instead, like the server and radmin already do. Signed-off-by: Bjørn Mork <bjorn@mork.no> --- src/main/radclient.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/main/radclient.c b/src/main/radclient.c index 1266502..8864798 100644 --- a/src/main/radclient.c +++ b/src/main/radclient.c @@ -927,7 +927,7 @@ int main(int argc, char **argv) timeout = atof(optarg); break; case 'v': - printf("radclient: $Id$ built on " __DATE__ " at " __TIME__ "\n"); + printf("radclient " RADIUSD_VERSION " built on " __DATE__ " at " __TIME__ "\n"); exit(0); break; case 'x': -- 1.7.1
On 09/22/2010 09:15 AM, Alan DeKok wrote:
I've put some preliminary tar files on:
http://git.freeradius.org/pre/
If there are any issues, let me know now. Otherwise we'll release 2.1.10 on Monday.
I verified 2.1.10 builds and produces an RPM. My apologies but I don't have time at the moment to test and exercise the resulting RPM's. -- John Dennis <jdennis@redhat.com> Looking to carve out IT costs? www.redhat.com/carveoutcosts/
On 2010/09/22 03:15 PM, Alan DeKok wrote:
I've put some preliminary tar files on:
http://git.freeradius.org/pre/
If there are any issues, let me know now. Otherwise we'll release 2.1.10 on Monday.
Would be nice to remove "+git" from debian/changelog -- Johan Meiring Cape PC Services CC Tel: (021) 883-8271 Fax: (021) 886-7782
I just noticed the redhat/freeradius.spec file wasn't fully updated in 2.1.0. It was missing the dynamic_clients and opendirectory modules in the %files section. Also the release tag was left at 2 instead of being reset to 1. Attached is a patch, in addition to the above it adds the changelog information. -- John Dennis <jdennis@redhat.com> Looking to carve out IT costs? www.redhat.com/carveoutcosts/
John Dennis wrote:
I just noticed the redhat/freeradius.spec file wasn't fully updated in 2.1.0. It was missing the dynamic_clients and opendirectory modules in the %files section. Also the release tag was left at 2 instead of being reset to 1. Attached is a patch, in addition to the above it adds the changelog information.
Added, thanks. Alan DeKok.
Hi, compiled and runs on a test server (but no real traffic load). One thing has changed from recently: on my openSUSE 11.2 i586 previously, I had to compile ---with-system-libtool, and *not using that* would break the build. Now, it's vice versa: --with-system-libtool breaks, and without it, stuff works. Strange; but never mind. Greetings, Stefan Winter Am 22.09.2010 15:15, schrieb Alan DeKok:
I've put some preliminary tar files on:
http://git.freeradius.org/pre/
If there are any issues, let me know now. Otherwise we'll release 2.1.10 on Monday.
The changelog is *extensive*. There are a large number of minor bugs fixed, and a lot of minor new features added. But the result is that the server has taken a significant step ahead in usability and functionality.
Thanks to everyone for testing intermediate releases.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473
Stefan Winter wrote:
One thing has changed from recently: on my openSUSE 11.2 i586 previously, I had to compile ---with-system-libtool, and *not using that* would break the build. Now, it's vice versa: --with-system-libtool breaks, and without it, stuff works.
Yes... I changed it so that the defaults were to use local libtool && libltdl. The system versions are "updated", and use incompatible APIs. So if you use system/local or local/system libtool/libltdl, the build breaks in strange and mysterious ways. Alan DeKok.
Alan DeKok <aland@deployingradius.com> wrote:
If there are any issues, let me know now. Otherwise we'll release 2.1.10 on Monday.
Is it worth tweaking the eap.conf comment so that it is explicitly mentioned that for session resumption to work sensibly for TTLS/PEAP that 'use_tunneled_reply' should be set to 'yes'? Cheers -- Alexander Clouter .sigmonster says: No yak too dirty; no dumpster too hollow.
Alexander Clouter wrote:
Alan DeKok <aland@deployingradius.com> wrote:
If there are any issues, let me know now. Otherwise we'll release 2.1.10 on Monday.
Is it worth tweaking the eap.conf comment so that it is explicitly mentioned that for session resumption to work sensibly for TTLS/PEAP that 'use_tunneled_reply' should be set to 'yes'?
Sure. Alan DeKok.
participants (10)
-
Alan Buxey -
Alan DeKok -
Alexander Clouter -
Bjørn Mork -
Garber, Neal -
Johan Meiring -
John Dennis -
John Horne -
Phil Mayers -
Stefan Winter