There are multiple examples on how to setup TACACS autentication/authorization on the PIXs, but they all seem to use local ACS (on the inside interface of the PIX). What if we have ACS on a remote site and have to send AAA requests across the VPN tunnel? Is this supported by Cisco? Should I still use: "aaa-server TACACS (inside)..." or is it considered to be on an outside interface? Any examples out there? Same question for the ASA appliance (8.0(3)).
Authentication determines who the user is and authorization determines what the user can do. Before you configure the security appliance to use an external server, you must configure the server with the correct security appliance authorization attributes and, from a subset of these attributes, assign specific permissions to individual users.
Refer the following urls for the configuration guide and example on authentication/authorization configs:
For more info on "aaa srever TACACS" COMMAND refer:
Thank you for the reply, Smahbub
However the question was about one particular scenario, when the ACS server (TACACS+) is on the opposite side of the VPN tunnel. How do I configure the ASA in that case? Is it supported by Cisco? I do not want to send AAA traffic over Internet, but via the VPN... Do I use (inside) or (outside) command in that case?
I dont think this can be done, I have been trying to accomplish the same thing on both 7.x ASA code and 8.x ASA code. I have opened a TAC and was told this isnt possible. I have also asked the question to our Cisco Advanced Services Team and other that I know that work for Cisco, including 2 CCIE route/switch and a CCIE security. I also want to send dhcp requests back across the VPN tunnel and this is also not possible. I have to run the dhcp server on the ASA, which makes it more difficult to administer.
I have confirmed that this is a bug in the 8.x code train. It was suggested to me to use 7.2(4) code, which I will be installing and testing tomorrow. If it works, I will post the proper syntax to source the AAA from the inside interface across the VPN tunnel.
i'm currently encountering this exact same issue. I'm running 8.0(3) code, and can't get the remote end to talk to out ACS Server, even though a ping sourced from the inside interface works. Seems silly this setup is possible between an ASA and a router but not an ASA to ASA setup. I'm intrigued to know your findings.
i'm waiting with bated breath :-)
Did you ever get this working? I am encountering exactly the same issue with 8.0(3) code.
Our 7.2 ASA's work fine with exactly the same config.
Is there a bug reference for this issue?
Hello. I'd be curious to know if anyone has tried this with 8.0(4) and if it is fixed. I am having this problem as well and have used RADIUS as a workaround in the meantime. I can't perform command authorization this way, but I do get authentication and it works fine.
Can you share your RADIUS setup? Which interface you use - inside or outside? Surprised to hear that it works for RADIUS - thought it does not work for both.
The configuration I'm using is on an ASA with 8.0(3) code. Basically, the AAA setup is the same as it always is (of course, RADIUS in this case because TACACS doesn't work) and I am using the 'inside' interface as the source interface. I am also using the management-access inside command to make sure that it will communicate using the inside address over the tunnel. I'm pretty sure this command has to be there for this to work (at least I think it used to be).
I have this working on an ASA right now and it works fine. Authentication only.
I opened a case on this issue to see if it was resolved in 8.0(4). This issue regarding TACACS over a VPN tunnel has a bug ID (CSCsk08454) and is resolved in 8.0(4). I have not tested this yet, but it is in the release notes as well. I also looked the bug up and found a workaround as well. I have not tried this either, but it is listed in the bug tracker. Apparently if you enable reverse route injection for the L2L tunnel, tacacs will work successfully. Again, I haven't tested this, but it's in the notes.
I had this exact problem with 8.0(3). I upgraded to 8.0(4) reloaded and logged straight in using TACACS.
8.0(4) should completely resolve this issue for you
This has been resolved with 8.0(4). In order to use it here is the syntax:
aaa-server SOMENAMEHERE protocol tacacs+
aaa-server SOMENAMEHERE (INTERFACE) host x.x.x.x key xxxxxxxxxx
I have personally verified that this works on 8.0(4)