Directory Service Integration

Purpose

Authenticate and authorize users against a remote directory service.

Details

When this feature is activated and configured correctly, TeamBeam will use the customer-provided directory service for authentication and authorization of users on this storagehost.

The external directory service is integrated via LDAPv3, using an SSL-encrypted transport channel.

For every user in the directory, an entry is always kept in the local database. The entries are updated with master-data from the directory service after successful authentication. The following fields are imported:

• full name
• dn (distinquished name)
• expiration timestamp
• info-field (configurable source)

Users are either managed by the directory service or by the local database. Mixing both kinds on the same storagehost is supported.

Directory-service-users' credentials are managed by the remote directory service. The local database does not hold password hashes. The users are prohibited from changing their password and cannot a request a password reset. A configurable text-message will inform the users of this; typically providing contact details for the help desk or administrator managing the remote directory service. If a user is marked as directory-service-managed and the matching entry in the directory service can no longer be found, the entry in the local user database is disabled (see Offboarding for more details).

Database managed users authenticate against stored password hashes.

Group membership authorization

It is possible to limit the right to use TeamBeam to users who are members of a directory-managed group. If this restriction is enabled, users are blocked from using TeamBeam, if they are not members of the group.

Similarly it is possible to configure the name of a directory group for administrators. If a user is found to be member of the named group, an administrator-role will be assigned to the user. If the user is not part of group, the administrator-role is deassigned.

Autoprovisioning

When a user is authenticated for the first time, the entry in the local database is created according to a configured preset. This preset assigns rights and roles to the newly created user.

The contract must allow for the additional user license, or the autoprovisioning fails. In that case, the authentication fails as well.

Rights and Roles

The concept of rights and roles applies unchanged. A user's set of privileges is calculated based on

• system default values,
• assigned roles, and
• assigned individual rights.

This includes the administrator right.

Storagehost association

A user is always bound to a single storagehost. Users can only authenticate on the storagehost they are associated with.

Onboarding and offboarding

Onboarding and offboarding describes the process of changing the entity that manages a user's credentials.

If users existed on a storagehost before the directory service integration was enabled, they are being migrated to directory-service-authentication when attempting to login. During this process, the user's password-hash is cleared and the dn field is populated. Note: contrary to auto-provisioning, the user's rights and roles are not modified.

The mass-user-import functionality can be used to onboard a set of users.

When administrators remove a user's entry in the directory service, the local entry in the database is converted to an unprivileged user automatically. This happens either automatically through background processes or when attempting to login. It is possible to create the user again on the same storagehost as database-managed as a manual task afterwards.

Disabling the directory service integration of a storagehost leads to complete offboarding of all users. This process is best done in cooperation with TeamBeam support staff, to avoid the need to manually recreate a large number of user accounts.

Offboarded users cannot be reused, until they are deleted in the TeamBeam database by an administrator. They can however be onboarded again.

Authentication with Email & Password

When a user authenticates himself with email & password, the following process is followed:

Authentication with Email & Onetimekey

Once a user has been authenticated, he can request one or several onetimekeys to use as authentication tokens. The onetimekey is stored in and validated against the local database; consequently the user must have existed beforehand. Onboarding of existing users is possible, but not autoprovisioning.

If onetimekey authentication was successful, the user is synced against the directory service, which may invalidate him (through missing group membership, or account-expires timestamp) afterwards.

Authentication with Reset-Password-ID

Users who are managed by an external directory service cannot use the reset-password-feature, and authentication requests with a reset-password-ID are rejected.

Authentication with Register-ID

Authentication with a register-ID is not supported for users who are managed by a directory service. However, such users can simply onboard themselves by authenticating with email & password.

SSL Transport

When communication between TeamBeam and the directory servers is over an insecure network, SSL must be used for authentication and encryption. The directory servers must be configured with valid SSL server certificates.

The TeamBeam server must be configured to trust the server certificates (by way of trusting the certificate chain). This can either mean that a public, "well known" certification authority is used to sign the server certificates, or an internal CA is used. In the case of the latter, the CA's root- or intermediate certificate must be configured in the TeamBeam servers' truststores. Do not use a self-signed server certificate, as this will impact certificate rotation.

The server certificates must be valid and match the directory servers' hostnames. Do not configure them with IP addresses.

TeamBeam may change its public IP addresses without prior warning. Do not use apparent public IP addresses of TeamBeam to establish client authentication. Instead a SSL client certificate can be used for this purpose. It must be configured in the TeamBeam server keystore, including the private key and the certificate of the signing CA.

Additional information for ActiveDirectory administrators:

• LDAP over SSL (LDAPS) Certificate
• How to enable LDAP over SSL with a third-party certification authority

Configuration

The following configuration is required for the integration of an external directory service:

• One or more addresses (IP or hostname and port) of LDAP directory servers. If multiple addresses are configured (separated by semicolon), TeamBeam will establish connections to all of them and use them for failover.
• An optional SSL client certificate to be used when connecting to the directory servers.
• The base DN for searches.
• The DN and password of an unprivileged user. Searches for entries and group memberships are performed with this user.
• The (unique) name of a group for optional user authorization.
• The (unique) name of a group for optional administrator role assignment.
• Information if groups are nested. If enabled, this can slow down the authentication process, since group membership is determined recursively.
• A preset, for autoprovisioning of new users.
• Information if password recovery is completely blocked.

• The optional custom password recovery instructions to be shown on the password recovery page.

• Scope: adminunit

• Privileges: cluster-administrator / server-administrator
• Default: no directory service integration

Currently no end-user frontend is available to manage the configuration.

Dependencies

none

Conflicts

none

Changes

none