9 Managing the Web Interface Access

Note

This chapter documents all possible menu options.

However, not all appliance models support all of these menu options. The model overview provides information about whether a specific feature is available on the used appliance model.

9.1 Users

The Greenbone Enterprise Appliance allows the creation and management of multiple users with different roles and permissions. During the initial setup of the appliance, the first user – the web/scan administrator – will be created in the GOS administration menu. With this user, additional users can be created and managed.

Roles

The appliance’s user management supports a role-based permission concept for accessing the web interface. The role determines which options of the web interface can be seen and used by the user. Read and write access can be assigned to roles separately.

Various roles are already set up by default. Additional roles can be created and used by an administrator.

The role enforcement is not implemented in the web interface, but in the underlying Greenbone Management Protocol (GMP) and thus affects all GMP clients.

Groups

Users can be organized into groups. This serves mainly for logical grouping.

  • Groups and roles can be used to assign permissions to several users at once.

  • Each user is assigned an IP address range that contains the allowed or denied targets. The appliance denies scanning any other IP addresses than the ones specified. Similarly, the access to certain interfaces of the appliance can be allowed or denied.

  • The user management is completely done with the appliance. External user management sources are not supported. However, to support centralized authentication and enable password synchronization, the appliance can be integrated into a central LDAPS or RADIUS server (see Chapter 9.5). The server is only used to check the password during the login process, all other settings are made in the appliance’s user management.

9.1.1 Creating a User

Note

Only administrators are allowed to create and manage additional users.

A user can be created as follows:

  1. Log in as an administrator.

  2. Select Administration > Users in the menu bar.

  3. Click in the upper left corner.

  4. Fill in the input boxes (see Fig. 9.1):

    _images/user_new.png

    Fig. 9.1 Creating a new user

    Login Name

    Name used for logging in. Only the following characters are allowed for the login name:

    • All alphanumeric characters

    • - (dash)

    • _ (underscore)

    • . (full stop)

    This input box is mandatory.

    Note

    When using a central user management (see Chapter 9.5), limitations to the length and character types may apply, based on the LDAP or RADIUS server. Additionally, the user must be created with the exact same name (rDN) as used by the server.

    Authentication

    Method used for logging in.

    • Password

      If this option is selected, authentication is done locally using the login name and the password.

      • The password can contain any type of character and has practically no length limit.

      • When using special characters, note that they must be available on all used keyboards and correctly supported by all client software and operating systems. Copying and pasting special characters for passwords can result in invalid passwords depending on these external factors.

      If the Password radio button is selected, the input box is mandatory.

    • LDAP Authentication Only

      If this option is selected, authentication is done using a central user management (see Chapter 9.5).

    • RADIUS Authentication Only

      If this option is selected, authentication is done using a central user management (see Chapter 9.5).

    Roles

    The role defines the permissions of a user. Each user can have multiple roles.

    Note

    If no role is selected, the user will not have any permissions and therefore cannot log in to the web interface.

    The roles Admin, User, Info, Observer, Guest and Monitor are available. Additionally, it is possible to add and configure custom roles (see Chapter 9.2.2).

    If a user with a custom role should be able to use the web interface, at least the following permissions are required for that role:

    • authenticate

    • get_settings

    • help

    For further details, see Chapter 9.2.

    Groups

    Each user can be a member of multiple groups. Permission can be managed using groups (see Chapter 9.4).

    Host Access

    Hosts on which the user is allowed to run scans. The restrictions also apply to administrators, but they can remove them themselves. Users with the User role or a role without access to the user management cannot bypass the restrictions. Basically either a denylist (allow all and deny some) or a allowlist (deny all and allow some) is possible.

    • Allow all and deny

      The scanning of all systems is allowed in general. Only explicitly listed systems are not allowed to be scanned.

    • Deny all and allow

      The scanning of all systems is denied in general. Only explicitly listed systems are allowed to be scanned.

    Tip

    In general, the allowlist methodology should be used. This ensures that users do not scan systems lying beyond their area of responsibility, located somewhere on the Internet, or reacting to malfunctioning scans by accident.

    System names or IPv4/IPv6 addresses (individual IP addresses, IP address ranges or network segments) can be entered. The following list shows some examples:

    • 192.168.15.5 (IPv4 address)

    • 192.168.15.5-192.168.15.27 (IPv4 address range long form)

    • 192.168.15.5-27 (IPv4 address range short form)

    • 192.168.15.128/25 (IPv4 address range, CIDR notation)

    • 2001:db8::1 (IPv6 address)

    • 2001:db8::1-2001:db8::15 (IPv6 address range long form)

    • 2001:db8::1-15 (IPv6 address range short form)

    • 2001:db8::/120 (IPv6 address range, CIDR notation)

    All options can be mixed and matched, and entered as a comma-separated list. By default, the subnet mask in the CIDR notation is restricted to a maximum of 20 for IPv4 and 116 for IPv6. The reason for this is that the maximum number of IP addresses per target is 4096 for most appliances. If the maximum number of IP addresses is higher, for example for the Greenbone Enterprise 6500, correspondingly larger subnet masks can be configured.

  5. Click Save.

    → The user is created and displayed on the Users page.

