On Mon, Dec 29, 2014 at 09:32:51AM -0600, Colton Conor 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?
Yes, this is possible as you can prevent the last resort username being used by having your AAA try tacacs+ first and having a non-overlapping username so it's rejected if t+ is operational. You should use username blah secret magic vs password as well to leverage md5 vs the reversable process. > 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. You can automate the login/change with scripting leveraging the clogin tool part of rancid. If you have a proper inventory of these devices and they are in rancid, it's easy to do clogin -x /tmp/commands `cat routerlist` - Jared > On Mon, Dec 29, 2014 at 9:22 AM, Scott Helms <khe...@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.co...@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 <rdr...@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 > >> > > >> > > >> > > > > -- Jared Mauch | pgp key available via finger from ja...@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.