Far too much discussion on this IMO. If you're that paranoid about it, just use the nuclear launch keys approach. Create the local account password, split it, give half of it to one party, half to the other. Then two separate parties must be engaged to use the account. Done.
Sincerely, Clay Curtis ------------------------------------------------------------------------------------ Glad to know you can make local access only work if TACAS+ isn't available. However, that still doesn't prevent the employee who know the local username and password to unplug the device from the network, and the use the local password to get in. Still better than our current setup of having one default username and password that everyone knows. On Mon, Dec 29, 2014 at 9:38 AM, Michael Douglas <michael.doug...@ieee.org> wrote: > In the Cisco world the AAA config is typically set up to try tacacs > first, > and local accounts second. The local account is only usable if > tacacs is > unavailable. Knowledge of the local username/password does not > equate to > full time access with that credential. Also, you would usually > filter the > incoming SSH sessions to only permit a particular management IP > range; the > local credential, or tacacs credential, shouldn't be usable from any > arbitrary network. > > On Mon, Dec 29, 2014 at 10:32 AM, Colton Conor > <colton.co...@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 <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 expecti...
