Roles and Permissions: Role-Based Access Control (RBAC) in rConfig V8

Role-Based Access Control (RBAC) in rConfig V8 provides granular control over user permissions, addressing the challenge of securing multi-user environments where different personnel require varying levels of access to sensitive network configuration data. Organizations can leverage RBAC to implement least privilege access, enforce segregation of duties, and maintain audit trails of who can perform which operations.

RBAC restricts network access based on the roles of individual users within an enterprise. Rather than assigning permissions individually to each user, administrators define roles with specific permission sets and assign users to those roles. This scalable approach simplifies permission management, ensures consistency across user groups, and adapts easily as organizational needs evolve.

When to Use This Page

Use this page when deciding whether the predefined Admin, User, and Guest roles cover your organization’s access needs, when designing a custom role for a specialized job function, or when restricting specific devices or snippets to particular teams. It is also the reference to reach for when troubleshooting why a user cannot access a feature they expect to have.

Prerequisites

• Admin role assigned to your own account (only Admins can create, edit, or delete roles and reassign users)
• An understanding of which entities the affected users need to interact with, so permissions can be scoped correctly
• For entity-level restrictions, the specific devices or snippets that need to be restricted must already exist

Understanding RBAC Concepts

Roles

Roles are named collections of permissions that define what actions users can perform within rConfig. Each role represents a job function or responsibility level, grouping related permissions logically. Users assigned to a role automatically inherit all permissions associated with that role.

Benefits of role-based permissions:

• Simplified management: Assign one role instead of dozens of individual permissions
• Consistency: All users in the same role have identical access
• Scalability: Add new users by assigning existing roles without permission configuration
• Audit clarity: Easily identify what any user can do by checking their role
• Reduced errors: Less granular permission assignment reduces misconfiguration risk

Permissions

Permissions define specific operations users can perform on system entities. rConfig implements five standard permission types applied to each entity:

View: Ability to see entity listings and navigate to entity pages. Without View permission, users cannot access the entity section at all.

Create: Ability to add new entity instances. For example, Create permission on Devices allows adding new devices to inventory.

Read: Ability to view detailed information about entity instances. Distinct from View which shows listings, Read shows full details of individual items.

Update: Ability to modify existing entity instances. Update permission on Commands allows editing command definitions.

Delete: Ability to remove entity instances. Delete permission on Tags allows removing tags from the system.

All: Convenience toggle that enables or disables all five permission types simultaneously for an entity.

Entities

Entities represent the major functional areas and data types within rConfig. Permissions are assigned per-entity, allowing fine-grained control. Key entities include:

Core infrastructure:

• Device: Network devices managed by rConfig
• DeviceCredentials: Authentication credentials for devices
• Vendor: Device manufacturer definitions
• Tag: Organizational labels for categorizing resources

Configuration management:

• Config: Downloaded device configurations
• ConfigChange: Configuration change tracking and history
• Command: Command definitions for device interaction
• Category: Command grouping and organization
• Snippet: Configuration templates and snippets

Compliance and policy:

• PolicyDefinition: Compliance policy rules and logic
• PolicyAssignment: Assignment of policies to devices
• PolicyComplianceResult: Compliance check outcomes
• PolicyComplianceReport: Aggregated compliance reporting

Automation and integration:

• Task: Scheduled and manual task definitions
• Taskdownloadreport: Task execution results and logs
• Template: Configuration templates
• TrackedJob: Background job tracking

System administration:

• User: User account management
• Role: Role and permission management
• Permission: Permission definitions
• Setting: System configuration settings
• Backup: System backup operations
• ActivityLog: Application event logging
• UserLogActivity: User authentication and activity

API and integrations:

• RestApiToken: API authentication tokens
• RestApiLog: API request logging
• ApiConnection: External API connection definitions
• ApiCredential: API authentication credentials
• ApiEndpoint: API endpoint configurations

Advanced features:

• Ldap: LDAP authentication configuration
• Zabbix: Zabbix integration settings
• ZabbixExtractStaging: Zabbix data import staging
• IntegrationConfigured: Active integration configurations
• IntegrationOption: Integration configuration options
• IntegrationDeviceLoaderStaging: Device import staging

Note

The entity list reflects rConfig V8 and is subject to expansion as new features are introduced. Custom integrations or plugins may add additional entities to the permission system.

