6. GUI Administration

6.1. User Management

The Greenbone Security Manager allows for the definition and the management of different users with different roles and permissions. When initializing the GSM the first user, the web/scan administrator respectively, is being created via the GOS-Admin-Menu already. This user allows the login and management of additional users.

The GSM user management supports a role based permission concept when accessing the web interface. Various roles are already set up by default. Additional roles can be created and used by an administrator. The role defines which options of the web interface can be viewed and modified by the user. The role enforcement is not implemented in the web interface but rather in the underlying GMP protocol and hence affecting all GMP clients. Read and write access can be assigned to roles separately.

In addition to the roles the GSM user management supports groups as well. This serves mainly for logical grouping. Groups and roles may be used to assign permissions to several users at once.

Each user may be assigned an IP address range containing the allowed or denied targets. The GSM appliance will then refuse to scan any other IP addresses than the ones specified for the respective user. Similarly the access to specific interfaces of the GSM appliance can be allowed and denied.

This user management is contained within the GSM. External sources for the user management are not supported. However, to support central authentication and to allow password synchronization the Greenbone Security Manager may be integrated with a central LDAP or RADIUS server. But this server will only be used to verify the password during the log in process of the user. All other settings are being performed in the User Management of the GSM appliance.

These functions are being covered in more detail below.

6.1.1. Creating and Managing Users

The dialog for the creation and management of users can be accessed via the Administration menu. This menu is only visible to administrators as only they are allowed to create and manage additional users. The dialog to create a new user can be accessed via the white asterisk on blue background new or by selecting the wrench an existing user can be modified.


Creating a new user.

