[RADIATOR] Ideas on group and reply attribs parsing

[Garry Shtern]

Hi Heikki,

That's an excellent idea!  In my case the SQLite DB doesn't even need to be writable by the radiator user.  I put my users and clients into that database, and created custom SQL queries and everything works perfectly.

Thanks a lot!

-----Original Message-----
From: radiator-bounces at open.com.au [mailto:radiator-bounces at open.com.au] On Behalf Of Heikki Vatiainen
Sent: Friday, April 05, 2013 4:53 PM
To: radiator at open.com.au
Subject: Re: [RADIATOR] Ideas on group and reply attribs parsing

On 04/05/2013 11:17 PM, Garry Shtern wrote:

> 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...

How about this approach: Create a SQLite DB from the information and use AuthBy SQL instead.

I have a couple of cases where information is kept in an frequently read but less infrequently (e.g., twice per hour) SQLite DB. Works very well.

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