Support Questions

Find answers, ask questions, and share your expertise
Announcements
Celebrating as our community reaches 100,000 members! Thank you!

Kerberos enabled cluster - Curl command for Cloudera Navigator

avatar
Contributor

Hello

 

We have a kerberos enabled cluster which has Navigator installed.

I am trying to view some metadata through Navigator API using Curl command suggested.

 

curl 'http://localhost:7187/api/v3/entities?query=type:file&limit=2&offset=0' \ -X GET \ -u :

With username and password, things are working fine.

 

How to get it to work with Kerberos ticket? I do have a valid ticket (kinit/klist).

 

None of the below tries worked.

 

curl -krb --negotiate 'http://localhost:7187/api/v3/entities?query=type:file&limit=2&offset=0' 
curl --krb private 'http://localhost:7187/api/v3/entities?query=type:file&limit=2&offset=0' 

 

I tried a few other ways read from various sources but none of them are working. I get the below error.

Can someone help me with getting the curl command to work? Thanks.

 

<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"/>
<title>Error 401 Full authentication is required to access this resource</title>
</head>
<body><h2>HTTP ERROR 401</h2>
<p>Problem accessing /api/v10/interactive/entities. Reason:
<pre>    Full authentication is required to access this resource</pre></p><hr /><i><small>Powered by Jetty://</small></i><br/>
<br/>
</body>
</html>





















1 ACCEPTED SOLUTION

avatar
Champion
Lets take a step back. You mentioned that the cluster is Kerberized and therefor Navigator needs some configs along those lines to interact with the cluster but what is its auth mechanism. I believe it can be different. Yes, it is. The External auth options for Nav are AD (LDAP), OpenLDAP, and SAML. If you do not have one of these set up then it will use the Cloudera Manager accounts (which could be internal or external). If it is internal, then you will need to use one of those accounts, with the proper Nav role/group assigned, in the -u cmuser:cmpass switch. You won't need a Kerberos ticket in this case.

View solution in original post

9 REPLIES 9

avatar
Champion

It should work with both --negotiate and -u.

curl -v --negotiate -u "username" http://www.blah.com

avatar
Contributor

I wish it did. 

 

It asked for password and same error as before. Even if I type the correct password, it gives the error msg. 

 

I do have a valid Kerberos ticket. It lists when I give a klist command. 

avatar
Champion
Lets take a step back. You mentioned that the cluster is Kerberized and therefor Navigator needs some configs along those lines to interact with the cluster but what is its auth mechanism. I believe it can be different. Yes, it is. The External auth options for Nav are AD (LDAP), OpenLDAP, and SAML. If you do not have one of these set up then it will use the Cloudera Manager accounts (which could be internal or external). If it is internal, then you will need to use one of those accounts, with the proper Nav role/group assigned, in the -u cmuser:cmpass switch. You won't need a Kerberos ticket in this case.

avatar
Contributor

Thanks for the reply.

 

It (Navigator) is set up to use LDAP. In this case, curl command cannot be used with a Kerberos tkt and LDAP credentials always needs to be passed as -u LDAPUser:LDAPPass?

Or, is there anyway that I can make the curl command work wihtout exposing the passwd?

avatar
Champion
You can leave the password blank, it will then prompt the user for the password.

curl -u user: https;//..

avatar
Contributor

For adhoc requests - the above method works. But, if I have to automate thru some script and I do not want to manage passwords (updating it everytime), what are my other options to make this work?

 

Thanks again for all your replies. With each reply, I learn something new.

avatar
Champion
Look for the --netrc switch for your curl command. You can use this file to pass the username and password to the command. This keeps it out of the ps output and history but the file security must be maintained. The format should be the below but check man if needed.

machine host.domain.com login myself password secret

avatar
Contributor

Thanks - familiar with .netrc - unfortunately, we are not using that. Will keep that in mind if nothing else works.

avatar
Explorer

Any luck on the solution?