05-31-2007 03:18 AM - edited 03-10-2019 03:11 PM
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.
06-01-2007 04:37 PM
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
06-02-2007 03:55 AM
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
06-02-2007 11:39 AM
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
06-03-2007 12:28 AM
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
06-03-2007 08:55 PM
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
08-24-2011 06:07 PM
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
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: