08-15-2017 06:17 AM - edited 08-15-2017 06:56 AM
Be interested to see if anyone else has seen a similar issue to ours... and what they did to get round it...
Although this may be caused by a complete lack of understanding on my part!
We need to add a kerberos based application to one of our Cloudera edge nodes (livy in this case)
This application requires SPNEGO, and hence an HTTP service principal needs to be used.
The Cloudera Manager kerberization process looks to create one for all the nodes in the cluster.
How do I get a keytab for this SPN so I can kinit against it?
We're using Active Directory as the KDC.
08-16-2017 11:54 AM
08-16-2017 11:21 PM
It's another piece of software - livy in this case, that is kinit-ing as the service principal.
In this case it's the HTTP SPN for SPNego that's being used; it looks like the CM kerberization wizard puts an HTTP SPN in AD for each host, but then as passwords are not published for the user account that's been mapped, there's no way of accessing it.
I can't create a new SPN in AD, as one already exists for the service/host combination I need.
There are no services using the HTTP SPN currently, as the node I'm working on is a gateway, but I don't want to start changing passwords (and I believe (although not absolutely sure!) using ktpass to remap the user will create a new password?)
01-23-2018 05:11 AM
OK - so the way round this, is to install a service that uses SPNEGO, and use that keytab, either by taking the principal out of the HTTP keytab and inserting it into your own (probable best option), or just referring directly to the keytab (which may be difficult as it'll be housed under the /process directory - so e.g., copy it out (with obviously restricted privs!)
An example service - we've used httpfs.
If you've copied the keytab, any time you regenerate krb principal information, you'll need to update your copied keytab.