Skip to main content

Users, Roles & Permissions

What this covers

Managing who can access the Greenbone web interface and what they can do: creating and managing users, working with roles (including the super administrator), grouping users with groups, fine-grained permissions (command, resource and super permissions), and integrating a central user management with an LDAPS or RADIUS server.

Source scope

Based on the Greenbone Enterprise Appliance manual (GOS 22.04 / OPENVAS SCAN 22.04), chapter 9, verified June 2026. The access-control model — users, roles, groups and permissions — is the same in the free Community Edition.

The appliance allows the definition and management of multiple users with different roles and permissions. The first user — the web/scan administrator — is created during initialization in the GOS administration menu. With this user, additional users can be created and managed (§9.1).

Access control combines four building blocks:

  • Roles define a role-based permission concept. Role enforcement is implemented in the underlying Greenbone Management Protocol (GMP), not in the web interface, so it affects all GMP clients. Read and write access can be assigned separately.
  • Groups are mainly for logical grouping of users.
  • Host access restricts each user to an allowed or denied IP address range; the appliance refuses to scan any other addresses.
  • Permissions grant specific actions, and can be assigned to several users at once via groups and roles.

The user management is done entirely on the appliance — external sources are not supported. To support central authentication and password synchronization, the appliance can be integrated with a central LDAPS or RADIUS server, which is used only to verify the password during login (see section 5).

note

This chapter documents all possible menu options. Not all appliance models support all of them — check the model tables in the manual chapter 3 to see whether a feature is available for your appliance model.

1. Users​

Creating a user​

Administrators only

Only administrators are allowed to create and manage additional users (§9.1.1).

  1. Log in as an administrator.
  2. Select Administration then Users in the menu bar.
  3. Create a new user with the create action.
  4. Define the user.
  5. Click Create. The user is created and shown on the Users page.

The following user details can be defined (§9.1.1.1):

  • Login Name — the name used for logging in. Only alphanumeric characters and the dash, underscore and full stop are allowed. When using a central user management, length and character limitations may apply based on the LDAP or RADIUS server, and the user must be created with the exact same name (rDN) as used by the server.
  • Authentication — the login method:
    • Password for local authentication with the login name and a password. The password can contain any character and has practically no length limit. Special characters must be available on all keyboards and correctly supported by all client software and operating systems; copying and pasting special characters can lead to invalid passwords.
    • LDAP Authentication Only for central user management (see section 5).
    • RADIUS Authentication Only for central user management (see section 5).
  • Roles — a user can have multiple roles. Roles define the GMP permissions. The roles Admin, User, Info, Observer, Guest and Monitor are available, plus any custom roles. If a user with a custom role should be able to use the web interface, the role needs at least the authenticate, get_settings and help permissions.
  • Groups — a user can be a member of multiple groups.
  • Host Access — the hosts on which the user is allowed to run scans.

Host access (whitelist vs. blacklist)​

Host access uses either a whitelist or a blacklist:

  • Whitelist — scanning of all systems is denied in general; only explicitly listed systems may be scanned.
  • Blacklist — scanning of all systems is allowed in general; only explicitly listed systems are not allowed to be scanned.

Restrictions also apply to administrators, but they are allowed to remove them themselves. Normal users and roles without access to user management cannot circumvent the restrictions.

tip

In general, use the whitelist methodology. This ensures users do not accidentally scan systems beyond their responsibility, located on the Internet, or reacting badly to malfunctioning scans.

System names as well as IPv4 and IPv6 addresses can be entered — individual addresses, ranges, and network segments — mixed and matched as a comma-separated list. Examples:

  • 192.168.15.5 — IPv4 address
  • 192.168.15.5-192.168.15.27 — IPv4 range, long form
  • 192.168.15.5-27 — IPv4 range, short form
  • 192.168.15.128/25 — IPv4 range, CIDR notation
  • 2001:db8::1 — IPv6 address
  • 2001:db8::1-2001:db8::15 — IPv6 range, long form
  • 2001:db8::1-15 — IPv6 range, short form
  • 2001:db8::/120 — IPv6 range, CIDR notation

