9. Managing the Web Interface Access

9.1. Users

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.

Roles
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 Greenbone Management Protocol (GMP) and so affects all GMP clients. Read and write access can be assigned to roles separately.
Groups
In addition to 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 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.

9.1.1. Creating and Managing Users

9.1.1.1. Creating a User

Users can be created as follows:

Note

Only administrators are allowed to create and manage additional users.

  1. Log in as an administrator.

  2. Select Administration > Users in the menu bar.

  3. Click new.

  4. Define the user (see Fig. 9.1).

    _images/user_new.png

    Fig. 9.1 Creating a new user

  5. Click Create.

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

The following details of the user can be defined:

Login Name
This is the name used for logging in. When an LDAP or a RADIUS server is used for central password management, the user needs to be created with the identical name (rDN) as used by the server (see Chapter 9.5). The name can contain letters and numbers and can be at most 80 characters long.
Authentication

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

Roles
Each user can have multiple roles. The roles define the permissions of a user when using GMP. While it is possible to add and configure additional roles, by default the roles Admin, User, Info, Observer, Guest and Monitor are available. For further details see Chapter 9.2.
Groups
Each user can be a member of multiple groups. Permissions management can be performed using groups as well (see Chapter 9.4).
Host Access

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.

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

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:

  • 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 (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 IP addresses for IPv4 and 116 IP addresses for IPv6. In both cases the result is a maximum of 4096 IP addresses.

Interface Access
This refers to the input box Network Source Interface when creating a new task (see Chapter 10.2.2). If a task is bound to a certain network interface by its configuration and a user has no access to this network interface, the user is restricted from running the task successfully. A comma-separated list of network adapters can be entered. Similar to Host Access a whitelist or a blacklist methodology is possible (see above).

9.1.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 of the user. A global user is marked with view_other
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
Type of authentication: Local if a password is used, RADIUS or LDAP if a central user management is used (see Chapter 9.5).

For all users the following actions are available:

  • delete Delete the user. Only users which are currently not logged in can be deleted.
  • edit Edit the user.
  • clone Clone the user.
  • export Export the user as an XML file.

Note

By clicking delete or export 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 details 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.5).
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:

  • help Open the corresponding chapter of the user manual.
  • list Show the list page of all users.
  • new Create a new user.
  • clone Clone the user.
  • edit Edit the user.
  • delete Delete the user. Only users which are currently not logged in can be deleted.
  • export Export the user as an XML file.
_images/user_details.png

Fig. 9.2 Details of a user

9.1.2. Simultaneous Login

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.

9.1.3. Creating a Guest Login

The guest user is only allowed to access the page SecInfo (see Chapter 13).

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

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

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 NVTs and SCAP information. All other information is not accessible. The role can modify personal setting, e.g. 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 GSM (see Chapter 17.2).
  • 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 SuperUser in the GOS administration menu. This role cannot be configured in the web interface but in the GOS administration menu (see Chapter 9.2.1.5)

9.2.1. Creating and Managing Roles

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.

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

    → The details of the new role are displayed.

  4. In the row of the clone click edit.

  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 trashcan in the list General Command Permissions.

    _images/role_edit.png

    Fig. 9.3 Editing a cloned role

  9. Click Save.

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

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

  5. Click Save.

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

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

  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 trashcan in the list General Command Permissions.

  9. Click Save.

Note

Some permissions are required:

  • authenticate and get_settings
    These permissions are necessary to log in to the web interface.
  • write_settings (optional)
    This allows a user to change its own password, time zone and other personal settings.

9.2.1.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. A global role is marked with view_other.

For all roles the following actions are available:

  • trashcan Delete the role. Only self-created roles can be deleted.
  • edit Edit the role. Only self-created roles can be edited.
  • clone Clone the role.
  • export Export the role as an XML file.

Note

By clicking trashcan or export 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 details 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.5).
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:

  • help Open the corresponding chapter of the user manual.
  • list Show the list page of all roles.
  • new Create a new role.
  • clone Clone the role.
  • edit Edit the role. Only self-created roles can be edited.
  • trashcan Delete the role. Only self-created roles can be deleted.
  • export Export the role as an XML file.

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

