Integrate LDAP and AD

Overview

Lightweight Directory Access Protocol (LDAP) is an open, vendor-neutral, industry standard application protocol for accessing and maintaining distributed directory information services over an IP network. Directory services play an important role in developing intranet and Internet applications by allowing the sharing of information about users, systems, networks, services, and applications throughout the network. As examples, directory services may provide any organized set of records, often with a hierarchical structure, such as a corporate email directory. Similarly, a telephone directory is a list of subscribers with an address and a phone number.

Active Directory (AD) is a directory service that Microsoft developed for Windows domain networks. It is included in most Windows Server operating systems as a set of processes and services. Initially, Active Directory was only in charge of centralized domain management. Starting with Windows Server 2008, however, Active Directory became an umbrella title for a broad range of directory-based identity-related services.

WorkFusion Control Tower and WorkSpace can provide security (authentication and authorization) through LDAP / AD integration. Authentication is based on Spring Security standard provider.

LDAP

important

The domain users must mandatorily have an email to use the LDAP authentication.

Control Tower Configuration

By default, Control Tower provides local user/groups/role management. LDAP / AD integration can be enabled by setting the following parameters in:

INSTALL_DIR/workfusion/conf/workfusion.properties:

# ldap properties
ldap.enabled=true
# to activate LDAP with WF roles switch this property to true. No groups from LDAP will be used.
#Properties ldap.group.base and ldap.group.filter will be ignored
ldap.internal.authorization.enabled=false

# container of corporate user database used for authentication
# support several base directories pipe separated <baseDN1>|<baseDN2>|...
ldap.user.base=ou=People,dc=somecompanydomain,dc=com

# container of corporate user groups used for authorization
# support several base directories pipe separated <baseDN1>|<baseDN2>|...
ldap.group.base=ou=Groups,dc=somecompanydomain,dc=com

# user filter for search, optional, alternative = (uid={0})
ldap.user.filter=(sAMAccountName={0})

# group filter for search, optional, alternative = (memberUid={1})
ldap.group.filter=(member={0})

# page size to load big amount of records to avoid size limit error
ldap.search.page.size=500
# default limit of records for retrieving external group names; use value "0" to disable limitation and AJAX autocomplete on user group page
ldap.external.group.limit=100
# group filter for list of all group names
ldap.search.all.groups.filter=(|(objectClass=group)(objectClass=groupOfNames)(objectClass=groupOfUniqueNames)(objectclass=posixGroup))
# ldap object attribute name that contains group name
ldap.search.groups.name.attribute=cn
# additional filter for list of group names matching provided name part (used in limited load)
# IMPORTANT: must be consistent with changes of 'ldap.search.all.groups.filter' (group clause) and 'ldap.search.groups.name.attribute' (name filter clause) properties. When changing one of them, edit the others accordingly.
ldap.search.all.groups.with.name.filter=(&(cn=*%s*)(|(objectClass=group)(objectClass=groupOfNames)(objectClass=groupOfUniqueNames)(objectclass=posixGroup)))

Default configuration:

# ldap properties
ldap.enabled=false
ldap.internal.authorization.enabled=false
ldap.user.filter=(sAMAccountName={0})
ldap.group.filter=(member={0})
ldap.search.page.size=500
ldap.search.all.groups.filter=(|(objectClass=group)(objectClass=groupOfNames)(objectClass=groupOfUniqueNames)(objectclass=posixGroup))
ldap.search.groups.name.attribute=cn

Secure properties:

# ldap server url
ldap.server.url=ldaps://{host}:{port}

# system user cridentials
ldap.bind.dn=<User distinguished name>
ldap.bind.password=<User password>

External authorization

Before enabling LDAP, at least one group must be mapped.

User groups are mapped in Control Tower during create/edit a User Group (default user roles you can find in Role Management):

After successful login, a user will be created/updated with data fetched from LDAP / AD.
The user properties cannot be changed in Control Tower, if LDAP configuration is enabled, only available filters can be added. The direct role selection is unavailable too.

If LDAP is enabled,

A user cannot be created, deleted, or disabled in Control Tower. The Create, Delete, and Disable buttons are unavailable.
Sections System Preferences → User Settings: Account Details, and Change Password are disabled too.

Internal authorization

To enable internal authorization, set property ldap.internal.authorization.enabled to true.

Common assumptions:

If LDAP authentication is passed successfully, a user is checked for existence in Control Tower, and Control Tower Roles are applied to the user, if such user exists. Otherwise, unable to login.
User Properties cannot be changed in Control Tower, if LDAP Internal configuration is enabled. You can only edit roles and enable/disable the user.
User can be created, deleted, and disabled in Control Tower. The Create, Delete, and Disable buttons on the User Management page are available, if LDAP with internal authorization is enabled.
The System Preferences → User Settings: Account Details, and Change Password sections are disabled too.
The following properties are not used, if LDAP with internal authorization is enabled:
- ldap.group.base
- ldap.group.filt

Integrate LDAP / AD

