[c-nsp] TACACS "emergency" password management

[Keegan Holley]

On Mon, Nov 1, 2010 at 5:03 PM, Phil Mayers <p.mayers at imperial.ac.uk> wrote:

> On 11/01/2010 08:02 PM, Keegan Holley wrote:
>
>> What do you mean by hierarchy?  Most of the companies I've seen have a
>> single level of access and just use tacacs as a way to grant or revoke
>> access to everything at once.  The biggest problem with local passwords
>>
>
> Interesting. I was under the impression that a common use-case for TACACS
> was command authorization; letting "2nd line" engineers do things like
> provision new gig ports, but needing a "3rd line" engineer to change IP
> routing etc.


Oh not at all.  That's one of things that's available but no one remembers
or needs.  The most common use case for TACACS is centralized authentication
and sometimes accounting.  It usually ends up tied to a database such as
active directory or LDAP as well so that all of the engineers accounts can
be managed from the same place.  I have seen complex deployments like that.
 For example the linux jump servers and routers (via TACACS) all
authenticated to AD.  Then the AD administrators would grant and revoke
rights simply by moving user accounts into preconfigured OU"s in active
directory.

>
>
>  is that they almost never change.  So anyone that can convince someone
>> to give them a password or has worked at the company in the past can
>> login to equipment provided they can gain access to the correct resources.
>>
>
> Shrug. We change passwords & SNMP communities pretty frequently.
>

Interesting.  To each his own I suppose.  Do you configure local accounts or
is it just the single vty password?  One of the other things TACACS buys you
is auditing and tying individual engineers to specific changes.

>
> We certainly don't have hundreds of routers, and I'm not advocating this
> method for huge networks or those with large teams / high turnover, but it
> works well for us.


Even better.  I've seen small networks use the freeware TACACS daemon just
for the centralized auth.  It honestly comes in pretty handy.  Depending on
how it's configured and the size of your network you should probably have a
redundant server or two.  I've even seen people regionalize this where there
were a couple of servers for each region.  Compute is cheap these days.

>
>
>
>> Then there's policy enforcement.  For example how do you prevent an
>> engineer from accidentally deploying a router with "cisco" as the
>> password or without any password at all.  Or a password with too few
>> characters... etc.
>>
>
> Templated configs.
>

What if someone decides to change the pw after the template has been rolled
out?  I assume this is scripted as well or there is also danger of mistyping
something or adding an extra space into the pw when pasting it in.

>
> If occurs to me that if one is archiving "fallback" passwords into some
> kind of database, it should be pretty trivial to do an SHA of the plaintext
> and compare that to the value on the router. Any differences == bad.
> Obviously that would work just as well for "merely" local passwords.
>

True.  You could also use the same mechanism in reverse to store the
passwords locally.  I think this is even built into openssl.