Re: Problem with Cisco WLC probes in FR 2.2.1

2013-10-07 Thread Scott Armitage

On 7 Oct 2013, at 02:30, Bruce Nunn ironr...@yahoo.com wrote:

 Thanks for the heads-up. I will look for this this coming weekend when I get 
 2.2.2 in production. 
 
 Jonathan Gazeley jonathan.gaze...@bristol.ac.uk 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

2013-10-07 Thread A . L . M . Buxey
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

2013-10-07 Thread Phil Mayers

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

2013-10-07 Thread Jonathan Gazeley

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

2013-10-07 Thread Scott Armitage

On 7 Oct 2013, at 09:59, Jonathan Gazeley jonathan.gaze...@bristol.ac.uk 
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

2013-10-07 Thread A . L . M . Buxey
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

2013-10-07 Thread Arran Cudbard-Bell

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 a.cudba...@freeradius.org
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

2013-10-07 Thread A . L . M . Buxey
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

2013-10-07 Thread Arran Cudbard-Bell

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 a.cudba...@freeradius.org
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

2013-10-06 Thread Bruce Nunn
Thanks for the heads-up. I will look for this this coming weekend when I get 
2.2.2 in production. 

Jonathan Gazeley jonathan.gaze...@bristol.ac.uk 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

2013-10-04 Thread Arran Cudbard-Bell
 
 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 a.cudba...@freeradius.org
FreeRADIUS Development Team

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html