Conditional Auth Response?
Darren Ward (darrward)
darrward at cisco.com
Wed Feb 12 06:08:25 CET 2014
I think we can take this offlist as the issues I'm seeing now are ASR related not FreeRADIUS which after Alan pointed out my blunder is working perfectly
Darren
-----Original Message-----
From: freeradius-users-bounces+darrward=cisco.com at lists.freeradius.org [mailto:freeradius-users-bounces+darrward=cisco.com at lists.freeradius.org] On Behalf Of Vijay
Sent: Wednesday, 12 February 2014 3:46 PM
To: FreeRadius users mailing list
Subject: Re: Conditional Auth Response?
> Yes it does but in order to send an Access-Accept for authorisation don't we need to update the control with a Password ?
Yes exactly you don't need to update and asr router sends password in access-request.
> Our mandatory point is we don't need authentication as such just
> authorisation based on whether the ASR has expired the quota volume
> (QV) or not - since the ASR is configured to only send when the
> counter goes over the limit then we can assume that any authorisation
> request where a QV value appears is already over-quota so we don't
> need to track usage and we have no SQL available either
Asr simply sends access-request again for reauthorisation when alloted quota gets over.That's what documented in asr docs.
> So the ability to match the incoming user-name and use a password to
> authorise based on the incoming attribute is mandatory
Sent from my iPhone
Regards
Vijay
On 12-Feb-2014, at 8:43 AM, "Darren Ward (darrward)" <darrward at cisco.com> wrote:
> Yes it does but in order to send an Access-Accept for authorisation don't we need to update the control with a Password ?
>
> Our mandatory point is we don't need authentication as such just
> authorisation based on whether the ASR has expired the quota volume
> (QV) or not - since the ASR is configured to only send when the
> counter goes over the limit then we can assume that any authorisation
> request where a QV value appears is already over-quota so we don't
> need to track usage and we have no SQL available either
>
> So the ability to match the incoming user-name and use a password to
> authorise based on the incoming attribute is mandatory
>
> Cheers
> Darren
>
> -----Original Message-----
> From: freeradius-users-bounces+darrward=cisco.com at lists.freeradius.org
> [mailto:freeradius-users-bounces+darrward=cisco.com at lists.freeradius.o
> rg] On Behalf Of Vijay
> Sent: Wednesday, 12 February 2014 1:57 PM
> To: FreeRadius users mailing list
> Cc: FreeRadius users mailing list
> Subject: Re: Conditional Auth Response?
>
> Hi Darren,
> You don't have to update password to Cisco, Chek your Cisco Asr routers configuration. If configured properly asr router will send Cisco as a password for all ip users.
>
> To update QV values you use SQL concat query and you will get desired result.
>
>
> Sent from my iPhone
>
> Regards
> Vijay
>
> On 12-Feb-2014, at 7:33 AM, "Darren Ward (darrward)" <darrward at cisco.com> wrote:
>
>> Apologies
>>
>> I'm trying in the authorise section of the default site in sites-enabled:
>>
>> So this rule I am hoping to create will see an incoming authorise
>> request for user 192.168.104.10 as an example use the password "cisco"
>> for the authorisation and then proceed to look at the request and if
>> it sees a Cisco-Control-Info attribute set with QV<anynumber> then
>> update the reply which needs to be an access-accept with QV="0" else
>> if there is no QV attribute set then set one to 50Meg
>>
>> I'm on a basic Red Hat box so I assume the POSIX regex is * but I
>> have also tried the + from a previous example I found
>>
>> authorize {
>>
>> if (User-Name =~ /192.168.*/) {
>> update control {
>> Cleartext-Password := "cisco"
>> }
>> if (Cisco-Control-Info =~ /QV*/) {
>> update reply {
>> Cisco-Control-Info += "QV0"
>> }
>> }
>> else {
>> update reply {
>> Cisco-Control-Info += "QV50000000"
>> }
>> }
>> }
>>
>> Etc etc
>>
>> }
>>
>> However in the debug log it doesn't seem to macth any rules in
>> authorisze and
>>
>> rad_recv: Access-Request packet from host 127.0.0.1 port 45778, id=65, length=84
>> User-Name = "192.168.104.10"
>> User-Password = "cisco"
>> NAS-IP-Address = 10.67.21.130
>> NAS-Port = 10
>> Message-Authenticator = 0xf253e291d588b17c3bb0e547c4993af8
>> Wed Feb 12 12:57:55 2014 : Info: # Executing section authorize from
>> file /usr/local/etc/raddb/sites-enabled/default
>> Wed Feb 12 12:57:55 2014 : Info: +group authorize { Wed Feb 12
>> 12:57:55 2014 : Info: ++[preprocess] = ok Wed Feb 12 12:57:55 2014 :
>> Info: ++[chap] = noop Wed Feb 12 12:57:55 2014 : Info: ++[mschap] =
>> noop Wed Feb 12 12:57:55 2014 : Info: ++[digest] = noop Wed Feb 12
>> 12:57:55 2014 : Info: [suffix] No '@' in User-Name =
>> "192.168.104.10", looking up realm NULL Wed Feb 12 12:57:55 2014 : Info: [suffix] No such realm "NULL"
>> Wed Feb 12 12:57:55 2014 : Info: ++[suffix] = noop Wed Feb 12
>> 12:57:55
>> 2014 : Info: [eap] No EAP-Message, not doing EAP Wed Feb 12 12:57:55
>> 2014 : Info: ++[eap] = noop Wed Feb 12 12:57:55 2014 : Info:
>> ++[files] = noop Wed Feb 12 12:57:55 2014 : Info: ++[expiration] =
>> noop Wed Feb
>> 12 12:57:55 2014 : Info: ++[logintime] = noop Wed Feb 12 12:57:55
>> 2014
>> : Info: [pap] WARNING! No "known good" password found for the user. Authentication may fail because of this.
>> Wed Feb 12 12:57:55 2014 : Info: ++[pap] = noop Wed Feb 12 12:57:55
>> 2014 : Info: +} # group authorize = ok Wed Feb 12 12:57:55 2014 :
>> Info: ERROR: No authenticate method (Auth-Type) found for the request:
>> Rejecting the user Wed Feb 12 12:57:55 2014 : Info: Failed to authenticate the user.
>> Wed Feb 12 12:57:55 2014 : Info: Using Post-Auth-Type REJECT Wed Feb
>> 12 12:57:55 2014 : Info: # Executing group from file
>> /usr/local/etc/raddb/sites-enabled/default
>> Wed Feb 12 12:57:55 2014 : Info: +group REJECT {
>> Wed Feb 12 12:57:55 2014 : Info: [attr_filter.access_reject] expand: %{User-Name} -> 192.168.104.10
>> Wed Feb 12 12:57:55 2014 : Debug: attr_filter: Matched entry DEFAULT
>> at line 11 Wed Feb 12 12:57:55 2014 : Info:
>> ++[attr_filter.access_reject] = updated Wed Feb 12 12:57:55 2014 :
>> Info: +} # group REJECT = updated Wed Feb 12 12:57:55 2014 : Info:
>> Delaying reject of request 0 for 1 seconds Wed Feb 12 12:57:55 2014 :
>> Debug: Going to the next request Wed Feb 12 12:57:55 2014 : Debug: Waking up in 0.9 seconds.
>> Wed Feb 12 12:57:56 2014 : Info: Sending delayed reject for request 0
>> Sending Access-Reject of id 65 to 127.0.0.1 port 45778
>>
>>
>> -----Original Message-----
>> From:
>> freeradius-users-bounces+darrward=cisco.com at lists.freeradius.org
>> [mailto:freeradius-users-bounces+darrward=cisco.com at lists.freeradius.
>> o
>> rg] On Behalf Of Alan DeKok
>> Sent: Wednesday, 12 February 2014 12:35 PM
>> To: FreeRadius users mailing list
>> Subject: Re: Conditional Auth Response?
>>
>> Darren Ward (darrward) wrote:
>>> Looking for some unlang tutorials I think! :)
>>
>> There are lots of examples in the raddb/ directory. See also raddb/policy.conf.
>>
>>> I'm trying to combine the two factors I need with is to have a macro entry for a common 'anonymous' set of users together with the ability to manipulate the response and so am trying to munge the two responses I received on the separate threads.
>>
>> I'm not sure what that means...
>>
>>> I am getting parse error - expecting operator on the first line so
>>> obviously the if +~ isn't an option
>>
>> The example you pasted below doesn't use +~.
>>
>>> Any pointers for me?
>>
>> Where are you putting this text?
>>
>> 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
> -
> List info/subscribe/unsubscribe? See
> http://www.freeradius.org/list/users.html
> -
> List info/subscribe/unsubscribe? See
> http://www.freeradius.org/list/users.html
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
More information about the Freeradius-Users
mailing list