Users, Groups & Roles

Access in GridNMS is built from three pieces that work together: users log in, each user belongs to a group, and each group is assigned a role that defines what its members can see and do. Set them up once and access stays consistent as your team grows.

You’ll find all three under Administration.

Users

A user is a login account. Every user belongs to exactly one group, and that group is what determines their permissions across the system.

• Passwords are stored securely (hashed, never in plain text). An administrator can force a password reset for any account from the user list.
• Passkeys — instead of a password, users can sign in with a hardware security key or a built-in authenticator like Face ID, Touch ID, or Windows Hello. Each user manages their own passkeys from their profile.
• Group membership decides what a user can do. To change someone’s access, move them to a different group, or change the role assigned to their group.

The built-in administrator account can’t be deleted, so you can’t accidentally lock every administrator out of the system.

Groups

A group is the link between users and permissions. Every user is in a group, and every group is assigned one role.

• The built-in Administrators group has full access to everything and can’t be deleted.
• A group’s role carries its full set of permissions. If a group has no role, its members get read-only access to the basics.
• Site scope is set on the group. If you restrict a group to specific sites, its members only see the devices that belong to those sites — ideal for giving a regional team access to just their own equipment.

Roles

A role is a named set of permissions you can assign to one or more groups. Defining permissions once as a role and reusing it keeps access consistent and avoids configuring the same thing over and over.

• Permissions are set per area of the product (devices, events, reports, discovery, maintenance, users, groups, and more), each at three levels:
  • Read — view only.
  • Write — create and edit.
  • Delete — remove.
• Site restrictions can scope a role to one or more sites. Combined with a site-scoped group, this is the main way to give teams regional or department-level access.
• No stacking — a user belongs to one group and inherits only that group’s role. To grant a combination of permissions, create a role that includes them all.

Members of the Administrators group always have full access, regardless of role settings.

A typical setup

1. Create a role with the permissions a team needs (for example, read-only access to devices and events for a help-desk role).
2. Create a group and assign that role to it. If the team should only see certain sites, set the group’s site scope.
3. Create users and add them to the group.

To change what the whole team can do later, edit the role — every group using it updates at once.