ACS TACACS+ Authorization for ASA Cut Through Proxy

Unanswered Question
May 31st, 2007

who does know how to configurea user profile for ACS to authorize a user for ASA cuit through Proxy ? Radius is simple, but TACACS+ is very uncommon and not outlined in any document or configuration example.

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Premdeep Banga Fri, 06/01/2007 - 16:37

Hi,

Is there any special requirement that you want to configure cut through proxy authentication/authorization using TACACS+?

Apart from that can you provide with the AAA configuration that you have using TACACS+?

Have to tried to do a test with such a setup? If you are authorizing the traffic, along with authentication, then traffic allowed need to be permitted exclusively.

What you need to permit, can be found from Failed Attempts logs from Reports and activity. Given you also have Authorization configured.

Else it works the same way, as Radius does. Cut through proxy authentication.

Regards,

Prem

herbert.aichhorn Sat, 06/02/2007 - 03:55

Hi

the configuration is on PIX:

virtual telnet 172.3.0.100

aaa-server tac protocol tacacs+

aaa-server tac host 10.2.20.34

access-list auth extended permit tcp any any eq telnet

aaa authentication match auth inside tac

The ACS authenticated the User, but the authorization failed as shown:

02/06/2007 13:26:40 Author failed user17 Default Group 10.2.20.34 (Default) .. Command unknown service=shell cmd=telnet 201.3.0.1 23 172.3.0.10 .. .. .. .. .. pix 172.3.0.10

02/06/2007 13:26:40 Author failed user17 Default Group 10.2.20.34 (Default) .. Service denied service=shell cmd* 23 172.3.0.10 .. .. .. .. .. pix 172.3.0.10

So I configured the following on ACS:

user profile:

service shell

command authorization set wihich permits command telnet with unknown args

My question:

Is this how to configure the authorization is this nonsense - I am not sure.

regards

Herbert

Premdeep Banga Sat, 06/02/2007 - 11:39

Hi Herbert,

I am not sure, if you have pasted the complete AAA config.

I think, you also have a command such as,

*aaa authorization match auth inside tac*

Which should be the one that is causing everything to be *authorized* even though user authenticated.

Purpose of authorization is to give authenticated users resources that they should get. And is indeed being checked against AAA server. If its not permitted they are being denied.

I think if you remove authorization command, you don't have to do anything under shell command authorization section.

Let me know.

Regards,

Prem

herbert.aichhorn Sun, 06/03/2007 - 00:28

Hi

yes I forgot the command to paste it in.

I have found a very old configuration example on Cisco Website - that is alos valid for ASA 7.2.

Configuring PIX 5.1.x: TACACS+ and RADIUS

Document ID: 4613

I am not confused any more.

thanks

Herbert

Premdeep Banga Sun, 06/03/2007 - 20:55

Hi Herbet,

Actually the device is working the way it should. Its just that we need to understand what we have requested device to do for cut through traffic.

When we use the command,

aaa authentication......

We are instructing device to authenticate the user before we could actually let the end user send the traffic(cut through).

Everything is fine at this end.

When we also tell,

aaa authorization......

Now we have instructed device to do, Okay now its good that user has come past the level of authentication, but I need more security, and that authenticated user should only be able to do what its permitted to. If that individual try to access something thats not permitted on their profile. Stop them there itself.

So in our case, that is what's happening.

Though the user is authenticated. Now if they try to browse something, they are trying to do

http and the ip address.

So we need to permit that too, else they will be denied access.

In case you do not want such a thing to occur.

You can simply remove the "aaa authorization.." that you have.

Use it, only if you want to use it.

Please go through this link :

http://www.cisco.com/univercd/cc/td/doc/product/multisec/asa_sw/v_7_2/cmd_ref/a1_711.htm#wp1439006

Here it talks about that if we have authorization then that particular traffic needs to be permitted on user's profile.

Regards,

Prem

Kureli Sankar Wed, 08/24/2011 - 18:07

I understand this is a very old thread but, I ran into this very same issue today.

deb aaa authorization showed the following: (This is when I used per user command authorization under the user config on ACS)

mk_pkt - type: 0x2, session_id: 39

mkpkt - authorize user: user1

cmd=telnet

Tacacs packet sent

Sending TACACS Authorization message. Session id: 39, seq no:1

Received TACACS packet. Session id:146411776  seq no:2

tacp_procpkt_author: FAIL

TACACS Session finished. Session id: 39, seq no: 1

Then, I removed that and configured separate shell command authorization set (used the exact same config)

and tied that to the user config.  Now it works and the debug shows below:

Proceeding to authorization for user: user1, session id: 2147483665

mk_pkt - type: 0x2, session_id: 42

mkpkt - authorize user: user1

Tacacs packet sent

Sending TACACS Authorization message. Session id: 42, seq no:1

Received TACACS packet. Session id:2058063958  seq no:2

tacp_procpkt_author: PASS_ADD

tacp_procpkt_author: PASS_REPL

Attributes = idletime

Attributes = priv-lvl

TACACS Session finished. Session id: 42, seq no: 1

Received response to AAA_AUTHOR_CONFIG request (session id: 2147483665)

Proceeding to authorization for user: user1, session id: 2147483665

mk_pkt - type: 0x2, session_id: 43

mkpkt - authorize user: user1

cmd=telnet

Tacacs packet sent

Sending TACACS Authorization message. Session id: 43, seq no:1

Received TACACS packet. Session id:1534723524  seq no:2

tacp_procpkt_author: PASS_ADD

tacp_procpkt_author: PASS_REPL

TACACS Session finished. Session id: 43, seq no: 1

Received response to AAA_AUTHOR request (session id: 2147483665)

Authorization for user: user1 succeeded, session id: 2147483665

So I believe there is some bug here but, it works when you use shell command authorization set and not per user command authorization.

-KS

Actions

This Discussion