CCIE Security Lab: ACS command authorization


Last time, we set up the ACS and gave me level 15 access, and Bob level 3 access. Let's give Bob access to a few commands now.

Just to give you a heads up, there was a LOT of trial and error today. So, if you want to jump down to the bottom and just read the working set up part, I really won't be offended. But if you want to read the pitfalls I had setting this up, then carry on!

Unfortunately, since leaving it for a couple of days, ACS has lost communication with AD.

Ciasco ACS lost communication to AD

So, we'll give the ACS a quick reboot, and wait for the ACS services to start up again.

ACS AD working

Thats better!

We'll give Bob some commands to run. At the moment, he cannot do much:
AP-DNS#sh priv
Current privilege level is 3
AP-DNS#conf t
          ^
% Invalid input detected at '^' marker.

AP-DNS#configure terminal
          ^
% Invalid input detected at '^' marker.

AP-DNS#show running-config
             ^
% Invalid input detected at '^' marker.

AP-DNS#sh version
Cisco IOS Software, IOSv Software (VIOS-ADVENTERPRISEK9-M), Version 15.5(3)M, RELEASE SOFTWARE (fc1)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2015 by Cisco Systems, Inc.
Compiled Wed 22-Jul-15 23:04 by prod_rel_team

          
AP-DNS#
We add the commands under Policy Elements > Authorization and Permissions > Device Administration > Command sets.

ACS command authorization

Some need to be split up, so "show" is the command, and "version" is the argument, and so on. If we just had "show" then all the subcommands beneath it would be allowed (or so I am lead to believe, I have not tried this yet).

We then need to create a new Access Service, which we will call Bob, and base it on the existing Device Admin Command Auth service template:

ACS new access policy

On the next page as accept the defaults, and click on Finish:

ACS access policy

We get a little message pop up telling us that it's been created, asking is we want to modify the service selection:

ACS access policy prompt

Yes, we do:

As Bob will not have console access, we will only allow him to access through Telnet. The default Service Selection Policies are Radius and Tacacs, so let's add a new one for Bob:

ACS service selection policy

Click on Create:

We can't specify Telnet as the protocol, so we need to specify Tacacs here:

ACS service selection policy 2

Click on OK, then move it to the top of the list:

ACS rule ordering

Save the changes.

Under the Bob Access Service, we need to select the correct Identity:

ACS rule select user

Hopefully this is correct!

You should see it in the list:

ACS custom rules

Save the changes.

We then move down one to Authorization, and click Create:

I am not too fussed (at the moment) about the groups and NDG's, but we do need to select the command set we set up previously:

ACS rules

If we click OK here, we are told that we need to select at least one condition, so let's do that:

ACS identity group

The new policy is accepted:

ACS policies

Save the changes.

Let's test it and see if it works or not.
AP-DNS#sh priv
Current privilege level is 15
AP-DNS#sh ip int bri
Interface                  IP-Address      OK? Method Status                Protocol
GigabitEthernet0/0         10.1.4.101      YES NVRAM  up                    up      
GigabitEthernet0/1         unassigned      YES NVRAM  administratively down down    
GigabitEthernet0/2         unassigned      YES NVRAM  administratively down down    
GigabitEthernet0/3         unassigned      YES NVRAM  administratively down down    
AP-DNS#sh run int gi0/0
Building configuration...

Current configuration : 115 bytes
!
interface GigabitEthernet0/0
 ip address 10.1.4.101 255.255.255.0
 duplex full
 speed auto
 media-type rj45
end

AP-DNS#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
AP-DNS(config)#int gi0/1
AP-DNS(config-if)#ip address 1.2.3.4 255.255.255.0  
AP-DNS(config-if)#no ip add
AP-DNS(config-if)#
No, it did not., we should not be able to add an IP address. We have level 15 access, and have more commands than we should do. We did, however, hit the correct rule:

ACS rule hits

So, not too bad, just not quite there!

We are getting the right user, so the Identity section is correct, we just need to set the Authorization correctly.

We only have one condition, what we need is a compound condition, like we had last time, so click on customize, and add Compound Condition. While we are at it, let's make life easier, and only include what we really need, so that we end up with something like this:

ACS customize

We can then edit the rule, so that it looks like this:

ACS customized rule

ACS command sets


ACS command set results

Hmmm, it's still letting him in at level 15, so I have missed something somewhere...

Turning to the TACACS logs we can see this:

ACS tacacs log

We recognize the username, and pick the Access Service "Bob". We get the right identity (Select-Bob), but the authorization policy matched rule says "Default". We should see it say "Bob-Rule".

I removed the Identity group from the Authorization rule, and got into Level 3:

ACS authorization rule simplified
AP-DNS#sh priv    
Current privilege level is 3
AP-DNS#sh ip route | b Gate
Gateway of last resort is 10.1.4.254 to network 0.0.0.0

