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
