0

Working with Samba 4 as a Windows “domain member”, I’d like to automate deployment of keytabs. Specifically, I’d like the equivalent of adding service principals to the appropriate tables. E. g.

# kadmin -k /etc/squid/proxy.keytab -w secret -p kadmin/admin -q "ktadd HTTP/proxy.my.domain"

Sadly, MS doesn’t appear to offer kadmin interoperability. Samba has commands like

# net rpc vampire keytab all.keytab -U Administrator%secret
# net ads keytab create -U Administrator%secret

neither of which however appears to be capable of selectively extracting service principals. Also, for a non-trivial site installation I imagine the “vampire” method to require too many system resources, not to mention the necessary postprocessing with ktutil.

In my test setup, the DC is a Windows2008 server, the client is running a 3.14-ish Linux, MIT KRB5 1.15.x, and Samba 4.x. The kerberized service in question is a Squid v3.5.x. Kerberos integration itself works well when creating keytabs on the DC (ktpass) and then copying them over to each machine manually. But I’d rather avoid this kind of pedestrian approach.

It doesn’t necessarily have to be a Samba based solution. That’s just the path I’m investigating ATM.

Clayton
  • 4,483
  • 16
  • 24
phg
  • 81
  • 1
  • 9

1 Answers1

2

The only hard part about what you're currently trying to do is extracting the existing password from the account/principal you're creating the keytab for. The rest of the info is readily available via LDAP queries against the DC via the msDS-KeyVersionNumber and servicePrincipalName attributes.

Assuming the current password on the account isn't set in stone, you could instead just reset/randomize it to something generated by the automation process. Then, you just use ktutil to create the keytab with the now known password and the queried KVNO and SPN(s).

Ryan Bolger
  • 16,472
  • 3
  • 40
  • 59
  • “extracting the existing password from the account/principal you're creating the keytab for” – I don’t follow. Those are service principals; they don’t have a password. I’m looking for the remote equivalent of ``ktpass princ SRV/srv.foo.bar@EXAMPLE.COM mapuser srv -pass admin-pw out srv.foo.bar.keytab`` that given admin credentials can be executed on *srv.foo.bar*. – phg Oct 05 '17 at 09:28
  • All principals have a password. With the ktpass command, you're just never told what it is. The keytab file is effectively just a hash of that password (potentially multiple hashes using the various supported encryption types). – Ryan Bolger Oct 05 '17 at 16:19
  • Bottom line though, you can generate a perfectly valid keytab file if you know the password, KVNO, and the UPN/SPN associated with the account. – Ryan Bolger Oct 05 '17 at 16:20
  • “All principals have a password.” – If I’m reading it correctly, RFC 4120 permits passwords for user principals only. Also, MIT Kerberos [definitely creates random keys directly](https://github.com/krb5/krb5/blob/master/src/lib/kadm5/srv/svr_principal.c#L1569) without a diversion through the KDF. – phg Oct 06 '17 at 08:08
  • 1
    Apologies, I meant all principals in an Active Directory. Service Principals in AD don't exist without an associated User account/principal. "servicePrincipalName" is a multi-valued attribute associated with a user (or computer) account as is "userPrincipalName". – Ryan Bolger Oct 06 '17 at 15:13
  • Got it! With the password of the associated user I was able to derive a functional keytab using ktutil (in case of a Win 2008 server: ``addent -password -p HTTP/proxybox.example.comi2n@EXAMPLE.COM -k 14 -e rc4-hmac``). While this approach still requires knowlege of which kvno the KDC currently uses, I think this answers the question clearly enough. – phg Oct 09 '17 at 07:48
  • 1
    And the kvno is queryable from the msDS-KeyVersionNumber attribute. – Ryan Bolger Oct 09 '17 at 16:45