Role-based visibility on credential sets

The entity permissions above control who can create, view, update, or delete credential sets. From V8.2.2, an individual credential set can also be restricted to specific roles, the same way tags and snippets already work.

• A credential set with no roles assigned is visible to everyone (the default, so existing sets are unaffected).
• Assign roles in the credential set’s Visible to Roles selector and the set is then visible only to those roles, plus admins.

This is a visibility control only. A device that already references a restricted set still collects configs and pushes snippets, even for a user who cannot see the set. Set the roles under Settings → Device Credentials when editing a set.

Predefined System Roles

rConfig V8 includes predefined system roles: Admin and User on every installation, and Guest on installations first set up before V8.4.2. To build a least-privilege role without starting from an empty permission matrix, use a role template.

Admin Role

The Admin role provides complete system access including all administrative capabilities:

Permissions: Full access (View, Create, Read, Update, Delete) to all entities

Typical use cases:

• System administrators managing rConfig infrastructure
• Senior network engineers with full operational authority
• Security personnel requiring complete visibility for auditing
• Implementation consultants during deployment phases

Responsibilities:

• User and role management
• System configuration and settings
• Integration setup and maintenance
• Backup and disaster recovery operations
• Security monitoring and incident response

Caution

Limit Admin role assignment to personnel genuinely requiring full system access. Excessive admin accounts increase security risk and complicate audit trails. Most operational users should receive User or custom role assignments instead.

User Role

The User role provides standard operational access for network configuration management tasks:

Permissions: Full access to operational entities (devices, configurations, commands, compliance), restricted access to administrative entities (cannot manage users, roles, system settings)

Typical use cases:

• Network engineers performing daily configuration management
• Operations staff downloading and reviewing configurations
• Compliance analysts running policy checks and reviewing results
• Team leads managing device inventory and task scheduling

Limitations:

• Cannot create or modify user accounts
• Cannot change role definitions or permissions
• Cannot modify system-wide settings
• Cannot access sensitive integration credentials
• Cannot execute system backups or restore operations

Guest Role

From V8.4.2, new installations don’t create the Guest role. Installations set up earlier keep it. For a read-only role on a new installation, create one from the Read-Only role template.

The Guest role provides read-only access for visibility without modification capabilities:

Permissions: View and Read access to most entities, no Create, Update, or Delete permissions

Typical use cases:

• Management personnel reviewing compliance status
• Junior team members observing operations before full access
• Auditors examining configuration management processes
• External consultants requiring visibility without modification rights
• Cross-functional teams needing network configuration insights

Limitations:

• Cannot modify any data or configuration
• Cannot download configurations or execute commands
• Cannot schedule tasks or execute operations
• Cannot access administrative functions
• Ideal for reporting and monitoring purposes only

System Role Characteristics

System roles (Admin, User, and Guest where it exists) are hardcoded and cannot be deleted. Administrators can deactivate system roles to prevent assignment to new users, but existing users retain their roles. Deactivating the Admin role is not recommended as it may leave the system without administrative access.

To view system role permissions:

1. Navigate to Roles from the main navigation
2. Locate the role to examine
3. Click the three-dot menu icon
4. Select Edit
5. Review the permission matrix showing all entity permissions

Role templates

From V8.4.2, the Add Role and Edit Role dialogs start with a row of templates: ready-made permission sets you apply with one click, then adjust. They save you toggling several hundred checkboxes by hand when a role is close to a common pattern.

A template is not a role. Applying one only fills in the permission matrix of the role you’re editing. Nothing is saved until you click Save or Update, and later changes to rConfig don’t change roles you built from a template.

The templates

Template	Permissions it selects
Read-Only	View and Read on every entity. No Create, Update, or Delete anywhere.
Read-Only + Device Edit	Everything in Read-Only, plus Create and Update on Device.
Standard User	Everything in Read-Only + Device Edit, plus Create, Update, and Delete on Policy Definitions, Policy Assignments, Policy Compliance Reports, Results and Exports, and EOC Definitions.
AI Center User	Everything in Read-Only, plus using the AI Center chat features and creating their own MCP tokens. No AI provider or settings rights.
Vector User	Create, Update, and Delete on day-to-day network work: devices, credentials, Vector agents, commands, categories, tags, templates, snippets, tasks, configs and compliance. Administration (users, roles, settings, LDAP, RADIUS, API tokens), AI settings, integrations setup, Vector binaries and the application log stay read-only. Shown only when Vector is installed.

