The state of TACACS+

Mon Dec 29 15:45:11 UTC 2014

Change the root when any senior person leaves.  It shouldn't be known to a large set of staff members.  During the bubble burst rifs we were changing them on 40k+ devices every week.  Make sure you verify the pass before disconnecting the login acct making the change.  Also make sure you understand the AAA process well when trying to do this so that you don't lock yourself out.

On December 29, 2014 10:32:51 AM EST, Colton Conor <colton.conor at gmail.com> wrote:
>Scott,
>
>Thanks for the response. How do you make sure the failsafe and/or root
>password that is stored in the device incase remote auth fails can't be
>accessed without having several employees engaged? Are there any
>mechanisms
>for doing so?
>
>My fear would be we would hire an outsourced tech. After a certain
>amount
>of time we would have to let this part timer go, and would disabled his
>or
>her username and password in TACAS. However, if that tech still knows
>the
>root password they could still remotely login to our network and cause
>havoc. The thought of having to change the root password on hundreds of
>devices doesn't sound appealing either every time an employee is let
>go. To
>make matters worse we are using an outsourced firm for some network
>management, so the case of hiring and firing is fairly consistent.
>
>On Mon, Dec 29, 2014 at 9:22 AM, Scott Helms <khelms at zcorum.com> wrote:
>
>> Colton,
>>
>> Yes, that's the 'normal' way of setting it up.  Basically you still
>have
>> to configure a root user, but that user name and password is kept
>locked up
>> and only accessed in case of catastrophic failure of the remote
>> authentication system.  An important note is to make sure that the
>fail
>> safe password can't be accessed without having several people engaged
>so it
>> can't be used without many people knowing.
>>
>>
>> Scott Helms
>> Vice President of Technology
>> ZCorum
>> (678) 507-5000
>> --------------------------------
>> http://twitter.com/kscotthelms
>> --------------------------------
>>
>> On Mon, Dec 29, 2014 at 10:15 AM, Colton Conor
><colton.conor at gmail.com>
>> wrote:
>>
>>> We are able to implement TACAS+. It is my understanding this a
>fairly old
>>> protocol, so are you saying there are numerous bugs that still need
>to be
>>> fixed?
>>>
>>> A question I have is TACAS+ is usually hosted on a server, and
>networking
>>> devices are configured to reach out to the server for
>authentication. My
>>> question is what happens if the device can't reach the server if the
>>> devices network connection is offline? Our goal with TACAS+ is to
>not have
>>> any default/saved passwords. Every employee will have their own
>username
>>> and password. That way if an employee gets hired/fired, we can
>enable or
>>> disable their account. We are trying to avoid having any
>organization wide
>>> or network wide default username or password. Is this possible? Do
>the
>>> devices keep of log of the last successful username/password
>combinations
>>> that worked incase the device goes offline?
>>>
>>> On Sun, Dec 28, 2014 at 5:02 PM, Robert Drake <rdrake at direcpath.com>
>>> wrote:
>>>
>>> > Picking back up where this left off last year, because I
>apparently only
>>> > work on TACACS during the holidays :)
>>> >
>>> >
>>> > On 12/30/2013 7:28 PM, Jimmy Hess wrote:
>>> >
>>> >> Even 5 seconds extra for each command may hinder operators, to
>the
>>> extent
>>> >> it would be intolerable;     shell commands should run almost
>>> >> instantaneously....  this is not a GUI, with an hourglass.  
>Real-time
>>> >> responsiveness in a shell is crucial --- which remote auth should
>not
>>> >> change.   Sometimes operators paste a  buffer with a fair number
>of
>>> >> commands,  not expecting a second delay between each command --- 
>a
>>> >> repeated delay, may also break a pasted sequence.
>>> >>
>>> >> It is very possible for two of three auth servers to be
>unreachable,
>>> in
>>> >> case of a network break, but that isn't necessary.      The
>"response
>>> >> timeout"  might be 5 seconds,  but in reality, there are cases
>where
>>> you
>>> >> would wait  longer,  and that is tragic,   since there are some
>obvious
>>> >> alternative approaches that would have had results  that would be
>more
>>> >> 'friendly'  to the interactive user.
>>> >>
>>> >> (Like remembering which server is working for a while,   or
>remembering
>>> >> that all servers are down -- for a while,  and having a  50ms 
>timeout,
>>> >>   with all servers queried in parallel,  instead of a 5 seconds
>>> timeout)
>>> >>
>>> > I think this needs to be part of the specification.
>>> >
>>> > I'm sure the reason they didn't do parallel queries was because of
>both
>>> > network and CPU load back when the protocol was drafted.  But it
>might
>>> be
>>> > good to have local caching of authentication so that can happen
>even
>>> when
>>> > servers are down or slow.  Authorization could be updated to send
>the
>>> > permissions to the router for local handling. Then if the server
>dies
>>> while
>>> > a session is open only accounting would be affected.
>>> >
>>> > That does increase the vendors/implementors work but it might be
>doable
>>> in
>>> > phases and with partial support with the clients and servers
>negotiating
>>> > what is possible.  The biggest drawback to making things like this
>>> better
>>> > is you don't gain much except during outages and if you increase
>>> complexity
>>> > too much you make it wide open for bugs.
>>> >
>>> > Maybe there is a simpler solution that keeps you happy about
>redundancy
>>> > but doesn't increase complexity that much (possibly anycast
>tacacs, but
>>> the
>>> > session basis of the protocol has always made that not feasible). 
>It's
>>> > possible that one of the L4 protocols Saku Ytti mentioned, QUIC or
>>> MinimaLT
>>> > would address these problems too.  It's possible that if we did
>the
>>> > transport with BEEP it would also provide this, but I'm reading
>the docs
>>> > and I don't think it goes that far in terms of connection
>assurance.
>>> >
>>> >> --
>>> >> -JH
>>> >>
>>> >>
>>> > So, here is my TACACS RFC christmas list:
>>> >
>>> > 1.  underlying crypto
>>> > 2.  ssh host key authentication - having the router ask tacacs for
>an
>>> > authorized_keys list for rdrake.  I'm willing to let this go
>because
>>> many
>>> > vendors are finding ways to do key distribution, but I'd still
>like to
>>> have
>>> > a standard (https://code.google.com/p/openssh-lpk/ for how to do
>this
>>> > over LDAP in UNIX)
>>> > 3.  authentication and authorization caching and/or something else
>>> >
>>> >
>>>
>>
>>

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.