TACACS Setup Across Multiple Networks

[bchristianson21]

I work for a company that provides IT Network Services to a number of small businesses. We have roughly 30 sites that we support, all of which are on their own separate networks, which internally, have similar IP schemes (10.x.x.x). It's a constant struggle to log into network devices (via TeamViewer) on a daily basis with local passwords to memorize. I'm looking into implementing TACACS, having it hosted here at our office and pointing all of our devices to it. My question is, with a lot of our networks devices having the same remote management IP's, is TACACS able to differentiate one authentication request from the next? Can it be done via DNS hostname? Here is an example of the question I have:

Site-A-SW1 (10.10.10.1) ---> TACACS Authentication Request 

                                                                                                        >>>> My Office TACACS Server (Public IP)

Site-B-SW1 (10.10.10.1) ---> TACACS Authentication Request

Can the TACACS server differentiate between the two?

I was wondering if anyone is familiar with this kind of setup, and if so, clue me into how I could go about implementing something like this?

Thanks in advance,

Brian

[Philip D'Ath]

Forget TACACS.  You will be buying into a nightmare.

Let me tell you what we do.

We use [free] ubuntu SSH proxies.  You need one at each customer site, and a tcp/22 NAT port forward to it.  We typically get customers to deploy this in a virtual infrastructure (needs 1 CPU 1 core, 1GB of RAM and 8GB of disk).  If the customers don't have that then use a Raspberry Pi.

Now go buy yourself SecureCRT.  An excellent terminal program.

Create a folder for each client.  In each folder create an SSH connection to the Ubuntu instance.  Now create a connection to the actual device you want to access (this can be telnet or ssh), and tell it to connect via the SSH Ubuntu session.

We actually have a team of engineers, so we use the SecureCRT option to host its config on a network share (which you then offline), so every engineer has the same view of all the customer devices.

The first time to log into the remote customer device via SSH it will ask you for the username and password, and you can tick the box to save the details.  If you are logging in with telnet you need to tell it to script the login.  Do this.  It is worth the 2 minutes of effort to save you having to look up the username and password everytime.

Now you can have a unique username/password for every customer/device, but you don't have to look it up each time.  You can just jump in directly.

We actually use a more complex configuration, using digital certificates, and we also have the Ubuntu boxes log every ssh session so we have a strong audit trail.  We also have the Ubuntu instances configured with tftp and http, so we can copy an image to the local instance on site, and then deploy it onto devices over their LAN.  If you use a Raspberry Pi, you can also plug in USB to Serial leads directly into the console ports, which lets you get to the devices out of band.

We also use Git for config revision control.  This lets engineers check in the changes they make to every customer device, with a change history.  You can then inspect every change to the device, who made it, what it looked like before, etc.

And as a bonus - Git can store and access its repository via - you guessed it - ssh on a Linux server.

We do some other tricky stuff as well, but you need to get the basic framework in place first.

[Jason Kopacko]

Buying into a nightmare? You're joking, right? Please tell me you're joking.

Brian,

ACS gives you tons of flexibility and accountability. But, it won't matter what you use, because routing alone will kill the reply.

You will need to NAT the non-local devices to unique IPs and then it will work.

[nspasov]

HI Brian, this will not work as IPs will need to be unique.

Thank you for rating helpful posts!