[RADIATOR] Ideas on group and reply attribs parsing

Garry Shtern Garry.Shtern at twosigma.com
Sat Apr 6 07:56:46 CDT 2013 

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:hugh at open.com.au] 
Sent: Friday, April 05, 2013 5:55 PM
To: Garry Shtern
Cc: 'Heikki Vatiainen'; radiator at open.com.au
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 <Garry.Shtern at twosigma.com> 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:hugh at open.com.au]
> Sent: Friday, April 05, 2013 3:30 AM
> To: Garry Shtern
> Cc: 'Heikki Vatiainen'; radiator at open.com.au
> 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 <Garry.Shtern at twosigma.com> 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: radiator-bounces at open.com.au
>> [mailto:radiator-bounces at open.com.au] On Behalf Of Heikki Vatiainen
>> Sent: Thursday, April 04, 2013 4:47 PM
>> To: radiator at open.com.au
>> 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 <hvn at open.com.au>
>> 
>> 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
>> radiator at open.com.au
>> http://www.open.com.au/mailman/listinfo/radiator
>> _______________________________________________
>> radiator mailing list
>> radiator at open.com.au
>> http://www.open.com.au/mailman/listinfo/radiator
> 
> 
> --
> 
> Hugh Irvine
> hugh at open.com.au
> 
> 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
hugh at open.com.au

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.

More information about the radiator mailing list