RE: [j-nsp] auth servers.

From: Guy Davies (Guy.Davies@telindus.co.uk)
Date: Wed Apr 03 2002 - 06:44:06 EST


 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Jeffrey,

Your description of Junipers implementation of TACACS+, while a bit
harsh, is mostly accurate. They only support the authentication
element and have no support for the authorisation and accounting
elements at all. They do not support any form of template beyond a
single "remote" user (which is kind of implicit in the fact that they
don't support authorisation levels - so what's the point ;-).

I've used RADIUS with Juniper, Cisco, Riverstone and Extreme in the
same network with no problems. With RADIUS, it is possible to define
multiple user templates (statically defined on each Juniper) and
reference them with a VSA in the response from the RADIUS server.
I've used Cistron and Merit's RADIUS servers, both of which are
reasonably easy to configure with the extra dictionary required to
support Juniper's VSAs.

I've also seen information regarding another RADIUS server (Funk
Steel-Belted RADIUS), with which I'm not familiar, on this mailing
list. I think that someone came across some issues which they
finally overcame and posted a fairly comprehensive set of details on
how to avoid the problems.

When it comes down to it, RADIUS is a standardised system whereas
TACACS+ is not. It makes sense to concentrate on the standardised
process rather than a competitors own system ;-) I don't expect much
from Juniper by way of improvements to their implementation of
TACACS+.

RADIUS provides all the mechanisms for AAA which you require so there
is no disadvantage to using it.

Hope that helps.

Regards,

Guy

> -----Original Message-----
> From: jeffrey arnold [mailto:jba@analogue.net]
> Sent: Wednesday, April 03, 2002 11:35 AM
> To: juniper-nsp@puck.nether.net
> Subject: [j-nsp] auth servers.
>
>
>
> Hello,
>
> I'm looking for insight on what people are using for centralized
> user authentication. I've been running devrim seral's great hacked
> tac+ server
> (http://www.gazi.edu.tr/tacacs/) for a while now, and while it
> works beautifully on my cisco and foundry gear, it "eats it" on
> juniper
> gear. As far as I can tell, junipers' docs for tac+ auth are
> completely
> incorrect, and their support is pretty lackluster (lack of command
> auth/acct and multiple template's being major issues). By
> conjecture, radius seems to be the answer, but without having used
> it in quite a while, I'd like some outside verification of this.
>
> SO, what are your experiences with tac+ and radius on junOS?
> If you prefer
> one over the other, why? Most importantly, what packages are
> you using for
> your radius/tac+ servers? If i must migrate to radius, i'd
> prefer to stay
> with something open-sourceish, but if i need to shell out a
> few bucks, i
> would be willing to do so in order to gain clean clustering and a
> distributed maintenance model.. any hints? (radiator?)
>
> My main need for this is to have a centralized way to separate out
> the engineers from the help desk, and allow services such as
> rancid or asset
> management tools to grab data from an unprivileged account.
>
> Any help would be much appreciated.
>
> cheers,
> -jba
> --
> [jba@analogue.net] :: analogue.networks.nyc :: http://analogue.net
>
>

-----BEGIN PGP SIGNATURE-----
Version: PGP 7.0.1

iQA/AwUBPKrqi43dwu/Ss2PCEQJeUwCdH1Mr3ml9casq+UkG5FKmc6wYCoUAniDB
WjJSms8WnSLtS6ZUVAwbXqBd
=EMFx
-----END PGP SIGNATURE-----

This e-mail is private and may be confidential and is for the intended
recipient only. If misdirected, please notify us by telephone and confirm
that it has been deleted from your system and any copies destroyed. If you
are not the intended recipient you are strictly prohibited from using,
printing, copying, distributing or disseminating this e-mail or any
information contained in it. We use reasonable endeavors to virus scan all
e-mails leaving the Company but no warranty is given that this e-mail and
any attachments are virus free. You should undertake your own virus
checking. The right to monitor e-mail communications through our network is
reserved by us.



This archive was generated by hypermail 2b29 : Mon Aug 05 2002 - 10:42:40 EDT