Showing posts with label acs. Show all posts
Showing posts with label acs. Show all posts

Thursday, December 23, 2010

Cisco IOS menu autocommand with AAA/Cisco ACS

A customer has a router dedicated to a site-to-site IPSec VPN , the users of that VPN  are a small group that are not directly responsible for the router. They want a way to check the status of the WAN connection, the IPSec tunnel and also to force a clear crypto sa.

This could be solved with a looking glass but that would require a web server. An alternative solution could be a special user with a menu auto command:

menu VPN title @ VPN VERIFICATION / RESET MENU @
menu VPN text 1 ping Internet (OpenDNS)
menu VPN command 1 ping 208.67.222.222
menu VPN text 2 ping VPN (192.168.0.1)
menu VPN command 2 ping 192.168.0.1 source gi0/1/0
menu VPN text 3 sh crypto isakmp sa
menu VPN command 3 sh crypto isakmp sa
menu VPN text 4 sh crypto ipsec sa
menu VPN command 4 sh crypto ipsec sa
menu VPN text 5 Reset VPN  (clear crypto ipsec sa)
menu VPN command 5 clear crypto sa
menu VPN text 6 Exit
menu VPN command 6 exit
menu VPN clear-screen
menu VPN status-line
menu VPN line-mode
menu VPN single-space

My environment uses AAA with a Cisco ACS, so the special user has to be created in the Internal ACS database, restricted to only that router (Per User Defined Network Access Restrictions), allowing shell (exec) access and the auto command menu VPN (TACACS+ Settings)

The router has to refer to the authorization for exec to the ACS:

aaa authorization exec default group tacacs+ local

Of course, if you don’t use ACS and only use AAA with the local database, Ivan @ Cisco IOS Hints has a great example.

Testing:

Server "VPN-Router"    Line 6    Terminal-type xterm

              VPN VERIFICATION / RESET MENU

    1          ping Internet (OpenDNS)
    2          ping VPN (192.168.0.1)
    3          sh crypto isakmp sa
    4          sh crypto ipsec sa
    5          Reset VPN (clear crypto ipsec sa)
    6          Exit

Selection: 1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 208.67.222.222, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 84/95/140 ms

More info:

Thursday, November 18, 2010

Watchguard PPTP VPN user validation via RADIUS using Cisco ACS 4.2

Wow that title is a mouthful.

A customer has a Watchguard Firebox firewall and a Cisco ACS, all the users for Cisco related activities are on the ACS and the customer wants to migrate all the PPTP VPN users from the firewall to the Cisco ACS.

Both the ACS and Firebox support RADIUS, so it sounds quite easy.

I did the initial configuration; creating the AAA client in the ACS, changing the VPN configuration on the watchguard so it asks the ACS for the users, creating a test user and a test group with the following RADIUS parameters:

[011] Filter-Id PPTP-Users

[311\007] MS-MPPE-Encryption-Policy "Encryption Required"
[311\008] MS-MPPE-Encryption-Types "128-bit"
[311\012] MS-CHAP-MPPE-Keys 
[311\016] MS-MPPE-Send-Key 
[311\017] MS-MPPE-Recv-Key

Testing with a Windows 7 Enterprise client, I got the error:

Error 734: The PPP link control protocol was terminated. 

The logs on the firewall showed:


