Report View ACL Analysis

[chuckn]

We were recently notified by ServiceNow that a batch of report view ACLs would be activated in our production instance if we did not activate them ourselves (see KB0958442). They provided a great analysis tool in the ACL Assessment for Reports. When that analysis came back saying we have hundreds of reports to review, we wanted a faster way to generate the list of all the potentially affected users instead of going through each report individually. If you're looking for something similar, this code should do it for you.

var limit = 50;
var c = 0;
var gg = new GlideRecord('report_view_acl_assessment');
gg.query();
while (gg.next()) {
	var uu = new GlideRecord('report_view_acl_assessment_users');
	uu.addEncodedQuery('report_view_acl_assessment=' + gg.sys_id);
	uu.query();
	if (!uu.hasNext() && c < limit) {
		c++;
		gs.print('checking ' + gg.report.title + ' (' + gg.report.sys_id + ')');
		var worker = new GlideScriptedHierarchicalWorker();
		worker.setScriptIncludeName('sn_report_acl.ReportViewACLImpactUtil');
		worker.setScriptIncludeMethod('insertAffectedUsersFromReport');		
		worker.putMethodArg('reportAffectedSysId', gg.sys_id);
		worker.setBackground(true);
		worker.start();
		gs.print(' --> ' + worker.getProgressID());
	}
}

It's configured to limit how many reports it analyzes during each run (limit). Once finished, the resulting records are created in report_view_acl_assessment_users.

By default, the assessment tool only returns five potentially affected users for each report. If you want it to return more, change the sn_report_acl.com.par_report_acl_assessment.max_affected_users system property (see the KB for more details). To find the reports where max_affected_users was reached, you can use this GlideAggregate query:

var ga = new GlideAggregate('report_view_acl_assessment_users');
ga.addAggregate('COUNT', 'report_view_acl_assessment');
ga.addHaving('COUNT', 'report_view_acl_assessment', '>', '9');
ga.query();
while (ga.next())
    gs.print(ga.getDisplayValue('report_view_acl_assessment'));

[Mario Garcia]

I've ran the first script and am trying to figure out where the records are stored I see they are stored in report_view_acl_assessment_users , but where specifically is that?

Thank you. 

[apjohn2]

Thank you for this Chuck.

Are you aware of any information about what exactly we're supposed to do (beyond what the KB article says) to prevent users we find from having issues once the RVAs are activated? Either that, or perhaps an example of the specific steps your organization is taking to prepare for RVAs?

I'm not sure if I need to create a custom role (which they say is an option), or if I need to give the users some role that they don't have already, or what. It's just not very clear to me.

I am preparing now to dig into the KB article again and read it over and over until something *clicks* here but so far I'm still fuzzy on this part.

Any help would be very much appreciated, and thank you again for posting this info!

[chuckn]

Hi Aaron!

You're welcome! Glad it's helpful!

Great question about what action(s) to take (the KB is quite dense). Being up front, at this point, we're still working through that same question ourselves. I appreciate your call-out regarding custom roles, though, as that's something I assumed would not be permitted. But per the KB article (at least as of today):

• You can create a new role, associate it with the ACL listed.

And:

Licensing considerations – When assigning roles to groups for users, take subscription licensing into consideration.  Applications that are entitled to use the "fulfiller" roles (e.g., ITSM and CSM) have a different subscription basis than a report viewer or "Requestor" role.  Using a "non-Fulfiller" group to assign the report view access control roles grants access to reports without impacting subscription. Using groups that have been identified as fulfillers will impact subscriptions if added users were not previously subscribed as fulfillers. Reach out to your Sales Representative or Account Manager for specific contractual details regarding role types, subscriptions, and licensing.

(bolding and underlining mine)

Based on that, I'm inclined to create some custom roles, create related custom report_view ACLs (so as to leave the OOB ACLs alone) with those roles assigned to them, and add those roles to the relevant groups.

Obviously, since this does relate to licensing, it's recommended to run your solution (or mine) past your account rep as your mileage may vary.

Thanks!

[chuckn]

Adding some observations after testing this approach.

I had initially:

1. Created a new custom report_view ACL for asmt_metric_result and added a new custom rva_assessment role to it.
2. Created a group, added the rva_assessment role to it, and add a user to it who was previously identified as not having access based on the ACL Assessment for Reports.

Then I reran the ACL Assessment for Reports. To my surprise, the user was still listed as not having access.

