Configuring LDAP
This topic includes descriptions of the LDAP configuration options available for configuring group-based authorization.
Configuring LDAP Context
All standard Java LDAP configurations are supported. Broker configurations starting with
ldap.java.naming and ldap.com.sun.jndi are stripped of their ldap. prefix
and these standard Java LDAP configurations are used to make connections to the LDAP server.
You must configure ldap.java.naming.provider.url with the URL of your LDAP server. For example:
ldap.java.naming.provider.url=ldap://somehost:389
For a complete list of standard Java configurations for the LDAP naming service provider and Java Naming and Directory Interface (JNDI), see LDAP Naming Service Provider for the Java Naming and Directory Interface (JNDI).
Note
Be aware that nested LDAP groups are not supported.
Configuring SSL for LDAP
Enable SSL for the connections from the Confluent Server Authorizer to your LDAP server
by setting ldap.java.naming.security.protocol=SSL. LDAP provider
URL must use the protocol ldaps if SSL is enabled. All the SSL configuration
options of Kafka clients are supported and must be prefixed with ldap..
For example:
# Configure provider URL with `ldaps` as protocol
ldap.java.naming.provider.url=ldaps://somehost:389
# Enable SSL for connections to LDAP server
ldap.java.naming.security.protocol=SSL
# Path of truststore for connections to LDAP
ldap.ssl.truststore.location=/path/to/truststore.jks
# Password of LDAP truststore
ldap.ssl.truststore.password=truststore-secret
For a list of supported SSL configurations, see Encryption and Authentication with SSL.
Note
In Java 8 update 181 and later, host name verification is enabled by default
on LDAPS connections. You can disable this verification by setting
KAFKA_OPTS=-Dcom.sun.jndi.ldap.object.disableEndpointIdentification=true,
but you should avoid using this option in production systems. Prior to Java 8
update 181, host name verification was disabled by default for LDAPS
connections. For improved security, consider upgrading to Java 8 181 or later.
Configuring GSSAPI for LDAP
You can use GSSAPI to authenticate the Confluent Server Authorizer with your LDAP server if Kerberos
is enabled on your LDAP server. You can configure the JAAS configuration for GSSAPI
using the ldap.sasl.jaas.config configuration option. You must also configure
the authentication protocol and security principal using standard Java LDAP
configurations prefixed with ldap.. For example:
# Configure SASL/GSSAPI as the authentication protocol for LDAP context.
ldap.java.naming.security.authentication=GSSAPI
# Security principal for LDAP context
ldap.java.naming.security.principal=ldap@EXAMPLE.COM
# JAAS configuration for Kerberos authentication with LDAP server
ldap.sasl.jaas.config=com.sun.security.auth.module.Krb5LoginModule required \
keyTab="/tmp/keytabs/ldap.keytab" \
principal="ldap@EXAMPLE.COM" \
storeKey="true" \
useKeyTab="true";
Note
The keytab
is a local file that stores the principal for LDAP, as well as a
timestamp, a key version number, and the encrypted keys. In this context,
keyTab is used to authenticate Kerberos with the LDAP server without having
to explicitly enter a password. You can view the principal in the keytab using
the klist command:
klist -kt /tmp/keytabs/ldap.keytab
#keytab content for LDAP principal
KVNO Timestamp Principal
---- ----------------- ------------------------------------
1 12/31/21 17:00:00 host/ldap@EXAMPLE.COM
If ldap.sasl.jaas.config is not configured, then the default JAAS configuration
of the broker will be used. The default JAAS configuration (the value specified in
the system property java.security.auth.login.config) is loaded from the login
context KafkaServer that is used as the broker’s login context using a single
shared login. You should use this configuration option for LDAP only if the
principal in this context can be used to search LDAP.
To test and perform basic troubleshooting on your LDAP client configuration when configuring Kafka to authenticate to LDAP using Kerberos, refer to Testing and Troubleshooting LDAP Client Authentication.
Configuring Password Credentials for LDAP
If password authentication is enabled on your LDAP server, then you can configure
the user principal and password so that brokers can authenticate with the LDAP
server using simple authentication. Use standard Java configurations prefixed
with ldap. to configure LDAP credentials for the
broker. For example:
# Specify the LDAP security authentication protocol
ldap.java.naming.security.authentication=SIMPLE
# Identify the principal for the LDAP context
ldap.java.naming.security.principal=CN=Kafka Broker,OU=Users,DC=EXAMPLE,DC=COM
# Security credential is the password of the user that performs LDAP search
ldap.java.naming.security.credentials=broker-secret
Configuring LDAP Search
To perform group-based authorization, brokers require a mapping of the user principal. This mapping is determined during authentication to group principals that define access rules.
You can configure broker search parameters so that your
LDAP server derives group principals for every user that connects to Confluent Platform.
The mapping can be derived from either user entries or group entries in LDAP by
configuring the search mode to use either USERS or GROUPS. You must
configure the search mode based on which entry contains both user and group
principals in the format used for authentication and authorization. You can
configure the LDAP attributes containing user and group principals in your LDAP
server entries, and regular expression patterns to extract the principal
from these attributes.
Sample Configuration for Group-Based Search
By default, brokers read group entries from LDAP using group-based mode. If the LDAP group entries in your LDAP server contain the user principal of members in the format used to authenticate the principal by Kafka brokers, then you can use the default group search.
For example, consider an LDAP server with a group entry that contains the following attributes:
dn: CN=Kafka Developers,OU=Groups,DC=EXAMPLE,DC=COM
cn: kafkadev
objectClass: groupOfNames
member: UID=alice,OU=Users,DC=EXAMPLE,DC=COM
member: UID=bob,OU=Users,DC=EXAMPLE,DC=COM
If the user principals used by Kafka are User:alice and User:bob, then you
can configure the group-based search to map User:alice and User:bob to the group
principal Group:kafkadev using the following configuration:
Note
Once Kafka locates the list of users, it still needs to understand what a user
entry looks like in LDAP for the actual authentication. Thus, you must include
the ldap.user. configuration options even when search mode is set to GROUPS.
ldap.search.mode=GROUPS
# Required to ensure that Kafka can locate user entries in LDAP during authentication
ldap.user.search.base=<user-search-base-DN>
ldap.user.object.class=user
ldap.user.name.attribute=<sAMAccountName>
# Required for group-based search
ldap.group.search.base=DC=EXAMPLE,DC=COM
ldap.group.object.class=groupOfNames
ldap.group.name.attribute=cn
ldap.group.member.attribute=member
ldap.group.member.attribute.pattern=UID=(.*),OU=Users,DC=EXAMPLE,DC=COM
In some environments, the distinguished name (DN) of the user in the member entry may not contain the principal generated by Kafka brokers during authentication. In these cases, you can configure user-based search as described in the following section.
Sample Configuration for User-Based Search
The user principal used for authorization by brokers is the principal generated
during authentication. For example, with Kerberos authentication using GSSAPI, the
default principal is the short name from the Kerberos principal. In some LDAP
environments, this principal may not appear in the member attribute of group
entries. In such cases, you can search in user mode to extract the principal
and group principals from LDAP user entries. This search mode provides the
flexibility required for most LDAP environments because group principals are
easily adapted to the format used in the user entry of your LDAP server.
For example, consider an LDAP server with a user entry containing the following attributes:
objectClass: user
distinguishedName: CN=Joe Bloggs,CN=Users,DC=EXAMPLE,DC=COM
sAMAccountName: joe
memberOf: CN=Kafka Developers,CN=Users,DC=EXAMPLE,DC=COM
If the user principal used by Kafka is User:joe , then you can configure
group-based search to map User:joe to the group Group:Kafka Developers
using the following configuration:
ldap.search.mode=USERS
ldap.user.search.base=DC=EXAMPLE,DC=COM
ldap.user.object.class=user
ldap.user.name.attribute=sAMAccountName
ldap.user.memberof.attribute=memberOf
ldap.user.memberof.attribute.pattern=CN=(.*),CN=Users,.*
For LDAP servers with a large number of users where only a small subset access Kafka, you can configure filters to limit the size of search results as described in Configuring LDAP Filters to Limit Search Results.
Configuring LDAP Filters to Limit Search Results
If you have a large number of users in the LDAP server, it is likely that only a subset require access to Confluent Platform. In such instances, you can configure filters to reduce the size of search results because brokers only require group mapping for the small subset of users who connect to the Confluent Platform. LDAP filters are particularly useful for user mode searches where you wish to avoid having brokers process every user defined in the LDAP server.
You can configure a simple filter by adding all users accessing Confluent Platform to a group. For example, the following configuration filters out users belonging to the Kafka group:
ldap.user.search.filter=(memberOf=CN=Kafka,CN=Users,DC=EXAMPLE,DC=COM)
You can also configure a simple filter that processes users belonging to a set of
groups when the users of the Confluent Platform already belong to a small set of
groups. For example, the following filter processes users belonging to the
groups Administrators and Kafka Developers:
ldap.user.search.filter=(|(memberOf=CN=Administrators,CN=Users,DC=EXAMPLE,DC=COM)(memberOf=CN=Kafka Developers,CN=Users,DC=example,DC=com))
If your LDAP server already has other attributes that match users or groups connecting to Confluent Platform, you can filter based on those. You can use any valid LDAP search filter to limit search results in both user and group search modes.
LDAP search filters do not use regex. Instead, LDAP search filters support
'substring' searches (which are not the same as wildcards)–not Regular
Expressions, which run on the LDAP server side rather than Confluent Platform. Examples of
valid substring LDAP search filters are: '(uid=abc*)', and
'(mail=`john@*.com')`)'.
When specifying memberOf and distinguishedName, you must specify the full
DN (distinguished name) of the objects. For details about how to specify
the full DN when setting LDAP search filters while using Active Directory, refer
to Active Directory: LDAP Syntax Filters.
Using Persistent LDAP Search
By default, the mapping of users to groups obtained from LDAP is refreshed periodically
with a refresh interval that you can configure using ldap.refresh.interval.ms.
If your LDAP server supports persistent search, you can set the refresh interval to zero
to initiate a persistent LDAP search in the Confluent Server Authorizer. LDAP updates are processed
as soon as notifications are received, enabling any changes to be used for authorization
immediately. Note that persistent search requires a connection to be kept open between
each broker and the LDAP server and may add load to your LDAP server.
ldap.refresh.interval.ms=0
LDAP Configuration Reference
Confluent License
confluent.licenseConfluent issues a license key to each subscriber. The license key is a short snippet of text that you can copy and paste. Without the license key, you can use Confluent security plugins for a 30-day trial period. If you are a subscriber and don’t have a license key, contact Confluent Support at support@confluent.io.
Type: string
Default: “”
Importance: high
LDAP Search Configuration
ldap.principal.mappingLDAP principal mapping mode dictates the mechanism used to determine the LDAP user principal name for downstream authorization purposes.
Type: string
Default: default
Valid Values: [default, ldap]
Importance: medium
Mapping mode options:
default- Use the case-sensitive authentication username supplied by theuser/caller as the user principal for authorization. This is the default value.
ldap- Use the case-sensitive user principal name from the LDAP server as the user principal for authorization. Note that even though the user principal name lookup is case-insensitive, the case from the LDAP records is used rather than the case used in the original authenticated username.Example: If a user principal in LDAP is all-caps “BOB”, the user can sign in with “bob” and during LDAP authentication, the lookup finds “BOB” and sets “BOB” as the user principal for authorization purposes.
Important
When the mapping mode is set to
ldap, the user principal value specified in the Kafka cluster role bindings must match the case of the user principal name used in the LDAP records; otherwise, authorization fails.ldap.refresh.interval.msLDAP group cache refresh interval in milliseconds. If set to zero, then persistent LDAP search is used.
Type: int
Default: 60000
Importance: medium
ldap.search.page.sizePage size for LDAP search if persistent search is disabled (in other words, when the refresh interval is greater than zero). Paging is disabled by default.
Type: int
Default: 0
Importance: medium
ldap.search.modeLDAP search mode that indicates if the user-to-group mapping is retrieved by searching for group or user entries. Valid values are USERS and GROUPS.
Type: string
Default: GROUPS
Valid Values: [GROUPS, USERS]
Importance: medium
LDAP search by groups
ldap.group.search.baseLDAP search base for group-based search.
Type: string
Default: ou=groups
Importance: high
ldap.group.search.filterLDAP search filter for group-based search.
Type: string
Default: “”
Importance: medium
ldap.group.search.scopeLDAP search scope for group-based search. Valid values are 0 (OBJECT), 1 (ONELEVEL) and 2 (SUBTREE).
Type: int
Default: 1
Importance: medium
ldap.group.object.classLDAP object class for groups.
Type: string
Default: groupOfNames
Importance: medium
ldap.group.name.attributeName of attribute that contains the name of the group in a group entry obtained using an LDAP search. A regex pattern may be specified to extract the group name used in ACLs from this attribute by configuring
ldap.group.name.attribute.pattern.Type: string
Default: cn
Importance: high
ldap.group.name.attribute.patternA Java regular expression pattern that extracts the group name used in ACLs from the name of the group obtained from the LDAP attribute specified using
ldap.group.name.attribute. By default the full value of the attribute is used.Type: string
Default: “”
Importance: low
ldap.group.member.attributeThe name of the attribute that contains the members of the group in a group entry obtained using an LDAP search. A regex pattern may be specified to extract the user principals from this attribute by configuring
ldap.group.member.attribute.pattern.Type: string
Default: member
Importance: high
ldap.group.member.attribute.patternA Java regular expression pattern that extracts the user principals of group members from group member entries obtained from the LDAP attribute specified using
ldap.group.member.attribute. By default the full value of the attribute is used.Type: string
Default: “”
Importance: medium
ldap.group.dn.name.patternA Java regular expression pattern that extracts the group name from the distinguished name (DN) of the group when a group is renamed. This is used only when persistent search is enabled. By default the
ldap.group.name.attributeis extracted from the DN.Type: string
Default: “”
Importance: low
ldap.user.dn.name.patternA Java regular expression pattern used to extract user name from the distinguished name (DN) of the user when user is renamed. This is used only when persistent search is enabled. By default
ldap.user.name.attributeis extracted from the DN.Type: string
Default: “”
Importance: low
LDAP search by users
ldap.user.search.baseThe LDAP search base for a user-based search.
Type: string
Default: ou=users
Importance: medium
ldap.user.search.filterThe LDAP search filter for a user-based search.
Type: string
Default: “”
Importance: medium
ldap.user.search.scopeThe LDAP search scope for a user-based search. Valid values are 0 (OBJECT), 1 (ONELEVEL), and 2 (SUBTREE).
Type: int
Default: 1
Importance: medium
ldap.user.object.classThe LDAP object class for users.
Type: string
Default: person
Importance: medium
ldap.user.name.attributeName of attribute that contains the user principal in a user entry obtained using an LDAP search. A regex pattern may be specified to extract the user principal from this attribute by configuring
ldap.user.name.attribute.pattern.Type: string
Default: uid
Importance: medium
ldap.user.name.attribute.patternA Java regular expression pattern used to extract the user principal from the name of the user obtained from the LDAP attribute specified using
ldap.user.name.attribute. By default the full value of the attribute is used.Type: string
Default: “”
Importance: medium
ldap.user.memberof.attributeThe name of the attribute that contains the groups in a user entry obtained using an LDAP search. A regex pattern may be specified to extract the group names used in ACLs from this attribute by configuring
ldap.user.memberof.attribute.pattern.Type: string
Default: memberof
Importance: medium
ldap.user.memberof.attribute.patternA Java regular expression pattern used to extract the names of groups from user entries obtained from the LDAP attribute specified using
ldap.user.memberof.attribute. By default the full value of the attribute is used.Type: string
Default: “”
Importance: medium
Error Handling Configuration
ldap.retry.backoff.msInitial retry backoff in milliseconds. Exponential backoff is used if
ldap.retry.backoff.max.msis set to a higher value.Type: int
Default: 100
Importance: medium
ldap.retry.backoff.max.msMaximum retry backoff in milliseconds. Exponential backoff is used if
ldap.retry.backoff.msis set to a lower value.Type: int
Default: 1000
Importance: medium
ldap.retry.timeout.msTimeout for LDAP search retries after which the Confluent Server Authorizer is marked as failed. All requests are denied access if a successful cache refresh cannot be performed within this time.
Type: long
Default: 86400000
Importance: medium
SSL Configuration for LDAP connection
ldap.ssl.protocolThe SSL protocol used to generate the SSLContext. The default setting is TLS, which is fine for most cases. Allowed values in recent JVMs are TLS, TLSv1.1, and TLSv1.2. SSL, SSLv2, and SSLv3 may be supported in older JVMs, but their usage is discouraged due to known security vulnerabilities.
Type: string
Default: TLS
Importance: medium
ldap.ssl.providerThe name of the security provider used for SSL connections. The default value is the default security provider of the JVM.
Type: string
Default: null
Importance: medium
ldap.ssl.enabled.protocolsThe list of protocols enabled for SSL connections.
Type: list
Default: TLSv1.2,TLSv1.1,TLSv1
Importance: medium
ldap.ssl.keystore.typeThe file format of the key store file. This attribute is optional for the client.
Type: string
Default: JKS
Importance: medium
ldap.ssl.truststore.typeThe file format of the trust store file.
Type: string
Default: JKS
Importance: medium
ldap.ssl.key.passwordThe password of the private key in the key store file. This attribute is optional for client.
Type: password
Default: null
Importance: high
ldap.ssl.keystore.locationThe location of the key store file. This attribute is optional for the client and can be used for two-way authentication for client.
Type: string
Default: null
Importance: high
ldap.ssl.keystore.passwordThe store password for the key store file. This attribute is optional for the client and is only needed if
ssl.keystore.locationis configured.Type: password
Default: null
Importance: high
ldap.ssl.truststore.locationThe location of the trust store file.
Type: string
Default: null
Importance: high
ldap.ssl.truststore.passwordThe password for the trust store file. If a password is not set, then access to the truststore is still available, but integrity checking is disabled.
Type: password
Default: null
Importance: high
ldap.ssl.cipher.suitesA list of cipher suites. This is a named combination of authentication, encryption, MAC and key exchange algorithm used to negotiate the security settings for a network connection using TLS or SSL network protocol. By default all the available cipher suites are supported.
Type: list
Default: null
Importance: low
ldap.ssl.keymanager.algorithmThe algorithm used by the key manager factory for SSL connections. The default value is the key manager factory algorithm configured for the Java Virtual Machine.
Type: string
Default: SunX509
Importance: low
ldap.ssl.secure.random.implementationThe SecureRandom PRNG implementation to use for SSL cryptography operations.
Type: string
Default: null
Importance: low
ldap.ssl.trustmanager.algorithmThe algorithm used by trust manager factory for SSL connections. The default value is the trust manager factory algorithm configured for the Java Virtual Machine.
Type: string
Default: PKIX
Importance: low
SASL Configuration for LDAP connection
ldap.sasl.jaas.configJAAS login context parameters for SASL connections in the format used by JAAS configuration files. JAAS configuration file format is described in the JAAS Login Configuration File documentation. The format for the value is:
loginModuleClass controlFlag (optionName=optionValue)*;.Type: password
Default: null
Importance: medium
ldap.sasl.login.callback.handler.classThe fully qualified name of a SASL login callback handler class that implements the AuthenticateCallbackHandler interface.
Type: class
Default: null
Importance: medium
ldap.sasl.login.classThe fully qualified name of a class that implements the Login interface.
Type: class
Default: null
Importance: medium
ldap.sasl.kerberos.kinit.cmdThe Kerberos kinit command path.
Type: string
Default: /usr/bin/kinit
Importance: low
ldap.sasl.kerberos.min.time.before.reloginThe login thread sleep time between refresh attempts.
Type: long
Default: 60000
Importance: low
ldap.sasl.kerberos.ticket.renew.jitterPercentage of random jitter added to the renewal time.
Type: double
Default: 0.05
Importance: low
ldap.sasl.kerberos.ticket.renew.window.factorThe duration that the login thread will sleep until the specified window factor of time from last refresh to ticket’s expiry has been reached, at which time it will try to renew the ticket.
Type: double
Default: 0.8
Importance: low