Create Access Rules for Specific Users/Groups

You are here:


Access to Northern’s self-service data management interface is controlled through Access Rules. These are rules that connect individual users, and/or AD groups, with the data repositories that they are responsible for. Via Access Rules users are able to login to the self-service interface, view information about the status of their file shares/SharePoint sites, and act on situations that require remediation – deleting redundant convenience copies of Records, for example.

There are two methods for creating Access Rules:

  1. Creating individual rules for specific users/groups (the topic of this article).
  2. Mirroring file system permissions to automatically create and maintain rules. These are called ‘Access Rules Policies’.

This article describes how individual Access Rules are created for specific users/groups.


1 Access Rules are created within the administrative pages of the console. Begin by logging into the Northern console.
2 In the left-hand menu click on “Administration” (1)-> “Security” (2)-> “Access Rules Users/Groups”(3)
3 Click on Create Rule on the right side of the page.
4 Add the user account or AD group that should have access in User/Group (4). Use domain\account format.
ex: northern-lab\adanna.coyWhen you begin typing a user\group the software will display a list of accounts that match the string you’ve entered. These accounts are retrieved from the local (to the NSSX service account) domain controller as you type.If you are unable to add an account here, it would usually suggest that the NSSX service account does not have sufficient rights to enumerate accounts in Active Directory, or that the desired user/group is in a different domain to the NSSX service account and there is insufficient trust between these domains for the enumeration request to be forwarded between the domain controllers.
5 Choose an Application Role (5) from the drop-down list.
NOTE: See ‘How to Create an Application Role’ for more information.
6 Specify if a welcome email should be sent to the affected user(s). This requires that the SMTP configuration has been completed and that the welcome email template has been edited (if necessary) to fit the needs of your organization.
7 Choose a Path role (6) from the drop-down list.
NOTE: See ‘Security Role’ for more information.
8 Enter a Path (7) that the user/group should be able to access information about.

When you begin typing a path, the software will display a list of available paths that match the string you’ve entered (‘Live Search’). This list only includes paths that have been scanned.

If you are scanning sub-directories to this path as separate paths in the scan configuration and you wish the user/group to also see these sub-directories as separate entries in the console, then you must choose to Include Subs (8).
NOTE: There is no effect if ‘Include Subs’ is checked when no sub-directories to the specified path are being scanned.

The paths entered here depend on the scan configuration in your environment. For example, if you are scanning Department Shares as individual paths (\\server\DepShares\Dep1\, \\server\DepShares\Dep2\, \\server\DepShares\Dep3\, etc.) and you wish to give a specific user access to information about his/her department’s file share, then you should enter the specific department share (\\server\DepShares\Dep2\). If you wish to give a Record Manager access to information gathered across all of these shares, then you can specify the root path (\\server\DepShares\) and check the ‘Include Subs’ checkbox.

  • Enter full paths for shares/sites to allow access only to the shares/sites specified.
  • Enter high-level paths, server names, and/or SharePoint domains to allow access to the specified path and all paths scanned below that level.
  • Use ‘*’ to give access to information gathered from all paths that have been scanned.
9 Click on Add Path (9) to add the selected path to the path list for this Access Rule.
10 Review your configuration and click on Create Access Rule.


11 Results are best verified by asking one or more users, who should now be able to access the Console interface, to login (http://your-console-server-name/nssconsole) and confirm that they have access to the features/information you intend to allow them to use/see. This may also be a good opportunity to explain in more detail what they are expected to do with the features/information now available.


Last updated: August 30, 2019