Then I modified the OOB ACL referenced in the Table ACLs Link for one of the reports based on that table by adding a role to it. After rerunning the ACL Assessment again, it no longer listed the user as not have access.

So that leads me to wonder: is the ACL Assessment only looking at specific OOB ACLs to determine if a user has access? It would seem so based on these observations. I'm a bit unclear about what that means regarding how access would be affected once the report_view ACLs are enabled. I would think that ensuring users have a role that is required by a report_view ACL would be sufficient for access, but that may not be reflected in the ACL Assessment report.

[M_Murry]

Thank you for this Chuck!

I added some guardrails in my version of the script. This can be setup as a scheduled job and run whenever you need to so it doesn't timeout in Scripts - Background. This script checks to see if the app is installed and if the scan has been run since those are both prerequisites. Also, it calculates the upper bound of how may records would be created by multiplying the value of the sn_report_acl.com.par_report_acl_assessment.max_affected_users property by the total number of affected reports. If the value is greater than 75000 records, the script doesn't generate them. You can set this value to what you like, but having a control mechanism to prevent unexpected table growth was important to me. Also, you can run this as a dry-run first to see what you should expect and just have to set DryRun = false on line 2 if you want to actually generate the records on the report_view_acl_activation_log table.

//rerunning the assessment scan removes these records from the report_view_acl_assessment_users_list
var DryRun = true; // set this value to false when you are ready to generate these records

//check if application is installed
var appInstalled = GlidePluginManager().isActive('sn_report_acl');

var scanLogCount = '0';
//check if assessment scan has been run
try {
  var grAssessmentScan = new GlideRecord('report_view_acl_activation_log');
  grAssessmentScan.addQuery('is_generate_report', 'true');
  grAssessmentScan.query();
  scanLogCount = grAssessmentScan.getRowCount();
} catch (error) {
  gs.info('An error occurred querying the [' + grAssessmentScan.getTableName() + '] table - ' + error);
}
if (appInstalled && scanLogCount > 0) {
  generateUsers();
} else {
  gs.info('Please install the ACL Assessment for Reports application and run the scan in the application before running this script.')
}

function generateUsers() {

  var acceptableMaxRecords = 750000; //change this to what you feel is acceptable for your instance
  // Get all affected reports
  var reports = new GlideRecord('report_view_acl_assessment');
  reports.query();
  // check number of affected reports X upper limit of users returned and exit if over 750K records could be generated
  var numAffectedReports = parseInt(reports.getRowCount());
  var upperLimitOfAffectedUsers = parseInt(gs.getProperty('sn_report_acl.com.par_report_acl_assessment.max_affected_users'));

  if ((numAffectedReports * upperLimitOfAffectedUsers) <= acceptableMaxRecords) {

    gs.log("Number of Affected Reports: " + reports.getRowCount());
    gs.log("numAffectedReports * upperLimitOfAffectedUsers: " + (numAffectedReports * upperLimitOfAffectedUsers));
    // Initialize script include - ReportViewACLImpactUtil
    var reportViewACLImpactUtil = new sn_report_acl.ReportViewACLImpactUtil();

    // Iterate through affected reports
    while (reports.next()) {

      // Call method to generate affected users for affected report
      if (!DryRun) {
        reportViewACLImpactUtil.insertAffectedUsersFromReport(reports.getValue('sys_id'));
      } else {
        gs.info('DRY RUN - Setting DryRun variable to false would have called insertAffectedUsersFromReport method for Affected report ' + reports.getValue('sys_id') + ' Report Name: ' + reports.getDisplayValue())
      }
    }
    return;
  }
  gs.info('skipping script as it could generate over ' + acceptableMaxRecords + ' affected user records. This could cause performance issues and is not recommended')
}

[Chuck Nusbaum]

Wow! Outstanding additions! Thank you! 🙂

[Chuck Nusbaum]

Just confirming based on a HI case I opened: yes, the Report View ACL Assessment tool is only checking OOB ACLs. I'm inquiring further about why that is...it may have just been a function of a time. I just know we try to minimize editing OOB anything if we can, and it's certainly possibly to create parallel ACLs to grant a different role the same access.

[chuckn]

Just confirming based on a HI case I opened: yes, the Report View ACL Assessment tool is only checking OOB ACLs. I'm inquiring further about why that is...it may have just been a function of a time. I just know we try to minimize editing OOB anything if we can, and it's certainly possibly to create parallel ACLs to grant a different role the same access.

[chuckn]

Wow--outstanding! Thank you for the additions!

[chuckn]

