Jump to content
Welcome to our new Citrix community!

Citrix ADC - readOnly user + report section


Angelo Pollastro

Recommended Posts

Hi i have a citrix adc with NS13.0 67.39.nc software version.
I have created two user in read-only permission, when i login with the read-only user and i click "report" appears error "User does not have permission to view this page"
How i can set permission to view at these two user in read-only the report sevtion?

 

Regards
Angelo

err.png

Link to comment
Share on other sites

Look in syslog for the commands that were denied.

(fyi - I tested the wrong thing at first, I thought you were looking at the System > Reports node and not the REPORTING Tab - so giving you a much more accurate answer now.)

 

The REPORTING Tab

To get the Reporting tab to load, you need access to these commands in addition to read-only rights:

(^show reporting.*)|(^show system datasource.*)|(^show system globaldata.*)|(^show system session)

 

Option1:

Create the new custom_reporting policy with just these new rights in them and bind both the read-only (default) and the custom_reporting command policy to user you System User or System Group.

Option 2:

Create a copy of the default read-only permissions as custom_reporting2 policy and append these additional patterns to the expression.

 

# option 2 - two separate policies that add together, using default read-only rule

add system cmdPolicy custom_reportadmin1 ALLOW "(^show reporting.*)|(^show system datasource.*)|(^show system globaldata.*)|(^show system session)"

bind system group testadminsA read-only 100

bind system group testadminsA custom_reportadmin2 110
 

# option 2 - one policy with read-only + reporting rights

add system cmdPolicy custom_reportadmin2 ALLOW "(^man.*)|(^show\\s+(?!system)(?!configstatus)(?!ns ns\\.conf)(?!ns savedconfig)(?!ns runningConfig)(?!gslb runningConfig)(?!audit messages)(?!techsupport).*)|(^stat.*)|(^show reporting.*)|(^show system datasource.*)|(^show system globaldata.*)|(^show system session)"
bind system group testadminsB custom_reportadmin2 100
 

How To Determine:

In general, there are two ways to approach figuring out which admin rights you need.

1) view syslog for the custom admin and review the "denied" rules to update the custom policy. Then logout and back in to test the new settings until all denials are resolved.

or 

2) view syslog for a working superuser and review the allowed audited commands to see what you might be missing (if the first method isn't quite helping.)

 

When developing custom command policies, generally start with a copy of read-only as your new customadminpol. Then figure out what additional allow patterns you need. If the allow is not permissive enough, the GUI may not even load.

 

To view syslog:

shell

cd /var/log

tail -f ns.log

tail -f ns.log | grep CMD_EXEC   # to see audit commands only....

 

 

 

  • Like 1
Link to comment
Share on other sites

You are a netscaler dragon! :)

thx for help works!

 

Only another question: i see in another port 

 

suggested putting this string, and remove (?!system)

(^man.*)|(^show\s+(?!configstatus)(?!ns ns\.conf)(?!ns savedconfig)(?!ns runningConfig)(?!gslb runningConfig)(?!audit messages)(?!techsupport).*)|(^stat.*)

 

Original read-only:

(^man.*)|(^show\s+(?!system)(?!configstatus)(?!ns ns\.conf)(?!ns savedconfig)(?!ns runningConfig)(?!gslb runningConfig)(?!audit messages)(?!techsupport).*)|(^stat.*)

 

It's correct this configuration?

 

Regards

Angelo

 

6 hours ago, Rhonda Rowland1709152125 said:

Look in syslog for the commands that were denied.

(fyi - I tested the wrong thing at first, I thought you were looking at the System > Reports node and not the REPORTING Tab - so giving you a much more accurate answer now.)

 

The REPORTING Tab

To get the Reporting tab to load, you need access to these commands in addition to read-only rights:

(^show reporting.*)|(^show system datasource.*)|(^show system globaldata.*)|(^show system session)

 

Option1:

Create the new custom_reporting policy with just these new rights in them and bind both the read-only (default) and the custom_reporting command policy to user you System User or System Group.

Option 2:

Create a copy of the default read-only permissions as custom_reporting2 policy and append these additional patterns to the expression.

 

# option 2 - two separate policies that add together, using default read-only rule

add system cmdPolicy custom_reportadmin1 ALLOW "(^show reporting.*)|(^show system datasource.*)|(^show system globaldata.*)|(^show system session)"

bind system group testadminsA read-only 100

bind system group testadminsA custom_reportadmin2 110
 

# option 2 - one policy with read-only + reporting rights

add system cmdPolicy custom_reportadmin2 ALLOW "(^man.*)|(^show\\s+(?!system)(?!configstatus)(?!ns ns\\.conf)(?!ns savedconfig)(?!ns runningConfig)(?!gslb runningConfig)(?!audit messages)(?!techsupport).*)|(^stat.*)|(^show reporting.*)|(^show system datasource.*)|(^show system globaldata.*)|(^show system session)"
bind system group testadminsB custom_reportadmin2 100
 

How To Determine:

In general, there are two ways to approach figuring out which admin rights you need.

1) view syslog for the custom admin and review the "denied" rules to update the custom policy. Then logout and back in to test the new settings until all denials are resolved.

or 

2) view syslog for a working superuser and review the allowed audited commands to see what you might be missing (if the first method isn't quite helping.)

 

When developing custom command policies, generally start with a copy of read-only as your new customadminpol. Then figure out what additional allow patterns you need. If the allow is not permissive enough, the GUI may not even load.

 

To view syslog:

shell

cd /var/log

tail -f ns.log

tail -f ns.log | grep CMD_EXEC   # to see audit commands only....

 

 

 

 

Link to comment
Share on other sites

6 hours ago, Angelo Pollastro said:

suggested putting this string, and remove (?!system)

 

You can do that, but you are giving access to way more commands.

 

So before you do this, my method is narrower.

Do either:  (help -all or help --all... I can't remember)

help -all | grep "show system .*" -i

help -all | grep ".* system" -i

and you can see how many system <object> commands and actions are present, to decide if you want to allow or prevent access to these.

 

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...