No template selects an All (*) wildcard, the web terminal, terminal recordings, private activity, or purge. Add those yourself if a role needs them. Each template is worked out from the permissions on your server, so a module added by an upgrade is covered at the right level the next time you apply it.

Apply a template

1. Open Roles and click New Role, or edit an existing role.
2. Under Start from a template, click the template closest to what you need. Its card shows how many permissions it selects.
3. The permission matrix now shows exactly the template’s permissions. A banner names the applied template and counts how many permissions you’ve changed since. Cells the template selected have an outlined edge, so your own changes stand out.
4. Adjust the matrix, then save.

• Applying replaces the selection. It doesn’t add to what was ticked. Click Undo in the banner to get back the selection you had before the first template.
• In Edit Role, applying a template to a role that already has permissions asks first: Replace this role’s N permissions with the … template?
• A greyed-out template includes permissions you don’t hold yourself. You can’t give a role more than you have, so ask an administrator.

A starting point, not a policy

Templates are deliberately broad on read access. If your compliance framework requires users to be blind to certain modules, untick them after applying the template.

Preset roles on older installations

Installations first set up between V8.3.1 and V8.4.1 also have three roles named Read-Only, Read-Only + Device Edit, and Standard User, created from the first three templates. New installations from V8.4.2 don’t create them.

If you have them, they’re ordinary roles from V8.4.2:

• They can be deleted, unless LDAP or RADIUS uses one as its default role. An upgrade doesn’t re-create one you delete.
• Upgrades keep them current. A role with no permissions gets the template’s full set; a role with permissions is only offered permissions created by that upgrade, so ones you removed stay removed. The rconfig:update-rbac-data command lists what it will add and asks before writing.
• Standard User is not the User role. They are separate roles with different permission sets. Check which one you are assigning.

Creating Custom Roles

Custom roles enable organizations to define permission sets aligned with specific job functions, operational requirements, or security policies not covered by predefined roles.

When to Create Custom Roles

Consider custom roles in these scenarios:

Specialized job functions: Teams with unique responsibilities requiring specific permission combinations (e.g., compliance-only analysts, configuration auditors, vendor management coordinators).

Segregation of duties: Compliance frameworks requiring separation of responsibilities (e.g., users who create policies cannot approve them, users who configure devices cannot manage credentials).

Geographic or organizational divisions: Different regions or business units requiring distinct access patterns based on operational scope.

Least privilege enforcement: Standard roles provide more access than needed, and custom roles restrict to minimum necessary permissions.

Third-party integration: External systems or services requiring API access with limited scope to specific entities and operations.

Start from a template

Before building a custom role from an empty matrix, apply the closest role template and adjust from there. Read-Only plus a handful of extra permissions covers a lot of requirements, and it’s faster and less error-prone than assembling a permission set from scratch.

Creating Custom Roles

To create a new custom role:

1. Navigate to Roles from the main navigation
2. Click New Role
3. Complete the role definition form:
   • Role Name: Descriptive identifier (e.g., “Compliance Analyst”, “Read-Only Network Engineer”). The form hints Lower case, one word, but any name is accepted and converted to an ident (see below)
   • Description: Detailed explanation of role purpose and intended users
   • Role Status: Active (default) or Inactive. Inactive roles are skipped by SSO and LDAP role mapping
   • SSO Groups (V8.3.3+): Optional. Group values from your SAML identity provider that grant this role when role mapping is on. Leave empty unless you use SAML role mapping
   • LDAP Groups (V8.4.0+): Optional. Directory groups that grant this role when LDAP role mapping is on. Leave empty unless you use LDAP role mapping
4. Optionally, click a template under Start from a template to fill the matrix with a ready-made set (see Role templates).
5. Configure permissions using the permission matrix:
   • Entity rows: Each row represents a system entity
   • Permission columns: View, Read, Create, Edit, Update, Delete, All (*), and module-specific actions such as MCP token, Terminal, Purge, and Resolve. Hover a column heading for what it grants
   • Toggle All: Convenience switch enabling/disabling all permissions for the role
   • Individual toggles: Select specific permissions per entity
6. Click Save to create the role

