cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1284
Views
0
Helpful
2
Replies

PIX AAA Authorize SSH, "command unknown" failure on ACS

gregwinkler
Level 1
Level 1

Please bear the long message. I think ultimately I have an ACS configuration problem.

I am configuring a PIX 515 v6.3.3 to aaa authorize inbound SSH sessions to an inside host using ACS server 2.3. I am certain I have the PIX configured properly. I am able to get things working with aaa authentication only. When I proceed to aaa authorize the problem develops.

Here is the pix command:

aaa authorization include tcp/22 outside 10.58.97.20 255.255.255.255 0.0.0.0 0.0.0.0 TACACS+

Since I want to authorize SSH and not one of the supported protocols (not ftp, http, or telnet) I have to also use the virtual telnet feature of the PIX to complete the authentication. As I say this works just fine.

After I authenticate (using telnet to the virtual telnet address) I then proceed to open up my ssh client. At this point the pix syslog reports that my authorization is denied (109008 error) from my ACS server. So I know my PIX is asking the ACS to authorize the connection (and authentication is already successful at this point).

On the ACS server in the failed attempts report I see that the ACS is dening the request due to author-failure-code of "command unknown". In that same report, diagnostic info supplied in the author-data field is:

service=shell

cmd=tcp/22

10.58.97.20

I think this is a configuration problem on the ACS and nothing to do with the PIX. I have tried adding commands by editing the ACS group of the user by using all combination of permit/deny arguements, service names, command names. Nothing is working. I need to know how to configure the ACS correctly.

Please don't point me at the PIX AAA docs as I have been through them dozens of times now. :<

2 Replies 2

dopenfield
Level 1
Level 1

You might check...

On the ACS under the User-ID you are using, Check that the Shell Exec is checked under TACACS Settings

Fixed it. It was one of those ID10T type errors. The user I was testing against was in in group1 on the ACS. Trouble is I was adding command authorizations to group0. Duh!