[RADIATOR] Ideas on group and reply attribs parsing

Hugh Irvine hugh at open.com.au
Fri Apr 5 16:54:46 CDT 2013 

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