9.1.2 Managing Users

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:

Name

Name that was assigned to the user when the account was created.

Global users are users that are created in the GOS administration menu (see Chapter 7.2.1). They are marked with .

Roles

Role of the user (see Chapter 9.2).

Groups

Groups to which the user belongs (see Chapter 9.3).

Host Access

Hosts on which the user is allowed to run scans.

Authentication Type

Method used for logging in.

  • Local: authentication is done locally using the login name and the password.

  • RADIUS authentication is done using a central user management (see Chapter 9.5).

  • LDAP: authentication is done using a central user management (see Chapter 9.5).

For all users the following actions are available:

  • Delete the user. Only users which are currently not logged in and which are not super administrator can be deleted.

  • Edit the user.

  • Clone the user.

  • Export the user as an XML file.

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:

Information

General information about the user.

User Tags

Assigned tags (see Chapter 8.4).

Permissions

Permissions of the user or of other users/roles/groups to the resources of the user (see Chapter 9.4).

The following actions are available in the upper left corner:

  • Open the corresponding chapter of the user manual.

  • Show the list page of all users.

  • Create a new user (see Chapter 9.1.1).

  • Clone the user.

  • Edit the user.

  • Delete the user. Only users which are currently not logged in and which are not super administrator can be deleted.

  • Export the user as an XML file.

_images/user_details.png

Fig. 9.2 Details of a user

9.1.3 Simultaneous Login

It is possible for two users to be 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. Logging in again in the same browser invalidates the first login.

9.1.4 Creating a Guest Login

The guest user has only limited access to the web interface.

To allow a 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 will see the page Dashboards.

To enable a guest to log in without needing a password, this function must be activated in the GOS administration menu (see Chapter 7.2.1.4).

9.2 Roles

The web interface supports the creation and configuration of own user roles.

The following roles are available by default:

  • Admin

    This role has all permissions by default. It is especially allowed to create and manage other users, roles and groups.

  • User

    This role has all permissions by default except for user, role and group management. This role is not allowed to synchronize and manage the feeds. In the web interface there is no access to the page Administration.

  • Info

    This role (Information Browser) has only read access to the VTs and SCAP information. All other information is not accessible. The role can modify personal setting, for example change the password.

  • Guest

    This role corresponds with the role Info but is not allowed to change the user settings.

  • Monitor

    This role has access to system reports of the appliance (see Chapter 17.1).

  • Observer

    This role has read access to the system but is not allowed to start or create new scans. It has only read access to the scans for which it has been set as an observer.

  • Super Admin

    This role has access to all objects of all users. It has no relation to the super user (su/root) in the GOS administration menu. This role cannot be configured in the web interface and users with this role cannot be deleted using the web interface. Users with this role should be managed using the GOS administration menu (see Chapter 9.2.5).

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 behavior when updating the software.

9.2.1 Cloning an Existing Role