level=''3'' msg=''pri=''3'' msg_id=''1401-3003'' msg=''pptp MSCHAPv2 authentication ok for peer wg''''
level=''7'' msg=''sent [CHAP Success id=0x32 ''S=5F85A740C65AD93F308ED6681B455486FC2EF4F5 M=Access granted'']'' new_msg='' level=''7'' msg=''sent [CHAP Success id=0x32 ''S=5F85A740C65AD93F308ED6681B455486FC2EF4F5 M=Access granted'']'''' Debug
pppd[1255] MPPE required, but keys are not available. Possible plugin problem?
pppd MPPE required but not available'''


Basically the issue seemed to be MPPE related, since the configuration requires encryption, no MPPE = no VPN.

In the ACS the authentication showed as successful and little else. I checked and double checked the RADIUS attributes. After sometime with Watchguard support, they suggested to get a packet capture of the ACS RADIUS response:



Using Wireshark, it was clear that the ACS was not sending any MPPE related attributes and in fact the only Microsoft attribute was the one indicating that the authentication was OK. 

I replicated the VPN configuration using a cisco router and it worked without issues, after that, I was checking everything again and noticed that the cisco router was defined in the ACS AAA client section as "RADIUS (Cisco IOS/PIX 6.0)" while the Watchguard Firewall was defined as "RADIUS (IETF)"

I changed the firewall to "RADIUS (Cisco IOS/PIX 6.0)" and ta-da, everything worked.


All the Microsoft attributes were there and all was well in the land. Of course after reading the ACS help, it seems obvious:

"RADIUS (IETF). These are the standard IETF RADIUS attributes. Select this option if you are using devices supporting RADIUS but do not need to make use of the vendor-specific attributes (VSA) of the manufacturer.

RADIUS (Cisco IOS/PIX 6.0) Select the RADIUS (Cisco IOS) option when using a Cisco Systems IOS device as a AAA client. This option enables you to make use of the Cisco IOS and PIX 6.0 RADIUS VSAs."

Monday, October 18, 2010

CiscoSecure ACS for Windows Router PPTP Authentication

If you need to migrate your PPTP users from a IOS device/PIX to a Cisco ACS, this is a good starting point:

Configuring CiscoSecure ACS for Windows Router PPTP Authentication

I was having an odd issue with this configuration, everything seemed fine but on my Windows 7 Test client I got the Error 742: "The remote server does not support encryption" every time I tried to connect, the ACS 4.2 showed the authentication as successful and nothing else, the debug on the router pretty much the same thing with the exception of :

"Vi1 MPPE: RADIUS keying material missing"

After 2 weeks with TAC,  We came to the conclusion that the issue was caused by the fact that starting with Vista, MS-CHAP v1 is deprecated, so in order for MS-CHAP v2 to work we needed to enable the extra MPPE Attributes:

[311\016] MS-MPPE-Send-Key
[311\017] MS-MPPE-Recv-Key

In the new Cisco ACS 5.x family, enabling the these particular attributes does not seem to be necessary  since "These are added to the profile as required". 

Thursday, October 7, 2010

Cisco ACS 4.2:: Quick and easy way to admin devices via TACACS+

A quick template for Cisco ACS 4.2 TACACS+ administration for IOS devices.

On the IOS device (taken from a switch):

enable secret <SECRET>
no enable password
no username <ANY CURRENT USERS>
username panicuser secret 0 <PANIC USER PASSWORD>

ip tacacs source-interface <MANAGEMENT INT>

tacacs-server directed-request
tacacs-server key <SECRET>
tacacs-server host <ACS IP>

aaa new-model
aaa authentication login default group tacacs+ local
aaa authentication login no-tacacs none
aaa authentication enable default group tacacs+ enable
aaa authorization config-commands
aaa authorization exec default if-authenticated
aaa authorization commands 1 default if-authenticated
aaa authorization commands 15 default group tacacs+ local
aaa authorization console

Exit the IOS device and enter with an ACS username:

aaa accounting exec default start-stop group tacacs+
aaa accounting commands 0 default start-stop group tacacs+
aaa accounting commands 1 default start-stop group tacacs+
aaa accounting commands 15 default start-stop group tacacs+
aaa accounting connection default start-stop group tacacs+
aaa accounting system default start-stop group tacacs+
aaa session-id common


Cisco ACS:

Interface Configuration->TACACS+ (Cisco IOS)->Advanced TACACS+ Features and Display enable default (Undefined) service configuration

Network Configuration-> AAA Clients Add Entry-> IOS Device IP Address/Secret/TACACS+ (Cisco IOS)

Group Setup-> The group you want to use->Rename Group-> Meaningful name (Eg: Networking Admins)

Group Setup-> Networking Admins->Edit Settings:

->Enable Options->Level 15
->TACACS+ Settings->Shell (exec)
->TACACS+ Settings->Privilege level->15
->TACACS+ Settings->Shell Command Authorization Set->Per Group Command Authorization->Permit
->Submit + Restart

User Setup->Name of the user to create->Add/Edit

->User Setup->Password
    ->User Setup->Group to which the user is assigned:->Networking Admins
    ->Advanced TACACS+ Settings-> TACACS+ Enable Control:->Use Group Level Setting
    ->Advanced TACACS+ Settings-> TACACS+ Enable Password->Use CiscoSecure PAP password
->Submit

That's it, now everything AAA related goes to the TACACS+ and if the IOS device can't reach it, you have the panicuser that gives you local access to the device.

Tuesday, September 28, 2010

Cisco Secure ACS password recovery

So today I got an ACS backup from a client to test some features on a lab setup and since I had never done it, instead of asking for the GUI password, I decided to do password recovery.

After some googling, I found a couple of ways, both on the official Cisco FAQ:

1. Using allowAutoLocalLogin to enable that if you are opening the GUI from the server, it doesn't ask for a password.
2. Removing existing entries in:
HKEY_LOCAL_MACHINE\SOFTWARE\Cisco\CiscoAAA##\CSAdmin\Administrators
Unfortunately, neither of those methods seemed to work on my version of ACS (4.2(1) Build 15 Patch 2), the keys were not in the Windows registry, so after more searching I got the fabulous news that:

"On ACS 4.0 or later, reinstallation is the only way"

So, I'm supposed to reinstall? Come on, this makes no sense at all, specially considering that after reinstalling, the next logical step would be to load the last good backup, which will use the same administrator password that you don't know. Not only you are supposed to reinstall but you are also supposed to reconfigure the ACS again by hand?.

Bad design, just bad.

I guess I'm going to take extra extra extra care of my production ACS passwords now ;)