Jump to content
Welcome to our new Citrix community!

Best way to limit LDAP accounts to only modify certain Services, service groups.


Stewart Roth

Recommended Posts

What is the best way to be able to limit what some users can do on a ADC?  For example, if I want a dev team member to be able to disable servers for patching etc in one service group but not be able to do the same on a different service group that isn't theirs.  Do I make custom roles?  Or do I have to use partitions and partition the service, service group in question to that partition?  Or is there a better way to accomplish this?

Thanks!!

Link to comment
Share on other sites

With delegated admin rights (custom roles aka command policies bound to system user or system group),

1) start with the operator account which is based on read-only and then grants enable/disable on service | lb vserver objects.  Create a copy of the operator as your custom operator.

2) Then when you edit the custom policy instance, you have to keep the read-only/show rights to all objects, but you can modify the section:

(Note: freehanding this, so there may be some typos)

| ((enable|disable) (server|service|servicegroup|(lb vserver)) .*) 

to

| ((enable|disable) (service|servicegroup|(lb vserver)) appname_.*)

See this thread for an example of the above:

https://discussions.citrix.com/topic/411213-app-admin-needs-access-to-a-one-vip-on-the-netscaler/

 

Bottom line, you have to allow your custom admins to SEE all the objects or the server, service, servicegroup, lb vserver nodes won't load.

But you can limit the actions you can perform enable|disable|add|rm|set|unset|bind|unbind as needed to objects with a specific naming convention.

 

With Admin Partitions:

If you can group your objects into admin partitions, then admin partitions might be easier to restrict what the admins can and can't do, BUT remember NOT ALL FEATURES are supported in admin partitions. So that may be a factor.  And you still need some admin rights restrictions within the admin partition such as a partition_operator, to keep those same admins from adjusting other settings at the partition level.

 

The other downside for Admin Partitions (for me) outside of the features that it doesn't support are that you really can't use group extraction as partition admins are assigned by user and not by group.  You also have to keep in mind to save config across all partitions if the partition admins don't do it and backing up across the partitions.  (Personally, I find properly managing the delegated admin rights to be more useful.)

 

 

 

 

  • Like 1
Link to comment
Share on other sites

Apart from Rhonda's exelent answer:

 

These command policies are simple regex to NetScaler command-line commands. Different to all documentation, these are no Pearl Regex (PCRE) but Python Regex. If you are not familiar to Regex: Use https://regex101.com/ to get friend with Regex :)

Greetings from cold and snowy Austria

Johannes Norz

CTA, CCI, CCE-N

https://blog.norz.at

https://www.wonderkitchen.network

Link to comment
Share on other sites

On 12/2/2020 at 11:07 PM, Rhonda Rowland1709152125 said:

With delegated admin rights (custom roles aka command policies bound to system user or system group),

1) start with the operator account which is based on read-only and then grants enable/disable on service | lb vserver objects.  Create a copy of the operator as your custom operator.

2) Then when you edit the custom policy instance, you have to keep the read-only/show rights to all objects, but you can modify the section:

(Note: freehanding this, so there may be some typos)

| ((enable|disable) (server|service|servicegroup|(lb vserver)) .*) 

to

| ((enable|disable) (service|servicegroup|(lb vserver)) appname_.*)

See this thread for an example of the above:

https://discussions.citrix.com/topic/411213-app-admin-needs-access-to-a-one-vip-on-the-netscaler/

 

Bottom line, you have to allow your custom admins to SEE all the objects or the server, service, servicegroup, lb vserver nodes won't load.

But you can limit the actions you can perform enable|disable|add|rm|set|unset|bind|unbind as needed to objects with a specific naming convention.

 

With Admin Partitions:

If you can group your objects into admin partitions, then admin partitions might be easier to restrict what the admins can and can't do, BUT remember NOT ALL FEATURES are supported in admin partitions. So that may be a factor.  And you still need some admin rights restrictions within the admin partition such as a partition_operator, to keep those same admins from adjusting other settings at the partition level.

 

The other downside for Admin Partitions (for me) outside of the features that it doesn't support are that you really can't use group extraction as partition admins are assigned by user and not by group.  You also have to keep in mind to save config across all partitions if the partition admins don't do it and backing up across the partitions.  (Personally, I find properly managing the delegated admin rights to be more useful.)

 

 

 

 