When an existing role closely reflects the demands, a new role can be created by cloning the existing role:

  1. Log in as an administrator.

  2. Select Administration > Roles in the menu bar.

  3. In the row of an existing role, click .

  4. In the row of the clone, click .

  5. Enter the name of the role in the input box Name (see Fig. 9.3).

  6. Select the users that should have the role in the drop-down list Users.

  7. Add a permission by selecting it in the drop-down list Name and clicking Create Permission.

  8. 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.

    _images/role_edit.png

    Fig. 9.3 Editing a cloned role

  9. Click Save.

9.2.2 Creating a Role

When a role with only limited functionality should be created, it can be started with a new, empty role:

  1. Log in as an administrator.

  2. Select Administration > Roles in the menu bar.

  3. Create a new role by clicking .

  1. Define the role.

    The following details of the role can be defined:

    Name

    The name of the role can contain letters and numbers and can be at most 80 characters long.

    Comment (optional)

    A comment describes the role in more detail.

    Users

    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).

  2. Click Save.

    → The role is created and displayed on the page Roles.

  3. In the row of the newly created role, click .

  4. Add a permission by selecting it in the drop-down list Name and clicking Create Permission.

    Note

    If users with the role should be able to use the web interface, at least the following permissions are necessary:

    • authenticate

    • get_settings

    • help

    The permission write_settings allows users to change their own password, time zone and other personal settings.

  5. 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.

  6. Click Save.

9.2.3 Managing Roles

List Page

All existing roles can be displayed by selecting Administration > Roles in the menu bar.

For all roles the following information is displayed:

Name

Name of the role. All default roles are global roles and are marked with .

For all roles the following actions are available:

  • Move the role to the trashcan. Only self-created roles can be moved to the trashcan.

  • Edit the role. Only self-created roles can be edited.

  • Clone the role.

  • Export the role as an XML file.

Note

By clicking or below the list of roles more than one role can be moved to the trashcan or exported at a time. The drop-down list is used to select which roles are moved to the trashcan 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:

Information

General information about the role.

General Command Permissions

GMP commands that can be executed by this role.

User Tags

Assigned tags (see Chapter 8.4).

Permissions

Permissions of the role or of other users/roles/groups to the role’s resources (see Chapter 9.4).

The following actions are available in the upper left corner:

  • Open the corresponding chapter of the user manual.

  • Show the list page of all roles.

  • Create a new role (see Chapter 9.2.2).

  • Clone the role.

  • Edit the role. Only self-created roles can be edited.

  • Move the role to the trashcan. Only self-created roles can be moved to the trashcan.

  • Export the role as an XML file.

9.2.4 Assigning Roles to a User

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.

_images/user_multiple_roles.png

Fig. 9.4 Creating a new user with multiple roles

9.2.5 Creating a Super Administrator

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 must 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.

9.3 Groups

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.

9.3.1 Creating a Group

A group can be created as follows:

Note

Only administrators are allowed to create and manage groups.

  1. Log in as an administrator.

  2. Select Administration > Groups in the menu bar.

  3. Create a new group by clicking .

  4. Define the group (see Fig. 9.5).

    _images/group_new.png

    Fig. 9.5 Creating a new group

  5. Click Save.

    → The group is created and displayed on the page Groups.

The following details of the group can be defined:

Name

The name of the group can contain letters and numbers and can be at most 80 characters long.

Comment (optional)

A comment describes the group in more detail.

Users

The members of the group can be selected in the drop-down list Users. Alternatively, group memberships can be managed in the user profile (see Chapter 9.1.1).

Special Groups

Activate the checkbox if all group members should have read and write access to all resources of the group.

9.3.2 Managing Groups

List Page

All existing groups can be displayed by selecting Administration > Groups in the menu bar.

For all groups the following information is displayed:

Name

Name of the group.

For all groups the following actions are available:

  • Move the group to the trashcan.

  • Edit the group.

  • Clone the group.

  • Export the group as an XML file.

Note

By clicking or below the list of groups more than one group can be moved to the trashcan or exported at a time. The drop-down list is used to select which groups are moved to the trashcan 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:

Information

General information about the group.

User Tags

