Hi Hugh,

I see how this can be useful to having a hirercical user structure in providing 
aggregate reply attributes back.  However, in my case, there is no hierarchy - 
I simply want to match a single user entry based on all Check parameters with 
the ability to skip over the attributes that the AuthBy doesn't handle.  As it 
stands now, if the AuthBY doesn't know how to handle Group attribute, it 
rejects instead of just ignoring that check.

Thanks!

-----Original Message-----
From: Hugh Irvine [mailto:[email protected]] 
Sent: Friday, April 05, 2013 5:55 PM
To: Garry Shtern
Cc: 'Heikki Vatiainen'; [email protected]
Subject: Re: [RADIATOR] Ideas on group and reply attribs parsing


Hello Garry -

Actually, Fall-Through continues after an ACCEPT.

For example, this users file:


DEFAULT User-Name = hugh, Password = hugh
        Fall-Through = yes

DEFAULT
        Reply-Message = "hello, world"


produces this:


Radiator-4.11 hugh$ perl radpwtst -noacct -user hugh -password hugh

sending Access-Request...
Sat Apr  6 08:48:36 2013: DEBUG: Packet dump:
*** Received from 127.0.0.1 port 60920 ....
Code:       Access-Request
Identifier: 171
Authentic:  ;<208><135><228><181><134><4><251><23><238><4>`<167>Q0<174>
Attributes:
        User-Name = "hugh"
        Service-Type = Framed-User
        NAS-IP-Address = 203.63.154.1
        NAS-Identifier = "203.63.154.1"
        NAS-Port = 1234
        Called-Station-Id = "123456789"
        Calling-Station-Id = "987654321"
        NAS-Port-Type = Async
        User-Password = q<22>a<130>)3<10><135><138>-<196><23><19><195><178><9>

Sat Apr  6 08:48:36 2013: DEBUG: Handling request with Handler 'Realm=DEFAULT', 
Identifier ''
Sat Apr  6 08:48:36 2013: DEBUG:  Deleting session for hugh, 203.63.154.1, 1234 
Sat Apr  6 08:48:36 2013: DEBUG: Handling with Radius::AuthFILE: 
Sat Apr  6 08:48:36 2013: DEBUG: Reading users file ./users.default Sat Apr  6 
08:48:36 2013: DEBUG: Radius::AuthFILE looks for match with hugh [hugh] Sat Apr 
 6 08:48:36 2013: DEBUG: Radius::AuthFILE REJECT: No such user: hugh [hugh] Sat 
Apr  6 08:48:36 2013: DEBUG: Radius::AuthFILE looks for match with DEFAULT 
[hugh] Sat Apr  6 08:48:36 2013: DEBUG: Radius::AuthFILE ACCEPT: : DEFAULT 
[hugh] Sat Apr  6 08:48:36 2013: DEBUG: Radius::AuthFILE looks for match with 
DEFAULT1 [hugh] Sat Apr  6 08:48:36 2013: DEBUG: Radius::AuthFILE ACCEPT: : 
DEFAULT1 [hugh] Sat Apr  6 08:48:36 2013: DEBUG: AuthBy FILE result: ACCEPT, 
Sat Apr  6 08:48:36 2013: DEBUG: Access accepted for hugh Sat Apr  6 08:48:36 
2013: DEBUG: Packet dump:
*** Sending to 127.0.0.1 port 60920 ....
Code:       Access-Accept
Identifier: 171
Authentic:  `<155><231>rR<0><239>+<168><130><12><147><22><217><4><148>
Attributes:
        Reply-Message = "hello, world"

OK


This is how you can cause multiple DEFAULT entries in the users file to be 
processed.

regards

Hugh


On 6 Apr 2013, at 07:17, Garry Shtern <[email protected]> wrote:

> Hi Hugh,
> 
> I am not quite clear on how this would help me.  Fall-Through controls 
> whether we will continue looking even after a REJECT. That's not what I want. 
>  I am looking to augment AuthBy FILE to match against the groups that we 
> retrieved in AuthBy LDAP2.  I want to return as soon as the first Group= is 
> matched and reject if none are matched...
> 
> Thanks,
> 
> -----Original Message-----
> From: Hugh Irvine [mailto:[email protected]]
> Sent: Friday, April 05, 2013 3:30 AM
> To: Garry Shtern
> Cc: 'Heikki Vatiainen'; [email protected]
> Subject: Re: [RADIATOR] Ideas on group and reply attribs parsing
> 
> 
> Hi Garry -
> 
> You probably want "Fall-Through" in your first set of DEFAULT entries.
> 
> See the following section in "doc/ref.pdf":
> 
> 
> 13.2.7 Fall-Through
> 
> This attribute is not actually returned to the NAS. Its presence causes 
> Radiator to continue looking for a match with the next DEFAULT user name.
> 
>        Fall-Through = yes
> 
> 
> regards
> 
> Hugh
> 
> 
> On 5 Apr 2013, at 08:04, Garry Shtern <[email protected]> wrote:
> 
>> I actually did.  It's similar to what I want to do, with the exception of 
>> the fact that I want to store the group to reply mappings in local files, 
>> rather than SQL server. 
>> 
>> I am thinking of using a hook to create a "userIsInGroup" function local to 
>> AuthBy FILE.  What do you think?
>> 
>> -----Original Message-----
>> From: [email protected]
>> [mailto:[email protected]] On Behalf Of Heikki Vatiainen
>> Sent: Thursday, April 04, 2013 4:47 PM
>> To: [email protected]
>> Subject: Re: [RADIATOR] Ideas on group and reply attribs parsing
>> 
>> On 04/04/2013 11:24 PM, Garry Shtern wrote:
>> 
>>> Thanks for the pointer.  What I want to accomplish (forgetting about 
>>> the actual code), it define all of my users in a single file.  And 
>>> in the same file to be able to distinguish which reply attributes 
>>> are returned based on the RADIUS client.
>> 
>> It's getting a bit late here, so I'll now just ask if you have noticed 
>> goodies/lookupauthgroup.pl? It uses SQL, but could still be useful as 
>> another pointer.
>> 
>> Thanks,
>> Heikki
>> 
>> --
>> Heikki Vatiainen <[email protected]>
>> 
>> Radiator: the most portable, flexible and configurable RADIUS server 
>> anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, 
>> Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, 
>> TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, DIAMETER etc. 
>> Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc.
>> _______________________________________________
>> radiator mailing list
>> [email protected]
>> http://www.open.com.au/mailman/listinfo/radiator
>> _______________________________________________
>> radiator mailing list
>> [email protected]
>> http://www.open.com.au/mailman/listinfo/radiator
> 
> 
> --
> 
> Hugh Irvine
> [email protected]
> 
> Radiator: the most portable, flexible and configurable RADIUS server 
> anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, 
> Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, TTLS, 
> PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, DIAMETER etc. 
> Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc.
> 


--

Hugh Irvine
[email protected]

Radiator: the most portable, flexible and configurable RADIUS server anywhere. 
SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, 
TACACS+, PAM, external, Active Directory, EAP, TLS, TTLS, PEAP, TNC, WiMAX, 
RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, DIAMETER etc. 
Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc.

_______________________________________________
radiator mailing list
[email protected]
http://www.open.com.au/mailman/listinfo/radiator

Reply via email to