Use of keytabs and service principals - apache-kafka

Question

I'm struggling with is the use of keytabs and service principals. I always thought keytabs were a combination of an encrypted password and Kerberos principal. For services or hosts, however there are no actual passwords unless I'm missing something.
In my case, I'm trying to use config Apache Kafka to run with Kerberos to Active Directory. Specifically I joined AD and created the SPN using the adcli command. I can create a keytab using the ktutil command for the service principal. However it prompts me for the password. I've tested using a service account password and the root password with no luck.
Any suggestions would be greatly appreciated.

Answer 1

I'm struggling with is the use of keytabs and service principals. I always thought keytabs were a combination of an encrypted password and Kerberos principal. For services or hosts, however there are no actual passwords unless I'm missing something.
There can be a password. Windows AD member hosts indeed have a "machine password" that is stored in the Windows LSA secrets storage – which is why they don't need a keytab. Similarly, "service" accounts1 in AD are just user accounts that have a (hopefully!) randomized password.
But to Kerberos, the original password doesn't actually matter. Only the derived key is what gets used. This means the key doesn't have to be derived from a password, and indeed in "traditional" MIT/Heimdal Kerberos the whole key is randomly-generated for host or service principals.
(Note that I said "derived", not "encrypted". For password inputs, the keys are the result of a one-way hash. Kerberos uses PBKDF2 for AES keys, while RC4-HMAC keys are "NTLM hashes".)
1 Oh, and don't try to re-use the "machine" account created via AD join for Kafka. Create a separate "user" account and assign it the SPN.
In my case, I'm trying to use config Apache Kafka to run with Kerberos to Active Directory. Specifically I joined AD and created the SPN using the adcli command. I can create a keytab using the ktutil command for the service principal. However it prompts me for the password. I've tested using a service account password and the root password with no luck.
ktutil could work, but there are two big issues to note:
First, when deriving the AES keys (using PBKDF2), you must use the correct salt. In Kerberos it can often be derived from the principal name, but not always; e.g. a renamed account will retain its original pre-rename salt. And in AD, all SPNs assigned to a custom user account will use that user's main account name as the salt, as the KDC knows about this relationship – but ktutil doesn't!
So you should always use the -f option to addent, which actually asks the KDC for the correct salt (just like kinit also would).
(RC4-HMAC keys use an NTLM hash, which is not salted. One of the reasons RC4-HMAC should become obsolete as soon as possible, and why you should also manually check whether the service account is indeed flagged for AES support.)
Second, you have to add keys for the same enctypes (algorithms) that the KDC thinks the service will support.
Fresh AD accounts are only considered to support arcfour-hmac (obsolete-ish), but I believe adcli sets the correct flags to indicate support for aes256 and aes128 as well. This means you need to repeat ktutil's addent 3 times, with different -e options.
ktutil: addent -password -p kafka/foo.example.tld#EXAMPLE.TLD -k 1 -e aes256-cts -f
ktutil: addent -password -p kafka/foo.example.tld#EXAMPLE.TLD -k 1 -e aes128-cts -f
ktutil: addent -password -p kafka/foo.example.tld#EXAMPLE.TLD -k 1 -e arcfour-hmac -f
ktutil: wkt kafka.keytab
It might be easier to find a Windows host with RSAT installed, which has ktpass.exe that'll create a keytab for you.
(And unfortunately, samba-tool domain exportkeytab is not an option, as it assumes it'll be run directly on a Samba-based AD DC and wants to access the raw database and extract the current keys, instead of doing the normal thing and going via LDAP.)