The broker configuration (in the
server.properties file) must set
io.confluent.kafka.security.ldap.authorizer.LdapAuthorizer to enable LDAP group-based authorization.
Fully qualified class name of the Apache Kafka® broker authorizer implementation class that implements
- Type: class
- Default: “”
- Importance: low
The following configuration options of
SimpleAclAuthorizer are also processed by the LDAP Authorizer.
Semicolon-separated list of principals of super users or super groups who are allowed access to all of the resources
for all of the actions for all of the hosts. If a resource has no ACLs associated with it, then only super users can
access the resource. For an example of how to set this, see Configure Brokers.
- Type: string
- Default: “”
- Importance: medium
Boolean flag that indicates if everyone is allowed access to a resource if no ACL is found for the user principal
or any of the groups that the user belongs to.
Use of the
allow.everyone.if.no.acl.found configuration option in production
environments is strongly discouraged.
- If you specify this option based on the assumption that you have ACLs, but then
your last ACL is deleted, you essentially open up your Kafka clusters to all users.
- If you’re using this option to disable ACLs, exercise caution: if someone adds
an ACL, all the users who previously had access will lose that access.
- Type: boolean
- Default: false
- Importance: medium
To enable the LDAP Authorizer to obtain the user principal to group mappings from your
LDAP server, configure these options to match the settings on your LDAP server.
In 5.3.0 and later, when using the LDAP Authorizer, you can use either the
ldap.authorizer. prefix (
ldap.authorizer. is supported for backward compatibility).
Configuring LDAP Context
All standard Java LDAP configurations are supported. Broker configurations starting with
ldap.com.sun.jndi are stripped of their
and these standard Java LDAP configurations are used to make connections to the LDAP server.
You can also use the prefix
ldap.authorizer.. You must configure
ldap.java.naming.provider.url with the URL of your LDAP server. For example:
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).
Be aware that nested LDAP groups are not supported.
Configuring SSL for LDAP
Enable SSL for the connections from the LDAP Authorizer to your LDAP server
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
# 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.
In Java 8 update 181 and later, host name verification is enabled by default
on LDAPS connections. You can disable this verification by setting
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 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
# 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 \
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
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.
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
ldap.authorizer. to configure LDAP credentials for the
broker. For example:
# Specify the LDAP security authentication protocol
# Identify the principal for the LDAP context
# Security credential is the password of the user that performs LDAP search
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
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
If the user principals used by Kafka are
User:bob, then you
can configure the group-based search to map
User:bob to the group
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
ldap.user. configuration options even when search mode is set to
# 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
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
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
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 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:
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
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:
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
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.