The Greenbone Security Manager (GSM) allows for the definition and management of multiple users with different roles and permissions. When initializing the GSM, the first user – the web/scan administrator – is already created in the GOS administration menu. With this user, additional users can be created and managed.
Groups and roles may be used to assign permissions to several users at once.
Each user is assigned an IP address range containing the allowed or denied targets. The GSM appliance will refuse to scan any other IP addresses than the ones specified. Similarly, the access to specific interfaces of the GSM appliance can be allowed or denied.
The user management is completely done with the GSM. External sources for the user management are not supported. However, to support central authentication and to allow password synchronization the GSM can be integrated with a central LDAP or RADIUS server (see Chapter 9.5). The server will only be used to verify the password during the login process of the user. All other settings are performed in the user management of the GSM.
Users can be created as follows:
Note
Only administrators are allowed to create and manage additional users.
Log in as an administrator.
Select Administration > Users in the menu bar.
Define the user (see Fig. 9.1).
Click Create.
→ The user is created and displayed on the page Users.
The following details of the user can be defined:
This is the password used for logging in. The password can contain any type of character and can be at most 40 characters long.
Note
When using special characters, note that they have to be available on all used keyboards and operating systems.
Note
When a central user management is used, more options are available (see Chapter 9.5).
Hosts on which the user is allowed to run scans. The restrictions also apply to administrators but they are allowed to remove them themselves. Normal users (User) and roles without access to the user management cannot circumvent the restrictions. Basically either a whitelist (deny all and allow) or a blacklist (allow all and deny) is possible.
Tip
In general the whitelist methodology should be used. This ensures that users do not scan systems lying beyond their responsibility, located somewhere on the Internet or reacting to malfunctioning scans by accident.
System names as well as IPv4 and IPv6 addresses can be entered. Individual IP addresses as well as address ranges and network segments can be specified. The following listing shows some examples:
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 IP addresses for IPv4 and 116 IP addresses for IPv6. In both cases the result is a maximum of 4096 IP addresses.
List Page
All existing users can be displayed by selecting Administration > Users in the menu bar when logged in as an administrator.
For all users the following information is displayed:
For all users the following actions are available:
Note
By clicking or
below the list of users more than one user can be deleted or exported at a time. The drop-down-list is used to select which users are deleted or exported.
Details Page
Click on the name of a user to display the details of the user. Click to open the details page of the user (see Fig. 9.2).
The following registers are available:
The following actions are available in the upper left corner:
It is possible that two users are logged in at the same time.
If the same user wants to log in more than once at the same time, the login must be performed from a different PC or with a different browser. Another login in the same browser invalidates the first login.
The guest user is only allowed restricted access to the web interface.
To allow the guest access, a user can be created and assigned the role Guest (see Chapter 9.1.1).
Having knowledge of the password the guest user can now log in and is presented with the page Dashboards.
To allow a guest to log in without needing a password, this feature has to be activated in the GOS administration menu (see Chapter 7.2.1.4).
The web interface supports the creation and configuration of own user roles.
The following roles are available by default:
Note
Only administrators are allowed to create and manage additional roles.
Note
Modifying the default roles is not possible but they can be copied (cloned) and subsequently modified.
This ensures consistent behaviour when updating the software.
When an existing role closely reflects the demands, a new role can be created by cloning the existing role:
Log in as an administrator.
Select Administration > Roles in the menu bar.
Enter the name of the role in the input box Name (see Fig. 9.3).
Select the users that should have the role in the drop-down-list Users.
Add a permission by selecting it in the drop-down-list Name and clicking Create Permission.
Add a super permission by selecting the respective group in the drop-down-list Group and clicking Create Permission.
Delete a permission by clicking in the list General Command Permissions.
Click Save.
When a role with only limited functionality should be created, it can be started with a new, empty role:
Log in as an administrator.
Select Administration > Roles in the menu bar.
Define the role.
The following details of the role can be defined:
The name of the role can contain letters and numbers and can be at most 80 characters long.
A comment describes the role in more detail.
The users with this role can be selected in the drop-down-list Users. Alternatively, roles can be managed in the user profile (see Chapter 9.1.1).
Click Save.
→ The role is created and displayed on the page Roles.
Add a permission by selecting it in the drop-down-list Name and clicking Create Permission.
Add a super permission by selecting the respective group in the drop-down-list Group and clicking Create Permission.
Delete a permission by clicking in the list General Command Permissions.
Click Save.
Note
Some permissions are required:
List Page
All existing roles can be displayed by selecting Administration > Roles in the menu bar.
For all roles the following information is displayed:
For all roles the following actions are available:
Note
By clicking or
below the list of roles more than one roles can be deleted or exported at a time. The drop-down-list is used to select which roles are deleted or exported.
Details Page
Click on the name of a role to display the details of the role. Click to open the details page of the role.
The following registers are available:
The following actions are available in the upper left corner:
A user can have more than one role to group permissions.
The roles are assigned when creating a new user (see Fig. 9.4, see Chapter 9.1.1). If more than one role is assigned to a user, the permissions of the roles will be added.
The role Super Admin is the highest level of access.
The role Admin is allowed to create, modify and delete users. Additionally, it can view, modify and delete permissions but is subordinated to those permissions as well. If any user creates a private scan configuration but does not share it, the administrator cannot access it.
The role Super Admin is more suited for diagnostic purposes. The super administrator is excluded from permission restrictions and allowed to view and edit any configuration settings of any user.
The super administrator has to be created in the GOS administration menu (see Chapter 7.2.1.5)
Note
The super administrator can only be edited by the super administrator.
By default, only administrators can grant other users read access to tasks and reports. Regular users cannot share their tasks and reports with other users.
If users want to assign read access for their tasks and reports to other users they require the permission get_users. This permission is not granted by default but can be added as follows:
Log in to the web interface as an administrator.
Select Administration > Roles in the menu bar.
Enter GrantReadPriv
in the input box Name.
Click Save.
→ The role is created and displayed on the page Roles.
In the drop-down-list Name in the section New Permission select get_users (see Fig. 9.5).
Click Create Permission.
→ The permission is displayed in the section General Command Permissions (see Fig. 9.5).
Click Save.
Select Administration > Users in the menu bar.
In the row of the user which should be assigned the newly created role click .
In the input box Roles add the role GrantReadPriv.
Click Save.
Note
Additionally, the permissions get_groups — granting read access to a group — and get_roles — granting read access to a role — are available and follow the same principle as described above.
Groups are used to logically assemble users. An unlimited number of groups can be created.
Permissions can be assigned for the groups (see Chapter 9.4). By default, no groups are set up.
A group can be created as follows:
Note
Only administrators are allowed to create and manage groups.
Log in as an administrator.
Select Administration > Groups in the menu bar.
Define the group (see Fig. 9.6).
Click Save.
→ The group is created and displayed on the page Groups.
The following details of the group can be defined:
List Page
All existing groups can be displayed by selecting Administration > Groups in the menu bar.
For all groups the following information is displayed:
For all groups the following actions are available:
Note
By clicking or
below the list of groups more than one group can be deleted or exported at a time. The drop-down-list is used to select which groups are deleted or exported.
Details Page
Click on the name of a group to display the details of the group. Click to open the details page of the group.
The following registers are available:
The following actions are available in the upper left corner:
Select Configuration > Permissions to display all permissions assigned on the system. If multiple roles are created, there can easily be hundreds of permissions.
Each permission relates to exactly one subject. A permission enables a subject to perform an associated action.
Subjects can be of the following types:
There are two types of permissions:
Note
Usually, permissions are assigned in the web interface using the role management (see Chapter 9.2).
Creating and managing permissions using the page Permissions is only recommended to experienced users looking for a specific permission.
A new permission can be created as follows:
Select Configuration > Permissions in the menu bar.
Define the permission (see Fig. 9.7).
Click Save.
→ The permission is created and displayed on the page Permissions.
The following details of the permission can be defined:
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.
When accessing a resource details page, e.g. the detail page of a task, permissions for the resource can be granted directly on the details page as follows:
Open the details page of a resource.
Example: Select Scans > Tasks in the menu bar.
Click on the name of a task.
Click on the register Permissions.
Define the permission (see Fig. 9.8).
Click Save.
→ The permission is created and displayed in the section Permissions on the resource details page.
There are two types of permissions that can be granted directly on the resource details page:
Some resource types include additional permissions:
For some resource types it can be selected whether the permissions should also be granted for related resources (see Fig. 9.8).
Note
Permissions can also be created only for the related resources.
The details of the related resources are displayed below the drop-down-list.
List Page
All existing permissions can be displayed by selecting Configuration > Permissions in the menu bar.
For all permissions the following information is displayed:
For all permissions the following actions are available:
Note
By clicking or
below the list of permissions more than one permission can be deleted or exported at a time. The drop-down-list is used to select which permissions are deleted or exported.
Details Page
Click on the name of a permission to display the details of the permission. Click to open the details page of the permission.
The following registers are available:
The following actions are available in the upper left corner:
Any resource created on the GSM (e.g. task, scan configuration or target) is either global or owned by a specific user.
Global resources are identified by .
Non-global resources can be viewed and used only by their owner. Individual permissions are necessary to make the resources available to other users which is quite tedious.
To avoid that, users, roles and groups can be assigned with super permissions. This makes all objects of other users, roles or groups accessible.
A user can get super permissions for:
These super permissions allow complete access to any resource of the respective user, role, group or effectively all resources.
Note
The super permission Any cannot be set explicitly. It is restricted to the super administrator (see Chapter 9.2.1.5) and can only be set by creating such.
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.
Click on the name of the user/role/group on the page Users/Roles/Groups for which super permissions should be assigned.
Open the details page by clicking .
→ The resource ID can be found in the upper right corner (see Fig. 9.9).
Note or copy the ID.
Select Configuration > Permissions in the menu bar.
In the drop-down-list Name select Super (Has super access) (see Fig. 9.10).
Select the radiobutton of the subject type that should have super permissions.
In the according drop-down-list select the user/role/group that should have super permissions.
Select the resource type for which super permissions should be assigned in the drop-down-list Resource Type.
Enter or paste the previously determined resource ID into the input box ID.
Click Save.
→ The super permission is created and displayed on the page Permissions.
Tip
Super permissions simplify the permission management on the GSM. They can easily be assigned for entire groups. This allows all users of a group to access all resources that are created by other members of the group.
Every user can share indefinite self-created resources.
Note
To do so, the user must be assigned the permission get_users. Otherwise, the user will not have permission to determine the name of other users (see Chapter 9.2.2).
When the user has obtained the permission get_users, the user can share resources as follows:
On the respective page click on the name of the resource which should be shared.
Open the details page by clicking .
→ The object ID can be found in the upper right corner (see Fig. 9.11).
Note or copy the ID.
Select Configuration > Permissions in the menu bar.
In the drop-down-list Name select the permission for the object to be shared.
Select the radiobutton of the subject type the object should be shared with (see Fig. 9.12).
In the according drop-down-list select the user/role/group the object should be shared with.
Enter or paste the previously determined resource ID in the input box ID.
Click Save.
→ The permission is created and displayed on the page Permissions.
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 supports the usage of a central password store using LDAP or RADIUS.
The GSM will use the service only for authentication on a per user basis, i.e. users who should be able to authenticate by the service have to be configured for authentication and to exist on the GSM as well.
Note
Prerequisite for using central authentication is the naming of the users with the same names as the objects in the LDAP tree or the RADIUS server.
For the connection to an LDAP tree the GSM uses a very simple interface and a simple bind operation with a hard coded object path. The LDAP authentication is done as follows:
Log in as an administrator.
Select Administration > LDAP in the menu bar.
Activate the checkbox Enable (see Fig. 9.13).
Enter the LDAP host in the input box LDAP Host.
Note
Only one system can be entered by IP address or by name.
The GSM accesses the LDAP host using SSL/TLS. For verifying the host, the certificate of the host has to be uploaded to the GSM. Without SSL/TLS the LDAP authentication will not be accepted (see Chapter 9.5.2).
Enter the distinguished name (DN) of the objects in the input box Auth. DN.
Note
The wildcard %s
replaces the user name.
Examples for the Auth. DN are:
cn=%s,ou=people,dc=domain,dc=de
uid=%s,ou=people,dc=domain,dc=de
%s@domain.de
domain.de\%s
To verify the host, upload the certificate of the host by clicking Browse....
Click OK.
→ When the LDAP authentication is enabled, the option LDAP Authentication Only is available when creating or editing a user. By default, this option is disabled.
Create a new user or edit an existing user (see Chapter 9.1).
Activate the checkbox LDAP Authentication Only when the user should be allowed to authenticate using LDAP (see Fig. 9.14).
Note
The user has to exist with the same name in LDAP before the authentication with LDAP can be used. The GSM does not add, modify or remove users in LDAP and it does not automatically grant any user from LDAP access to the GSM.
The GSM uses either the command StartTLS via LDAP on port 389 or SSL/TLS via LDAPS on port 636. The LDAP server must make its services available to SSL/TLS.
The following references are helpful for the exact configuration of all available LDAP servers:
To verify the identity of the LDAP server, the GSM has to trust the server’s certificate. For this, the certificate of the issuing certificate authority (CA) must be stored on the GSM.
To do so, the certificate of the CA must be exported as a Base64 encoded file.
A Base64 encoded certificate often has the file extension .pem
. The file itself starts with ------BEGIN CERTIFICATE-------
.
If the CA is an intermediate CA, the complete certificate chain needs to be imported. This is often true if an official CA is used because the Root CA is separated from the Issuing CA.
In these cases the contents of the file look as follows:
-----BEGIN CERTIFICATE-----
......
Issuing CA
......
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
......
Root CA
......
-----END CERTIFICATE-----
The actual location where the certificate can be found may vary based on the environment.
Univention Corporate Server (UCS)
Here the CA certificate is retrieved from the file /etc/univention/ssl/ucsCA/CAcert.pem
. This file already contains the certificate in the correct format and has to be uploaded when enabling LDAP.
Active Directory LDAP
If the Active Directory LDAP service does not yet use LDAPS, the following article may be helpful: https://social.technet.microsoft.com/wiki/contents/articles/2980.ldap-over-ssl-ldaps-certificate.aspx.
The Active Directory LDAP CA certificate can then be exported as follows:
Note
The steps have to be executed from a desktop or server that has access to the CA console.
Open the CA console from any domain-joined computer or server.
Right click the name of the CA and select Properties.
In the CA certificates dialog box, select the tab General.
Select the certificate for the CA that should be accessed.
Click View Certificate.
In the dialog box Certificate, select the tab Certification Authority.
Select the name of the root CA and click View Certificate.
In the dialog box Certificate, select the tab Details.
Click Copy to File.
→ The certificate export wizard is opened.
Click Next.
Select Base-64 encoded X.509 (.CER) on the page Export File Format.
Click Next.
Enter the path and the name for the certificate in the input box File to Export.
Click Next.
Click Finish.
→ The CER file is created in the specified location. A dialog box informs that the export was successful.
Click OK.
The contents of the file must be uploaded when enabling LDAP.
Note
If the LDAP authentication does not work, verify that the entry in LDAP Host matches the commonName of the certificate of the LDAP server. If there are deviations, the GSM refuses using the LDAP server.
The RADIUS authentication is done as follows:
Log in as an administrator.
Select Administration > Radius in the menu bar.
Activate the checkbox Enable.
Enter the host name or IP address of the RADIUS server in the input box RADIUS Host.
Enter the common preshared secret key in the input box Secret Key.
Click OK.
→ When the RADIUS authentication is enabled, the option RADIUS Authentication Only is available when creating or editing a user. By default, this option is disabled.
Create a new user or edit an existing user (see Chapter 9.1).
Activate the checkbox RADIUS Authentication Only when the user should be allowed to authenticate using RADIUS (see Fig. 9.16).