It’s not best practice to manage a Citrix ADC / NetScaler using nsroot. Most of our bigger customers use nsroot just to do an initial setup and than switch to individual users for each admin.
Creating our first user
This will be some try and error, so I use two browsers for this procedure: One with nsroot logged on, another one for testing.
We find user-management at System → User Administration → User.
We currently have just one user, nsroot. Its idle timeout is set to 900 seconds, 15 minutes. That’s perfect for a production environment, as security is our main focus, but inconvenient in a test environment. We may change this parameter at any time. This user will have to log off and on to bring changes like that into effect.
Click add and create a user: user: Test, password 1234
Let’s log on! We want you to try, using a wrong password first. We will see: Logon is not possible, and we loop back to the logon screen.
Now, let’s use the correct password: We log on, but we see some errors.
In addition, we see, there is no information about CPU, host-id and so on. There is no chance to do any changes: This user does not have any permissions. So there is still something missing!
Looking into /var/log we see tons of errors:
Let’s open this user again.
A command policy? Sounds good! Let’s click and see, what it is!
We click add. There are several built-in ones:
We don’t touch the “yellow ones”. They are for admin partitions only and out of our focus.
- read-only: this kind of users may read most of the settings, but no information about users and groups (and some more). No access to BSD shell. This kind of users will face an error message after logon, you may ignore it.
- operator: Like read-only, but permissions to enable/disable servers and services.
- network: A user with almost all permissions, but a bit outdated. Use sysadmin instead.
- sysadmin: May do almost everything, but has no access to shell and user-management. This user does not face errors during logon.
- superuser: Like nsroot.
You may create your own command policies if you click add. Creating command policies is creating regex on command-line commands. for example ^(add|rm|set|bind)\s(lb\svserver) will give you permissions on load-balancing vServers.
There are a more user-friendly command editor and an admin-friendly regex-editor.
You may find command policies at System → User Administration → Command Policies.
You may bind more than just one command policy. All policies have to be bound with a certain priority, default is 100. They will be evaluated from the lowest to the highest number to find a matching policy. The first matching policy will get applied and the command will be allowed or denied. The command will be denied if there is no pilicy match.
(see next chapter: Command policies)
Creating groups
Creating too many users and binding policies to these users may be much work to do. So we could create groups instead and bind users to these groups. Creating groups is as simple as creating users: System → User Administration → Groups.
Create a group, add existing users to this group (you may also add groups to users) and don’t forget to bind command policies to groups.
A user may be a member of several groups, but it may be hard to predict user-rights if you do so. That’s why you should avoid binding users into many groups.
[wpedon id=”798″ align=”center”]
