Hi there. There is a wealth of information on how to set this up on the Cisco web site. A good document to take a look at can be found on http://www.cisco.com/warp/public/110/pix422.html#add_auth . This should give you enough to complete your set-up and point you in the right direction for further documentation. The set-up is fairly straightforward on both the TACACS+ server and the PIX firewall.
I hope this helps. Many Regards, Mark Searle B.Sc(Hons) Executive Consultant Network Solutions & OSS Integration KPMG Service Provider Solutions -----Original Message----- From: Langa Kentane [mailto:[EMAIL PROTECTED]] Sent: 09 January 2002 07:52 To: Mark S. Searle Subject: RE: Help with AAA on PIX Importance: High Hi Mark. Thanks for your response. I am using PIX 5.2 and Cisco Secure ACS 2.4 on Windows NT 4 SP6. Awaiting more info from you. I appreciate your time. Thanks -----Original Message----- From: Mark S. Searle [mailto:[EMAIL PROTECTED]] Sent: 08 January 2002 17:59 To: Langa Kentane Subject: RE: Help with AAA on PIX First of all in order to answer this question you need to supply further information along the lines of: (1) What ACS are you using? (e.g. Cisco Secure, Cisco Access Registrar etc..) (2) What platform are you working on? (e.g. NT, UNIX etc..) (3) What version of IOS are you running on the PIX? (Is it 5.2 or higher (different commands available) Most importantly RADIUS authorisation is not valid for traffic through the PIX firewall. TACACS+ authorisation is valid. Normal operation is that if authentication has been passed and authorisation is on then the PIX sends the "command" the user is doing to the ACS server. The server then authorises or denies access to the requested service. A sample configuration using CAR on a UNIX platform as the ACS and a PIX firewall would be as follows: Cisco Secure UNIX Configuration: user = can_only_do_telnet { password = clear "**********" service = shell { cmd = telnet { permit .* } } } user = can_only_do_ftp { password = clear "*******" service = shell { cmd = ftp { permit .* } } } user = httponly { password = clear "********" service = shell { cmd = http { permit .* } } } PIX Firewall Configuration aaa authorization include telnet outside 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 AuthInbound aaa authorization include http outside 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 AuthInbound aaa authorization include ftp outside 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 AuthInbound On version 5.2 or later of the PIX you can replace these statements with: aaa authorization match 101 outside AuthInbound where ACL 101 is a previously configured access-list. You can also set up per-user authorisation. For example: Cisco Secure UNIX Configuration: user = admin { password = clear "**********" service = shell { set acl = 100 } } } user = general { password = clear "*****" service = shell ( set acl = 101 } } } PIX Firewall Configuration access-list 100 permit ip any 192.168.1.0 255.255.255.0 access-list 100 deny ip any any access-list 101 permit tcp any 192.168.1.0 255.255.255.0 eq telnet access-list 101 permit tcp any 192.168.1.0 255.255.255.0 eq http access-list 101 deny ip any any Hope this helps. Cheers, Mark Searle B.Sc(Hons) Executive Consultant Network Solutions & OSS Systems KPMG Service Provider Solutions mailto:[EMAIL PROTECTED] <http://www.kpmg-cisco.com> -----Original Message----- From: Langa Kentane [mailto:[EMAIL PROTECTED]] Sent: 07 January 2002 12:30 Subject: Help with AAA on PIX Importance: High Greetings. I have a 'DMZ' where I have installed an NT ras box for dial-in. I have on the internal network an ACS server doing auth for the PIX. I have defined two groups of users on the ACS, general and admin. The general users should only be able to access two ports into the internal network and the admin must be able to access everything on the internal network. What AAA commands should I put on the PIX to be able to get the two groups to get different auth for the different network services that they will use. All users will be required to auth to the NT box and the PIX [using a browser or telnet] before doing anything on the internal network. Thanks in advance. Langa Email Disclaimer The information in this email is confidential and may be legally privileged. It is intended solely for the addressee. Access to this email by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. When addressed to our clients any opinions or advice contained in this email are subject to the terms and conditions expressed in the governing KPMG client engagement letter. Email Disclaimer The information in this email is confidential and may be legally privileged. It is intended solely for the addressee. Access to this email by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. When addressed to our clients any opinions or advice contained in this email are subject to the terms and conditions expressed in the governing KPMG client engagement letter.
