[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