Assigned tags (see Chapter 8.4).

Permissions

Permissions of the group or of other users/roles/groups to the resources of the group (see Chapter 9.4).

The following actions are available in the upper left corner:

  • Open the corresponding chapter of the user manual.

  • Show the list page of all groups.

  • Create a new group (see Chapter 9.3.1).

  • Clone the group.

  • Edit the group.

  • Move the group to the trashcan.

  • Export the group as an XML file.

9.4 Permissions

Select Administration > 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:

  • Users

  • Roles

  • Groups

There are two types of permissions:

  • Command permissions

    Command permissions are linked to the Greenbone Management Protocol (GMP). Each command permission applies to a specific GMP command. The name of the permission is the relevant command.

    A command permission is either a command level permission or a resource level permission.

    • Command level

      When no resource is specified, a command level permission is created. A command level permission allows the subject to run the given GMP command.

    • Resource level

      When a resource is specified, a resource level permission is created. A resource level permission allows the subject to run the given GMP command on a specific resource.

  • Super permissions

    (see Chapter 9.4.2)

9.4.1 Creating and Managing 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.

9.4.1.1 Creating a Permission

A new permission can be created as follows:

  1. Select Administration > Permissions in the menu bar.

  2. Create a new permission by clicking .

  3. Define the permission (see Fig. 9.6).

    _images/permission_new.png

    Fig. 9.6 Creating a new permission

  4. Click Save.

    → The permission is created and displayed on the page Permissions.

The following details of the permission can be defined:

Name

Permission that should be granted.

Comment (optional)

A comment describes the permission in more detail.

Subject

Subject (user, role or group) that should be granted with the permission.

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.

Resource Type (only for the permission Super (Has super access))

Resource type (user, role or group) to which the user/role/group has super access.

User/role/group ID (only for the permission Super (Has super access))

ID of the user/role/group to which the user/role/group has super access.

Description

Textual description of the permission.

9.4.1.2 Creating Permissions from the Resource Details Page

When accessing a resource details page, for example the detail page of a task, permissions for the resource can be granted directly on the details page as follows:

  1. Open the details page of a resource.

    Example: Select Scans > Tasks in the menu bar.

  2. Click on the name of a task.

  3. Click to open the details page of the task.

  4. Click on the register Permissions.

  5. Click in the opened section Permissions.

  6. Define the permission (see Fig. 9.7).

    _images/permission_from_detailspage.png

    Fig. 9.7 Creating a permission from the resource details page

  7. 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:

  • read

    Granting the permission read means allowing to view the resource on list pages and on its details page.

  • write

    Granting the permission write means allowing to view and modify (but not delete) the resource.

Some resource types include additional permissions:

  • Tasks

    When granting the permission write for a task, the permissions to start (start_task), stop (stop_task) and resume (resume_task) the task are added automatically.

  • Alerts

    When granting the permission write for an alert, the permission to test the alert (test_alert) is added automatically.

  • Report formats and scanners

    When granting the permission write for a report format or a scanner, the permissions to verify the report format (verify_report_format) or the scanner (verify_scanner) is added automatically.

For some resource types it can be selected whether the permissions should also be granted for related resources (see Fig. 9.7).

  • Tasks

    For tasks this includes alerts and their filters, the target as well as its related credentials and port list, the schedule, the scanner and the scan configuration.

  • Targets

    For targets this includes credentials and the port list.

  • Alerts

    For alerts this includes the filter that is used on the report.

Note

Permissions can also be created only for the related resources.

The details of the related resources are displayed below the drop-down list.

9.4.1.3 Managing Permissions

List Page

All existing permissions can be displayed by selecting Administration > Permissions in the menu bar.

For all permissions the following information is displayed:

Name

Name of the permission. A global permission is marked with .

Description

Textual description of the permission.

Resource Type

Resource type to which the user/role/group has access.

Resource

Name of the resource to which the user/role/group has access.

Subject Type

Subject type (user/role/group) that is granted with the permission.

Subject

Subject that is granted with the permission.