The new role becomes immediately available for user assignment. Its ident (a URL-safe slug of the name, so Network Operations becomes network-operations) is fixed when the role is created and does not change if the role is renamed. Two roles cannot share an ident.

SSO Groups (V8.3.3+)

When SAML role mapping is enabled, rConfig assigns roles from the group values in the SAML assertion on every login. Each role can match on one of two things:

• Its SSO Groups list, when one or more values are set. Use this when the IdP sends Active Directory group names, object IDs, or any value that differs from the role’s ident. Type a value and press Enter; up to 20 values, 255 characters each.
• Its ident, when no SSO group is set. The IdP value is slugified and compared, so Net_Ops or NET OPS match a role with ident net-ops.

Matching is case-insensitive. An SSO group value may grant only one active role: saving a role whose SSO group is already used by another active role, or which would match another role’s ident, is rejected and the conflicting role is named. Inactive roles are never matched. Once a role has an SSO group, its ident no longer matches.

The identity provider is authoritative

With role mapping on, roles assigned through Change Role in Users are replaced at the user’s next SAML login with whatever the assertion grants. Manage SAML users’ roles at the IdP, or by setting SSO Groups on the role, not per user.

LDAP Groups (V8.4.0+)

When LDAP role mapping is on, rConfig sets each LDAP user’s roles from their directory groups at every sign-in. A role is granted only when one of the user’s groups is in the role’s LDAP Groups list. There is no fallback to the role’s ident, unlike SSO group matching.

Each entry is either a group name or the group’s full path (DN):

• Group name, for example NetOps-Admins, matches a group with that name in any OU.
• Full path, for example CN=NetOps-Admins,OU=Privileged,DC=corp,DC=local, matches only that exact group. Use a full path for the admin role and other privileged roles.

Type a value and press Enter; up to 20 values per role, 255 characters each. Matching is case-insensitive. An LDAP group may grant only one active role, and saving a duplicate is rejected with the conflicting role named. LDAP Groups and SSO Groups are independent lists, so a value in one never affects the other.

A role chosen as the LDAP or RADIUS default role cannot be deleted or deactivated until a different default is set.

The directory is authoritative

With LDAP role mapping on, roles assigned through Change Role in Users are replaced at the user’s next LDAP sign-in. Manage LDAP users’ roles through their directory groups, not per user.

Permission Matrix Strategy

When configuring custom role permissions, use these strategies:

Start with minimum access: Begin with no permissions and add only those required. This ensures least privilege by default.

Grant View broadly, other permissions selectively: Most roles benefit from broad View access for situational awareness, with Create/Update/Delete restricted to operational areas.

Consider permission dependencies: Some operations require multiple permissions. For example, running compliance checks requires Read access to Devices, PolicyDefinitions, and PolicyAssignments.

Test role thoroughly: Create test user accounts with the custom role and validate they can perform intended operations without accessing restricted areas.

Document permission rationale: Maintain internal documentation explaining why each permission was granted, facilitating future reviews and audits.

Custom Role Examples

Compliance Analyst Role:

• Full access: PolicyDefinition, PolicyAssignment, PolicyComplianceResult, PolicyComplianceReport
• Read access: Device, Config, Vendor, Tag
• View access: All other entities
• Rationale: Analysts create and manage policies, review compliance, but don’t modify device configurations

Configuration Auditor Role:

• Full Read access: Config, ConfigChange, Device
• View access: All other entities
• No Create, Update, or Delete permissions
• Rationale: Auditors review configurations and changes without modification capabilities

Device Manager Role:

• Full access: Device, DeviceCredentials, Tag, Vendor
• Read access: Config, Task
• View access: All other entities
• No access: PolicyDefinition, Setting, User, Role
• Rationale: Manages device inventory and credentials without policy or system administration access

Assigning Roles to Users

User Role Assignment

Each user is assigned one or more roles determining their system permissions. To assign or change a user’s roles:

1. Navigate to Users from the main navigation
2. Locate the user to modify
3. Click the three-dot menu icon in the user row
4. Select Change Role
5. A dialog displays showing the current role
6. Select the new role from the dropdown
7. Click Save to apply the change

Change Role replaces all of the user’s current roles with the one selected. To add a role without removing the others, open the role in the Roles list, select the Users tab, choose the user and click Add User. Remove on the same tab takes the role away from one user.

