LDAP
Basic concepts used in Kerberos LDAP:
-
Active Directory — database and set of services that connect users to the necessary network resources.
-
LDAP server — hierarchical database, a directory service based on Active Directory, used for centralized storage of accounts. The credentials include the principals against which the user is validated in Kerberos.
-
LDAP — application layer protocol for accessing the Active Directory directory service, used in cluster kerberization to establish user principals.
-
LDAPS — LDAP activation using SSL/TLS protocol to create secure traffic. Creating passwords for ADS users with accounts in Active Directory during cluster kerberization is only possible using LDAPS.
-
Key Distribution Center — access control system component responsible for servicing user requests for access to resources by providing access tickets and session keys. It uses Active Directory as the account database.
-
DN (Distinguished Name) is an account in Active Directory. The DN must be unique within the tree. The DN describes the content of the attributes in the tree (navigation path) for accessing a particular entry.
A DN consists of a series of RDN (Relative Distinguished Names) determined by moving up the tree in the direction of its root entry. RDNs are written from left to right.
Preparing to run Active Directory on an ADS cluster
-
Set up an Active Directory server (LDAP server).
-
Create a user account to connect the cluster to LDAP-server using the LDAP protocol.
-
Generate a certificate for the user by enabling LDAP over SSL using a third party CA.
-
Set a password for the account.
-
Assign a user principal name to the account, for example,
admin-kafka@AD.RANGER-TEST
, and generate a keytab file with these principal and keys.
Running Active Directory on ADS cluster in the ADCM interface
-
Make sure you know the necessary data to start Active Directory:
-
KDC hosts — address of the host where Key Distribution Center is installed, for AD kerberization this address is the same as the address of the LDAP server;
-
Realm — designation of realm for authentication in Kerberos;
-
Kadmin server — server for installing the Kerberos V5 administration system, for kerberization on AD this address is the same as the address of the LDAP server;
-
Kadmin principal — designation of the user principal created to connect the cluster to Active Directory;
-
Kadmin password — password for the user principal created to connect the cluster to Active Directory;
-
Admin DN — account in Active Directory for the user used to connect the cluster to Active Directory;
-
LDAP URL — LDAP server address;
-
Container DN — distinguished name ou, which will be the default location for cluster objects created during kerberization below the user described in Admin DN;
-
TLS CA certificate Path — path to the generated CA certificate for the Admin DN user (you can leave it blank, then ADCM will contact the LDAP server);
-
TLS CA certificate (optional) — the number of the created CA certificate for the user Admin DN (it is allowed not to specify, then ADCM will contact the LDAP server)
-
-
Initiate MS Active Directory enablement for the selected cluster. To do this, select Enable Kerberos in Actions of the cluster.
Enabling Kerberos on the ADS cluster -
Enable Existing Active Directory. To do this, you need to enable the eponymous switch in the window that opens.
Enable Existing Active Directory -
Set the configuration parameters of the ADS cluster for MS Active Directory according to the values set for the user in the LDAP directory and click Run.
Configuring ADS Cluster for MS Active Directory -
Wait for the Kerberos LDAP enablement to complete. Analyze and correct errors if they occur.
LDAP installation process
Verify installed Kerberos LDAP
-
Check the settings set for Kerberos in the cluster configurations.
Go to the cluster configuration, select Advanced, find the section with Kerberos configurations, expand it.
Installed ADS cluster configuration settings for Kerberos -
Check the security and authentication configuration of the Kafka brokers.
On each host with a Kafka broker, issue the command:
$ sudo vim /usr/lib/kafka/config/server.properties
Ensure that in the server.properties file for each Kafka broker, the lines defining the security protocol are changed to
SASL_PLAINTEXT
; lines defining the authentication mechanism - toGSSAPI
.security.inter.broker.protocol=SASL_PLAINTEXT sasl.mechanism.inter.broker.protocol=GSSAPI sasl.enabled.mechanisms=GSSAPI
-
Verify that after installing Kerberos SASL, the listeners parameter in the Kafka service settings has changed from
PLAINTEXT://:9092
toSASL_PLAINTEXT://:9092
.Kafka service settings -
Using the command line utility to search the LDAP directory ldapsearch from the Kafka broker host, it is possible to test the generated principals in the
AD.RANGER-TEST
environment at a given Container DN.Enter the command, specifying the
Admin DN
,Container DN
and user password specified when starting LDAP on ADCM:$ ldapsearch -v -H ldaps://ldap_host -x -D "cn=admin,ou=kerberos,ou=adh,dc=ad,dc=ranger-test" -b "ou=admin_ou,ou=kerberos,ou =adh,dc=ad,dc=ranger-test" -w Password
As a result, information is displayed for each created account in LDAP for each instance of each ADS service. Withdrawal option for one account:
# kafka/sov-ads-test-5.ru-central1.internal, admin_ou, kerberos, adh, ad.ranger-test dn: CN=kafka/sov-ads-test-5.ru-central1.internal,OU=admin_ou,OU=kerberos,OU=adh,DC=ad,DC=ranger-test objectClass: top objectClass: person objectClass: organizationalPerson objectClass: user cn: kafka/sov-ads-test-5.ru-central1.internal distinguishedName: CN=kafka/sov-ads-test-5.ru-central1.internal,OU=admin_ou,OU=kerberos,OU=adh,DC=ad,DC=ranger-test instanceType: 4 whenCreated: 20220816100038.0Z whenChanged: 20220816100042.0Z uSNCreated: 14950769 uSNChanged: 14950786 name: kafka/sov-ads-test-5.ru-central1.internal objectGUID:: S/7BU9kZcE6pOwqxKUDJRQ== userAccountControl: 66048 badPwdCount: 0 codePage: 0 countryCode: 0 badPasswordTime: 0 lastLogoff: 0 lastLogon: 133053546143620502 pwdLastSet: 133051176384557312 primaryGroupID: 513 objectSid:: AQUAAAAAAAUVAAAAKcXXWJ6nBwdKJbrR0v8QAA== accountExpires: 0 logonCount: 50 sAMAccountName: $IUV110-ESD8M6LCFJGL sAMAccountType: 805306368 userPrincipalName: kafka/sov-ads-test-5.ru-central1.internal@AD.RANGER-TEST servicePrincipalName: kafka/sov-ads-test-5.ru-central1.internal objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=ad,DC=ranger-test dSCorePropagationData: 16010101000000.0Z lastLogonTimestamp: 133051176422839302
NOTEFor a complete description of the ldapsearch command-line utility features and applicable options, see ldapsearch. -
Check for the presence on hosts with installed services of files for storing passwords *.service.keytab.
On each host with installed services, issue the command:
$ ls -la /etc/security/keytabs/
The file listing shows that *.service.keytab files have been created for each service installed on the host:
total 16 drwxr-xr-x. 2 root root 102 Aug 9 20:55 . drwxr-xr-x. 7 root root 4096 Aug 9 19:38 .. -rw-------. 1 dockerroot dockerroot 890 Aug 9 20:55 kafka-manager.service.keytab -rw-------. 1 kafka kafka 826 Aug 9 20:54 kafka.service.keytab -rw-------. 1 zookeeper zookeeper 858 Aug 9 20:55 zookeeper.service.keytab