Configuring LDAP Authentication
Last updated
Was this helpful?
Connectware 1.10.2
Last updated
Was this helpful?
Helm version 3 is installed on your system.
The Kubernetes command line tool kubectl is configured and has access to the target installation.
You know the name and namespace of your Connectware installation. See .
The values.yaml file is available.
When configuring LDAP authentication, you need to match Connectware’s setting to the capabilities of your LDAP server. There are two fundamental decisions to make:
Choosing between “group” and “attribute” mode.
Whether to use a bind user.
Connectware offers two modes for LDAP authentication:
Group mode
Attribute mode
For more information, see .
A bind user is common in LDAP setup that use a more complicated directory structure. It is a limited user you create in your LDAP directory, that is usually a read-only user with the permission to search through the LDAP directory tree.
It is used when users don’t share a single LDAP base DN (e.g. are not in the same group). If your users are spread among the directory tree, you will likely want to use a bind user.
To enable the LDAP feature in Connectware, you need to set the Helm value global.authentication.ldap.enabled to true.
Additionally, you always need to provide these Helm values within the global.authentication.ldap context:
bindDn
CN=Users,DC=example,DC=org
bindDN contains either the LDAP base DN of users logging in, or the DN of a dedicated bind user that is able to search for the user trying to log in within the search base.
url
ldap://dc.mycompany.tld:389
URL of the LDAP server in format schema://hostname:port
Example
If you are using a bind user to search through the directory tree, you must specify the full DN of the bind user as bindDn, and also need to provide these values:
bindPassword
ANc97WCO"!xcC=(
bindPassword contains the password for the bind user as defined in your LDAP server.
searchBase
ldap://dc.mycompany.tld:389
URL of the LDAP server in format schema://hostname:port
Example
By providing a bindPassword through one of these mechanisms, the nature of bindDn changes from being a single base DN that contains all users that are allowed to log into Connectware, to containing the DN of a single user – the bind user. In this scenario, searchBase takes the role of containing the base DN which all users share, acting as the root from which a search for valid users will be performed.
To configure Connectware to use LDAP in group mode, you need to specify the LDAP attribute of your user, that specifies what LDAP groups they are part of. This is done through the Helm value memberAttribute within the global.authentication.ldap context. Additionally, mode must be set to group.
The default value of memberOf is often the correct choice, but you may have to adapt this to your LDAP server.
Example
To configure Connectware to use LDAP in attribute mode, you need to specify the LDAP attribute of your user, that specifies the Connectware role that is associated with the user. This is done through the Helm value rolesAttribute within the global.authentication.ldap context. Additionally, mode must be set to attribute.
The default value of employeeType is often the correct choice, but you may have to adapt this to your LDAP server.
Example
Related Links
If you don’t want to provide the bind user and its password through your Helm values, for example because you follow a GitOps approach for your Connectware deployment, you can also provide the bind user through a manually created Kubernetes secret that is specified in existingBindSecret. For more information, see .
These LDAP groups are then mapped to Connectware roles using the Connectware UI. For more information, see .
Connectware supports connecting to LDAP servers that offer Transport Layer Security. You can find out how to configure this .
You can provide the bind user through a manually created Kubernetes secret that is specified in existingBindSecret. You can find detailed instructions .
By default the username trying to log in acts as the search filter, but there may be advanced situations where this is not enough, for example when that matches multiple users. Visit to learn how to customize the search filter.
The user RDN describes what LDAP attribute contains the username. By default this uses cn, but if this is not correct for your LDAP setup, you can customize this using the userRdn Helm value. Find out more .
.