[tac_plus] Questions about a simple setup.

Daniel Schmidt daniel.schmidt at wyo.gov
Fri Jan 27 02:35:35 UTC 2012


Can if you want.  Easy way to make it so users can change their password.
default authentication = file /etc/passwd

Doesn't work for enable though - that has to go under the user.  Took a
crack at it once, failed.  No good at C. Have to define it per user:

enable = file /etc/passwd

-----Original Message-----
From: tac_plus-bounces at shrubbery.net
[mailto:tac_plus-bounces at shrubbery.net] On Behalf Of Hayden
Katzenellenbogen
Sent: Thursday, January 26, 2012 3:12 PM
To: Alan McKinnon; tac_plus at shrubbery.net
Subject: Re: [tac_plus] Questions about a simple setup.

Alan,

Thanks for the update. It's funny I ran into all those non-root issues and
eventually used worked my way through them.

I have the log files owned corrected and then log rotate restarted the
daemon after it moves all the logs and sets user/group/permissions.

If you are running as root now. Do you just authenticate off the Unix
passwd file?

Hayden

-----Original Message-----
From: tac_plus-bounces at shrubbery.net
[mailto:tac_plus-bounces at shrubbery.net] On Behalf Of Alan McKinnon
Sent: Thursday, January 26, 2012 1:45 PM
To: tac_plus at shrubbery.net
Subject: Re: [tac_plus] Questions about a simple setup.

On Thu, 26 Jan 2012 13:27:30 -0800
"Hayden Katzenellenbogen" <hayden at nextlevelinternet.com> wrote:

> I have a couple hundred devices that are managed by a support team.
> They have full access to these devices so I will not need
> authorization. (In the future I might).
>
> If all that I need to do is manage passwords in a central location
> using tac_plus. Is the config as simple as having  a user for each
> team member and an enable password.  And a tac-key.
>
> The remote devices then only need authorization commands and the rest
> can be blank.
>
> Next as far as simple security.
>
> * I will have the two tac_plus servers behind a firewall only allowing
> port 49.
> * I am running as a non-root user.
> * The configs are not viewable by anyone by root/tacacs user.
> * Passwords are des encrypted with a salt.
>
> For now I want to keep this as simple as possible.
>
> Thanks to everyone who responds.

Yup, that's pretty much right, you understand it well.

Just one thing about password hashes - you don't need to stick to DES (and
shouldn't). tac_plus couldn't care less about your password hashes, it
completely depends on what your local libc supports. On Linux, that's
usually all common hashes. I have tac_plus servers happily working with a
mixture of DES, md5 and SHA hashes.

I tried running tac_plus as a non-root user. It doesn't work too well -
the daemon does the wrong thing if the log files do not already exist.
The daemon starts as root to open port 49 for listening, creates the log
files (owned by root of course) then drops privs to the tacacs user. At
which point the daemon can no longer write to it's own log files and comes
to a screeching halt. Silently. That one is hard to debug. You gett he
same thing with logrotate if you are not careful.
Eventually I just got fed up and recompiled removing the "run as tacacs
user" option.

The simplest possible way to authorize everything is to create one group
with a single directive "permit .*" and assign every user membership to
that group.

However, you might want to rethink who can run AAA commands. Letting
anyone do that just undoes all the hard work you went through to get the
goodness of tacacs :-)


--
Alan McKinnnon
alan.mckinnon at gmail.com

_______________________________________________
tac_plus mailing list
tac_plus at shrubbery.net
http://www.shrubbery.net/mailman/listinfo.cgi/tac_plus
_______________________________________________
tac_plus mailing list
tac_plus at shrubbery.net
http://www.shrubbery.net/mailman/listinfo.cgi/tac_plus
E-Mail to and from me, in connection with the transaction 
of public business,is subject to the Wyoming Public Records 
Act, and may be disclosed to third parties.



More information about the tac_plus mailing list