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: 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
Re: Problem with Cisco WLC probes in FR 2.2.1
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. > >Thanks, and happy Friday >Jonathan >- >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: Problem with Cisco WLC probes in FR 2.2.1
> > 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'll be releasing 2.2.2 very soon to fix various issues with unlang. In the mean time could you try the current v2.x.x HEAD to see if it resolves your issues? -Arran Arran Cudbard-Bell FreeRADIUS Development Team - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Problem with Cisco WLC probes in FR 2.2.1
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. Thanks, and happy Friday Jonathan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html