Permissions by Default Class
The first exercise demonstrates creating users and using default classes. Two users are created 'read' and 'admin'. The 'read' user should only have read-only access and the 'admin' user should have access to everything. Below is a screenshot displaying the configuration for the two users along with the desired permissions.
The user creation, class assignment and password can all be entered with a single command for each user.
The output below shows that the 'admin' user has access to the configuration mode and the user 'read' does not.
This exercise will demonstrate the use of permission bits and some allow/deny commands. We will do this by creating a new login class and configuring these items in the login class. For more information on permission bits and classes see my post "Users and User Accounts in Junos". We will use the existing users created in the previous exercise with some slight modifications.
We want to make the following changes to the 'read' user;
1. can access and configure interfaces
2. can access and configure ospf, but not ospfv3
To accomplish these requirements we need to add the 'configure' and 'interface-control' permission bits to the new class named 'custom_class1'. This will allow the user to gain access to the configuration menu and access all commands under the interface hierarchy. To only allow configuration of ospf and not of ospfv3 we can use the allowed-configuration statement with some Regex operators. By specifying the "$" we are instructing junos to match exactly to that point. If we would have used the statement "protocols ospf" we would match on ospf and ospfv3 which we do not want in this case.
We want to make the following changes to the 'admin' user;
1. maintain 'all' permissions
2. cannot restart the device
To accomplish these requirements we can use the deny-commands statements within a new class named 'custom_class2'.
Here is how the configuration looks.
The screenshot below outlines that the user 'admin' is not able to reboot the device by running the request system reboot command.
This screenshot demonstrates the new access that the user 'read' has. This user can enter the configuration mode and edit interfaces but cannot edit other parameters such as firewall filters. This user can also edit ospf but not ospfv3.
Interesting Facts & Conclusion
When completing these exercises I noticed that committing changes to the user's class when the user was logged in did not take effect until that user logged out and back into the system. Next I will be working on similar exercises using RADIUS authentication.