Role changes take effect immediately for new sessions. Users currently logged in should log out and back in to activate new permissions.

Role Assignment Considerations

Roles are additive: A user with several roles gets the union of their permissions. Review the full role list when troubleshooting unexpected access.

Role mapping overrides manual assignment: When SAML role mapping is on, a SAML user’s roles are set from the identity provider at every login. When LDAP role mapping is on, an LDAP user’s roles are set from their directory groups at every sign-in. In both cases any change made here is overwritten. Local users, and users whose sign-in method has no role mapping turned on, are unaffected.

Role change impact: Changing a user’s role immediately affects their access. Ensure role changes align with actual job function changes to prevent operational disruption.

Temporary elevated access: For temporary administrative needs, consider creating time-limited admin accounts rather than elevating existing user accounts and remembering to downgrade later.

Review role assignments regularly: Quarterly access reviews should validate each user’s assigned role remains appropriate for their current responsibilities.

Entity-Level Role Restrictions

Device and Snippet Role Assignment

Beyond system-wide role permissions, rConfig V8 supports entity-level role restrictions for Devices and Snippets. This provides additional granularity by limiting which devices or snippets specific roles can access.

How entity-level restrictions work:

1. Assign roles to specific devices or snippets during creation or editing
2. Users with those roles see only devices/snippets where their role is assigned
3. Users without assigned roles see no devices/snippets (unless they have Admin role)
4. Admin role bypasses entity-level restrictions and sees all devices/snippets

Use cases for entity-level restrictions:

Multi-tenant environments: Service providers managing customer devices can restrict each customer’s operations team to only their devices.

Geographic segmentation: Regional teams see only devices in their geographic responsibility area.

Vendor-specific teams: Cisco specialists see Cisco devices, Juniper specialists see Juniper devices, preventing cross-vendor configuration errors.

Sensitive device isolation: High-security devices (production core routers, firewalls) restricted to senior engineers, while access switches visible to junior staff.

Snippet library organization: Configuration snippets organized by team, with each team accessing only their approved templates.

Configuring Entity-Level Role Restrictions

For Devices:

1. Navigate to device creation or edit form
2. Locate the Assigned Roles section
3. Select one or more roles that should access this device
4. Save the device
5. Only users with assigned roles (plus Admins) can now view/manage this device

For Snippets:

1. Navigate to snippet creation or edit form
2. Locate the Assigned Roles section
3. Select one or more roles that should access this snippet
4. Save the snippet
5. Only users with assigned roles (plus Admins) can now view/use this snippet

For detailed entity-level role assignment procedures, see:

• Device Management Documentation
• Snippet Management Documentation

Tag-Scoped Roles

A role can also be assigned one or more tags. Users with that role see only the devices carrying those tags, plus those devices’ backups and change history.

Use tag-scoped roles when a team should see one slice of the estate without assigning roles device by device. For example, tag every device in a security zone and give that zone’s engineers or auditors a role scoped to the zone’s tag. The Vector agent per security zone design uses this pattern.

Managing Roles

Viewing Role Details

To examine role configurations:

1. Navigate to Roles from the main navigation

2. The role list displays all roles with:

   • ID: The role’s database ID
   • Name: The role name
   • Description: Purpose and intended use
   • SSO Groups: The role’s SSO group values, or Role name when none are set
   • Users: Count of users currently assigned to the role
   • Active: Switch to activate or deactivate the role
   • Created: When the role was created
   • Actions: Edit or Delete

3. Click the role name or Edit icon to view full permission matrix

Editing Role Permissions

To modify existing role permissions:

1. Locate the role in the Roles list
2. Click the three-dot menu icon
3. Select Edit
4. Modify the permission matrix:
   • Toggle individual permissions per entity
   • Use Toggle All to quickly enable/disable all permissions
   • Update role name or description if needed
5. Click Save to commit changes

Permission changes affect all users assigned to the role immediately. Users logged in when permissions change must log out and back in for new permissions to apply.

Caution

Exercise caution when modifying roles with many assigned users. Permission reductions may disrupt ongoing operations for multiple users simultaneously. Consider creating new roles with desired permissions and migrating users gradually instead of modifying active roles.

Deactivating Roles

To prevent new assignments while preserving existing ones:

1. Navigate to Roles
2. Locate the role to deactivate
3. Toggle its Active switch in the role row to off

