Yeah, I agree, it is quite off the track for ASA and Tacacs. And to your last statement, it is true, if you are not matching Telnet on CTP_ACL, permit telnet makes little sense.
But this is the command you see sent to Tacacs from ASA IF you match telnet. If you configure authorization wrong or of you configure accounting on Tacacs, you see in logs (either failed or accounting) "cmd telnet a.b.c.d". I have just done a quick test with different types of traffic matching ASA CTP_ACL: - SSH - TCP port 22 - DNS - UDP port 53 - GRE IP - IP protocol 47 Here is a test bed: ACS (.100) --- 10.0.0.0/24 -- (.3 inside) ASA (.3 outside) -- 10.1.1.0/24-- (.1) R1 ! ACS - ASA as a NAS - Regular user AUTH with just password defined, no command authorization or downloadable ACLs. ! ASA interface Ethernet0 nameif outside security-level 0 ip address 10.1.1.3 255.255.255.0 ! interface Ethernet1 nameif inside security-level 100 ip address 10.0.0.3 255.255.255.0 ! aaa-server ACS_TAC protocol tacacs+ aaa-server ACS_TAC (inside) host 10.0.0.100 key cisco ! access-list AUTH extended permit tcp any any eq telnet access-list AUTH extended permit tcp any any eq ssh access-list AUTH extended permit gre any any access-list AUTH extended permit udp any any eq domain ! aaa authentication match AUTH outside ACS_TAC aaa authorization match AUTH outside ACS_TAC I am omitting OUTSIDE_IN ACL here. It is the same as AUTH ACL. OUDSIDE_IN ACL has to have whatever AUTH ACL has or else the traffic will never get matched. ! R1 interface FastEthernet0/0 ip address 10.1.1.1 255.255.255.0 ! ip route 0.0.0.0 0.0.0.0 10.1.1.10 ! interface Tunnel1 ip address 172.16.1.1 255.255.255.0 tunnel source FastEthernet0/0 tunnel destination 10.0.0.100 ! ip name-server 10.0.0.100 Tests from R1: Initial telnet 10.0.0.100 – triggers authentication. Subsequent telnet 10.0.0.100 – triggers authorization request for Telnet telnet 10.0.0.100 22 – triggers authorization request for TCP 22 ping R1 – triggers authorization request for UDP 53 ping 172.16.1.2 – triggers authorization request for IP 47 Here is what ASA is sending for authorization to ACS (Logging->Failed) once I start sending the traffic after successful authentication but with no authorization for commands in user profile: service=shell cmd=telnet 10.0.0.100 service=shell cmd=tcp/22 10.0.0.100 service=shell cmd=udp/53 10.0.0.100 service=shell cmd=47/0 10.0.0.100 I also ran a capture on ASA inside interface ASA1(config)# sh cap capture ACS type raw-data access-list AUTH interface inside [Capturing - 0 bytes] There is no traffic passed to destinations matched by AUTH ACL with failed authorization. As soon as I authorize a command on ACS, say "command udp/53 arg permit 10.0.0.100". It starts passing the traffic. ASA1(config)# sh cap ACS detail 1 packet captured 1: 02:21:57.005630 00ab.bffb.c401 0800.2723.6cae 0x0800 62: 10.1.1.1.56456 > 10.0.0.100.53: [udp sum ok] udp 20 (ttl 255, id 1) 1 packet shown So it works, but configuration on Tacacs server is REALLY weird. :-) There is no such real shell commands as udp/53 a.b.c.d or 47/0 a.b.c.d.. but there you go… what has really been consistent on that bloody ASA/IPX from day one? :-) It has been 10 years since I started working on PIX and later ASA, it has always been a constant pain in the… On that enthusiastic note I would suggest you listen to one of the last Cisco TAC Security podcasts “History of PIX”. :-) It would crack me big time. Hope it makes sense. A. On 23 July 2012 09:26, Eugene Pefti <[email protected]> wrote: > I agree with that latter but what about the former, i.e. ASA CTP with > TACACS. Why would you need to authorize telnet to 1.1.1.1 with commands set > if you don’t run this command on ASA. **** > > Here are my reasoning. You enable CTP on ASA with CTP ACL that has to > contain at least one of the protocols that would trigger CTP.**** > > ** ** > > E.g. (I want to authenticate the user with HTTP and then allow access to > the host behind the ASA via SSH)**** > > access-list CTP-ACL extended permit tcp any host 136.1.125.5 eq www **** > > access-list CTP-ACL extended permit tcp any host 136.1.125.5 eq ssh**** > > ** ** > > What’s the use of command authorization set ? E.g. If I want to allow > telnet traffic to my host behind ASA via “telnet permit 136.1.125.5” then > it will never be useful because telnet is not on CTP-ACL and it will always > work providing it is allowed by interface ACL. Simply speaking, telnet > traffic will always bypass CTP.**** > > ** ** > > Eugene**** > > ** ** > > ** ** > > ** ** > > *From:* Alexei Monastyrnyi [mailto:[email protected]] > *Sent:* Sunday, July 22, 2012 3:52 PM > *To:* Eugene Pefti > *Cc:* Marta Sokolowska; GuardGrid; ccie_security > > *Subject:* Re: [OSL | CCIE_Security] Radius VSA**** > > ** ** > > I don't think so. I reckon for ASA auth-proxy and Tacacs it is recommended > to use command authorization sets, say for Telnet it would be command > telnet arg permit 1.1.1.1 > > For ASA and RADIUS it is recommended to use downloadable ACLs in ASA > format. > > Cheers, > A. > **** > > On 7/23/2012 3:29 AM, Eugene Pefti wrote:**** > > Auth-proxy examples:**** > > ** ** > > > http://www.cisco.com/en/US/docs/ios-xml/ios/sec_usr_auth/configuration/12-4/sec-cfg-authen-prxy.html#GUID-06899095-B258-4A9C-85F1-5832D29E754C > **** > > ** ** > > A question/comment on ASA EZVPN and SSL VPN related guide. There's table > D4 in the guide "Table D-4 Examples of Cisco AV Pairs and their Permitting > or Denying Action"**** > > And it shows the ACL like this:**** > > ip:inacl#1=deny ip 10.155.10.0 0.0.0.255 10.159.2.0 0.0.0.255 log**** > > ** ** > > Will ASA understand the wilcard notation ?**** > > ** ** > > Eugene**** > > ** ** > > *From: *Alexei Monastyrnyi <[email protected]> > *Reply-To: *"[email protected]" <[email protected]> > *Date: *Sunday, July 22, 2012 4:24 AM > *To: *Eugene Pefti <[email protected]> > *Cc: *Marta Sokolowska <[email protected]>, GuardGrid < > [email protected]>, ccie_security <[email protected]> > *Subject: *Re: [OSL | CCIE_Security] Radius VSA**** > > ** ** > > Hi guys, > here are some links covering RADIUS attributes. > > For the purpose of quick navigation during the lab, I reckon it is better > to refer to some documents where those attributes are within a context, not > just a bare list.**** > > IOS EZ VPN related **** > > > http://www.cisco.com/en/US/docs/ios-xml/ios/sec_conn_esyvpn/configuration/12-4t/sec-easy-vpn-srvr.html#GUID-D0BC5B4D-7BDB-44B6-B49F-EBBD79F1D185 > **** > > > > **** > > IOS SSL VPN related**** > > > http://www.cisco.com/en/US/docs/ios-xml/ios/sec_conn_sslvpn/configuration/12-4t/sec-conn-sslvpn-ssl-vpn.html#GUID-F005501D-8992-48A9-8D4A-7650D7554A3F > **** > > ** ** > > ASA EZ VPN and SSL VPN related**** > > > http://www.cisco.com/en/US/docs/security/asa/asa82/configuration/guide/ref_extserver.html#wp1661512 > **** > > ** ** > > ACS RADIUS attributes reference list**** > > > http://www.cisco.com/en/US/docs/net_mgmt/cisco_secure_access_control_server_for_windows/4.2/user/guide/A_RADAtr.html > **** > > ** ** > > ACS TACACS attributes list**** > > > http://www.cisco.com/en/US/docs/net_mgmt/cisco_secure_access_control_server_for_windows/4.2.1/User_Guide/A_TACAtr.html > **** > > ** ** > > CAR RADIUS attributes list**** > > > http://www.cisco.com/en/US/docs/net_mgmt/access_registrar/5.1/user/guide/a_attrib.html > **** > > ** ** > > ** ** > > HTHJ > A. > > > **** > > On 7/22/2012 12:10 PM, Eugene Pefti wrote:**** > > Good point, Marta,**** > > I wish there’s a consolidated documentation showing how to properly form > those attributes with the required service for different scenarios – > auth-proxy, shell access, VPN and so on.**** > > I.e. we do auth-proxy via RADIUS and it’s not enough to know the attribute > name - Name=proxyacl.**** > > The syntax is auth-proxy:proxyacl#1=permit ip any any”**** > > And so on for other situations and scenarios.**** > > **** > > Eugene**** > > **** > > **** > > *From:* [email protected] [ > mailto:[email protected]<[email protected]>] > *On Behalf Of *Marta Sokolowska > *Sent:* Saturday, July 21, 2012 4:35 PM > *To:* GuardGrid > *Cc:* ccie_security > *Subject:* Re: [OSL | CCIE_Security] Radius VSA**** > > **** > > Type the following command on the router's CLI: > > show aaa attributes > > -- > > Marta Sokolowska.**** > > 2012/7/22 GuardGrid <[email protected]>**** > > Guys,**** > > **** > > Where in the documentation do we get the complete listing of all > attributes like below for RADIUS and TACACS for that matter,**** > > **** > > ipsec:tunnel-type=ESP**** > > ipsec:key-exchange=IKE**** > > ipsec:tunnel-password=ipexpert**** > > ipsec:inacl=SPLIT**** > > ipsec:save-password=1**** > > **** > > **** > > I found some in examples for configuring EZVPN but not a seperate section > of just these VSA not IETF's.**** > > **** > > Let me know.**** > > **** > > **** > > > > > **** > > _______________________________________________**** > > For more information regarding industry leading CCIE Lab training, please > visit www.ipexpert.com**** > > ** ** > > Are you a CCNP or CCIE and looking for a job? Check out > www.PlatinumPlacement.com <http://www.platinumplacement.com/>**** > > ** ** > > ** ** >
_______________________________________________ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com Are you a CCNP or CCIE and looking for a job? Check out www.PlatinumPlacement.com