S*    0.0.0.0/0 [1/0] via 10.1.4.254
      10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C        10.1.4.0/24 is directly connected, GigabitEthernet0/0
L        10.1.4.101/32 is directly connected, GigabitEthernet0/0
AP-DNS#
We still have more commands that we should at our disposal.

But we are getting closer:

ACS tacacs log 2

We now get the correct "Selected Shell Profile" of LVL-3, and the Authentiation Policy Matched Rule shows "Bob-Rule", like we need it to. We just have more commands than we should! Some we do not have access to, like "show running-config":
AP-DNS#show running-config
show running-config
      ^
% Invalid input detected at '^' marker.

AP-DNS#
So what's the deal here?

Let's think about this a different way. I have a user logging in, who is assigned a privilege level, and is allowed to use a subset of commands. But what if these commands are denied by the privilege levels being too low? Should we set him higher, and then the commands will be limited?

Let's set it higher and find out:

ACS shell privilige levels

Nope, still did not work. Also, my own account is locked out.

Let's scratch the "Bob" Service Selection Rule and start again. Things worked much better last time, I got in with my account at level 15, and Bob got in at level 3, so maybe we should just edit what we used in the previous post.

I set the LVL-3 back to 3, and deleted the Bob Access Policy. The went into the Default Device Admin, and into Authorization. Clicked on Customize, and added "Command Sets". I then edited the Rule-LVL-3, and changed it to look like this:

ACS authorization command set

I ended up with this:

ACS levels

Does this work?
SW1#telnet 10.1.4.101
Trying 10.1.4.101...
Connected to 10.1.4.101.
Escape character is 'off'.


username: stuart
password: 

AP-DNS#sh priv
Current privilege level is 15
AP-DNS#sh ip int bri
Interface                  IP-Address      OK? Method Status                Protocol
GigabitEthernet0/0         10.1.4.101      YES NVRAM  up                    up      
GigabitEthernet0/1         unassigned      YES manual administratively down down    
GigabitEthernet0/2         unassigned      YES NVRAM  administratively down down    
GigabitEthernet0/3         unassigned      YES NVRAM  administratively down down    
AP-DNS#sh ip route | b Gate
Gateway of last resort is 10.1.4.254 to network 0.0.0.0

S*    0.0.0.0/0 [1/0] via 10.1.4.254
      10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C        10.1.4.0/24 is directly connected, GigabitEthernet0/0
L        10.1.4.101/32 is directly connected, GigabitEthernet0/0
AP-DNS#exit
Connection closed by foreign host.
SW1#
SW1#telnet 10.1.4.101
Trying 10.1.4.101...
Connected to 10.1.4.101.
Escape character is 'off'.

username: dodgybob
password: 

AP-DNS#sh priv     
Current privilege level is 3
AP-DNS#sh ip int bri
Interface                  IP-Address      OK? Method Status                Protocol
GigabitEthernet0/0         10.1.4.101      YES NVRAM  up                    up      
GigabitEthernet0/1         unassigned      YES manual administratively down down    
GigabitEthernet0/2         unassigned      YES NVRAM  administratively down down    
GigabitEthernet0/3         unassigned      YES NVRAM  administratively down down    
AP-DNS#sh ip route
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area 
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
       a - application route
       + - replicated route, % - next hop override, p - overrides from PfR

Gateway of last resort is 10.1.4.254 to network 0.0.0.0

S*    0.0.0.0/0 [1/0] via 10.1.4.254
      10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C        10.1.4.0/24 is directly connected, GigabitEthernet0/0
L        10.1.4.101/32 is directly connected, GigabitEthernet0/0
AP-DNS#conf t
conf t
   ^
% Invalid input detected at '^' marker.

AP-DNS#
Crap. Maybe we need more commands on the client:
AP-DNS(config)#aaa authorization commands 3 default group tacacs+ if-authenticated
AP-DNS(config)#aaa authorization commands 15 default group tacacs+ if-authenticated
AP-DNS(config)#aaa accounting commands 3 default start-stop group tacacs+
AP-DNS(config)#aaa accounting commands 15 default start-stop group tacacs+
AP-DNS(config)#
I can run "test rib route show 1" as me, not as Bob, so kind of working:
AP-DNS#test rib route show 1
Command authorization failed.

AP-DNS#
Other commands are also working as they should:
SW1#telnet 10.1.4.101
Trying 10.1.4.101...
Connected to 10.1.4.101.
Escape character is 'off'.

username: dodgybob
password: 

AP-DNS>en
Password: 
AP-DNS#sh priv
Current privilege level is 15
AP-DNS#sh ip route | b Gate
Gateway of last resort is 10.1.4.254 to network 0.0.0.0

