(RADIATOR) Patch against 3.13 to support per-client TACACS+ keys

[Mike McCauley]

Hello James,

thanks for your contribution. We really appreciate it when people send 
patches.
We have applied the patch but made some changes for performance and to be 
compatible with IPV6 addresses.

The patches are now in the latest patch set, if you would like to verify it 
still works for you?

Thanks again for contribution.

Cheers.

On Friday 14 October 2005 22:58, James FitzGibbon wrote:
> Hi Mike.
>
> Attached is the updated patch.  I changed from using 'Secret' to
> 'TACACSPLUSKey'.  I've tested this using global and per-client TACACS+ keys
> and RADIUS secrets, and nothing seems to have broken.  There are however a
> few things to consider in the patch:
>
> - the log warning for a client that has no 'Secret' had to be changed to to
> check that they have neither 'Secret' nor 'TACACSPLUSKey'.  Unfortunately,
> this means that if such a client feeds us a RADIUS request at runtime, we
> have to issue a warning.  There are several places where the warning could
> go in - I decided to do it in the block that already handles bad RADIUS
> authenticators by issuing a different warning message in the log when the
> secret is undefined.
>
> - does a failed request due to a missing secret count as a 'badAuthRequest'
> for statistics counting?  Right now I presume that it's just a
> 'droppedRequest' (this is in the same block as the last point)
>
> - My philosophy is to punish the user early for configuration mistakes
> rather than emit potentially vague errors at runtime.  Is there any way to
> tell during Radius::Client contruction whether there is a a
> <ServerTACACSPLUS> block defined?  I suspect that there is not because you
> can't guarantee the order in which objects will be constructed.  If I could
> tell if there was such a block defined during Radius::Client contruction,
> the first point above becomes a bit easier: if there is a <Server> block,
> clients must have a Secret defined; if there is a <ServerTACACSPLUS> block,
> clients must have a TACACSPLUSKey defined, etc.
>
> - Is there a hook that can perform post-configuration-pre-runtime checks on
> the configuration as a whole?  That might do the trick, but again it hinges
> on being able to tell if there are any Radius::ServerTACACSPLUS objects in
> existence.  I can't find any easy way to do that, save for adding a package
> global like $Radius::ServerTACACSPLUS::at_least_one_server_enabled, or a
> class method to provide the same type of info.  Not a very pretty solution,
> and it would be a one-off.  I guess what I'm really looking for is a
> server-wide config object registry where you can say "how many
> Radius::Client objects have been contructed?  How many
> Radius::ServerTACACSPLUS objects have been constructed?  etc."
>
> Also, where should documentation changes be made?  I don't want to send a
> patch to the HTML if the master copy is some other file or format that
> doesn't come with the tarball.
>
> Thanks
>
> -----Original Message-----
> From: owner-radiator at open.com.au [mailto:owner-radiator at open.com.au] On
> Behalf Of Mike McCauley
> Sent: Saturday, October 08, 2005 9:48 PM
> To: James FitzGibbon
> Cc: radiator at open.com.au
> Subject: Re: (RADIATOR) Patch against 3.13 to support per-client TACACS+
> keys
>
> Hello James,
>
> On Sunday 09 October 2005 10:20, James FitzGibbon wrote:
> > On 8-Oct-05, at 3:20 AM, Mike McCauley wrote:
> > > This looks useful and interesting (and backwards compatible!)
> > > I think the only thing I would suggest is that the client-specific
> > > tacacs key
> > > be kept in a different parameter than Secret, say in TacacsKey.
> > > Otherwise you
> > > could not have a Tacacs and Radius client on the same box unless
> > > they had the
> > > same secret/key. What do you think?
> >
> > Good point; I hadn't figured on that, but that's what you get for
> > designing for your own network instead of the general case.
> >
> > I'll make that change and re-submit.  It will be a bit bigger since
> > I'm guessing I'll have to modify Radius/Client.pm as well to allow
> > the new key...
>
> No problem.
> If you will use a unified diff (diff -u) and send it as an attachment, it
> will
> really help.
>
> Cheers.
>
> > Thanks
> >
> > --
> > j.
>
> --
> Mike McCauley                               mikem at open.com.au
> Open System Consultants Pty. Ltd            Unix, Perl, Motif, C++, WWW
> 9 Bulbul Place Currumbin Waters QLD 4223 Australia   http://www.open.com.au
> Phone +61 7 5598-7474                       Fax   +61 7 5598-7070
>
> 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 etc on Unix, Windows, MacOS etc.
>
> --
> Archive at http://www.open.com.au/archives/radiator/
> Announcements on radiator-announce at open.com.au
> To unsubscribe, email 'majordomo at open.com.au' with
> 'unsubscribe radiator' in the body of the message.
>
> --
> No virus found in this incoming message.
> Checked by AVG Anti-Virus.
> Version: 7.0.344 / Virus Database: 267.11.14/129 - Release Date: 10/11/2005
>
>
> --
> No virus found in this outgoing message.
> Checked by AVG Anti-Virus.
> Version: 7.0.344 / Virus Database: 267.11.14/131 - Release Date: 10/12/2005

-- 
Mike McCauley                               mikem at open.com.au
Open System Consultants Pty. Ltd            Unix, Perl, Motif, C++, WWW
9 Bulbul Place Currumbin Waters QLD 4223 Australia   http://www.open.com.au
Phone +61 7 5598-7474                       Fax   +61 7 5598-7070

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 etc on Unix, Windows, MacOS etc.

--
Archive at http://www.open.com.au/archives/radiator/
Announcements on radiator-announce at open.com.au
To unsubscribe, email 'majordomo at open.com.au' with
'unsubscribe radiator' in the body of the message.