- Subscribe to RSS Feed
- Mark as New
- Mark as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
Overview
Back in 2023 I talked about the Access Analyzer plugin that had just been published. Lots of things have changed since and there are many of them that are quite interesting.
Initially this feature allowed to analyse which access a given user, group or role had. Nowadays it even allows to simulate what would happen if a user got a role, lost it, it a user left a group or joined one before doing so among other things. Let’s tackle the changes, shall we?
General view
In the past we only had a simple view to evaluate access, but nowadays we have three main sections atop:
- Analyze permissions
- Access Simulator
- Settings
Analyze permissions
Under “Analyze permissions” by default we can see the Evaluate Access tab. I encourage you to have a look at the article I wrote in 2023, since this feature works the same way.
Then we have the “Compare user records” which was added since. In here we can select two users we want to compare to know what differences they have.
Over the years, we all had to do this manually by comparing roles two users have when we were told someone who should have certain permissions couldn’t do something one of their colleagues could. It used to be a tedious process, so this feature dramatically speeds up investigation processes. When we click on “Compare user records” after choosing two people as done above, we get these results:
Under the “Details” tab we see a simple side-to-side comparison of fields. Then we have the “Roles” tab, which represents the differences in roles between those users showing in red the ones missing. A great asset for any system administrator! Bear in mind there’s a “Show differences only” checkbox that allows us to focus on the delta.
The last tab is “Groups”, which obviously shows the difference between users in terms of groups.
The next tab under “Analyze permissions” is “Compare user access”. This is quite useful for analysing whether someone has read, write, create, or any other ACL-related type of access to a table, a specific record that may be more protected than the rest, or a given field. This last is particularly interesting for encrypted fields or any other type of sensitive field that may have a different security treatment
Results are shown in a similar way as before:
An interesting feature is that we can click on those operations on the left and get extra information about the ACLs determining those results. For instance, if we clicked on “Read” we would see this:
If we specified a given record or a field, results would be displayed in the same way, an ACL type on each row and green/red depending on whether they have access or not.
Not to repeat these queries all the time, we have a way to revisit them by going to the section below called “Previously Searched Criteria”:
Access Simulator
The next tab atop is “Access Simulator” which allows us to simulate what would happen if a user has a new role, loses a role, joins a group or leaves it. An interesting feature to be performed prior to taking a decision of this type, especially if it’s a sensitive role such as “admin”, “security_admin” or any other kind of powerful permission.
This is the most exciting and visual feature that was added. Let’s simulate what would happen in regards to the “Incident” table if we granted “Abel Tuter” the “itil_admin” role by clicking on “Simulate” under “Add a Role to the user”:
This will show us a map of all the inherited roles:
A green check is shown close to the role this person will acquire, whereas a gray one means that will not change. Also we can locate a role on the map by typing it on the filter on the left-hand side at the top.
If we continue by clicking on “Next” we will, as before, see the results based on ACL types.
Finally, if we carry on to the last step and are happy with the simulation, we can click on “Enable actions” to carry out the changed we have simulated.
Bear in mind that assigning roles directly to users is not recommended, it should be done via groups instead. However, given that there’s a way to simulate a user being added or removed from a group, that would be totally fine.
Settings
Under the “Settings” tab we can see the ones about the “Access Simulator”. By default the “Enable taking actions on Role and Group assignments” property comes disabled.
If this setting is changed to “Enabled” then the question we saw above will disappear and now if we click on “Add and complete” the button at the very bottom of the screen, the action will be taken. Be mindful this is a risky setting, as you or your colleagues might end up adding/removing roles/groups to users without even realising.
If we go to the “Access Insights” tab instead under “Settings” we will find the following:
By default, the “Configure Insights” comes disabled. If we check the checkbox we will see there’s another property under it:
If we want to gain access insights, ServiceNow allows us to analyse users against others who belong to the same Manager, Department, etc… we can specify the fields we want to add to the analysis.
In order to show what this does, we need to go back to compare two users in terms of access to a table. Let’s imagine we want to compare two users about their access to the “Incident” table. Then if we click on an ACL type as we saw before, let’s say “Read” we will see this.
Now, if we click on any of those rows which represent ACLs being evaluated we will get the details about why the ACL allowed or blocked the access:
For instance, in this case, the role in this ACL is blocking Abel but not the System Admin from reading Incidents. If we clicked on “Show role hierarchy” we would get a hierarchical view of their roles and a side panel called “Access Insights” which will provide extra details. The rest can be obtained without such setting enabled, but those insights wouldn’t be shown.
Hopefully, this article has given you enough knowledge as to be able to start leaving behind manual comparisons or committing old mistakes.
Please like 👍 and share 🌍 this article to your colleagues if you found it useful.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
