[tac_plus] Full AAA logging / supported configuration
heasley
heas at shrubbery.net
Mon Sep 12 21:01:08 UTC 2016
Mon, Sep 12, 2016 at 01:49:13PM -0700, Sean:
> Speaking of debugs, and a little off-topic, but earlier when I had `-d 256` enabled to look at the output, I noticed the passwords being transmitted and logged in clear text. I know TACACS+ itself is not encrypted, but logging the passwords in clear text via tac_plus debugs seems like a bad idea. Anyone with the necessary permissions, including other sysadmins, can see your TACACS+ password just by bouncing the daemon and restarting it with the right debug level.
tacacs can be encrypted if you configure it to be.
anyway, -d is for debugging. it can be useful to log the data as it is
received, esp for low level debugging.
> Not sure if that’s intentional or if there’s a better way to protect it other than file permissions.
>
> On 9/12/16, 1:16 PM, "heasley" <heas at shrubbery.net> wrote:
>
> Mon, Sep 12, 2016 at 01:09:57PM -0700, Sean:
> > It’s tac_plus, it’s just ancient. I believe it had something to do with MAVIS as well.
> >
> > The system(s) I’m running v4 on are using PAM instead of the MAVIS module.
> >
> > So more or less just enable the right debug levels and route to syslog, expecting to find things in auth.log, etc.? With accounting being the exception. If so, I will look into getting rsyslogd to route the data correctly.
>
> it only uses 1 facility, whichever you specify in the config. otherwise,
> yes. tacacs is fairly quiet; leaving the auth/auth-failure to the clients.
> I'd be willing to add an option for tacacs to log these itself, at least
> for authentication.
>
>
>
More information about the tac_plus
mailing list