By default, the CIDR subnet mask is restricted to a maximum of 20 for IPv4 and 116 for IPv6, because the maximum number of IP addresses per target is 4096 on most appliances. Where the maximum is higher (for example the Greenbone Enterprise 6500), correspondingly larger subnet masks can be configured.

Managing users​

Select Administration then Users (as an administrator) to display all users with their Name, Roles, Groups, Host Access and Authentication Type (Local, RADIUS or LDAP). Global users — those created in the GOS administration menu — are marked accordingly (§9.1.1.2).

For each user the following actions are available: delete, edit, clone, and export as an XML file. More than one user can be deleted or exported at once using the controls below the list.

caution

A user can only be deleted if it is not currently logged in and is not the super administrator (§9.1.1.2).

Click a user name and open the details page to see three registers: Information, User Tags, and Permissions (permissions of the user, or of other users, roles and groups to the user's resources). The details page also offers actions to show the user list, create, clone, edit, delete and export a user.

Simultaneous login​

Two different users can be logged in at the same time. If the same user wants to log in more than once simultaneously, the login must be performed from a different PC or with a different browser — another login in the same browser invalidates the first login (§9.1.2).

Guest login​

The guest user has only restricted access. To allow guest access, create a user and assign it the Guest role; with knowledge of the password the guest can log in and is presented with the Dashboards page. To allow a guest to log in without a password, the feature must be activated in the GOS administration menu (§9.1.3).

warning

A passwordless guest login removes the password barrier to the web interface. Enable it only when the restricted Guest access level and your network controls make this acceptable.

2. Roles​

The web interface supports the creation and configuration of custom roles. Each role defines which options of the web interface a user can view and modify. The following roles are available by default (§9.2):

RoleWhat it allows
AdminAll permissions by default. Especially allowed to create and manage other users, roles and groups.
UserAll permissions by default except user, role and group management. Not allowed to synchronize and manage feeds; no access to the Administration page.
Info(Information Browser) Read access only to VTs and SCAP information; all other information is not accessible. Can modify personal settings, e.g. change the password.
GuestCorresponds to Info, but is not allowed to change user settings.
MonitorAccess to the system reports of the appliance.
ObserverRead access to the system; not allowed to start or create new scans. Read access only to the scans for which it has been set as an observer.
Super AdminAccess to all objects of all users. Has no relation to the super user (su/root) in the GOS administration menu. Cannot be configured in the web interface and cannot be deleted via the web interface — manage via the GOS administration menu.
note

Only administrators may create and manage additional roles. The default roles cannot be modified, but they can be cloned and the clone modified. This keeps behavior consistent across software updates.

Cloning an existing role​

When an existing role closely matches the requirement, clone it (§9.2.1):

  1. Log in as an administrator.
  2. Select Administration then Roles.
  3. Clone an existing role using the clone action in its row.
  4. Edit the clone.
  5. Enter the role name in the Name box.
  6. Select the users that should have the role in the Users drop-down list.
  7. Add a permission by selecting it in the Name drop-down list and clicking Create Permission.
  8. Add a super permission by selecting the group in the Group drop-down list and clicking Create Permission. Delete a permission via the delete action in the General Command Permissions list.
  9. Click Save.

Creating a role​

To start from an empty role with limited functionality (§9.2.2):

  1. Log in as an administrator.
  2. Select Administration then Roles.
  3. Create a new role with the create action.
  4. Define the role. Details:
    • Name — letters and numbers, at most 80 characters.
    • Comment (optional) — describes the role in more detail.
    • Users — select users with this role in the Users drop-down list; alternatively manage roles in the user profile.
  5. Click Save. The role appears on the Roles page.
  6. Edit the newly created role.
  7. Add a permission by selecting it in the Name drop-down list and clicking Create Permission.
  8. Add a super permission by selecting the group in the Group drop-down list and clicking Create Permission. Delete a permission via the delete action in General Command Permissions.
  9. Click Save.
note

For a role to be usable in the web interface, it needs at least the authenticate, get_settings and help permissions. The write_settings permission lets users change their own password, time zone and other personal settings.

Managing roles​

Select Administration then Roles to list all roles by Name; all default roles are global roles and are marked as such. Available actions: move to trashcan (only self-created roles), edit (only self-created roles), clone, and export as XML. Multiple roles can be moved to the trashcan or exported at once (§9.2.3).

The role details page has the registers Information, General Command Permissions (GMP commands this role can execute), User Tags and Permissions.

Assigning roles to a user​

A user can have more than one role to group permissions. Roles are assigned when creating a new user. If more than one role is assigned, the permissions of the roles are added together (§9.2.4).

Super administrator​

The Super Admin role is the highest level of access (§9.2.5).

The Admin role can create, modify and delete users, and can view, modify and delete permissions — but is itself subordinate to those permissions. For example, if a user creates a private scan configuration and does not share it, the administrator cannot access it.

The Super Admin is more suited for diagnostic purposes: it is excluded from permission restrictions and can view and edit any configuration setting of any user.

warning

The super administrator must be created in the GOS administration menu, not in the web interface, and can only be edited by the super administrator. It cannot be deleted via the web interface. Because it bypasses all permission restrictions, reserve it for diagnostic use.

3. Groups​

Groups logically assemble users. An unlimited number of groups can be created, and permissions can be assigned to groups. By default, no groups are set up (§9.3).

Creating a group​

Administrators only

Only administrators may create and manage groups (§9.3.1).

  1. Log in as an administrator.
  2. Select Administration then Groups.
  3. Create a new group with the create action.
  4. Define the group.
  5. Click Save. The group appears on the Groups page.

Group details:

  • Name — letters and numbers, at most 80 characters.
  • Comment (optional) — describes the group in more detail.
  • Users — select members in the Users drop-down list; alternatively manage memberships in the user profile.
  • Special Groups — activate this checkbox so that all group members have read and write access to all resources of the group.

Managing groups​

Select Administration then Groups to list all groups by Name. Available actions: move to trashcan, edit, clone, and export as XML. Multiple groups can be moved to the trashcan or exported at once. The details page has the registers Information, User Tags and Permissions (§9.3.2).

4. Permissions​

Select Administration then Permissions to display all permissions assigned on the system. With multiple roles there can easily be hundreds of permissions (§9.4).

Each permission relates to exactly one subject and enables that subject to perform an associated action. Subjects can be users, roles or groups. There are two types of permissions:

  • Command permissions — linked to GMP. Each applies to a specific GMP command; the permission name is the relevant command.
    • Command level — no resource specified; allows the subject to run the given GMP command.
    • Resource level — a resource is specified; allows the subject to run the GMP command on a specific resource.
  • Super permissions — see "Granting super permissions" below.
note

Usually permissions are assigned via role management. Creating and managing permissions directly on the Permissions page is only recommended for experienced users looking for a specific permission (§9.4.1).

Creating and managing permissions​

To create a permission on the Permissions page (§9.4.1.1):

  1. Select Administration then Permissions.
  2. Create a new permission with the create action.
  3. Define the permission.
  4. Click Save.

Permission details:

  • Name — the permission to be granted.
  • Comment (optional).
  • Subject — the user, role or group to be granted the permission.
  • Resource Type — only for the Super (Has super access) permission; the resource type (user, role or group) the subject has super access to.
  • User/role/group ID — only for Super (Has super access); the ID of the user, role or group the subject has super access to.
  • Description — textual description.
note

The subjects for which permissions can be assigned depend on the role of the currently logged-in user. Users can grant permissions to other users, whereas administrators can grant permissions to users, roles and groups (§9.4.1.1).

The list page shows Name (a global permission is marked as such), Description, Resource Type, Resource, Subject Type and Subject. Actions: move to trashcan, edit, clone (all only for self-created permissions) and export as XML (§9.4.1.3).

Creating a permission from a resource details page​

Permissions for a resource can be granted directly from the resource's details page (§9.4.1.2). For example:

  1. Select Scans then Tasks.
  2. Click a task name.
  3. Open the task details page.
  4. Open the Permissions register.
  5. Create a new permission in the Permissions section.
  6. Define the permission.
  7. Click Save.

Two permission types can be granted this way:

  • read — allows viewing the resource on list pages and on its details page.
  • write — allows viewing and modifying (but not deleting) the resource.

Some resource types add further permissions automatically:

  • Tasks — granting write adds start_task, stop_task and resume_task.
  • Alerts — granting write adds test_alert.
  • Report formats and scanners — granting write adds verify_report_format or verify_scanner.

For some resource types you can choose whether the permissions also apply to related resources:

  • Tasks — alerts and their filters, the target plus its credentials and port list, the schedule, the scanner and the scan configuration.
  • Targets — credentials and the port list.
  • Alerts — the filter used on the report.

Permissions can also be created only for the related resources.

Granting super permissions​

Any resource on the appliance is either global (marked accordingly) or owned by a specific user. Non-global resources can only be viewed and used by their owner; granting individual permissions to make them available to others is tedious. Super permissions solve this by making all objects of other users, roles or groups accessible (§9.4.2).

A user can receive super permissions for: User, Role, Group or Any.

warning

The super permission Any cannot be set explicitly — it is restricted to the super administrator and is only set by creating one. A user can only set super permissions for self-created objects; only the super administrator can grant super permissions to any other user, role or group. Super permissions grant complete access to a subject's resources, so assign them deliberately.

To assign a super permission:

  1. On the Users, Roles or Groups page, click the name of the user, role or group that should receive super permissions.
  2. Open its details page; the resource ID is shown in the upper right corner.
  3. Note or copy the ID.
  4. Select Administration then Permissions.
  5. Create a new permission.
  6. In the Name drop-down list select Super (Has super access).
  7. Select the radio button for the subject type that should have super permissions.
  8. In the corresponding drop-down list select the user, role or group.
  9. Select the resource type in the Resource Type drop-down list.
  10. Enter or paste the resource ID into the ID box.
  11. Click Save.
tip

Super permissions can be assigned to entire groups, letting all members of a group access all resources created by other members.

Granting read access to other users​

Every user can share an unlimited number of self-created resources. To do so, the user requires the global get_users permission and the specific get_users permission for the user who should obtain read access (§9.4.3.1).

tip

The easiest and recommended way to share self-created resources is to use an administrator account and to create — with that account — the user accounts that should receive read access. The other methods below are more cumbersome and time-consuming.

Requirements for administrators​

By default, administrators already have the global get_users permission. An administrator obtains the specific get_users permission for an account in two ways:

  • Create the account themselves — administrators automatically have the specific get_users permission for accounts they created.
  • Have a super administrator grant it: as super administrator, open Administration then Users, open the target account's details and Permissions register, create a permission, select read in the Grant drop-down list, choose the User radio button, select the administrator, and Save.

Requirements for regular users​

Regular users do not have the global get_users permission by default. Add it by creating a dedicated role:

  1. As an administrator, select Administration then Roles.
  2. Create a new role.
  3. Enter GrantReadPriv in the Name box and Save.
  4. Edit the new role; in the New Permission section, Name drop-down list, select get_users.
  5. Click Create Permission (it appears in General Command Permissions) and Save.
  6. Select Administration then Users, edit the relevant user, add the GrantReadPriv role in the Roles list and Save.

A super administrator can grant a specific get_users permission to a user the same way as for an administrator (open the account details and Permissions register, select read in Grant, choose the User radio button, select the user, and Save).

Granting read access​

Once a user has both the global and the specific get_users permission, they can share a resource:

  1. Click the name of the resource to be shared and open its details page; the object ID is shown in the upper right corner.
  2. Note or copy the ID.
  3. Select Administration then Permissions and create a new permission.
  4. In the Name drop-down list select the read permission for the object type:
    • Filter — get_filters
    • Scan configuration — get_configs
    • Alert — get_alerts
    • Note — get_notes
    • Override — get_overrides
    • Tag — get_tags
    • Target — get_targets
    • Task with report — get_tasks
    • Schedule — get_schedules
  5. Select the User radio button.
  6. In the corresponding drop-down list select the user the object should be shared with.
  7. Enter or paste the resource ID into the ID box.
  8. Click Save.
note

Resources can also be shared with roles or groups. This requires the global and specific get_groups permission (read access to a group) or get_roles permission (read access to a role), following the same principle. Exception: users with a default role already have the specific get_roles permissions for all default roles (§9.4.3.2).

5. Central User Management (LDAPS / RADIUS)​

In larger environments, password synchronization is difficult and creating or resetting passwords is costly. The appliance supports a central password store using LDAPS or RADIUS. The service is used only for authentication on a per-user basis: users must be configured for that authentication method and must also exist on the appliance (§9.5).

caution

The prerequisite for central authentication is that users are named with the same names as the objects in the LDAPS tree or the RADIUS server. The appliance does not add, modify or remove users in the external directory, and does not automatically grant any directory user access to the appliance.

LDAPS​

The appliance only supports encrypted connections via LDAP using StartTLS (port 389) or LDAPS using SSL/TLS (port 636). The server must make its services available over SSL/TLS (§9.5.1).

Store the server certificate first. To verify the LDAPS server's identity, the certificate of the issuing certificate authority (CA) must be stored on the appliance, exported as a Base64-encoded file (often a .pem file beginning with the BEGIN CERTIFICATE marker). If the CA is an intermediate CA, the complete certificate chain (Issuing CA plus Root CA) must be imported — common when an official CA is used (§9.5.1.1).

Connect to the LDAPS tree (§9.5.1.2):

  1. Log in as an administrator.
  2. Select Administration then LDAP.
  3. Open the edit action and activate the Enable checkbox.
  4. Enter the LDAPS host in the LDAP Host box. Only one system can be entered, by IP address or name. The appliance accesses the host over SSL/TLS; without it, LDAPS authentication is rejected.
  5. Enter the distinguished name in the Auth. DN box. The wildcard %s replaces the user name. Examples:
    • cn=%s,ou=people,dc=domain,dc=de — works for any LDAPS server with the correct attributes, using cn. All users must be in the same branch and level of the tree.
    • uid=%s,ou=people,dc=domain,dc=de — uses uid as a filter; ou=people,dc=domain,dc=de is the base object for the search.
    • %s@domain.de — typically Active Directory; the user object location is irrelevant.
    • domain.de\%s — typically Active Directory; the user object location is irrelevant.
  6. Upload the host certificate via Browse.
  7. Optionally activate Use LDAPS only to disable StartTLS and plain-text connections, allowing only LDAPS — useful when the LDAP port is blocked by a firewall.
  8. Click OK.

When LDAPS is enabled, the LDAP Authentication Only option becomes available when creating or editing a user (disabled by default). Activate it for users that should authenticate via LDAPS. The user must already exist with the same name in LDAPS.

warning

If LDAPS authentication does not work, verify that the LDAP Host entry matches the commonName of the LDAPS server's certificate. If they differ, the appliance refuses to use the server.

RADIUS​

Configure RADIUS authentication (§9.5.2):

  1. Log in as an administrator.
  2. Select Administration then Radius.
  3. Open the edit action and activate the Enable checkbox.
  4. Enter the host name or IP address in the RADIUS Host box.
  5. Enter the common preshared secret key in the Secret Key box.
  6. Click OK.

When RADIUS is enabled, the RADIUS Authentication Only option becomes available when creating or editing a user (disabled by default). Activate it for users that should authenticate via RADIUS. The user must already exist with the same name on the RADIUS server.