For all permissions the following actions are available:

  • Move the permission to the trashcan. Only self-created permissions can be moved to the trashcan.

  • Edit the permission. Only self-created permissions can be edited.

  • Clone the permission. Only self-created permissions can be cloned.

  • Export the permission as an XML file.

Note

By clicking or below the list of permissions more than one permission can be moved to the trashcan or exported at a time. The drop-down list is used to select which permissions are moved to the trashcan 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:

Information

General information about the permission.

User Tags

Assigned tags (see Chapter 8.4).

The following actions are available in the upper left corner:

  • Open the corresponding chapter of the user manual.

  • Show the list page of all permissions.

  • Create a new permission (see Chapter 9.4.1.1).

  • Clone the permission. Only self-created permissions can be cloned.

  • Edit the permission. Only self-created permissions can be edited.

  • Move the permission to the trashcan. Only self-created permissions can be moved to the trashcan.

  • Export the permission as an XML file.

9.4.2 Granting Super Permissions

Any resource on the appliance (for example, a user, a task, a target) is either global or owned by a specific user. Global resources are identified by .

Non-global resources can only be viewed and used 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:

  • User

  • Role

  • Group

  • Any

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.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.

  1. Click on the name of the user/role/group on the page Users/Roles/Groups for which super permissions should be assigned.

  1. Open the details page by clicking .

    → The resource ID can be found in the upper right corner (see Fig. 9.8).

    _images/id_resource.png

    Fig. 9.8 ID of a resource

  2. Note or copy the ID.

  3. Select Administration > Permissions in the menu bar.

  4. Create a new permission by clicking .

  5. In the drop-down list Name select Super (Has super access) (see Fig. 9.9).

  6. Select the radio button of the subject type that should have super permissions.

  7. In the according drop-down list select the user/role/group that should have super permissions.

  8. Select the resource type for which super permissions should be assigned in the drop-down list Resource Type.

  9. Enter or paste the previously determined resource ID into the input box ID.

    _images/permission_super.png

    Fig. 9.9 Creating a new super permission

  10. Click Save.

    → The super permission is created and displayed on the page Permissions.

Tip

Super permissions simplify the permission management on the appliance. 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.

9.4.3 Granting Read Access to Other Users

9.4.3.1 Requirements for Granting Read Access

Every user can share indefinite self-created resources. To do so, the user requires the global get_users permission as well as the specific get_users permission for the respective user who should obtain read access.

Note

The easiest and recommended way to share self-created resources is to use an administrator account and to create the user accounts that should receive read access with this administrator account.

All other ways described here are cumbersome and time-consuming.

Requirements for Administrators

By default, administrators already have the global get_users permission.

The administrator can get the specific get_users permission for the account that should obtain read access in two ways:

  • Create the account oneself because administrators automatically have the specific get_users permission for accounts they created.

  • With the help of a super administrator.

A super administrator can grant specific get_users permissions to an administrator as follows:

  1. Log in to the web interface as a super administrator (see Chapters 7.2.1.5 and 9.2.5).

  2. Select Administration > Users in the menu bar.

  3. Click on the name of the account who should obtain read access from the administrator.

  4. Click .

  5. Click on the register Permissions.

  6. Create a new permission by clicking in the section Permissions.

  7. Select read in the drop-down list Grant (see Fig. 9.10).

    _images/admin_specific_get_users.png

    Fig. 9.10 Granting an administrator a specific get_users permission

  8. Select the radio button User.

  9. Select the administrator that should be able to grant read access in the drop-down list User.

  10. Click Save.

    → The specific get_users permission is created and displayed in the list (see Fig. 9.11).

    The administrator is now able to grant read access to the respective user as described in Chapter 9.4.3.2.

    _images/admin_specific_get_users_2.png

    Fig. 9.11 Specific get_users permission for an administrator

Requirements for Regular Users

