nanog mailing list archives
Re: The state of TACACS+
From: Clay Curtis <clay584 () gmail com>
Date: Tue, 30 Dec 2014 22:39:39 -0500
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.Douglas () 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.conor () gmail com> wrote:Scott, Thanks for the response. How do you make sure the failsafe and/orrootpassword that is stored in the device incase remote auth failscan't beaccessed without having several employees engaged? Are there anymechanismsfor doing so? My fear would be we would hire an outsourced tech. After a certainamountof time we would have to let this part timer go, and would disabledhis orher username and password in TACAS. However, if that tech stillknows theroot password they could still remotely login to our network andcausehavoc. The thought of having to change the root password onhundreds ofdevices doesn't sound appealing either every time an employee islet go. Tomake 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 () zcorum com>wrote:Colton, Yes, that's the 'normal' way of setting it up. Basically youstill haveto configure a root user, but that user name and password is keptlockedupand only accessed in case of catastrophic failure of the remote authentication system. An important note is to make sure thatthe failsafe password can't be accessed without having several peopleengaged soitcan'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 () gmail comwrote:We are able to implement TACAS+. It is my understanding this afairlyoldprotocol, so are you saying there are numerous bugs that stillneed tobefixed? A question I have is TACAS+ is usually hosted on a server, andnetworkingdevices are configured to reach out to the server forauthentication. Myquestion is what happens if the device can't reach the server ifthedevices network connection is offline? Our goal with TACAS+ isto nothaveany default/saved passwords. Every employee will have their ownusernameand password. That way if an employee gets hired/fired, we canenable ordisable their account. We are trying to avoid having anyorganizationwideor network wide default username or password. Is this possible?Do thedevices keep of log of the last successful username/passwordcombinationsthat worked incase the device goes offline? On Sun, Dec 28, 2014 at 5:02 PM, Robert Drake<rdrake () direcpath com>wrote:Picking back up where this left off last year, because Iapparentlyonlywork 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 theextentit would be intolerable; shell commands should run almost instantaneously.... this is not a GUI, with an hourglass.Real-timeresponsiveness in a shell is crucial --- which remote authshould notchange. Sometimes operators paste a buffer with a fairnumber ofcommands, not expecti...
Current thread:
- Re: The state of TACACS+, (continued)
- Re: The state of TACACS+ joseph . snyder (Dec 29)
- Re: The state of TACACS+ Jared Mauch (Dec 29)
- Re: The state of TACACS+ Scott Helms (Dec 29)
- Re: The state of TACACS+ Robert Drake (Dec 29)
- Re: The state of TACACS+ Berry Mobley (Dec 29)
- Re: The state of TACACS+ Michael Douglas (Dec 29)
- Re: The state of TACACS+ Colton Conor (Dec 29)
- Re: The state of TACACS+ Michael Douglas (Dec 29)
- Re: The state of TACACS+ Tim Raphael (Dec 29)