Support Questions

Find answers, ask questions, and share your expertise
Announcements
Check out our newest addition to the community, the Cloudera Data Analytics (CDA) group hub.

SPNEGO service on an existing node

New Contributor

Hi

 

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.

 

Thanks

Simon

3 REPLIES 3

Champion
When CM creates a principal it sets the password and creates the keytab file. This can be found in the running process directory for the process, /var/run/cloudera-scm-agent/process.

Why do you want to auth as this process's user?

New Contributor

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?)

New Contributor

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.

Take a Tour of the Community
Don't have an account?
Your experience may be limited. Sign in to explore more.