Regular users do not have the global get_users permission by default. It can be added as follows:

  1. Log in to the web interface as an administrator.

  2. Select Administration > Roles in the menu bar.

  3. Create a new role by clicking .

  4. Enter GrantReadPriv in the input box Name.

  5. Click Save.

    → The role is created and displayed on the page Roles.

  6. In the row of the newly created role, click .

  7. In the drop-down list Name in the section New Permission select get_users (see Fig. 9.12).

    _images/role_permissions.png

    Fig. 9.12 Selecting permissions for a new role

  8. Click Create Permission.

    → The permission is displayed in the section General Command Permissions (see Fig. 9.12).

  9. Click Save.

  10. Select Administration > Users in the menu bar.

  11. In the row of the user which should be assigned the newly created role, click .

  12. In the drop-down list Roles add the role GrantReadPriv.

  13. Click Save.

A super administrator can grant specific get_users permissions to a user as follows:

  1. Log in to the web interface as a super administrator (see Chapters 7.2.1.5 and 9.2.5).

  2. Select Administration > Users in the menu bar.

  3. Click on the name of the account who should obtain read access from the user.

  4. Click .

  5. Click on the register Permissions.

  6. In the section Permissions click .

  7. Select read in the drop-down list Grant (see Fig. 9.13).

    _images/user_specific_get_users.png

    Fig. 9.13 Granting a user a specific get_users permission

  8. Select the radio button User.

  9. Select the user that should be able to grant read access in the drop-down list User.

  10. Click Save.

    → The specific get_users permission is created and displayed in the list (see Fig. 9.14).

    The user is now able to grant read access to the respective user as described in Chapter 9.4.3.2.

    _images/user_specific_get_users_2.png

    Fig. 9.14 Specific get_users permission for a user

9.4.3.2 Granting Read Access

When a user has the global and the specific get_users permission (see Chapter 9.4.3.1), the user can share resources as follows:

  1. On the respective page click on the name of the resource which should be shared.

  2. Open the details page by clicking .

    → The object ID can be found in the upper right corner (see Fig. 9.15).

    _images/id_resource.png

    Fig. 9.15 ID of a resource

  3. Note or copy the ID.

  4. Select Administration > Permissions in the menu bar.

  5. Create a new permission by clicking .

  6. In the drop-down list Name select the permission for the object to be shared.

    • 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

  7. Select the radio button User (see Fig. 9.16).

  8. In the according drop-down list select the user the object should be shared with.

  9. Enter or paste the previously determined resource ID in the input box ID.

    _images/permission_share_objects.png

    Fig. 9.16 Share objects with other users

  1. Click Save.

    → The permission is created and displayed on the page Permissions.

Note

Additionally, resources can be shared with roles or groups.

For this, the global and specific permissions get_groups – granting read access to a group – or get_roles – granting read access to a role – are required and follow the same principle as described in Chapter 9.4.3.1.

Exception: users with a default role already have the specific get_roles permissions for all default roles.

9.5 Using a 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 appliance supports the usage of a central password store using LDAPS or RADIUS.

The appliance will use the service only for authentication on a per-user basis, which means that users who should be able to authenticate by the service must be configured for authentication and to exist on the appliance as well.

Note

Prerequisite for using central authentication is the naming of the users with the same names as the objects in the LDAPS tree or the RADIUS server.

9.5.1 LDAPS

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

The following references are helpful for the exact configuration of all available LDAPS servers:

9.5.1.1 Storing the Server’s Certificate on the Appliance

To verify the identity of the LDAPS server, the appliance must trust the server’s certificate. For this, the certificate of the issuing certificate authority (CA) must be stored on the appliance.

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 content of the file looks 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 LDAPS.

  • Active Directory LDAPS

    If the Active Directory LDAP service does not yet use LDAPS, the following article may be helpful: https://learn.microsoft.com/en-us/archive/technet-wiki/2980.ldap-over-ssl-ldaps-certificate.

    The Active Directory LDAPS 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.

    1. Open the CA console from any domain-joined computer or server.

    2. Right click the name of the CA and select Properties.

    3. In the CA certificates dialog box, select the tab General.

    4. Select the certificate for the CA that should be accessed.

    5. Click View Certificate.

    6. In the dialog box Certificate, select the tab Certification Authority.

    7. Select the name of the root CA and click View Certificate.

    8. In the dialog box Certificate, select the tab Details.

    9. Click Copy to File.

      → The certificate export wizard is opened.

    10. Click Next.

    11. Select Base-64 encoded X.509 (.CER) on the page Export File Format.

    12. Click Next.

    13. Enter the path and the name for the certificate in the input box File to Export.

    14. Click Next.

    15. Click Finish.

      → The CER file is created in the specified location. A dialog box informs that the export was successful.

    16. Click OK.

    The content of the file must be uploaded when enabling LDAPS.