This is an example to give an overview of LDAP / AD integration.

You must have distinqueshedName and password of the "system user" to initialize the connection properties. It can be any user with privileges to read the directory tree and the object attributes.
```
ldap.bind.dn=CN=System User,OU=demo,DC=somecompany,DC=local
ldap.bind.password=********
```
Configure the base directories for users and groups.
```
ldap.group.base=OU=Groups,OU=demo,DC=somecompany,DC=local
ldap.user.base=OU=Minsk,OU=Users,OU=demo,DC=somecompany,DC=local
```
It supports multi values with pipe separator for users and groups.
```
ldap.user.base=OU=Minsk,OU=Users,OU=demo,DC=somecompany,DC=local|OU=New York,OU=Users,OU=demo,DC=somecompany,DC=local
```
When the base directories are configured properly, it can help reducing time for searching users and/or groups. ldap.group.base is a base directory for loading user's groups during login and a list of groups for "External Group Name" mapping on the Edit User Group page.
Configure user filter.

Usually, a username attribute for Microsoft Active Directory is sAMAccountName. In this case ldap.user.filter=(sAMAccountName={0}).

For example, if we are going to use the email for login, so the filter looks as ldap.user.filter=(mail={0}). Keep in mind, that a user filter must return a unique result, otherwise it is configured incorrectly.
Configure a user groups filter.

ldap.group.filter=(member={0}). In this case the {0} parameter is distinqueshedName of the logging in user.

For example, an alternative filter ldap.group.filter=(memberUid={1}), In this case the {1} parameter is username of the logging in user.
Configure the filter to fetch all group names. For that in Control Tower → Create/Edit User Group page, fill External Group Name.

ldap.search.all.groups.filter=(objectClass=groupOfNames) ldap.search.groups.name.attribute=cn

WorkSpace configuration

By default, WorkSpace provides local user/role management. LDAP / AD integration can be enabled by setting the following parameters:

In INSTALL_DIR/workspace/conf/workspace.properties or workspace-sandbox.properties:

# ldap properties
ldap.enabled=true

# activate internal authorization if swithed to true with ldap.enabled
ldap.internal.authorization.enabled=false

# Comma separated group names from LDAP for mapping to worker users
ldap.worker.groups=CC Dev,Galiot,CC Ops

# Comma separated group of roles from LDAP which are mapped to the WorkSpace Requester role
ldap.requester.groups=CC Admin

# Name of license that is set to requester if new requester is created
ldap.requester.license=license_name

# container of corporate user database used for authentication
# support several base directories pipe separated <baseDN1>|<baseDN2>|...
ldap.user.base=ou=People,dc=crowdcomputingsystems,dc=com

# container of corporate user groups used for authorization
# support several base directories pipe separated <baseDN1>|<baseDN2>|...
ldap.group.base=ou=Groups,dc=crowdcomputingsystems,dc=com

# user filter for search, optional, alternative= (uid={0})
ldap.user.filter=(sAMAccountName={0})

# group filter for search, optional, alternative = (memberUid={1})
ldap.group.filter=(member={0})

# optional block
ldap.user.attribute.email=mail
ldap.user.attribute.firstName=givenname
ldap.user.attribute.lastName=sn
ldap.user.attribute.country=country

User group mapping is configured through ldap.worker.groups

Default configuration:

# ldap properties
ldap.enabled=false
ldap.internal.authorization.enabled=false
ldap.user.filter=(sAMAccountName={0})
ldap.group.filter=(member={0})
ldap.user.attribute.email=mail
ldap.user.attribute.firstName=givenname
ldap.user.attribute.lastName=sn
ldap.user.attribute.country=country

Secure properties:

ws.secure.ldap.server.url=ldaps://{host}:{port}
# system user cridentials
ws.secure.ldap.bind.dn=<User distinguished name>
ws.secure.ldap.bind.password=<User password>

External authorization

After successful login, a user will be created/updated with data fetched from LDAP / AD.

Register and Forgot password functionality is unavailable, if LDAP / AD is integrated.

workspace-login

Internal authorization

To enable internal authorization, set property ldap.internal.authorization.enabled to true.

Common assumptions:

If LDAP authentication is passed successfully, a user is checked for existence in WorkSpace, and WorkSpace Roles are applied to the user, if such user exists. Otherwise, unable to login.
User Properties cannot be changed in WorkSpace, if LDAP Internal configuration is enabled. You can only enable and disable the user.
A user can be created, deleted, or disabled in WorkSpace. The Create, Delete, and Disable buttons on the Workers and Requesters pages are available for requesters.
The following properties are not used, if LDAP with internal authorization is enabled:
- ldap.group.base
- ldap.group.filter

Configure Elastic stack

note

To integrate LDAP for the Elastic stack in the HA environment, the changes mentioned below must be applied for all the servers/roles, for example, for two APP and three INT servers.

Active Directory

To configure AD, log in to the INT server via SSH and do the following:

Create the LDAP realm by adding the following lines to the elasticsearch.yml configuration file located in the <elasticsearch_home>/config directory.

