We all have our preference over AAA protocols. The most popular being RADIUS, with TACACS+ having a following only due to historical momentum of the company using it. DIAMETER is slowly coming to the market due to it’s more ‘enhanced’ capabilities, but it’s hard to change from “what works”. And TACACS+, my friends, just works. I won’t go into detail on why I love that protocol, but instead, tell you about what I learned today.
Why move away from tac_plus?
For years, I’ve been using the tac_plus daemon to do all of my AAA (Authentication/Authorization/Accounting) needs. It’s free, it’s solid, and there is little to “foul up”. It runs on Unix/Linux which is a solid OS, and all of it is free. No licensing needed for anything. In today’s “vendor license cornucopia”, that’s a blessing! But, I’ve decided to move my AAA from tac_plus to HP’s Intelligent Management Center’s TAM (Tacacs Authentication Manager). Why? Well, a couple of reasons:
For one, it allows me to build authentication against my existing AD accounts. I no longer have to have separate account/passwords for my device security. Secondly, it provides better granularity than tac_plus (or, if not, it looks more granular due to easier configuration). And third, and probably the most important, it gives me decent human-readable logs to see ‘who’s doing what and where’. It can be better, but it’s not bad. It also gives me a one-stop-show for all my network management needs, since I’m already using IMC for many other NMS services.
The largest difference between tac_plus and TAM is that tac_plus allows you to access all IP’s on a device (unless specifically told not to). TAM, however, only allows you to access the interface that IMC uses for management. Maybe it’s a loopback, maybe it’s a L3 interface, but regardless of what it is, TAM will fail if the device IP requesting access does not match the management IP that IMC uses.
What Do You Mean?
Ok. Let’s setup an example. I have one fresh, because this happened to me today. I have a Cisco 4510 switch where one of the VLAN’s IP is 192.168.2.1. This is the IP Address that Intelligent Management Center is using to poll and monitor, and consequently, the deemed “management address”. [Tangent] No, it’s not the loopback. When I added the device many many moons ago, I didn’t check the “use loopback for management”. That’s another discussion. If I change the address now, I lose all my history of the device. [/Tangent]
Now, I setup the configurations in TAM for this device. Pretty basic configuration. You basically create your policies, then bind the policy to the device/user. But, when I change AAA on the Cisco switch to go to TAM, all my logins fail (well, I get my local backup authentication). Bad configuration? Nope. After running some debugs on the Cisco switch, I get the cryptic:
004732: *Jan 29 07:57:28.514 EST: TAC+: Using default tacacs server-group "tacacs+" list. 004733: *Jan 29 07:57:28.514 EST: TAC+: Opening TCP/IP to 10.1.1.1/49 timeout=5 004734: *Jan 29 07:57:28.518 EST: TAC+: Opened TCP/IP handle 0x17FBDE10 to 10.1.1.1/49 004735: *Jan 29 07:57:28.518 EST: TAC+: 10.1.1.1 (1715735864) AUTHOR/START queued 004736: *Jan 29 07:57:28.718 EST: TAC+: (1715735864) AUTHOR/START processed 004737: *Jan 29 07:57:28.718 EST: TAC+: received bad AUTHOR packet: type = 0, expected 2 004738: *Jan 29 07:57:28.718 EST: TAC+: Invalid AUTHOR/START packet (check keys). 004739: *Jan 29 07:57:28.718 EST: TAC+: Closing TCP/IP 0x17FBDE10 connection to 10.1.1.149 004740: *Jan 29 07:57:28.718 EST: TAC+: Using default tacacs server-group "tacacs+" list. 004741: *Jan 29 07:57:28.718 EST: TAC+: Using default tacacs server-group "tacacs+" list. 004742: *Jan 29 07:57:28.718 EST: TAC+: Opening TCP/IP to 10.1.1.1/49 timeout=5 004743: *Jan 29 07:57:28.726 EST: TAC+: Opened TCP/IP handle 0x18C12728 to 10.1.1.1/49 004744: *Jan 29 07:57:28.726 EST: TAC+: 10.8.13.84 (2101712117) ACCT/REQUEST/START queued 004745: *Jan 29 07:57:28.926 EST: TAC+: (2101712117) ACCT/REQUEST/START processed 004746: *Jan 29 07:57:28.926 EST: TAC+: received bad ACCT packet: type = 0, expected 3 004747: *Jan 29 07:57:28.926 EST: TAC+: Invalid ACCT/REQUEST/START packet (check keys). 004748: *Jan 29 07:57:28.926 EST: TAC+: Closing TCP/IP 0x18C12728 connection to 10.1.1.1/49 004749: *Jan 29 07:57:28.926 EST: TAC+: Using default tacacs server-group "tacacs+" list.
Albeit a little cryptic, I see that I received a bad “AUTHOR” packet (line 4737). Not sure what it means exactly, but obviously, I received something wrong from that tacacs server. So, I turned my efforts to the IMC TAM log:
% 2014-01-29 16:29:01 ; Invalid Source IP or port number(from 10.1.0.29:49). % 2014-01-29 16:29:04 ; Invalid Source IP or port number(from 10.1.0.29:49). % 2014-01-29 16:29:04 ; Invalid Source IP or port number(from 10.1.0.29:49). % 2014-01-29 16:29:09 ; Invalid Source IP or port number(from 10.1.0.29:49).
Hmmm. It’s saying invalid source IP, because IMC is not managing a device with the IP Address of 10.1.0.29. Incidentally, that IP is actually an L3 address on a FastEthernet interface of that switch. After checking, it looks like this address is the lowest numerical address on the switch, but it’s also the L3 interface used to communicate with IMC TAM, so I’m not totally sure the algorithm used to determine which IP a Cisco device will ultimately use in AAA for future reference. If I were to guess, I’d say it’s the lowest numerical value, but this scenario doesn’t confirm that. IMC is rejecting it because the address doesn’t match the management address it’s using for the device. Now, personally, I think it should still work, since IMC is aware of all addresses on this switch, but, that’s a developer problem.
So, it’s really a quick fix. Just use the “tacacs source-interface” on the Cisco switch to specify the address to use. Unfortunately for me, that command showed up in 12.2(33), and this switch is running 12.2(25). I’m not going to bother upgrading, because it’s an old switch, and is getting removed from production. It obviously never got that much love from us in the first place, being that far behind in release. In the end, I moved it back to tac_plus for the remainder of it’s life-support before “pulling-the-plug”.
What I learned
Well, I learned that while IMC TAM is very granular and functional, it certainly requires more detail in the setup than tac_plus does. While this inevitably is a good thing (enforces more security), it can add to your implementation time (and your troubleshooting). Make sure to plan well when designing your “device areas” and “device types”. While not critical, proper planning will deter any future ad-hoc changes you do later to “make it work”.