When creating a new user the following options are available:

  • Login Name: This is the name the user logs in with. If an LDAP server is used for central password management, the user needs to be created with the identical name (rDN) as used by the LDAP server. This is also true when using a RADIUS server. The name can be a maximum of 80 characters and can contain letters and numbers.

  • Password: This is the password for the user. The password can be a maximum of 40 characters and can contain any type of character. Please note when using special characters that they are available on all keyboards and operating systems in use.

  • Roles (optional): Each user can have multiple roles. The roles define the permissions of a user when using the OMP protocol. Since the Greenbone Security Assistant utilizes the OMP protocol the roles define directly the features in the web interface. While it is possible to add and configure additional roles, at the beginning, the roles Admin, User, Info, Observer, Guest and Monitor are available. These roles are discussed in more detail in section User Roles.

  • Groups: Each user can be a member of multiple groups. Permissions management can be performed via groups as well (see section Permissions).

  • Host Access: These systems may be analyzed by the user in a scan. Alternatively you can specify which systems should not be considered in a scan. These restrictions also apply to administrators. They can, however, remove these restrictions themselves. This function simply serves as a self-protection for administrators. Normal users (User) and roles without access to the user management respectively cannot circumvent this restriction. Basically either a whitelist (deny all and allow) or a blacklist (allow all and deny) are possible. In the first case the scanning of all systems is denied in general and only explicitly listed systems are allowed to be scanned. In the latter case the scanning of all systems is allowed except the listed systems. System names as well as IPv4 and IPv6 addresses can be entered. Furthermore individual IP addresses as well as address ranges and network segments can be specified. The following listing shows some examples:

    • (IPv4 address)
    • (IPv4 range long form)
    • (IPv4 range short form)
    • (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 (CIDR notation)

    All options can be mixed and matched and entered as a comma separated list. The netmask in the CIDR notation is restricted to a maximum of 20 for IPv4 and 116 for IPv6. In both cases the result is a maximum of 4096 IP addresses.


    Displaying a user.

  • Interface Access: If the GSM uses several network adapters to connect to different networks the usage of these adapter may be restricted for the scan by the user. A comma separated list of network adapters can be entered and similar to the Host Access it can be chosen between a whitelist and blacklist methodology.


In general the whitelist methodology should be used and scans of systems denied except for the chosen systems. This is to ensure that users do not scan systems by accident or unknowingly that are outside of there are of responsibility, are located somewhere on the Internet or react to a malfunctioning scan.

After creating the user the user’s properties are displayed. The display should be verified to ensure that the user does not have too many permissions assigned to him.

6.1.2. Simultaneous Log in

It is possible, of course, that two users are logged into a GSM at the same time. If the same user wants to log in multiple times the login must be performed from a different PC or at least a different browser. Another log in in the same browser invalidates the first login.

6.2. User Roles

The Greenbone Security Assistant supports the creation and configuration of your own user roles. Like in all other instances the modification of the factory provided roles is not possible. However they may be copied (cloned) and subsequently modified. This ensures consistent behaviour when updating the software.

The role management can be accessed via the web interface in the menu Administration in the submenu Roles. The following three roles are available by default:

  • Admin: This role by default has all permissions. It is especially allowed to create and manage other users.
  • Guest: This role corresponds with the Info role. It merely is not allowed to change its settings.
  • Info: This role (Information Browser) only has read access to the NVTs and SCAP information. All other information is not available.
  • Monitor: This role has access to performance data of the GSM (see section monitoring_and_debugging).
  • Observer: This role has read access to the system. It is not allowed to start or create new scans. It has only read access to the scans for which the respective users have been set up as observers.
  • Super Admin: This role has access to all objects of all users. It has no relation to the SuperUser in the command line. This role can not be configured in the web interface. The configuration is only possible in the GOS-Admin-Menu (see section Super Admin),
  • User: This role by default has all permissions with the exception of user, role and group management. Besides, this role is not allowed to synchronize and manage the feeds. In the web interface there is no access to the menu option Administration. All other options, however, are available to this role.

Additional roles can easily be created. The simplest way to create a new role is copying one of the existing roles that reflects your needs the closest and modify it. In rare cases you might want to create a role that only supports limited functionality. In those cases it makes more sense to start with an empty role.

User can have more than one role. Therefore permissions can be grouped with the help of the roles. If more than more than one role is assigned to a user the permissions of the roles will all be added.

Hence a role Maintenance can be created for example. This role is being assigned the following permissions:

  • authenticate
  • get_settings
  • write_settings
  • help
  • describe_cert
  • describe_feed
  • describe_scap
  • sync_cert
  • sync_feed
  • sync_scap

The TaskAdmin role only has restricted access.

Additional roles then can have the name TargetAdmin, ScanConfigAdmin, TaskAdmin and Scanner and assigned permissions respectively. Important is the fact that roles require at minimum the permissions authenticate and get_settings. These are an imperative requirement to log into the web interface. The permission write_settings makes sense as well. Then a user can change his own password, time zone and other personal settings.

Users can be assigned different permutations of these roles. This allows specific users to configure target systems, scan configurations or configure and start the actual scan. In the selection of the permissions only the permissions that are not assigned are being displayed. This simplifies adding and the overview of the still available permissions.

If a user logs in with the role TaskAdmin later the menu options are restricted respectively.


The menu selection for the TaskAdmin role is restricted.

6.2.1. Guest Log in

The GSM can be configured for guest log in. The guest user is only allowed to access the SecInfo-Management (see chapter secinfo_management). This offers easy access to current information without password.


The guest role has access to the SecInfo Dashboard.

To allow this guest access a user can be created and assigned the Guest role.


Create a guest user.

Having knowledge of the password this user now can log in and is presented with the dashboard.

To allow a guest log in without password it must be activated on the command line first. To do so start the GOS-Admin-Menu and select the option User followed by Web Users. Afterwards activate the Guest User in the respective option. Enter the name of the guest user and his password. Save the pending changes. No reboot is required. Now the guest login is available at the web login screen (see figure Log in as guest user without password.)


Log in as guest user without password.

6.2.2. Super Admin

The Super Admin is the highest level of access. It was introduced with the new permission concept. The regular admin role is equal to a simple user but additionally allows the creation, modification and deletion of users. Furthermore the admin can view, modify and delete any permission on the system but the admin is at the same time subjected to those permissions. If any user creates a private scan configuration but does not share it, the admin may not access the scan configuration. Of course the Admin could create respective permissions itself to the resource created by the user but this is quite cumbersome. For the collaborative work of groups of users additional permissions might be setup (see section Super Permissions).

Again for diagnostic purposes these are not very helpful and the Super Admin is more suited. The Super Admin is excluded from the permission restrictions. The Super Admin is allowed to view and edit any configuration settings of any user.

But the Super Admin can not be created in the web interface. To create the Super Admin access to the command line is required. This user and password can be created in Gos-Admin-Menu under the menu User/Web Users submenu Super Admin.

Afterwards the super admin may be edited in the web interface.


The Super Admin can not be created in the web interface!

The Super Admin can not be modified by the regular admin. Only the Super Admin itself can modify the settings of this user! Super Permissions

Roles and groups can be assigned with Super-Permissions. Then all objects within a group may be accessed.

Any resource created on the GSM (scan, configuration, target, and so on) is either global or is owned by a specific user. Global resources are identified by the icon view_other. Any resource that is not global can be viewed and used only by its owner initially. Individual permissions are necessary to make the resource available to other users. This is very cumbersome. Therefore the Greenbone OS offers the option to assign Super Permissions. A user can get these Super Permissions for:

  • User
  • Role
  • Group
  • Any

These Super Permissions then allow complete access to any resources of the respective user, role, group or effectively all resources. The any access can not be set explicitly. It is a privilege of the Super Admin (see section Super Admin). This is why the last Super Permission can only be set by creating a Super Admin.

A user can only set Super Permissions for objects created by himself. First the user must determine the Resource ID of the user, the role or the group for which to set the Super Permissions.

Afterwards the values can be entered in the dialog.


For the Super Permission the Resource ID is required.

In the success message instead of the Resource ID the name is being displayed in clear text.


The group DepartmentA has Super Access to the resources of the group DepartmentA.

In this example all members of the group DepartmentA have full access to the object created by the other users within the same group. If a user with the role observer is member of the group DepartmentA this user may execute only read permissions on all objects created by the members of the group. The observer role restricts the available permissions.

The Super Permissions simplify the permission management on the GSM. Super Permissions for entire groups can be assigned very easily. This allows all users of a group access to all resources that are being created by other members of the group. GetUsers Role for Observers

The GSM allows for management of observers (see section Permissions). These are users that have read access to specific tasks and their respective reports. These observers by default can only get permissions to tasks and reports by administrators. Regular users can not grant observers access to their own tasks. Therefore they can not share their tasks with other users. The respective dialog to manage permissions in not functional and does not support the selection of users.


Regular users can not create observers.

For regular users to assign read permission to their tasks to other users they require the permission get_users to access the user database. This permission is not granted by default but can be easily added using a special role.

The following steps explain the creation of this special role GrantReadPriv (see figure The role GrantReadPriv allows to manage read access.). In a second step the role needs to be assigned the permission gos:perm:get_users. Every user with this additional role is assigned the permission to read the userdatabase. He then may share read access to their own tasks.


The role GrantReadPriv allows to manage read access.

Then, in addition, this role must only be assigned to the respective users.


In case the user is also allowed to share read access to groups or roles the get_groups and get_roles permissions must be assigned respectively.

6.3. Groups

Aside of the roles group management is also part of the Greenbone Security Assistant. These groups are used to logically group users. Additionally through the groups permissions can be assigned as well (see section Permissions). By default no groups are set up. Indefinite groups can be created.

The following information must be included:

  • Name: The name of the Group can be a maximum of 80 characters and can contain letters and numbers.
  • Comment: An optional comment that describes the group in more detail.
  • Users: The members of the group can be selected directly. The members can be separated by a space or comma. The length of the entry can be a maximum of 1000 characters. Alternatively, group memberships can be managed in the user profile directly.

Groups can be used to manage permissions.

6.4. Permissions

Under the menu option Configuration/Permissions every single permission assigned on the system can be viewed. This can easily reach hundreds of permissions if multiple roles are created. Each individual permission displayed always relates to exactly one subject.

A subject can be either

  • a user
  • a role
  • or a group.

Normally permissions are being managed using the web interface vie the roles (see section User Roles). Thereby the permissions of the role can be managed in the role management as well as here. Alternatively permissions can be assigned directly to users and groups.

This option gives you the most possible flexibility when managing permissions. However adding and managing permissions using this dialog is only recommended for experienced users who are looking for a specific permission or who want to delete a specific user, for example.


It is also possible to modify the permissions of the default roles with this dialog. This could have unwanted effects when updating and the permissions are reset again.

6.4.1. Sharing Individual Objects for Other Users

Every user can share indefinite objects created by himself. However, the user must be assigned the permission get_users. Otherwise the user will not have permission to determine the name of other users (see section GetUsers Role for Observers).

To share an object, first determine the Object-ID. Sharing by name is not possible. To acquire the ID display the object that is to be shared in the browser (i.e. a filter). At the top right of the display you can find and copy the ID.


Copying of the ID of an object to be shared.

Afterwards switch into the menu Configuration/Permissions. Create a new permission new. Then select the proper permission for the object to be shared:

  • Filter: get_filters
  • Scan configuration: get_configs
  • Alert: get_alerts
  • Notes: get_notes
  • Overrides: get_overrides
  • Tags: get_tags
  • Targets: get_targets
  • Task with report: get_tasks
  • Schedules: get_schedules

Select the appropriate subject (user, role or group) and paste the copied Resource ID into the respective field.


Copying of the ID of an object to be shared.

6.5. Central User Management

Especially in larger environments with multiple users it is often difficult to achieve password synchronization. The effort to create new or reset passwords is often very high. To avoid this, the GSM appliance supports the usage of a central password store via LDAP or RADIUS. The GSM will use the service only for authentication on a per user basis. This means that users who should be able to authenticate through the service have to exist on the GSM as well and have to be configured for authentication through the service as well.

Prerequisite for using central authentication is the naming of the users with the same name as the object in the LDAP tree or the RADIUS server.

6.5.1. LDAP

Below the connection to a LDAP tree is covered. Thereby the GSM appliance uses a very simple interface. While other most systems supporting LDAP first search for the matching object in the LDAP tree and subsequently log in as this object afterwards (Search&Bind), the GSM appliance uses a simple bind with a hard coded object path.


Central LDAP authentication requires entering the DN.

Then the distinguishedName of the objects can be defined distinctively. Thereby the wildcard %s replaces the username. Examples for the Auth. DN are:

  • uid=%s,ou=people,dc=domain,dc=de
  • %s@domain.de
  • domain.de\%s

While the first example should work for any LDAP server with the correct attributes, the second and third example are typical formats used by Active Directory. Hereby the exact location of the user object is irrelevant.

The first example does not support users in different sub trees or different recursive depths of an LDAP tree. All users that need to log into the GSM must be in the same branch and in the same level of the LDAP tree!

The other information required is the LDAP Host. Only one system with its IP address or name can be entered here. The GSM accesses the LDAP host via SSL. To verify the host the certificate of the host must be uploaded to the GSM. Without SSL the LDAP authentication will not be accepted. Further information is available in the section LDAP with SSL/TLS.

Once you have enabled LDAP authentication, you will notice a new option LDAP Authentication Only in the New User section which will be off by default. Checked it if the new user should be able to login with the credentials configured in the directory service. For existing users you may enable this option through the Edit User dialog.

Please note that the user has to exist with this name in your directory service prior to use with the GSM. The GSM will not add, modify or remove users in your directory service. It will also not grant any user from your directory service automatically access to the GSM. You have to authorize every user separately by adding a user with the same name to the GSM with Allow LDAP-Authentication only checked as described above.

Also note that a locally configured user (i.e. a user which is not enabled for LDAP authentication) “Smith” on the GSM takes precedence over a user “Smith” in the connected directory service.

6.5.2. LDAP with SSL/TLS

The GSM appliance uses either the command StartTLS via the LDAP protocol on port 389 or SSL via LDAPS on port 636. Therefore the LDAP server must make its services available via SSL. The exact configuration of all available LDAP servers is out of scope for this manual. Therefore the following are just a couple of references:

In order for the GSM appliance to verify the identity of the LDAP server it must trust its certificate. For this the certificate of the issuing certificate authority must be stored on the GSM. To do so the certificate of the certificate authority must be exported as a Base64 encoded file. A Base64 encoded certificate is often using the file extension .pem. The file itself starts with ------BEGIN CERTIFICATE-------.

If the certificate authority is an intermediate certificate authority the complete certificate chain needs to be imported. This is often true if an official certificate authority is used because the Root CA is separated from the Issuing Certificate Authority. In these cases the contents of the file looks like:

Issuing Certificate Authority
Root CA

The actual place where you may find this certificate may vary based on your environment.

  • Univention Corporate Server (UCS)

    Here you may retrieve the CA certificate from the file /etc/univention/ssl/ucsCA/CAcert.pem. This file already contains the certificate in the correct format and may be used by the command ldapcertdownload.

  • Active Directory LDAP

    If your Active Directory LDAP service does not yet use LDAPS, you may find the following article helpful: http://social.technet.microsoft.com/wiki/contents/articles/2980.ldap-over-ssl-ldaps-certificate.aspx The Active Directory LDAP — CA certificates can then be exported using the following procedure which must be performed from a desktop or server that has access to the Certification Authority console.

    • Open the Certification Authority console from any domain-joined computer or server.
    • Right-click the name of the certification authority and then select Properties.
    • In the CA certificates dialog box, choose the General tab, and then select the certificate for the certification authority you want to access.
    • Choose View Certificate.
    • In the Certificate dialog box, choose the Certification Authority tab. Select the name of the root certification authority and then choose View Certificate.
    • In the Certificate dialog box, choose the Details tab and then choose Copy to File.
    • The Certificate Export Wizard appears. Choose Next.
    • On the Export File Format page, select the Base-64 encoded X.509 (.CER) option.
    • Choose Next.
    • In the File to Export box, choose the path and name for the certificate, and then choose Next.
    • Choose Finish. The .cer file will be created in the location that you specified in the previous step.
    • A dialog box appears to inform you that the export was successful. Choose OK to finish.

    The contents of the file must be uploaded when enabling LDAP.

If the LDAP authentication does not work please verify that the entry in LDAP Host matches the commonName of the certificate of the LDAP server. If there are deviations the GSM appliance will refuse using the LDAP server.

6.5.3. RADIUS

Using a RADIUS server for central authentication is very simple. Navigate to the Administration/Radius menu.


RADIUS just requires a common preshared secret key.

Enable the RADIUS authentication and enter the hostname or IP address of the RADIUS server and the common preshared secret key to authenticate to and subsequently encrypt the communication with the RADIUS service.

Once the RADIUS service is enabled any user can be configured to authenticate via the RADIUS service.


Enable RADIUS for a user