S*    0.0.0.0/0 [1/0] via 10.1.4.254
      10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C        10.1.4.0/24 is directly connected, GigabitEthernet0/0
L        10.1.4.101/32 is directly connected, GigabitEthernet0/0
AP-DNS#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
AP-DNS(config)#int gi 0/2
AP-DNS(config-if)#ip add 12.12.12.12 255.0.0.0 
Command authorization failed.

AP-DNS(config-if)#
This is exactly what I want! So, why does "sh ip route" route work, when it shouldn't? Turns out that it's down to the privilege level. It helps to Google the crap out of it, and here is the doc I found: http://www.cisco.com/c/en/us/support/docs/security/secure-access-control-system/113590-acs5-tacacs-config.html. Let's see how things should have been done from the get-go.

ACS Command Authorization (working)

Before we go into the actual configuration of both the TACACS+ client, and the ACS, here is the proof:
SW1#telnet 10.1.4.101
Trying 10.1.4.101...
Connected to 10.1.4.101.
Escape character is 'off'.

username: dodgybob
password: 

AP-DNS>en
Password: 
AP-DNS#sh priv
Command authorization failed.

AP-DNS#sh ver | i ios
System image file is "flash0:/vios-adventerprisek9-m"
AP-DNS#sh ip int bri
Interface                  IP-Address      OK? Method Status                Protocol
GigabitEthernet0/0         10.1.4.101      YES NVRAM  up                    up      
GigabitEthernet0/1         unassigned      YES manual administratively down down    
GigabitEthernet0/2         unassigned      YES manual administratively down down    
GigabitEthernet0/3         unassigned      YES NVRAM  administratively down down    
AP-DNS#sh ip route
Command authorization failed.

AP-DNS#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
AP-DNS(config)#int gi 0/2
AP-DNS(config-if)#ip add 12.12.12.12 255.255.255.0
Command authorization failed.

AP-DNS(config-if)#no shut
AP-DNS(config-if)#
AP-DNS(config-if)#shut
AP-DNS(config-if)#end
AP-DNS#exit
Connection closed by foreign host.
SW1#
This is using the exact commands we have permitted, and the others are denied. My own account still has full access. Now let's break down the working configuration!

The Lvl-3-Commands command set has not changed since we implemented it, but I have added a new one, for Level-15-Commands:

ACS working level 3


We are not specifying any commands, so the table is empty, but we are allowing any commands that are not in the table - which is everything.

The Shell profile has changed:

ACS working level 3 common tasks

Notice now the default privilege is 1. We also have a LVL-15 shell profile, which has the default set at 15:

ACS working level 15

That's it for the Policy Elements section.

We have just two service selection rules (the defaults):

ACS working service selection

The one we are interested in is Rule-2 for TACACS+, but this has not been edited, so we can head straight to the Default Device Admin. I have edited this to include "Group Mapping":

ACS working group mapping

We have two group mappings:

ACS working groups

The level-3 group connects the AD group "Network-Support" to the identity group "Level-3 Group":

ACS working level 3 group

The level-15 group is similar, connecting the Network-Admin group to the identity group "Level-15 Group" (or it would be if I had named it correctly):

ACS working level 15 group

The Identity has not changed, we are still bound to AD, as we were in the previous post. All the magic happens in the Authorization:

ACS working authorization

We have a rule for each of our levels. Both are similar:

ACS working authorization level 3

ACS working authorization level 15

The last bit to show is the Identity groups, and this is just two groups for us to use as containers, just give them a name and that's it:

ACS working identity groups

Although this took a lot of Googling to finally get the answer, there does seem to be a lot of conflicting information, most said that everyone (including the ones you want to limit) should get privilege level 15 to begin with, then we limit down the commands as needed. The Cisco doc linked above actually has it the other way around, we limit to begin with (privilege level 1), then increase as needed (by adding the commands we allow).

The client configuration is below:
AP-DNS#sh run | i aaa
aaa new-model
aaa authentication login default group tacacs+ local
aaa authorization config-commands
aaa authorization exec default group tacacs+ 
aaa authorization commands 1 default group tacacs+ local 
aaa authorization commands 3 default group tacacs+ 
aaa authorization commands 15 default group tacacs+ local 
aaa accounting commands 9 default start-stop group tacacs+
aaa session-id common
AP-DNS#
The flip side is that I have probably learnt more about ACS this way, than if things worked straight away. It is definitely better to get this kind of trial and error out of the way now, than in the exam. It's certainly not as "clean" as I would like it to be. ACS is highly configurable, and really this should all be done under a separate selection policy, but that's something to keep for later when I set up a new lab as preparation for the real thing.

I think we will return to ISE next, and look at web auth.

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

Related Posts

Previous
Next Post »