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:
We have a 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:
We have two identity groups (Admins and Users):
We have two users (Admin1 and User1). These are in the groups above:
We have two Shell profiles, one for Admins, one for Users.
The User one gets a privilege of 8.
We have some allowed commands:
We have a policy called Telnet:
Telnet looks for a device type of Switch, and a location of Inside. It matches the Tacacs protocol, and internal users:
The Authorization part of Telnet set up the mapping Users should get the User-Shell and the User-Commands.
But when I try, I do not get the desired result. We do not match a permit rule, when logging in as User1:
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.
We have a hit on the Telnet-Users - so we *should* get the shell and command set matching this.
But we don't. We pass authentication, but not authorization:
From the device:
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:
Here is the R6 config:
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...
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:
We have a 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:
We have two identity groups (Admins and Users):
We have two users (Admin1 and User1). These are in the groups above:
We have two Shell profiles, one for Admins, one for Users.
The User one gets a privilege of 8.
We have some allowed commands:
We have a policy called Telnet:
Telnet looks for a device type of Switch, and a location of Inside. It matches the Tacacs protocol, and internal users:
The Authorization part of Telnet set up the mapping Users should get the User-Shell and the User-Commands.
But when I try, I do not get the desired result. We do not match a permit rule, when logging in as User1:
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.
We have a hit on the Telnet-Users - so we *should* get the shell and command set matching this.
But we don't. We pass authentication, but not authorization:
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...
, which although it's for the CCNP Security, should certainly help things.
