Resource Based Groups (Enhanced)

[DevonAnderson]

Version History

Version	Date	Notes
1.0	2026-04-07	Initial release — enhanced Resource Based Groups job with activity-based modeling, exact effective rights, exclusion lists, customizable group naming, and full control group support

Solution Download

FS_ResourceBasedGroups_1.0.zip (38.2 KB)

---

Installation

Step 1 — Download and Transfer the ZIP

Download the FS_ResourceBasedGroups.zip attachment from this post and transfer the file to your NAA application server.

Step 2 — Unblock the ZIP Before Extracting

Windows may block files downloaded from the internet. Before extracting, right-click on FS_ResourceBasedGroups.zip and select Properties.

At the bottom of the General tab, check the Unblock checkbox if it is present, then click OK.

If the Unblock checkbox is not present, the file is already unblocked and you can proceed.

Step 3 — Extract the ZIP

Right-click the ZIP and select Extract All, then extract to a convenient location on the server.

Step 4 — Replace the Existing Job Folder

This enhanced job replaces the out-of-the-box JOB_FS_ResourceBasedGroups job that ships with the File System Resource Based Groups solution. Navigate to your NAA Jobs directory and locate the existing Resource Based Groups solution group.

You can open the Jobs folder directly by running the following in a Run dialog (Win+R) or the address bar in Windows Explorer:

%sainstalldir%Jobs

%sainstalldir% is an environment variable set by the NAA installer that points to the installation directory.

Before replacing, rename the existing JOB_FS_ResourceBasedGroups folder to JOB_FS_ResourceBasedGroupsOLD as a backup. Then copy the new JOB_FS_ResourceBasedGroups folder into the same location.

Step 5 — Refresh the Job Tree in NAA

Once the folder is in place, either right-click in the job tree and select Refresh, or close and reopen the NAA console. The job will appear with the new configuration and analysis tasks.

---

Summary

The out-of-the-box FS_ResourceBasedGroups job in NAA transforms file system permissions to a resource-based group model — it creates AD security groups named after each folder and permission level, maps existing trustees into those groups, and then applies the new ACLs to the folders. This is a powerful concept, but the stock implementation has significant gaps that limit its usefulness in real environments:

• No way to exclude principals — service accounts, admin groups, and other trustees you don’t want in resource-based groups get swept in alongside regular users
• No activity-based modeling — the job only looks at existing permissions, so users who have permissions but never actually access a resource still get added to groups
• Open access permissions inflate results — if Everyone or Authenticated Users has access to a folder, the effective rights calculation includes that inherited access for every user, making the results misleading
• Hardcoded group name tokens — the permission portion of the group name is fixed to R, RWD, and FullControl with no way to customize
• No support for pre-existing full control groups — organizations that already have admin or IT groups that should receive Full Control on every share have no way to include them
• No visibility into where proposed access came from — when reviewing the change modeling report, there’s no way to know whether a user’s proposed access was derived from their permissions, their activity, or both

This enhanced version addresses all of these gaps while preserving full backward compatibility with the original job’s actions and reporting structure.

---

What’s New in the Enhanced Version

Activity-Based Access Modeling

The most significant enhancement. When enabled (@includeactivity = 1), the job models user access based on what users have actually done — not just what they’re permitted to do.

The activity model:

• Queries SA_FSAC_ActivityEventsView for all file access events within the configured lookback window (@activitydays)
• Recursively walks the entire folder tree beneath each target path to capture activity at all descendant levels
• Classifies each user’s access as Read (read-only operations) or Modify (any write/delete/rename operation) based on the highest operation type observed
• Assigns users to the appropriate Read or Modify group based on their actual usage pattern

When @activitypriority = 1, if a user’s activity shows a higher access level than their permissions would grant (e.g., they have Read permissions but activity shows Modify operations), the activity-based level takes priority. This ensures the modeled groups reflect reality.

Users with no activity within the @activity_filter day window are removed from the proposed groups entirely when activity modeling is enabled — eliminating stale access from the model.

Exact Effective Rights

