Role-Based Access Control (RBAC)
Introduction
Role-Based Access Control (RBAC) lets you create custom Eyeglass roles that grant access to specific desktop icons and functionality, then map those roles to individual users or Active Directory (AD) groups. Use RBAC to limit a user or team to only the Eyeglass features they need — for example, a read-only monitoring role, a Ransomware Defender-only security role, or a failover-only operations role — instead of granting full administrative access.
RBAC is configured from the User Roles icon on the Eyeglass desktop.
Built-in Roles and Accounts
Eyeglass ships with the following built-in roles and accounts:
| Account | Default Password | Role |
|---|---|---|
| admin | 3y3gl4ss | All permissions for all licensed products. |
| rwdefend | 3y3gl4ss | Built-in Ransomware Defender role — manage and monitor Ransomware Defender. |
| auditor | 3y3gl4ss | Built-in Auditor role — read and modify access within Easy Auditor, including the Manage Services icon to view Eyeglass Clustered Agent (ECA) status. |
Change the default passwords for these built-in accounts as part of your initial deployment.
A default read-only role is also available that can view all desktop icons without the ability to make changes.
Common Use Cases for Custom Roles
- Monitoring-only (read-only) access
- Departmental login limited to DR readiness view
- Ransomware Defender monitoring/security access only
- Auditing access limited to Easy Auditor
- Failover-only operations access (for example, without permission to add new clusters)
- Storage or cluster reporting access only, without DR or configuration functions
Authentication Options
Eyeglass supports two login methods for RBAC-controlled access:
- Local Eyeglass OS Login: uses a user account created directly on the Eyeglass appliance's operating system. This method does not depend on your storage platform and works identically across all supported platforms.
- Proxy Login: authenticates against your storage platform's own Active Directory integration (where supported), proxying the username and password to the storage platform for validation and AD group membership lookup. Exact configuration steps vary by storage platform — confirm with your storage administrator whether your platform's AD/SMB integration supports this method before configuring Proxy Login for RBAC.
Create a Local Eyeglass OS User
- SSH to the Eyeglass appliance:
ssh admin@x.x.x.x - Switch to the root user:
sudo -s - Create the user:
useradd <user name> - Set a password:
passwd <user name>
We recommend a naming convention that makes it clear the account is a local Eyeglass OS user rather than an AD account — for example, prefixing local usernames with UNIX_USERS\ in your own internal documentation (this is a naming convention only, not a required Eyeglass syntax).
Requirements
- To use Proxy Login, your storage platform must have an AD authentication provider configured, and the AD group or user being mapped to a role must be resolvable by that provider.
- When adding a user or group to a role, Eyeglass validates that the entry resolves to a valid AD security identifier (SID) or group identifier (GID) before saving. If the user or group cannot be resolved, an error is displayed and the entry is not saved to the role.
- AD group names used in a role may not contain special characters other than a dash, underscore, or space.
- A user added directly to a role (rather than via an AD group) must be specified in User Principal Name (UPN) format:
user@domain. - A local storage-platform user added directly to a role uses the format
user@clustername.
Before configuring AD group-based RBAC, confirm with your storage or AD administrator that the AD group you plan to use is correctly resolvable and that its members' group memberships are visible to your storage platform's AD integration.
Quick Start
Follow these steps in order to configure role-based access:
- Review the Requirements above with your AD/storage administrator.
- Create the AD group you plan to map to a role (see Configure AD Group-Based Access below).
- Create a custom role in Eyeglass and assign the AD group or user to it.
- Log in to verify the role's permissions apply as expected.
Configure AD Group-Based Access
- In Active Directory, create a new global security group for the role — for example,
superna-admins. Use a lowercase group name. - Add the intended user accounts to this AD group.
- In Eyeglass, open the User Roles icon and log in as an admin user to create or edit the role (see Create a Custom Role below).
- When adding the AD group to the role, enter the domain name in uppercase and the group name in lowercase — for example,
AD02\superna-admins. - Select the desktop icons/functionality the role should have access to, then save the role.
- Confirm with your storage or AD administrator that the AD group is correctly visible in the group membership of the users who will log in with this role. If it is not visible to your storage platform's AD integration, the RBAC role will not work for Proxy Login.
Create a Custom Role
- Open the User Roles icon from the Eyeglass main menu.
- Select + next to Roles.
- Enter a name for the role.
- Select the checkboxes next to the permissions/desktop icons this role should have access to.
- To map an AD group to the role, follow Configure AD Group-Based Access above.
- To map a user directly to the role instead of via an AD group, enter the user in UPN format (
user@domain) per the Requirements above. - Click Save.
Login with RBAC
Once a role has been created and mapped to a user or AD group, the login screen accepts both local Eyeglass OS accounts and proxied AD accounts, and resolves the login to the correct authentication method automatically.
- To log in with an AD account via Proxy Login, enter the username as
<sam account name>@<DNS domain name>. - To log in with a local storage-platform account (where supported), enter the username as
<username>@<cluster name>.
The host/cluster field on the login screen can typically be left blank — Eyeglass automatically checks all managed clusters/storage systems until a successful authentication occurs. Only override this field if you need to force authentication against a specific cluster.
See Also
- User Roles — Data Security-specific roles and permissions (Ransomware Defender, Easy Auditor) that can be assigned when configuring a custom role above.
- SupernaOne — Example of granting a specific permission (
APP_REGISTER) from the User Roles menu.