9.5.1.2 Connecting to the LDAPS Tree

For the connection to an LDAPS tree, the appliance uses a very simple interface and a simple bind operation with a hard-coded object path. The LDAPS authentication is done as follows:

  1. Log in as an administrator.

  2. Select Administration > LDAP in the menu bar.

  3. Click .

  4. Activate the checkbox Enable (see Fig. 9.17).

    _images/ldap_config.png

    Fig. 9.17 Configuring an LDAPS authentication

  5. Enter the LDAPS host in the input box LDAP Host.

    Note

    Only one system can be entered by IP address or by name.

    The appliance accesses the LDAPS host using SSL/TLS. For verifying the host, the certificate of the host has to be uploaded to the appliance (see Chapter 9.5.1.1). Without SSL/TLS, the LDAPS authentication will not be accepted.

  6. 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

      This format works for any LDAPS server with the correct attributes. The attribute cn (common name) is used. Users in different sub trees or different recursive depths of an LDAPS tree are not supported. All users logging into the appliance must be in the same branch and in the same level of the LDAPS tree.

    • uid=%s,ou=people,dc=domain,dc=de

      This format works for any LDAPS server with the correct attributes. The attribute uid (user ID) is used as a filter. It should be in the first place. The attributes ou=people,dc=domain,dc=de are used as base objects to perform a search and to retrieve the corresponding DN.

    • %s@domain.de

      This format is typically used by Active Directory. The exact location of the user object is irrelevant.

    • domain.de\%s

      This format is typically used by Active Directory. The exact location of the user object is irrelevant.

  7. To verify the host, upload the certificate of the host by clicking Browse….

  1. Activate the checkbox Use LDAPS only if only connections via LDAPS should be allowed.

    Note

    This option disables StartTLS and plain text connections to the LDAP server, allowing only connections via LDAPS. This is useful in cases where the LDAP port is blocked by a firewall.

  2. Click OK.

    → When the LDAPS authentication is enabled (see Fig. 9.18), the option LDAP Authentication Only is available when creating or editing a user. By default, this option is disabled.

    _images/ldap_config_2.png

    Fig. 9.18 Enabled LDAPS authentication

  3. Create a new user or edit an existing user (see Chapter 9.1).

  4. Activate the checkbox LDAP Authentication Only when the user should be allowed to authenticate using LDAPS (see Fig. 9.19).

    _images/user_ldap.png

    Fig. 9.19 Enabling authentication using LDAPS

Note

The user has to exist with the same name in LDAPS before the authentication with LDAPS can be used. The appliance does not add, modify or remove users in LDAPS and it does not automatically grant any user from LDAPS access to the appliance.

If the LDAPS authentication does not work, verify that the entry in LDAP Host matches the commonName of the certificate of the LDAPS server. If there are deviations, the appliance refuses using the LDAPS server.

9.5.2 RADIUS

The RADIUS authentication is done as follows:

  1. Log in as an administrator.

  2. Select Administration > Radius in the menu bar.

  3. Click .

  4. Activate the checkbox Enable (see Fig. 9.20).

  5. Enter the host name or IP address of the RADIUS server in the input box RADIUS Host.

  6. Enter the common preshared secret key in the input box Secret Key.

    _images/radius_config.png

    Fig. 9.20 Configuring a RADIUS authentication

  7. 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.

  8. Create a new user or edit an existing user (see Chapter 9.1).

  9. Activate the checkbox RADIUS Authentication Only when the user should be allowed to authenticate using RADIUS (see Fig. 9.21).

    _images/user_radius.png

    Fig. 9.21 Enabling authentication using RADIUS