(RADIATOR) Patch against 3.13 to support per-client TACACS+ keys
James FitzGibbon
jfitzgibbon at primustel.ca
Wed Oct 19 09:57:09 CDT 2005
My test suite is admittedly simplistic (RADIUS tests using default
client/specific client secrets and TACACS+ tests using global/default
client/specific client keys), but everything that was working with my trunk
copy is still working with 3.13 + the latest patch set.
Thanks
-----Original Message-----
From: owner-radiator at open.com.au [mailto:owner-radiator at open.com.au] On
Behalf Of Mike McCauley
Sent: Tuesday, October 18, 2005 7:47 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,
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.
--
No virus found in this incoming message.
Checked by AVG Anti-Virus.
Version: 7.0.344 / Virus Database: 267.12.2/139 - Release Date: 10/17/2005
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.344 / Virus Database: 267.12.2/139 - Release Date: 10/17/2005
--
----------------------------------------------------------------------------
This electronic message contains information from Primus Telecommunications
Canada Inc. ("PRIMUS") , which may be legally privileged and confidential.
The information is intended to be for the use of the individual(s) or entity
named above. If you are not the intended recipient, be aware that any
disclosure, copying, distribution or use of the contents of this information
is prohibited. If you have received this electronic message in error, please
notify us by telephone or e-mail (to the number or address above)
immediately. Any views, opinions or advice expressed in this electronic
message are not necessarily the views, opinions or advice of PRIMUS.
It is the responsibility of the recipient to ensure that
any attachments are virus free and PRIMUS bears no responsibility
for any loss or damage arising in any way from the use
thereof.The term "PRIMUS" includes its affiliates.
----------------------------------------------------------------------------
Pour la version en français de ce message, veuillez voir
http://www.primustel.ca/fr/legal/cs.htm
----------------------------------------------------------------------------
--
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.
More information about the radiator
mailing list