nanog mailing list archives
Re: The state of TACACS+
From: joseph.snyder () gmail com
Date: Mon, 29 Dec 2014 10:45:11 -0500
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 () 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 () zcorum com> wrote:Colton, Yes, that's the 'normal' way of setting it up. Basically you stillhaveto configure a root user, but that user name and password is keptlocked upand only accessed in case of catastrophic failure of the remote authentication system. An important note is to make sure that thefailsafe password can't be accessed without having several people engagedso itcan'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 com>wrote:We are able to implement TACAS+. It is my understanding this afairly oldprotocol, so are you saying there are numerous bugs that still needto befixed? 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 if the devices network connection is offline? Our goal with TACAS+ is tonot haveany 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 anyorganization wideor network wide default username or password. Is this possible? Dothedevices 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 Iapparently onlywork 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, totheextentit 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 auth shouldnotchange. Sometimes operators paste a buffer with a fair numberofcommands, not expecting a second delay between each command ---arepeated delay, may also break a pasted sequence. It is very possible for two of three auth servers to beunreachable,incase of a network break, but that isn't necessary. The"responsetimeout" might be 5 seconds, but in reality, there are caseswhereyouwould wait longer, and that is tragic, since there are someobviousalternative approaches that would have had results that would bemore'friendly' to the interactive user. (Like remembering which server is working for a while, orrememberingthat all servers are down -- for a while, and having a 50mstimeout,with all servers queried in parallel, instead of a 5 secondstimeout)I think this needs to be part of the specification. I'm sure the reason they didn't do parallel queries was because ofbothnetwork and CPU load back when the protocol was drafted. But itmightbegood to have local caching of authentication so that can happenevenwhenservers are down or slow. Authorization could be updated to sendthepermissions to the router for local handling. Then if the serverdieswhilea session is open only accounting would be affected. That does increase the vendors/implementors work but it might bedoableinphases and with partial support with the clients and serversnegotiatingwhat is possible. The biggest drawback to making things like thisbetteris you don't gain much except during outages and if you increasecomplexitytoo much you make it wide open for bugs. Maybe there is a simpler solution that keeps you happy aboutredundancybut doesn't increase complexity that much (possibly anycasttacacs, butthesession basis of the protocol has always made that not feasible).It'spossible that one of the L4 protocols Saku Ytti mentioned, QUIC orMinimaLTwould address these problems too. It's possible that if we didthetransport with BEEP it would also provide this, but I'm readingthe docsand I don't think it goes that far in terms of connectionassurance.-- -JHSo, here is my TACACS RFC christmas list: 1. underlying crypto 2. ssh host key authentication - having the router ask tacacs foranauthorized_keys list for rdrake. I'm willing to let this gobecausemanyvendors are finding ways to do key distribution, but I'd stilllike tohavea standard (https://code.google.com/p/openssh-lpk/ for how to dothisover 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.
Current thread:
- Re: The state of TACACS+ Robert Drake (Dec 28)
- Re: The state of TACACS+ Christopher Morrow (Dec 28)
- Re: The state of TACACS+ Jimmy Hess (Dec 28)
- Re: The state of TACACS+ Randy Bush (Dec 28)
- Re: The state of TACACS+ Robert Drake (Dec 29)
- Re: The state of TACACS+ Jimmy Hess (Dec 28)
- Re: The state of TACACS+ Colton Conor (Dec 29)
- Re: The state of TACACS+ Scott Helms (Dec 29)
- Re: The state of TACACS+ Colton Conor (Dec 29)
- 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)
- Re: The state of TACACS+ Scott Helms (Dec 29)
- Re: The state of TACACS+ Christopher Morrow (Dec 28)
- <Possible follow-ups>
- RE: The state of TACACS+ emille (Dec 29)
- Re: The state of TACACS+ Clay Curtis (Dec 31)