Replied in wrong thread.  Thanks for this.  I know where to go now.  I had no success in making it work thus far, but will keep trying.  Thanks for pointing me in the right direction.

Link to comment
Share on other sites

2 hours ago, Stewart Roth said:

had no success in making it work thus far, but will keep trying. 

 

Try sharing the expression you are trying and someone might be able to help you make corrections. The thread I reference has a more complete example. An app naming convention is also needed (case-sensitive) to be able to limit edits to only objects with certain naming conventions as opposed to all lb vservers or all services.

 

One thing to do when testing cmd policies is

1) view syslog for the deny messages AND a working account to see differences and what else might be needed.

2) Build off the read-only or operator policies to be sure GUI can load and then modify permissions.  For example, start broad and then narrow down. Get custom LB admin to do all the necessary lb tasks you want without restricting to objects with a specific naming convention (such as .*) and then try to see how the naming convention restriction works or fails with the policy defined.    

3) If all of your policies are ALLOWs, then the user or group will get the summation of all the ALLOW policies. If you start mixing ALLOW vs DENIES then priorites start coming into play and it can get complicated.  Instead of making one giant policy. You can sometimes make combinations of individual allow phrases.

4) Finally, trying CLI vs GUI might help you see that the CLI is working granularly but the GUI is failing because some dependent command isn't working yet.  Bottom line, we can make the CLI commands super-restrictive but the GUI has to allow enough show commands to display all the objects in the node; while the restrictions on the edit verbs can be implemented.

 

Also, make sure your system authentication and gorup extraction is working so the user is getting some rights.

 

To view syslog for audit denials only:

shell

cd /var/log

tail -f ns.log | grep CMD_EXECUTED

# this filter will get audited command allow/denials only and eliminate most other syslog events

 

To confirm user group extraction:

shell

cd /tmp

cat aaad.debug

# view output of the test account during the authentication event if using external accounts like ldap/radius...

 

See if this helps any.

 

 

Link to comment
Share on other sites

On 12/4/2020 at 5:54 PM, Rhonda Rowland1709152125 said:

 

An app naming convention is also needed (case-sensitive) to be able to limit edits to only objects with certain naming conventions as opposed to all lb vservers or all services.

 

 

I managed to work it out.  Unfortunately there wasn't really an app naming convention until I took it over some years ago.  There is now, but some of the services needed have none.  I complicates thigs but I got it to work.

I have an example but I am unsure on what part is needed and not needed.

(^(enable|disable) (service|serviceGroup|(lb vserver)|(ssl vserver)|(serviceGroup)) sg-QAT.* | www-QAT.*)
Not sure what the difference between "|serviceGroup|" and "|(serviceGroup)" is.

Thanks!!

Link to comment
Share on other sites

(^(enable|disable) (service|serviceGroup|(lb vserver)|(ssl vserver)|(serviceGroup)) sg-QAT.* | www-QAT.*)

 

The two phrases may be redundant or a result of missing parentheses somewhere  as the phrase in BLUE should be part of the same parenthentical  BUT your ending filter may not do exactly what you want highlighted in RED. See example below.

 

# This was modified from the example in the other post and then I modified it to be closer for what you did in your follow up....

If you want to do enable|disable across any of the objects types listed with either naming convention, then you might actually need:

(^man.*)|(^show\s+(?!system)(?!configstatus)(?!ns ns\.conf)(?!ns savedconfig)(?!ns runningConfig)(?!gslb runningConfig)(?!audit messages)(?!techsupport).*)|(^stat.*)|(^(enable|disable) (server|service|serviceGroup|(lb vserver)|(lb monitor)|(ssl vserver)) (sg-QAT.*|www-QAT.*))

 

This would basically allow;

<these verbs> on these objects (server|service|serviceGroup|(lb vserver)|(lb monitor)|(ssl vserver)) as long as the objects have one of these patterns in the name (sg-QAT.*|www-QAT.*)

 

I know the colors are hard to see in this post, but pasting into word may help.

 

Without the parentheses around the (sg-QAT.*|www-QAT.*) you might end up with (^(phrase1)|www-QAT.*) where any command with www-QAT.* in it would work.  Meaning the left and right scope of the OR clause may not be exactly what you expect.  

 

If you do the testing and its restrictive enough, no problem. If you test and you see more commands than you wanted are allowed, then you might change it.

 

 

 

 

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...