xpack.security.authc.realms.active_directory.<name_of_realm>:         # name of AD realm
    order: <order>                                                    # unique order of AD realm             
    domain_name: <ldap_domain_name>                                   # domain name of AD
    url: <ldap_url>                                                   # URL of AD
    bind_dn: <bind_dn>                                                # User by which all requests to AD will be executed
    ssl:
        certificate_authorities: [ "<ca_sert_path>" ]                 # Path to CA certificate (should be PEM encoded)

# Certificate is provided by Active Directory maintainers.

# Example:
xpack.security.authc.realms.active_directory.ad:
    order: 0
    domain_name: example.com
    url: ldaps://ad.example.com:636/
    bind_dn: "cn=Administrator,cn=Users,dc=example,dc=com"
    ssl:
        certificate_authorities: [ "/opt/workfusion/elasticsearch/certs/cacert.pem" ]

Configure password of the bind_dn user by executing the following:

$ cd <elasticsearch_home> # directory where elasticsearch was installed.

$ bin\elasticsearch-keystore add xpack.security.authc.realms.active_directory.<name_of_realm>.secure_bind_password
# name of AD realm configured in elasticsearch.yml file.

# Example for name of realm 'ad':
$ bin\elasticsearch-keystore add xpack.security.authc.realms.active_directory.ad.secure_bind_password

Configure role mappings of external users and / or groups by adding the following lines to role_mapping.yml file located in <elasticsearch_home>/config directory.

<role>:                   # role. Description of built-in roles will be provided below.
    - "<user_dn>"         # The Active Directory distinguished name (DN) of user
    - "<group_dn>"        # The Active Directory distinguished name (DN) of group

# Example:
kibana_user:
    - "cn=Mark,cn=users,dc=example,dc=com"      # The Active Directory distinguished name (DN) of user 'Mark'
    - "cn=admins,dc=example,dc=com"             # The Active Directory distinguished name (DN) of group 'admins'

For the description of a built-in user, see the documentation.

LDAP

To configure LDAP:

Create the LDAP realm by adding the following lines to the elasticsearch.yml configuration file located in the <elasticsearch_home>/config directory.

xpack.security.authc.realms.ldap.<name_of_realm>:         # name of LDAP realm
    order: <order>                                        # unique order of LDAP realm
    url: <ldap_url>                                       # URL of LDAP
    bind_dn: <bind_dn>                                    # User by which all requests to LDAP will be executed
    user_search:
        base_dn: "ou=users,dc=example,dc=com"               # The LDAP distinguished name (DN) in which users will be searched
        filter: "(cn={0})"                                  # The attribute which will be used to search user by provided username
    group_search:
        base_dn: "ou=groups,dc=example,dc=com"              # The LDAP distinguished name (DN) in which groups will be searched
    ssl:
        certificate_authorities: [ "<ca_sert_path> " ]    # Path to CA certificate (should be PEM encoded)

# Certificate is provided by Active Directory maintainers.

# Example:
xpack.security.authc.realms.ldap.openldap:
    order: 0
    url: "ldaps://ldap.example.com:636"
    bind_dn: "cn=admin,dc=example,dc=com"
    user_search:
        base_dn: "ou=users,dc=example,dc=com"
        filter: "(cn={0})"
    group_search:
        base_dn: "ou=groups,dc=example,dc=com"
    ssl:
        certificate_authorities: [ "/opt/workfusion/elasticsearch/certs/cacert.pem" ]

Configure the password for the bind_dn user by executing the following commands:

$ cd <elasticsearch_home> # directory where elasticsearch was installed.

$ bin\elasticsearch-keystore add xpack.security.authc.realms.ldap.<name_of_realm>.secure_bind_password
# name of LDAP realm configured in elasticsearch.yml file.

# Example for name of realm 'openldap':
$ bin\elasticsearch-keystore add xpack.security.authc.realms.ldap.openldap.secure_bind_password

Configure role mappings of external users and / or groups by adding the following lines to role_mapping.yml file located in <elasticsearch_home>/config directory.

<role>:                   # role. Description of built-in roles will be provided below.
    - "<user_dn>"         # The LDAP distinguished name (DN) of user
    - "<group_dn>"        # The LDAP distinguished name (DN) of group

# Example:
kibana_user:
    - "cn=Mark,ou=users,dc=example,dc=com"      # The LDAP distinguished name (DN) of user 'Mark'
    - "ou=admins,dc=example,dc=com"             # The LDAP distinguished name (DN) of group 'admins'

For the description of a built-in user, see the documentation.

WorkFusion Documentation

10.1.2

Prepare for installation

High availability setup

Standard setup

High availability setup

Standard setup

Install OCR Windows server

Logs management

Security settings in Control Tower

Overview

important

Control Tower Configuration

External authorization

Internal authorization

Integrate LDAP / AD

WorkSpace configuration

External authorization

Internal authorization

Configure Elastic stack

note

Active Directory

LDAP