2.2.2 release date
I remember Alan mentioned that 2.2.2 may be released today. I checked git for 2.x.x and it says 2.2.1. I am wondering if it'll be released soon. Thanks, Yu Wang - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Version 3.0.0 has been released
On 7 Oct 2013, at 23:23, Arran Cudbard-Bell wrote: > > On 7 Oct 2013, at 23:00, Alan DeKok wrote: > >> Brian Julin wrote: >>> You guys are truly obsessed. I get exhausted just reading your commit >>> logs. :-) >> >> It's what I do. > > I'm just in it for the groupies. Everyone knows girls dig guys who have a > working knowledge of OpenLDAP client library. release_branch_3.0.0 has now been renamed v3.0.x and will be used for bugfixes in v3.0.x. Major new development will now be done in master, which will be branched again before the release of v3.1.0. git branch -m release_branch_3.0.0 v3.0.x Should be sufficient to update your local repositories. Arran Cudbard-Bell FreeRADIUS Development Team - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Version 3.0.0 has been released
On 7 Oct 2013, at 23:00, Alan DeKok wrote: > Brian Julin wrote: >> You guys are truly obsessed. I get exhausted just reading your commit logs. >> :-) > > It's what I do. I'm just in it for the groupies. Everyone knows girls dig guys who have a working knowledge of OpenLDAP client library. Arran Cudbard-Bell FreeRADIUS Development Team - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Version 3.0.0 has been released
Brian Julin wrote: > You guys are truly obsessed. I get exhausted just reading your commit logs. > :-) It's what I do. I spend a fair amount of time on other things, too. But pushing FreeRADIUS ahead is a high priority. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: radwho not working
Clint Petty wrote: > Hi Alan, > > Well I discovered a way to display a list of all active users without having > to implement FreeRadius accounting, which BTW is not as straight forward as > it should be. > > I was able to display all active users through my StrongSwan server, with the > simple following command: > > # strongswan leases > > FreeRadius should be so easy! RADIUS does a LOT more than strongswan. And yes, basic RADIUS really is easy. A large part of the difficulties are due to bad client implementations. No one wants to blame the client, so everyone blames FreeRADIUS. I've learned to deal with it, but that doesn't mean I have to like it. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: radwho not working
On 7 Oct 2013, at 22:39, Clint Petty wrote: > Hi Alan, > > Well I discovered a way to display a list of all active users without having > to implement FreeRadius accounting, which BTW is not as straight forward as > it should be. > > I was able to display all active users through my StrongSwan server, with the > simple following command: > > # strongswan leases > > FreeRadius should be so easy! It is if you understand SQL, and don't insist on using arcane decade old modules and utilities. -Arran Arran Cudbard-Bell FreeRADIUS Development Team - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: radwho not working
Hi Alan, Well I discovered a way to display a list of all active users without having to implement FreeRadius accounting, which BTW is not as straight forward as it should be. I was able to display all active users through my StrongSwan server, with the simple following command: # strongswan leases FreeRadius should be so easy! Thanks, Clint -Original Message- From: freeradius-users-bounces+cpetty=luthresearch@lists.freeradius.org [mailto:freeradius-users-bounces+cpetty=luthresearch@lists.freeradius.org] On Behalf Of Alan DeKok Sent: Thursday, October 03, 2013 3:10 PM To: FreeRadius users mailing list Subject: Re: radwho not working Clint Petty wrote: > I am not blaming, I am just wanting to get the radwho command to work. That is *entirely* the wrong attitude. There is no "just get it to work". There *are* multiple pieces involved, each of which has to be verified. I'm trying to convince you to use a methodical approach. If you read "man radwho", you'll see it uses accounting packets. That should indicate that you'll need to enable accounting. But you didn't do that. You were told to run the server in debugging mode, and you did once... but not the next time. The less you do yourself, and the more difficult you make it to help you, the less we're inclined to help. *THAT* is the goal of many of my responses. > I have now turned on accounting info to be sent from the StrongSwan server > to the FreeRadius server. For I can see the accounting info in > /var/log/radius/radacct//detail-20131003 file. Which isn't the radutmp file, is it? Again, "man radwho" says it reads the radutmp file. Again, your process should be something like this: - "man radwho" says it needs the radutmp file. - is the radutmp module enabled? - if enabled, is it doing anything? - where is the file? - is it being modified? > However I am still getting the same results with the radwho command, showing > just the titles, with no connections? You other message indicates that the module is being used, and is returning "ok". Does the "radwho" command print anything after the "radutmp" module returns "ok" ? It should. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: Version 3.0.0 has been released
Congratulations Alan, Arran for pushing this out of the nest, all the while being so attentive on the mailing list, along with Phil and "the other Alan" :-) You guys are truly obsessed. I get exhausted just reading your commit logs. :-) - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Version 3.0.0 has been released
After many years of development, the FreeRADIUS team is happy to announce Version 3 of the world's most popular server. The release was delayed from June in order to track down and solve a number of last-minute issues. We'd like to thank all of the beta testers for helping with that process. The release announcement is available on the web site: http://freeradius.org/press/index.html#3.0.0 In short, it's simpler, easier to use, and better organized. Upgrading instructions are available here: https://github.com/FreeRADIUS/freeradius-server/blob/release_branch_3.0.0/raddb/README.rst As this is a major version, you CANNOT just use your 2.x configuration files. Sorry, but many of the new features require changes which aren't compatible with 2.x. See the LDAP and SQL modules for new connection pools, for example. The debug output is colorized, with yellow WARNINGS and red ERRORS. This should help people understand which messages are important and need attention. RADIUS over TLS (RadSec) is supported. This means RADIUS has actual security, instead of the 20 year-old MD5 weirdness. Many configuration errors are caught at startup, rather than run time. Helpful messages are printed, including a pointer to which character caused the error. The raddb/ directory has been re-organized. The files should now be easier to find, as they use a consistent layout. DHCP and VMPS are still supported, but their code has been moved to plug-in modules. We expect to continue this process for the 3.1 release. The goal is to move RADIUS to a plug-in module. The server will then be capable of handling many more protocols. We have a number of new protocols in development, and will be announcing them later this year. SNMP traps are now supported. You can trigger a trap when a home server goes down, and when it comes back up again! While supporting many new features, the code is almost 10% smaller than version 2.2. In addition, it has daily builds on multiple platforms, including automatic static source code analysis. This means that the code is smaller, more secure, and easier to maintain. We'd like to add a special thanks to the Samba project, for the talloc library. Many of the new features we made possible by talloc. We expect more features in the future. Alan DeKok. FreeRADIUS Project Leader - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: What does FR 2.2.2 fix?
Hi, > clarification/agreement from Stefan or others? tried the newest GIT this morning and the proxy issues were gone. I haven't seen your "Internal sanity check failed" just yet (and am not looking forward to it :-/ ). Stefan > > alan > - > 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 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66 0x8A39DC66.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: What does FR 2.2.2 fix?
a.l.m.bu...@lboro.ac.uk wrote: > now its monday AM and the load has gone back to higher levels > the server is freaking out and freezing witht he last message in > the log being > > > Mon Oct 7 07:50:28 2013 : Error: [event.c:2318] Internal sanity check failed At least that's clearer. It would be nice to be able to debug the exact state for that, but the fix should be simple. I'll push something to git later today. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Problem with Cisco WLC probes in FR 2.2.1
On 7 Oct 2013, at 11:31, a.l.m.bu...@lboro.ac.uk wrote: > Hi, > >> Well you want the probes to go through and hit your backed authentication >> servers, >> and your databases, and any external resource. > > ..and get a valid user with access accept? bad. you are better off just > semding a reject - > just like RADIUS status server probes. it would be nice if the WISM would do > proper > RADIUS status-server probe insteadbut since cisco want you to buy ACS/ISE > and that doesnt > do nice things - then I guess we can live in hope No. You want a policy in post-auth which checks what happened when the test user's authentication was processed. Everything ok: Access-Reject Somethings wrong: Don't respond And you want to make sure that you have ACLs in place to only allow access to the RADIUS test user object from the RADIUS test server (obviously :) ). In regards to upstream proxy servers, i'll echo Alan D's thoughts on this, and say that it's really the responsibility of a AAA routing protocol. Though yes, for eduroam checking next hop connectivity is probably useful. Maybe an xlat method which returns the state of a realm? -Arran Arran Cudbard-Bell FreeRADIUS Development Team - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Problem with Cisco WLC probes in FR 2.2.1
Hi, > Well you want the probes to go through and hit your backed authentication > servers, > and your databases, and any external resource. ..and get a valid user with access accept? bad. you are better off just semding a reject - just like RADIUS status server probes. it would be nice if the WISM would do proper RADIUS status-server probe insteadbut since cisco want you to buy ACS/ISE and that doesnt do nice things - then I guess we can live in hope - after all, if you were REALLY going to validate what the WISM and RADIUS server can do, you'd want your status check to go through your remote RADIUS server proxiesas the user might be a visitor or from some 3rd party org that you peer with - then we get into the whole business of the status probes being more intelligent with multiple realms etc etc... this is WAY off topic now ;-) alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Problem with Cisco WLC probes in FR 2.2.1
On 7 Oct 2013, at 10:36, a.l.m.bu...@lboro.ac.uk wrote: > Hi, > >> We're finding these nuggets of code as we dig deeper into James's >> legacy config. If the Access-Accept response is not required, then >> presumably I can ditch that entire code block and let the >> wisms-testing auth attempt go through the system as any other user. > > yesbut you'd be better off just sending an immediate Access-Reject > or these probes go through your whole config and hit your backend > authentication > servers for no reason. Well you want the probes to go through and hit your backed authentication servers, and your databases, and any external resource. In the event of a failure of any of those modules you want to not respond to the WiSM. In 3.0.0 a really easy way to check for that sort of thing is using the presence of Module-Failure-Message, though you should be careful to clear it if you have redundant sections, or alternative behaviour on module failure. Previously Module-Failure-Message had to be set explicitly by the module, so wasn't implemented by all modules. In 3.0.0 when standardising the logging macros and added a call to set it on all request errors (RERROR, REDEBUG, REDEBUG2, REDEBUG3, REDEBUG4), which most, if not all modules use to log errors. -Arran Arran Cudbard-Bell FreeRADIUS Development Team - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Problem with Cisco WLC probes in FR 2.2.1
Hi, > We're finding these nuggets of code as we dig deeper into James's > legacy config. If the Access-Accept response is not required, then > presumably I can ditch that entire code block and let the > wisms-testing auth attempt go through the system as any other user. yesbut you'd be better off just sending an immediate Access-Reject or these probes go through your whole config and hit your backend authentication servers for no reason. alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Problem with Cisco WLC probes in FR 2.2.1
On 7 Oct 2013, at 09:59, Jonathan Gazeley
wrote:
> On 07/10/13 08:40, a.l.m.bu...@lboro.ac.uk wrote:
>> Hi,
>>
if (Service-Type == "NAS-Prompt-User") {
if (NAS-IP-Address =~ /^172\.17\.107\./) {
if (User-Name =~ /^wisms\-testing/) {
update control {
Auth-Type := Accept
}
>> ouch do you realise how dangerous that is? there
>> should be no need to send an access accept packet back
>> to these probes - a reject should suffice - and that would stop
>> an end user subverting your system by simply using
>> that UserName (if they are using wpa_supplicant they could
>> add that NAS-Prompt-User attribute)
>>
>> alan
>> -
>
> We're finding these nuggets of code as we dig deeper into James's legacy
> config. If the Access-Accept response is not required, then presumably I can
> ditch that entire code block and let the wisms-testing auth attempt go
> through the system as any other user.
Yes, or immediately reject that user in the authorise section. Rejecting
immediately just makes things more efficient, particularly if the wism is doing
a check because it has marked the server as dead.
Test it, see what happens.
Regards
Scott
signature.asc
Description: Message signed with OpenPGP using GPGMail
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Problem with Cisco WLC probes in FR 2.2.1
On 07/10/13 08:40, a.l.m.bu...@lboro.ac.uk wrote:
Hi,
if (Service-Type == "NAS-Prompt-User") {
if (NAS-IP-Address =~ /^172\.17\.107\./) {
if (User-Name =~ /^wisms\-testing/) {
update control {
Auth-Type := Accept
}
ouch do you realise how dangerous that is? there
should be no need to send an access accept packet back
to these probes - a reject should suffice - and that would stop
an end user subverting your system by simply using
that UserName (if they are using wpa_supplicant they could
add that NAS-Prompt-User attribute)
alan
-
We're finding these nuggets of code as we dig deeper into James's legacy
config. If the Access-Accept response is not required, then presumably I
can ditch that entire code block and let the wisms-testing auth attempt
go through the system as any other user.
Thanks,
Jonathan
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Problem with Cisco WLC probes in FR 2.2.1
On 10/07/2013 08:40 AM, a.l.m.bu...@lboro.ac.uk wrote:
Hi,
if (Service-Type == "NAS-Prompt-User") {
if (NAS-IP-Address =~ /^172\.17\.107\./) {
if (User-Name =~ /^wisms\-testing/) {
update control {
Auth-Type := Accept
}
ouch do you realise how dangerous that is? there
should be no need to send an access accept packet back
to these probes - a reject should suffice - and that would stop
an end user subverting your system by simply using
that UserName (if they are using wpa_supplicant they could
add that NAS-Prompt-User attribute)
Er... wpa_supplicant speaks EAP, and Service-Type is a RADIUS attribute.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: What does FR 2.2.2 fix?
Hi, > If everyone's in favor, I'll release 2.2.2 on Monday. hold request now its monday AM and the load has gone back to higher levels the server is freaking out and freezing witht he last message in the log being Mon Oct 7 07:50:28 2013 : Error: [event.c:2318] Internal sanity check failed (thats it...no other output - the server needs a restart, it doesnt process anything else once it hits this error) alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Problem with Cisco WLC probes in FR 2.2.1
Hi,
> >if (Service-Type == "NAS-Prompt-User") {
> > if (NAS-IP-Address =~ /^172\.17\.107\./) {
> > if (User-Name =~ /^wisms\-testing/) {
> >update control {
> > Auth-Type := Accept
> >}
ouch do you realise how dangerous that is? there
should be no need to send an access accept packet back
to these probes - a reject should suffice - and that would stop
an end user subverting your system by simply using
that UserName (if they are using wpa_supplicant they could
add that NAS-Prompt-User attribute)
alan
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Problem with Cisco WLC probes in FR 2.2.1
On 7 Oct 2013, at 02:30, Bruce Nunn wrote:
> Thanks for the heads-up. I will look for this this coming weekend when I get
> 2.2.2 in production.
>
> Jonathan Gazeley wrote:
>
>> We've recently upgraded our radius servers from 2.1.12 (CentOS 6
>> packaged default) to 2.2.1 (latest stable from FR, built by hand).
>>
>> A config that used to work under 2.1.12 no longer appears to work the
>> same way under 2.2.1. Our Cisco WLCs send periodic probes in the form of
>> a test authentication. There is a snippet of config that intercepts
>> these authentication requests:
>>
>> # /etc/raddb/conf.d/wism-checks.conf
>> if (Service-Type == "NAS-Prompt-User") {
>> if (NAS-IP-Address =~ /^172\.17\.107\./) {
>> if (User-Name =~ /^wisms\-testing/) {
>> update control {
>>Auth-Type := Accept
>> }
>> updated
>> }
>> else {
>>reject
>> }
>> }
>> updated = return
>> }
>>
>>
>> This config is included in every virtual server's outer config:
>>
>> # /etc/raddb/sites-enabled/eduroamlocal
>> authorize {
>> $INCLUDE conf.d/wism-checks.conf
>> }
>>
>>
>> Looking at the output from radiusd -XC the wism-checks.conf file is
>> being included in multiple places, yet when the server is running there
>> is no record of these test probe packets being processed. This means the
>> WLCs think the radius server is dead, and stop using it. I've had to
>> roll back to 2.1.12 to restore stable wireless service for our users.
>>
>> I can only assume this code block is being skipped over for some reason.
>> At present I'm unable to drop production radius servers into debug mode
>> since they can't handle the load while debugging, and while I do have
>> some development radius servers, our WLCs won't sent it these probe
>> packets unless it is an active production radius server.
>>
>> Does anyone have any tips for debugging this in a minimally disruptive
>> way? At the moment we don't have any development WLCs but we might have
>> to get some so we can have a separate environment for testing. In the
>> meantime I'm trying to get this code block to work so we can use the
>> newer version of FR.
We don't have any extra code for the wism checks on our FreeRADIUS. The
wism-check user is treated just like any other user, and consequently receives
an Access-Reject (because it isn't a real user). Why send an access accept?
The wism doesn't care what it gets back (Accept or Reject), it simply wants an
answer from the radius so it knows it is alive.
Have you tried running with your wism-checks config commented out?
To debug I would first check the configuration on the wism. Make sure it is
configured for Active fallback checks. Then I would use radmin, something like:
set debug file wism-fallback-test
set condition '(User-Name == wism-check)'
signature.asc
Description: Message signed with OpenPGP using GPGMail
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
