The user ID specified in group role bindings is case-specific, and must match
the case specified in the AD record. Also note that when logging in as a super user,
the login ID is also case-specific and must match the case specified for the user
ID in role bindings.
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:
Following are detailed descriptions of the required baseline JNDI LDAP
configuration options that Kafka uses to authenticate to the directory service
with the bind user.
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).
Enable SSL for the connections from the LDAP 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..
# Configure provider URL with `ldaps` as protocol
# Enable SSL for connections to LDAP server
# Path of truststore for connections to LDAP
# Password of LDAP truststore
For a list of supported SSL configurations, see Encryption and Authentication with SSL.
You can use GSSAPI to authenticate the LDAP Authorizer with your LDAP server if Kerberos
is enabled on your LDAP server. The JAAS configuration for GSSAPI may be configured using
the config option ldap.sasl.jaas.config. Authentication protocol and security
principal must also be configured using standard Java LDAP configs prefixed with ldap..
# Configure SASL/GSSAPI as the authentication protocol for LDAP context.
# Security principal for LDAP context
# JAAS configuration for Kerberos authentication with LDAP server
ldap.sasl.jaas.config=com.sun.security.auth.module.Krb5LoginModule required \
If ldap.sasl.jaas.config is not configured, the default JAAS configuration
of the broker will be used. The default JAAS configuration (e.g configured using the
system property java.security.auth.login.config) is loaded from the login context
KafkaServer that is used as broker’s login context using a single shared login. This
should be used for LDAP only if the principal in this context can be used to search 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:
# Configure simple LDAP binding for authentication
# Security principal is the distinguished name of the LDAP user that performs LDAP search
# Security credential is the password of the user that performs 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.
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
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.
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
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:
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.
# Required to ensure that Kafka can locate user entries in LDAP during authentication
# Required for group-based search
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
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
distinguishedName: CN=Joe Bloggs,CN=Users,DC=EXAMPLE,DC=COM
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:
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 Configure 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:
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:
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.
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 LDAP 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 group cache refresh interval in milliseconds. If set to zero, then persistent LDAP search is used.
Page 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.
LDAP 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.
LDAP search base for group-based search.
LDAP search filter for group-based search.
LDAP search scope for group-based search. Valid values are 0 (OBJECT), 1 (ONELEVEL) and 2 (SUBTREE).
LDAP object class for groups.
Name 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
A 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.
The 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
A 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.
A 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.attribute is extracted from the DN.
A 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.attribute is extracted from the DN.
The LDAP search base for a user-based search.
The LDAP search filter for a user-based search.
The LDAP search scope for a user-based search. Valid values are 0 (OBJECT), 1 (ONELEVEL), and 2 (SUBTREE).
The LDAP object class for users.
Name 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
A 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.
The 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.
A 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.
Initial retry backoff in milliseconds. Exponential backoff is used if ldap.retry.backoff.max.ms is set to a higher value.
Maximum retry backoff in milliseconds. Exponential backoff is used if ldap.retry.backoff.ms is set to a lower value.
Timeout for LDAP search retries after which the LDAP Authorizer is marked as failed. All requests are denied access if
a successful cache refresh cannot be performed within this time.
The 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.
The name of the security provider used for SSL connections. The default value
is the default security provider of the JVM.
The list of protocols enabled for SSL connections.
The file format of the key store file. This attribute is optional for the client.
The file format of the trust store file.
The password of the private key in the key store file. This attribute is optional for client.
The location of the key store file. This attribute is optional for the client and can be used for two-way authentication for client.
The store password for the key store file. This attribute is optional for the client and is only needed if ssl.keystore.location is configured.
The location of the trust store file.
The 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.
A 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.
The 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.
The SecureRandom PRNG implementation to use for SSL cryptography operations.
The algorithm used by trust manager factory for SSL connections. The default value is the trust manager factory
algorithm configured for the Java Virtual Machine.
JAAS 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)*;.
loginModuleClass controlFlag (optionName=optionValue)*;
The fully qualified name of a SASL login callback handler class that implements
the AuthenticateCallbackHandler interface.
The fully qualified name of a class that implements the Login interface.
The Kerberos kinit command path.
The login thread sleep time between refresh attempts.
Percentage of random jitter added to the renewal time.
The 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.