The enhanced job introduces a new @exacteffective toggle. When enabled (@exacteffective = 1), the job uses a custom SQL function (SA_FSAA_GetExactEffectiveRights) that calculates effective permissions per direct trustee only — ignoring inherited permissions from open access principals like Everyone (S-1-1-0), Authenticated Users (S-1-5-11), and Domain Users (S-1-5-21-*-513).

This prevents the common problem where every user appears to have Full Control on a folder simply because Everyone has Read access inherited from a parent — the exact effective rights calculation only considers permissions explicitly granted to that specific user or their group memberships, not permissions inherited from broad principals.

Principal Exclusion Lists

Two new exclusion mechanisms allow you to keep specific principals out of the resource-based group model:

• Excluded Groups (ExcludedSids.csv / #excluded_groups) — provide ObjectSIDs of groups whose members should be excluded from the proposed RBG groups. The job expands group membership and excludes all effective members. The SIDs themselves are also excluded, so you can add individual user SIDs as well.
• Admin Groups (AdminGroupSids.csv / #admin_groups) — provide ObjectSIDs of groups whose members should be treated as administrators. Admin group members are excluded from the normal Read/Modify group assignment but can optionally be added to the Full Control group via @add_admin_groups.

This means service accounts, break-glass accounts, IT admin groups, and other principals you don’t want in resource-based groups can be cleanly excluded without manual post-processing.

Full Control Group Support

The new #fullcontrol_groups configuration (backed by FullControlGroups.csv) lets you specify existing AD security groups that should receive Full Control on every targeted share. These groups are resolved to their SamAccountName via AD inventory data and added to a separate SA_FS_RBG_FullControlGroups table, which is then merged into the SA_FS_RBG_GroupsToApply table used by the Modify Permissions action.

This addresses environments where an IT Operations group, a backup service account group, or a Data Governance team needs Full Control on every share — without creating a new resource-based group for them.

Customizable Group Name Tokens

The OTB job hardcodes the permission portion of group names to R, RWD, and FullControl. The enhanced version adds three new parameters:

Parameter	Description	Default
@read_groupname	Token used in group names for Read permissions	RO
@modify_groupname	Token used in group names for Modify permissions	MOD
@fullcontrol_groupname	Token used in group names for Full Control permissions	FC

Combined with the existing @naming_convention parameter, this gives full control over how groups are named. For example, with the default naming convention ACL[HostName][FolderName][Permissions] and the default tokens, a Read group for folder Projects on server FS01 would be named ACLFS01ProjectsRO.

Modeled Source Tracking

The Access Changes report now includes a Modeled Source column that shows where each user’s proposed access was derived from:

Value	Meaning
Permissions	Access was modeled from the user’s existing NTFS effective permissions only
Activity	Access was modeled from the user’s file activity only (user has no direct permissions but was active)
Both	Access was modeled from both permissions and activity data

This gives administrators full transparency into the modeling logic when reviewing proposed changes.

Group DN Generation

A new analysis task (SA_FS_ResourceBasedGroups_GroupDNs) generates the full Distinguished Name for each proposed group based on a configurable @oupath parameter. This enables the Create Groups action to place groups in the correct OU and supports downstream actions that need to reference groups by DN (such as setting group descriptions).

---

Configuration

Select JOB_FS_ResourceBasedGroups in the job tree and open the Analyze Group Permissions analysis task to access the configuration parameters.

Target Folders

Parameter	Description	Default
@levels_down	Number of levels down from share root to target. Ignored if #folders is populated.	1
#folders (UNCPaths.csv)	Explicit list of UNC paths to target. Overrides @levels_down when populated.	(empty)

If #folders is empty, the job targets all folders at the specified nesting level below every known share root on the targeted hosts. If #folders contains UNC paths, only those specific paths are processed regardless of the @levels_down setting.

Group Naming

Parameter	Description	Default
@naming_convention	Template for group names. Tokens: [HostName], [ShareName], [FolderName], [Permissions]	ACL[HostName][FolderName][Permissions]
@read_groupname	Token substituted for [Permissions] on Read groups	RO
@modify_groupname	Token substituted for [Permissions] on Modify groups	MOD
@fullcontrol_groupname	Token substituted for [Permissions] on Full Control groups	FC

Spaces are stripped from all token values automatically. Group names longer than 64 characters are flagged with an exception.

Effective Rights Calculation

Parameter	Description	Default
@exacteffective	1 = use exact effective rights (ignores open access / inherited-from-Everyone). 0 = use standard effective rights (OTB behavior).	1

When @exacteffective = 1, the job deploys two custom SQL functions (SA_CORE_GetExactTrusteePermissionEx and SA_FSAA_GetExactEffectiveRights) that calculate permissions per direct trustee — excluding permissions inherited from Everyone, Authenticated Users, and Domain Users. This is recommended for most environments.

Activity Modeling

Parameter	Description	Default
@includeactivity	1 = model access based on user activity in addition to permissions. 0 = permissions only.	1
@activitydays	Number of days of activity history to consider.	30
@activitypriority	1 = if activity shows higher access than permissions, promote to activity level. 0 = permissions always take precedence.	1
@activity_filter	Maximum number of days since last activity before a user is removed from the proposed groups. Only applies when @includeactivity = 1.	365

When activity modeling is enabled, users with no activity within the @activity_filter window are removed from the proposed groups entirely. This is the primary mechanism for eliminating stale access from the model.

Exclusion and Admin Groups

Parameter	Description	Default
#excluded_groups (ExcludedSids.csv)	ObjectSIDs of groups (or individual accounts) to exclude from RBG modeling. Members of these groups will not appear in any proposed group.	(empty)
#admin_groups (AdminGroupSids.csv)	ObjectSIDs of groups whose members are treated as administrators. Excluded from Read/Modify groups.	(empty)
@add_admin_groups	1 = add admin group SIDs to the Full Control group for every share. 0 = exclude admins entirely.	0
#fullcontrol_groups (FullControlGroups.csv)	ObjectSIDs of existing groups to grant Full Control on every targeted share. These groups are added to the permissions action table alongside the generated RBG groups.	(empty)

Important: Ensure that the service account being used to run actions within NAA is added to a Full Control group that will exist on shared folder once permissions are changed. This can be done by adding sid of service account to #admin_groups and switching @add_admin_groups to 1 or adding account as a member to a group within #fullcontrol_groups.

Group DN Configuration

The Add DN for new groups analysis task has its own configuration:

Parameter	Description	Default
@oupath	The OU distinguished name where groups will be created.	OU=Groups,DC=lab,DC=com

Update this to match the OU in your environment where resource-based groups should be created. This value is also used in the Create Groups action.

---

Reports

The job produces several reports accessible from the job tree. Select the job and navigate to the report tabs.

Change Modeling

The primary planning report. Shows a pie chart summarizing proposed access changes (Added, Removed, Changed, No Change) and a per-share breakdown table.

The per-share grid includes the following columns:

Column	Description
NetworkPath	The UNC path of the targeted folder
Added Access	Number of users who would gain new access
Removed Access	Number of users who would lose access
Changed Access	Number of users whose access level would change
No Change	Number of users whose access would remain the same
Group Exceptions	True if any proposed group for this path has an exception (name too long, duplicate name)

Access Changes (Detail)

The full per-user detail view showing every proposed access change. This is the report to review before running any actions.

Key columns:

Column	Description
NetworkPath	Target folder UNC path
NTAccount	The user’s domain\username
Current Access	The user’s current effective permission string (e.g., LR, LRWD, LRWDMA)
New Access	The proposed permission level under the RBG model
Group Name	The resource-based group the user would be added to
Access Change	Whether this represents Added, Removed, Changed, or No Change access
Modeled Source	Whether the proposed access was derived from Permissions, Activity, or Both

Groups to Create

Lists every resource-based group that needs to be created in AD, along with the permission level and any exceptions.

Groups to Apply (Permissions Action Input)

The merged table used by the Modify Permissions action. Combines the generated RBG groups with any Full Control groups from the FullControlGroups.csv configuration.

Group DNs

Shows the full Distinguished Name for each proposed group, incorporating the configured @oupath. This is the input for the Update Description action.

Effective Membership Changes

Shows the impact on each user’s total group membership count — their current effective group membership, the number of new RBG groups they would be added to, and the resulting total.

Review this table to identify users who might hit AD’s token bloat threshold (approximately 1,015 group memberships) if they are added to all proposed groups.

Action History

Shows all actions taken on each share for audit trail purposes — which groups were created, when members were updated, when permissions were applied, and when inheritance was changed.

---

Actions

The job includes five actions that execute the resource-based group transformation in sequence. All actions are disabled by default — enable and run each one deliberately after reviewing the reports.

Important: Always review the Change Modeling and Access Changes reports thoroughly before running any action. These actions modify Active Directory and file system permissions — changes should be validated in the reports before execution.

Action 1 — Create Groups

Creates the resource-based security groups in Active Directory in the OU specified during action configuration.

Setting	Value
Input Table	SA_FS_ResourceBasedGroups_GroupsToCreate
Group Scope	Domain local group
Group Type	Security group

Be sure to configure the target OU to create the groups in. Select the rows from the Groups to Create report that you want to process, then run the action. Groups that already exist will be skipped.

Action 2 — Update Description

Updates the description on the resource-based security groups created in Active Directory with specified description using values from target table.

Setting	Value
Input Table	SA_FS_ResourceBasedGroups_GroupDNs
Description	Example: Modify on \APP1\TestRBG

Action 3 — Update Members

Populates the resource-based groups with the appropriate user memberships based on the analysis results.

Setting	Value
Input Table	SA_FS_ResourceBasedGroups_NewACLs
Operation	Add members to groups

Be sure to configure the target OU where the groups that need members added in exist. This action adds each user identified in the NewACLs table to their corresponding resource-based group. Users whose access level was set to NULL (filtered out by activity) are excluded from the action automatically.

Action 4 — Modify Permissions

Applies the resource-based group permissions to the target folders — replacing the existing ACL with the new RBG-based ACL.

Setting	Value
Input Table	SA_FS_RBG_GroupsToApply
Operation	Replace ACL with RBG permissions
Propagate Permissions	Yes
Rollback	Supported — reverts to previous ACL

Warning: This action replaces the folder’s ACL. Ensure the Change Modeling report shows the expected results before running. Use the rollback capability if an action produces unintended results. Rollback will only restore explicit permissions removed during action but not inherited permissions. Folder will have to manually have inheritance disabled and then re-enabled to restore inherited permissions as well. Also, uncheck the Replace permission entries on all child objects setting if there is no desire to force inheritance on child objects below target folder.

Action 5 — Break Inheritance

Removes permission inheritance on the target folders so that only the explicitly applied RBG permissions remain.

Setting	Value
Input Table	SA_FS_ResourceBasedGroups_GroupsToCreate
Operation	Remove inherited permissions
Rollback	Supported — restores inheritance

Warning: Breaking inheritance is a significant change. Only run this after confirming that the Modify Permissions action applied the correct RBG ACLs. Removing inheritance without correct explicit permissions will result in access loss.

Recommended Action Sequence

Run the actions in order, validating results between each step:

1. Create Groups — verify the groups appear in AD in the correct OU
2. Update Description — verify the description updates in AD as expected on the groups
3. Update Members — verify group memberships are correct using the NAA AD Inventory or native AD tools
4. Modify Permissions — verify the new ACLs are applied correctly by re-running the File System collection and reviewing results
5. Break Inheritance — only after confirming the new ACLs are correct and complete

---

First Run Sequence

Step 1 — Configure Target Folders

Open the Analyze Group Permissions analysis task and populate the #folders table (UNCPaths.csv) with the UNC paths of the shares you want to transform. If you prefer to target all shares at a specific nesting level, leave #folders empty and set @levels_down to the desired level.

Step 2 — Configure Exclusions

Add any groups or accounts that should be excluded from the RBG model to the ExcludedSids.csv grid. Common exclusions include service account groups, computer accounts, and any principals that should not appear in the proposed groups.

If your environment has admin groups that should receive Full Control on every share, add their ObjectSIDs to AdminGroupSids.csv and set @add_admin_groups = 1.

If you have existing groups that should be granted Full Control alongside the generated RBG groups, add their ObjectSIDs to FullControlGroups.csv.

Step 3 — Configure Group Naming

Set @naming_convention to your desired template and customize @read_groupname, @modify_groupname, and @fullcontrol_groupname to match your organization’s naming standards.

Set @oupath on the Add DN for new groups analysis task to the OU where groups should be created.

Step 4 — Configure Activity Modeling

If you want to model access based on actual user activity (recommended), ensure @includeactivity = 1 and set @activitydays to an appropriate lookback window. 30 days is a reasonable starting point for most environments.

Set @activitypriority = 1 if you want activity to take precedence when it shows a higher access level than permissions.

Set @activity_filter to the maximum number of days of inactivity before a user is excluded from the proposed groups. 365 days is a reasonable starting point.

Step 5 — Run the Job

Run JOB_FS_ResourceBasedGroups to generate the analysis. This is a reporting-only step — no changes are made to AD or file system permissions.

Important! Ensure none of the action tasks are checked before running the job to ensure no unexpected changes occur.

Step 6 — Review Reports

Review the Change Modeling and Access Changes reports carefully. Pay attention to:

• The Modeled Source column to understand where each user’s proposed access came from
• Any Group Exceptions that indicate naming issues
• The Effective Membership Changes report for users approaching token bloat limits

Step 7 — Execute Actions

Once you are satisfied with the analysis results, enable and run the actions in sequence as described in the Actions section above.

---

Scheduling

Schedule the job to run as a scheduled task when ready to run actions.

The account running the job needs:

• Local administrator rights on the NAA application server (to execute the analysis tasks)
• db_owner rights to the NAA database (to read permissions/activity data and write analysis tables)

If you plan to run the actions on a schedule (e.g., to automatically update group memberships as access patterns change), ensure the account also has the appropriate AD and file system permissions documented in each action’s description.

---

Prerequisites

• NAA Modules: File System Feature, Reports Add-on, File Systems Actions Add-on, Active Directory Actions Add-on
• Data Dependencies: The following job groups must have run successfully before this job:
  • .Active Directory Inventory — provides user and group data for membership resolution and exclusion list expansion
  • FileSystem > 0.Collection — provides the file system permissions and share data used by the analysis
  • FileSystem > Activity (if using activity modeling) — provides the SA_FSAC_ActivityEventsView data used for activity-based access modeling

---

Comparison with Out-of-the-Box Job

Capability	OTB	Enhanced
Target specific UNC paths	Yes	Yes
Target all shares at N levels down	Yes	Yes
Customizable naming convention template	Yes	Yes
Customizable permission name tokens	No — hardcoded to R/RWD/FullControl	Yes — @read_groupname, @modify_groupname, @fullcontrol_groupname
Exclude specific groups/accounts	No	Yes — ExcludedSids.csv
Admin group handling	Basic #admin_groups only	AdminGroupSids.csv + member expansion + exclusion from Read/Modify groups
Full control group support	No	Yes — FullControlGroups.csv
Exact effective rights (ignore open access)	No	Yes — @exacteffective toggle
Activity-based access modeling	No	Yes — @includeactivity, @activitydays, @activitypriority
Stale access removal based on activity	Basic @activity_filter on DailyActivityView	Enhanced — removes users with no activity when modeling is enabled
Modeled Source tracking	No	Yes — Permissions / Activity / Both
Group DN generation for OU placement	No	Yes — @oupath parameter
Create Groups action	Yes	Yes
Update Description action	No	Yes — targets GroupDNs table
Update Members action	Yes	Yes
Modify Permissions action	Yes	Yes — targets merged GroupsToApply table
Break Inheritance action	Yes	Yes
Rollback support	Yes	Yes