Deactivated roles:

• Are no longer granted by SSO or LDAP role mapping
• Can still be assigned to users manually, so deactivation alone doesn’t stop new assignments
• Remain assigned to existing users with full permissions intact
• Remain visible in the roles list with the Active switch off
• Can be reactivated at any time

Use deactivation when phasing out roles, temporarily suspending role use, or preventing accidental assignment during role redesign.

Deleting Custom Roles

To permanently remove custom roles:

1. Navigate to Roles
2. Check the Users column. Any users still assigned will lose the role when it is deleted
3. Click the three-dot menu icon
4. Select Delete
5. Confirm deletion when prompted

Caution

Deleting a role removes it from every user assigned to it, with no further warning. A user whose only role was deleted is left with 0 Roles and no meaningful access. Give affected users another role before deleting. System roles (Admin, User, and Guest where it exists) cannot be deleted under any circumstances, and neither can a role set as the LDAP or RADIUS default role. From V8.4.2, the preset roles on older installations can be deleted like any other role.

Deleted roles are permanently removed and cannot be recovered. Document role permissions before deletion if you may need to recreate similar roles later.

Common Gotchas

Caution

• Permission changes don’t apply to active sessions. Users who are already logged in keep their old permission set until they log out and back in.
• Entity-level restrictions only cover Devices and Snippets. Restricting a role’s visibility on any other entity type isn’t supported: use the standard permission matrix instead.
• Deleting a role silently removes it from its users. Anyone who held only that role is left with no access. Reassign users first, or deactivate the role instead if you may need it again.
• A credential set with no roles assigned is visible to everyone, including users without Admin access. Assign roles under Settings → Device Credentials if a set needs restricting.

Troubleshooting

Symptom: User Cannot Access Expected Features

Diagnosis: Verify user’s role and required permissions.

Possible Causes:

• User assigned role lacking necessary permissions
• Entity-level role restrictions preventing access to specific devices/snippets
• Session established before recent permission changes
• User attempting to access admin features without admin role
• SAML role mapping replaced a manually assigned role at the user’s last login (check the resolved to [ trace in the Application Log)

Resolution Steps:

1. Verify user’s assigned role in Users list
2. Check role permissions match required operations
3. If entity-level restrictions apply, verify user’s role is assigned to relevant devices/snippets
4. Have user log out and back in to refresh session permissions
5. Assign different role or modify role permissions if access is legitimately required

Symptom: Custom Role Cannot Be Deleted

Diagnosis: Check the error message shown when the delete fails.

Possible Causes:

• Attempting to delete a system role: Admin, User, or Guest (not possible, returns Cannot delete this system role)
• The role is set as the LDAP or RADIUS default role (returns Cannot delete a role that LDAP or RADIUS uses as its default role)
• Your own role is less privileged than the role you’re deleting

Resolution Steps:

1. Read the error message to identify which cause applies
2. For a default role, choose a different LDAP or RADIUS default role in that integration’s settings, then retry deletion
3. For a role more privileged than your own, ask an administrator with a higher-level role to delete it
4. If it is a system role, deletion is not possible. Remove its users on the role’s Users tab if you don’t want it in use

Symptom: Permission Changes Not Taking Effect

Diagnosis: User sessions cache permissions requiring refresh.

Possible Causes:

• User logged in when permissions changed
• Browser caching old permission state
• Application cache not cleared after permission changes
• Database replication lag in distributed deployments

Resolution Steps:

1. Have affected users log out completely
2. Clear browser cache and cookies
3. Log back in to establish new session with updated permissions
4. If issue persists, clear application cache:

   php /var/www/html/rconfig8/current/artisan config:clear
   php /var/www/html/rconfig8/current/artisan cache:clear

5. Review System Logs for permission-related errors

Symptom: RBAC Data Appears Corrupted

Diagnosis: Permission table may need refresh or repair.

Possible Causes:

• Database corruption affecting permissions table
• Incomplete migration after rConfig upgrade
• Manual database modifications introducing inconsistencies
• Disk failure or filesystem issues

Resolution Steps:

Caution

Contact rConfig support before executing RBAC data refresh commands. These commands modify permission structures and should only be run under guidance to prevent unintended access changes.

1. Document current role configurations and user assignments
2. Create complete database backup
3. Contact support@rconfig.com with issue description
4. Support will provide guidance on executing:

   php /var/www/html/rconfig8/current/artisan rconfig:update-rbac-data

5. Review each change the command previews and confirm or decline it
6. Verify role permissions after refresh
7. Reapply any custom role configurations if needed

From V8.3.1 the command checks the seeded Admin, User, and Guest roles before making any change. If those roles no longer hold their expected identifiers, the command reports the mismatch, writes nothing, and exits. This is the signal to contact support rather than to re-run the command.

Best Practices

Security

Apply least privilege principle: Assign the minimum role necessary for users to perform their job functions. Default to User or custom roles rather than Admin unless administrative access is genuinely required.

Limit Admin role assignments: Maintain a small, well-documented list of admin users. Every additional admin increases security risk and complicates audit trails.

Review role assignments quarterly: Conduct regular access reviews to identify role assignments that no longer align with job responsibilities. Downgrade or remove access proactively.

Document role purpose: Maintain clear documentation of each custom role’s purpose, intended users, and permission rationale. This facilitates reviews and knowledge transfer.

Implement segregation of duties: Use custom roles to enforce separation of responsibilities required by compliance frameworks (e.g., policy creators cannot approve policies).

Audit permission changes: Monitor the ActivityLog for role creation, modification, and deletion events. Unauthorized permission changes indicate potential security incidents.

Organization

Use descriptive role names: Name roles after job functions or responsibilities rather than departments. “Compliance Analyst” is clearer than “Team B Member” and remains valid through organizational changes.

Create role hierarchies logically: Design custom roles that build upon each other (e.g., Junior Engineer, Senior Engineer, Lead Engineer) with incremental permission additions at each level.

Standardize role definitions: Establish organizational standards for common roles (e.g., all regional deployments use identical role definitions) to simplify management and user transfers.

Test custom roles before production use: Create test user accounts with new custom roles and validate they can perform intended operations before assigning to production users.

Maintain role documentation: Document which teams use which roles, typical user counts, and escalation procedures for access requests. Store this documentation in accessible locations for operations teams.

Compliance

Map roles to job descriptions: Align role definitions with formal job descriptions and responsibility matrices. This demonstrates access controls match organizational structure for auditors.

Retain role change history: Maintain detailed records of role creation, modification, and deletion including business justification, approval authority, and implementation date.

Generate role assignment reports: Produce quarterly reports of all users, assigned roles, and last login dates for compliance audits and management review.

Implement role approval workflows: Establish formal procedures for requesting custom role creation including business justification, security review, and approval requirements.

Document exception access: When users require temporary elevated access, document the business justification, approval authority, duration, and removal date for audit trails.

Related Documentation

• Users - User account management and role assignment
• CLI Commands - The rconfig:update-rbac-data command used to refresh permissions and keep older installations’ preset roles current
• SSO Configuration - Single Sign-On integration
• SAML Auto-Approval and Role Mapping - Assigning roles from identity provider groups
• LDAP Configuration - LDAP authentication with role assignment
• Application Log - Viewing role and permission change events
• Device Management - Entity-level role assignment for devices
• Snippet Management - Entity-level role assignment for snippets

Summary

Role-Based Access Control in rConfig V8 provides the foundation for secure multi-user environments through predefined and custom roles, granular permission management, and entity-level access restrictions. Organizations can leverage RBAC to implement least privilege access, enforce segregation of duties, and maintain comprehensive audit trails of who can perform which operations.

Key takeaways for effective RBAC implementation:

• Use predefined roles (Admin, User) for common access patterns to simplify management
• Start from a role template (Read-Only, Read-Only + Device Edit, Standard User, AI Center User, Vector User) for least-privilege access without building a permission set by hand
• Create custom roles when job functions require specific permission combinations not covered by the predefined roles or a template
• Apply least privilege by assigning minimum necessary permissions and restricting Admin role to genuine administrators
• Leverage entity-level restrictions for devices and snippets when multi-tenant or geographic segmentation is required
• Review role assignments quarterly to ensure access remains aligned with current job responsibilities

Effective RBAC implementation balances security with operational efficiency, enabling authorized personnel to perform their duties while preventing unauthorized access to sensitive network configuration management capabilities. Regular review and refinement of role definitions ensures the permission model evolves with organizational needs.