DAMN YOU ACS!!!!


My lab exam is on Friday, so I have a few hours today, a few tomorrow and then Monday to Thursday, it's a mere five days to get stuff right and it isn't.

ACS is kicking my arse and I can't figure out why. I have had this working before, but I have spent two days trying to get this to work, and it's two days that I cannot afford to spend fucking about.

I am consoling myself by listening to some angry hip-hop:


My musical taste has not really moved on since the 90's. But I digress. Hopefully, by blogging about it, it might give me a chance to figure out why it is not working - or someone else might point out my problem (with ACS, not any of my other problems)...

We have a location:

Cisco ACS setting location

We have a device type:

Cisco ACS setting device type

We have two devices. Originally I was just using SW6 (a router image with a switch module), thinking it might be a version issue I added R6:

Cisco ACS setting clients

We have two identity groups (Admins and Users):

Cisco ACS setting identity groups

We have two users (Admin1 and User1). These are in the groups above:

Cisco ACS setting local users

We have two Shell profiles, one for Admins, one for Users.

Cisco ACS setting shell profiles

The User one gets a privilege of 8.

Cisco ACS setting privilege levels

We have some allowed commands:

Cisco ACS setting command authoriztion

We have a policy called Telnet:

Cisco ACS setting policies


Cisco ACS setting access policies

Telnet looks for a device type of Switch, and a location of Inside. It matches the Tacacs protocol, and internal users:

Cisco ACS setting protocol

The Authorization part of Telnet set up the mapping Users should get the User-Shell and the User-Commands.

Cisco ACS setting authorization rule

But when I try, I do not get the desired result. We do not match a permit rule, when logging in as User1:

Cisco ACS logs

As the next two grabs show, we should get the User-Commands command set, we are found in the Users Identity group, the service selection rule matches Telnet, as does the Identity policy.

Cisco ACS log results

We have a hit on the Telnet-Users - so we *should* get the shell and command set matching this.

Cisco ACS logs

But we don't. We pass authentication, but not authorization:

Cisco ACS no permit rule matched

From the device:

R6#sh priv
Command authorization failed.

R6#sh ver
Command authorization failed.

R6#conf t
      ^
% Invalid input detected at '^' marker.

R6#en
% Error in authentication.

R6#
Admin works fine, though:




So, clearly, something is different between the User and Admin configurations.

The Admin-Commands has the tick next to "Permit any command that is not listed in the table below:



If this is unticked, commands that are permitted actually fail:
R6#sh ver
Command authorization failed.

R6#sh ver
Cisco IOS Software, IOSv Software (VIOS-ADVENTERPRISEK9-M), Version 15.5(2)T, RELEASE SOFTWARE (fc1)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2015 by Cisco Systems, Inc.
Compiled Wed 25-Mar-15 13:34 by prod_rel_team


ROM: Bootstrap program is IOSv

R6 uptime is 2 hours, 7 minutes
System returned to ROM by reload
System image file is "flash0:/vios-adventerprisek9-m"
Last reload reason: Unknown reason



This product contains cryptographic features and is subject to United
States and local country laws governing import, export, transfer and
use. Delivery of Cisco cryptographic products does not imply
third-party authority to import, export, distribute or use encryption.
Importers, exporters, distributors and users are responsible for
compliance with U.S. and local country laws. By using this product you
agree to comply with applicable laws and regulations. If you are unable
          
R6#
You can see that when unticked the command fails and works when ticked. So, actually, there is no difference in working/not working when comparing the User setup to the Admin setup. Something is just wrong, somewhere.

Here is the R6 config:
R6#sh run | i aaa
aaa new-model
aaa authentication login Admin group tacacs+ local
aaa authorization config-commands
aaa authorization exec Admin group tacacs+ local 
aaa authorization commands 1 Admin group tacacs+ 
aaa authorization commands 8 Admin group tacacs+ 
aaa authorization commands 15 Admin group tacacs+ 
aaa session-id common
R6#sh run | s line vty
line vty 0 4
 password cisco
 authorization commands 1 Admin
 authorization commands 8 Admin
 authorization commands 15 Admin
 authorization exec Admin
 login authentication Admin
 transport input telnet
R6#sh run | i tacacs
aaa authentication login Admin group tacacs+ local
aaa authorization exec Admin group tacacs+ local 
aaa authorization commands 1 Admin group tacacs+ 
aaa authorization commands 8 Admin group tacacs+ 
aaa authorization commands 15 Admin group tacacs+ 
tacacs-server host 192.168.20.102 key cisco
tacacs-server directed-request
R6#
I added a few changes:
R6(config)#aaa authentication login CONSOLE none
R6(config)#aaa authorization console 
R6(config)#line con 0
R6(config-line)#login authentication CONSOLE
R6(config-line)#exi
R6(config)#aaa accounting exec Admin start-stop group tacacs+ 
R6(config)#aaa accounting commands 8 Admin start-stop group tacacs+ 
R6(config)#aaa accounting commands 15 Admin start-stop group tacacs+ 
R6(config)#aaa accounting commands 1 Admin start-stop group tacacs+  
R6(config)#line vty 0 4
R6(config-line)#accounting commands 1 Admin
R6(config-line)#accounting commands 8 Admin
R6(config-line)#accounting commands 15 Admin
R6(config-line)#
But the problem remains the same.

I now have four days left before the lab. not feeling too good about it, to be honest!

But I need to move on, give myself a break from ACS and come back to it another day, not that I have many days remaining.

EDIT: 28/09/2016

I now have it working. I created a new access policy (Telnet-2), but on the Identity I set the conditions to be:

NDG:Location = in All Locations:Inside
NDG:Device Type = in All Device Types:Inside
Device IP Address = 150.1.7.66

The authorization part remained the same (albeit with the Command Sets result being first).

This gave me the desired result.

I think the issue with the first try was that the protocol condition would not be correct, the connection would be Telnet.

Got there in the end.

One day 19 hours to go before D-Day...

CCIE #49337, author of CCNA and Beyond, BGP for Cisco Networks, MPLS for Cisco Networks, VPNs and NAT for Cisco Networks.

Related Posts

Latest
Previous
Next Post »

1 comments:

comments
44113
25 September 2016 at 07:14 delete

It will come together before the exam.

Reply
avatar