Configuring Client Authentication with LDAP

You can use Active Directory (AD) and/or LDAP to configure client authentication across all of your Kafka clusters that use SASL/PLAIN. The SASL/PLAIN binding to LDAP requires a password provided by the client. Note that you cannot bind SASL/SCRAM to LDAP because client credentials (the password) cannot be sent by the client.

You must set up an LDAP server (for example, AD) before starting up the Kafka cluster. The configuration that follows is based on the assumption that you have an LDAP server at the URL LDAPSERVER.EXAMPLE.COM:3268 that is accessible using DNS lookup from the host where the broker is run. The configuration expects a Kerberos-enabled LDAP server (although Kerberos is not required–you can perform a simple bind if your LDAP supports it) and the LDAP Authorizer configuration uses GSSAPI for authentication. These security settings must match your LDAP server configuration.

If your LDAP server authenticates clients using Kerberos, a keytab file is required for the LDAP authorizer and the keytab file and principal should be updated in authorizer JAAS configuration option ldap.sasl.jaas.config.

To configure LDAP, refer to Configure LDAP Group-Based Authorization for MDS.

To configure client authentication with AD/LDAP:

  1. Start the LDAP server.

  2. Add the user name and password to LDAP:

    dn: uid=client,ou=people,dc=planetexpress,dc=com
    userPassword: client-secret
  3. Enable LDAP authentication for Kafka clients by adding the LDAP callback handler to in the broker.

    Add the SASL configuration: required;

    If you want to use LDAP authentication for inter-broker communication, then you must include the broker’s user name and password in your SASL configuration.

    Add the LDAP configuration:
    # Authenticate to LDAP,DC=planetexpress,DC=com
    # Locate users,dc=planetexpress,dc=com
  4. Restart the Kafka broker.

    /bin/kafka-server-start etc/kafka/
  5. Specify the client configuration in and

      required username="client" password="client-secret";

    It’s recommended that you encrypt the password in your client configuration using Secrets Management. The following example shows an encrypted client configuration:
      required username="client" password=${securepass:/secretsDemo/ /password};


    Credentials are sent in PLAIN text, so be sure to use TLS with LDAP.

Testing and Troubleshooting LDAP Client Authentication

This section provides basic troubleshooting tips to address common errors that can occur when configuring LDAP client authentication.

Test your LDAP client configuration using the following steps.

  1. Verify LDAP connectivity:

    # Ping the LDAP host to verify connectivity
    # Connect to the LDAP host (this command uses the default port)
    telnet 389
  2. Install the ldapsearch tool to conduct subsequent tests:

    sudo yum install openldap-clients -y
  3. Verify basic access without specifying any credentials:

    ldapsearch -LLL -x -H ldap:// -s "base" -b "" supportedSASLMechanisms

    This command should return either a success response or an authentication error. Any other errors indicate that LDAP not set up correctly.

    A success response looks like the following:

    ldapsearch -LLL -x -H ldap://localhost -s "base" -b "" supportedSASLMechanisms
    supportedSASLMechanisms: GS2-IAKERB
    supportedSASLMechanisms: GS2-KRB5
    supportedSASLMechanisms: SCRAM-SHA-1
    supportedSASLMechanisms: SCRAM-SHA-256
    supportedSASLMechanisms: GSS-SPNEGO
    supportedSASLMechanisms: GSSAPI
    supportedSASLMechanisms: DIGEST-MD5
    supportedSASLMechanisms: OTP
    supportedSASLMechanisms: NTLM
    supportedSASLMechanisms: CRAM-MD5

    An authentication error looks like the following:

    ldapsearch -LLL -x -W -H ldap://localhost -s "base" -b "" supportedSASLMechanisms
    Enter LDAP Password:
    ldap_bind: Invalid credentials (49)

    In cases where you are unable to communicate with an LDAP server, and/or the LDAP server is not set up correctly to accept LDAP requests, the error looks like the following:

    ldapsearch -LLL -x -H ldap://localhost:8090 -s "base" -b "" supportedSASLMechanisms
    ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
  4. Verify basic credential-based access using the same user specified in in

    ldapsearch -LLL -x -H ldap:// -s "base" -b "" -D CN=kafka_user,CN=Users,DC=hostname,DC=com -w 'pa55word' supportedSASLMechanisms

    If the value of points to a Kerberos principal, be sure to specify the corresponding user from LDAP.

If the preceding verification tests work, then MDS can authenticate against LDAP.

When configuring Kafka to communicate over LDAPS, verify TLS connectivity to the LDAP server as follows:

# To verify the LDAP configuration
ldapsearch -LLL -x -H ldaps:// -s "base" -b "" supportedSASLMechanisms
# If using self-signed certificates from the LDAP server
LDAPTLS_CACERT=/path/to/CA.cert ldapsearch -LLL -x -H ldaps:// -s "base" -b "" supportedSASLMechanisms

When configuring Kafka to authenticate to LDAP using Kerberos, verify authentication to the LDAP server as follows:

# To verify the Kerberos configuration
kinit -k -t ./filename.keytab kafka_broker/
ldapsearch -LLL -Y GSSAPI -H ldap:// -s "base" -b "" supportedSASLMechanisms