HI didn't provide a specific reason for their decision (aside from not modifying customizations, which I don't think is really a factor here...it's more about evaluating if a user does or doesn't have access based on ACLs), but it is confirmed that the assessment tool only checks the OOB ACLs. I tested myself and confirmed that custom report_view ACLs using custom roles do permit users to see reports, so that's the route we'll go.

[Gowtham2]

Hi All

This is a great article with very supportive responses. I think going through this Article provided more versatile information than RVA KB published by ServiceNow.

Quick question - For us there are around 500+ reports which are having affected users, do we need to manually create ACL and role for each report and assign those users with role ? 

Regards

Madhav

[chuckn]

Hi Madhav,

You don't have to create ACLs and roles for each report if you use the existing roles that ServiceNow identifies in the Report View ACL Assessment tool. For example, you could grant itil which would likely allow access to many of your reports...however, there are licensing implications of granting that role. If you do create custom roles and either (1) add them to the respective OOB ACL or (2) create a custom ACL for the respective table, then there are no licensing implications per the KB article (all licensing questions should be referred to your account team).

Hope that helps!

-Chuck

[KSLN SAHITHI]

Hi @chuckn Where can we write this script?

[apjohn2]

Hi @KSLN SAHITHI - I ran the script in Scripts - Background and it worked for me. Hope this helps.

[chuckn]

Same here, via background script: /nav_to.do?uri=%2Fsys.scripts.do

[SM16]

• I think it applies only to the classic reports and has no impact on Performance Analytics. Am I right?
• Is it compulsory to activate RVAs? Even we got it for our instance to activate them.
• After running the script, what did you do with the results?

[chuckn]

Hi SM,

Correct: as far as I am aware, these report_view ACLs only apply to sys_report reports, not to PA.

From my understanding, report_view ACLs are not optional. The KB article does say that they can be disabled but that opens the risk of unintended access to table data.

If you're referring to running the scripts above, all they are intended to do is streamline creating the related records in report_view_acl_assessment_users which you'll want for analysis. Those records show which users currently have access to reports that they will not be able to see once the report_view ACLs are activated.

Thanks!

-Chuck

[Nagarjun S]

Hi Chuck,

I have added a custom ACL of type 'report_view' and added a custom role to that ACL. Then added that custom role to user. But still user is not able to access the respective report. Could you please tell me, where i am going wrong?

Thank you

[chuckn]

Hi Nagarjun,

Couple of thoughts:

1. Did the user log out and back in after the new role was assigned? That's required to pick up the new role.
2. Can you confirm the custom ACL applies to the table on which the report is based? And confirm the custom ACL is active?

Thanks!

[chuckn]

It seems the RVA saga continues. Today we got word that ServiceNow recommends using the ACL Assessments for Reports tool after every upgrade, patch, and store update to make sure that RVAs aren't disabled as a result of said upgrade, patch, or store update. I'm pursuing additional information because this doesn't seem like an acceptable solution since we were required by ServiceNow to enable to the RVAs in the first place.

More to come!

[Geet2]

Hi,

Thanks for sharing this article, it really helped to understand and clear many things.

I have 1 question.

As I see multiple table reports are affected, what is the best practice to create role(s) and assign to tables.

Example: I created a role = report_acl_assessment

I assigned this role to all the affected acl of incident table. Also, will assign this role to users who are not able to view incident table reports.

Now for other tables, such as change_request, problem, sc_req_item, what should be the best way to use the role? shall I assign report_acl_assessment role to all the report_view acls of these tables?

OR

I should create separate custom roles for each table.

Kindly suggest!

Regards,

Geet

[chuckn]

Hi Geet,

I would create roles based on how you want to segment access to reports for various tables. If you always want the same people to have access to incident, change_request, problem, sc_req_item, etc, then using your report_acl_assessment role should work just fine. However, if you want to restrict access to, say, problem to a subset of users, then you could create a new role specifically for that table.

Hope that helps!

-Chuck

[chuckn]

Got an update from HI Support today that they will be introducing a fix (anticipated to come in July, 2022) to address this issue and prevent RVAs from being disabled during upgrades, patching, and updates.

More information is available in KB1121670.

Thank you, ServiceNow!

[Luiz Lucena]

Thanks everyone for all input and discussion around this. This would be extremely helpful!

We had a case opened with ServiceNow, ZERO help in there. To be honest, this was one of the most terrible implemented decision they did I've ever seen. 
From security perspective, OK, but they should have created a READ_ONLY role instead of assigning application_admin.