9.2.2. Creating a Role for Granting Read Access to Other Users

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:

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

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

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

    _images/role_permissions.png

    Fig. 9.5 Selecting permissions for a new role

  8. Click Create Permission.

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

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

  12. In the input box Roles add the role GrantReadPriv.

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

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

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

    _images/group_new.png

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

  • trashcan Delete the group.
  • edit Edit the group.
  • clone Clone the group.
  • export Export the group as an XML file.

Note

By clicking trashcan or export 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 details 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.5).
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:

  • help Open the corresponding chapter of the user manual.
  • list Show the list page of all groups.
  • new Create a new group.
  • clone Clone the group.
  • edit Edit the group.
  • trashcan Delete the group.
  • export Export the group as an XML file.

9.4. Permissions

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:

  • 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 Configuration > Permissions in the menu bar.

  2. Create a new permission by clicking new.

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

    _images/permission_new.png

    Fig. 9.7 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, e.g. 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 details to open the details page of the task.

  4. Click on the register Permissions.

  5. Click new in the opened section Permissions.

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

    _images/permission_from_detailspage.png

    Fig. 9.8 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.8).

  • 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 Configuration > Permissions in the menu bar.

For all permissions the following information is displayed:

Name
Name of the permission. A global permission is marked with view_other.
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:

  • trashcan Delete the permission. Only self-created permissions can be deleted.
  • edit Edit the permission. Only self-created permissions can be edited.
  • clone Clone the permission. Only self-created permissions can be cloned.
  • export Export the permission as an XML file.

Note

By clicking trashcan or export 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 details 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.5).

The following actions are available in the upper left corner:

  • help Open the corresponding chapter of the user manual.
  • list Show the list page of all permissions.
  • new Create a new permission. Only self-created permissions can be deleted.
  • clone Clone the permission. Only self-created permissions can be cloned.
  • edit Edit the permission. Only self-created permissions can be edited.
  • trashcan Delete the permission.
  • export Export the permission as an XML file.

9.4.2. Granting Super Permissions

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

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:

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

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

  2. Open the details page by clicking details.

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

    _images/id_resource.png

    Fig. 9.9 ID of a resource

  3. Note or copy the ID.

  4. Select Configuration > Permissions in the menu bar.

  5. Create a new permission by clicking new.

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

  7. Select the radiobutton of the subject type that should have super permissions.

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

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

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

    _images/permission_super.png

    Fig. 9.10 Creating a new super permission

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

9.4.3. Granting Read Access to Other Users

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:

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

  2. Open the details page by clicking details.

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

    _images/id_resource.png

    Fig. 9.11 ID of a resource

  3. Note or copy the ID.

  4. Select Configuration > Permissions in the menu bar.

  5. Create a new permission by clicking new.

  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 radiobutton of the subject type the object should be shared with (see Fig. 9.12).

  8. In the according drop-down-list select the user/role/group 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.12 Share objects with other users

  10. Click Save.

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

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

9.5.1. LDAP

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:

  1. Log in as an administrator.

  2. Select Administration > LDAP in the menu bar.

  3. Click edit.

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

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

  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 LDAP server with the correct attributes. The attribute cn (common name) is used. Users in different sub trees or different recursive depths of an LDAP tree are not supported. All users logging into the GSM must be in the same branch and in the same level of the LDAP tree.
    • uid=%s,ou=people,dc=domain,dc=de
      This format works for any LDAP 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.
    _images/ldap_config.png

    Fig. 9.13 Configuring an LDAP authentication

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

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

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

  10. Activate the checkbox LDAP Authentication Only when the user should be allowed to authenticate using LDAP (see Fig. 9.14).

    _images/user_ldap.png

    Fig. 9.14 Enabling authentication using LDAP

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.

9.5.2. LDAP with SSL/TLS

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

9.5.3. RADIUS

The RADIUS authentication is done as follows:

  1. Log in as an administrator.

  2. Select Administration > Radius in the menu bar.

  3. Click edit.

  4. Activate the checkbox Enable.

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

    _images/user_radius.png

    Fig. 9.16 Enabling authentication using RADIUS