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.
So, we'll give the ACS a quick reboot, and wait for the ACS services to start up again.
Thats better!
We'll give Bob some commands to run. At the moment, he cannot do much:
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:
On the next page as accept the defaults, and click on Finish:
We get a little message pop up telling us that it's been created, asking is we want to modify the service selection:
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:
Click on Create:
We can't specify Telnet as the protocol, so we need to specify Tacacs here:
Click on OK, then move it to the top of the list:
Save the changes.
Under the Bob Access Service, we need to select the correct Identity:
Hopefully this is correct!
You should see it in the list:
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:
If we click OK here, we are told that we need to select at least one condition, so let's do that:
The new policy is accepted:
Save the changes.
Let's test it and see if it works or not.
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:
We can then edit the rule, so that it looks like this:
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:
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:
But we are getting closer:
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":
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:
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:
I ended up with this:
Does this work?
The Lvl-3-Commands command set has not changed since we implemented it, but I have added a new one, for Level-15-Commands:
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:
We have two group mappings:
The level-3 group connects the AD group "Network-Support" to the identity group "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):
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:
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:
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:
I think we will return to ISE next, and look at web auth.
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.
So, we'll give the ACS a quick reboot, and wait for the ACS services to start up again.
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.
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:
On the next page as accept the defaults, and click on Finish:
We get a little message pop up telling us that it's been created, asking is we want to modify the service selection:
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:
Click on Create:
We can't specify Telnet as the protocol, so we need to specify Tacacs here:
Click on OK, then move it to the top of the list:
Save the changes.
Under the Bob Access Service, we need to select the correct Identity:
Hopefully this is correct!
You should see it in the list:
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:
If we click OK here, we are told that we need to select at least one condition, so let's do that:
The new policy is accepted:
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:
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:
We can then edit the rule, so that it looks like this:
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:
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:
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:
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:
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:
I ended up with this:
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:
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:
Notice now the default privilege is 1. We also have a LVL-15 shell profile, which has the default set at 15:
That's it for the Policy Elements section.
We have just two service selection rules (the defaults):
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":
The level-3 group connects the AD group "Network-Support" to the identity group "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):
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:
We have a rule for each of our levels. Both are similar:
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:
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.
