Cisco CCIE Security 350-701 – AAA Authorization Part 3

4. IOS Privilege Levels _ Limitations

IOS privilege Levels and Limitations now, in this video we’ll try to understand what are the limitations of iOS privilege levels. Like the first one is, as we discussed earlier, the commands at the lower privilege levels are always executable. At higher privilege levels, like in the previous we discuss, we see some configuration where I have assigned a user with a privilege level of five and also we have created a user with a privilege level of two with a user two as a username. So by default all the commands which are defined in the privileged level of two, privileged level of two, the user with the privilege of five can access, but the user with the privilege of two cannot access the commands at the higher level. So that is one limitation.

So you cannot create any distinct profiles like, take an example, you got a security engineer and I want to assign a privilege level of, let’s say five or maybe, let’s say ten here and I’m creating another profile here, let’s say maybe a routing switching engine. And this routing switching engine, I’m going to assign a privilege level of eight. Let’s say by default you can assign same level for both, but the same commands will apply. But let’s say if I’m giving ten here, which means the security engineer can automatically use or execute all the commands defined in the privilege level of eight and but the router switching engineer cannot execute any commands which are defined inside the privilege of ten unless defined in this. So that’s one kind of limitation.

We cannot create two distinct isolated privilege levels that are not possible because sometimes you may want the routing switching engine as well as security engineer. So whatever the commands we defined in the security engineer, like maybe some VPN related commands like access list or applying some any other security policies so I want the routing engineer should not be able to execute anything. So likewise, any specific configurations relating to routing or the one interfaces security unit should not modify any specific things.

So we cannot create two distinct profiles, user, user specific commands, you cannot use two isolated levels, that’s not possible. The same example and one more thing, you cannot control specific commands to specific interfaces, codes or logical interfaces or slots like so take an example, I have a routine here and then we got some interfaces here, maybe a zero page interface and we got some other interfaces like tunnel interfaces. So we use tunnel interfaces for VPNs. Or maybe you have one more interface which is connecting to service portal running some kind of BGP and you want to make sure that your level two engineer should be able to execute everything on specific interfaces like s zero by zero, s zero by 10 by zero. But he cannot make any changes onto this interface or maybe he cannot make any changes onto the tunnel interface.

There’s something we cannot do because whenever you assign this user interface specific commands, he can execute those commands at every interface level and the next thing is assigning the commands with the multiple keywords, the fuel level automatically assign all the commands. Like let’s say if I assign a user fire to be able to execute a router commands inside the global configuration mode and when we say router OSPO now he can execute router OSPF, router BGP, router Rip as well as EHR like that. So if I want to restrict not to use router BGP commands because I don’t want my junior engineer or level to engineer to make any changes to the BGP configurations.

So once you assign a user with the router specific commands he can execute, he can use all the router level commands at the same time. Another drawback is like if the administrator need to access most of the commands. Like he got a user assigned with a field of ten. And I want this user to be below all the commands except few commands. Like all the commands you want to allow, maybe a few commands accept so you may end up need to allow all the commands here. So with the local authorization we cannot say accept or allow all the commands or deny specific commands. So we cannot actually filter in a better way. So that’s the reason in today’s networks privilege levels are not widely used because we have some better and scalable solution.

5. Role based CLI Access – RBAC

Cisco iOS role based seal access. So it’s also called as role based access control, or in other words, we can call them as tableau views. Now, this tablet views or Role based Access control is a newer and a flexible way of assigning a specific user with a specific commands. Same like a privilege levels. But we got a newer and a flexible method to control what commands the user can execute. So here instead of using the privilege levels, we are going to create some views. Like I’m going to create a view called Security engineer and I’m going to associate all the commands relating to security and then I’m going to create another view with a name called Routing Switching engineer and we’ll associate all the commands relating to routing switching in that views.

And then we’ll associate the user, let’s say I’m creating a user five, who is my security engineer and we associate this view and then we’ll create a user six, let’s say associating the routing switching view. So same like privilege levels, but here we create views. The main difference is these two views are actually isolated, so there’s no more levels here, like higher loyal kind of levels. So each and every view is like a specific separate set of commands assigned to individual users. And once we associate this user with specific views, now the user can only see the commands which are defined in that view, like when we use iOS question mark, let’s say the Routing Switching engineer assigned with a level of router OSPF.

And if you say a router router and use question mark, you can only see a specific command called Router OSPF and it cannot see any other commands like router BGP or Router EHRP commands because you want to restrict this user to make any changes only to OSPF configurations, not to the BGP configurations. And each view defines a specific commands, like I said, will define a specific commands and the views will be associating them to the users and we can test it out or we can switch to the users. While we are testing, we can also verify by switching to the different views.

Now, the main advantage of using this role based access control instead of privileged levels is we can create an isolated views. Like I can have a separate security engineer with the commands while engineer specific commands and these two views can be isolated.

So whatever the commands defined in the security engineer, these commands may not be accessible here. And whatever the commands we define in the routing switching are not accessible here unless you have a common commands like you may have some common commands like showrun and these commands may be present in both of you. That’s okay, you can still have some common commands, but whatever the command set defined in this level is not allowed or not allowed for any other user with other view. Again, and one more advantage is we can control a specific user based on specific ports, interfaces or the slots. Like you may have a requirement where you got some router, maybe some physical interfaces, maybe s one by zero here.

And I want my routing switching engineer should be able to configure all these interfaces. They can make changes to the specific interfaces. But let’s say there is one interface called tunnel interface, which I’m using for security purpose for VPNs. And I want the user who belongs to security Engineer to have access to this interface but not to other interfaces like the blue ones here, the blue ones, the colors. These are the routing switching engineer interfaces. And security Engineer can make changes to tunnel interface but not to the physical interfaces. If you want you can still allow the security engineer to access any specific interfaces as per the requirement so we can control specific commands.

We can also control we can say that the user can execute router OSP of one command router switching indeed, but not accept he can use all the router commands except router BGP because you can allow the user to add all the commands using the router but accept the BGP. We can exclude specific commands like that so it’s like a flexible way to manage the commands to a specific users. And one more thing we can only see the CLI commands that are given in that level like if I create a view with a security operator then if I use iOS help you will be able to see only the specific commands which are defined in that particular view.

So this is actually an advantage to prevent because it’s less complex and easy to use iOS help. Because if you use question mark and if you see only specific commands what you can use, it becomes very easy for the engineers to figure out which commands they can execute and of course prevent unintentional execution of the commands by any unauthorized for personnels which could result in undesirable results.