Our Community is getting an upgrade! To get everything ready for the relaunch, we’ll be placing the site in read-only mode starting September 21st.
We really appreciate your understanding while we get things set up behind the scenes. Catch up on all the exciting details about the move here.
Need help or have questions? Drop us a line at [email protected]
Created 04-27-2017 11:22 AM
Hi,
I am currently facing an issue at accessing SOLR collection via curl . Cluster is kerberized and working properly (HDFS/Hive/...), but while executing (after grabbing a kerberos ticket as user 'solr') e.g.
curl --negotiate -u : 'http://mgr-node1:8983/solr/'
I receive the following response:
...HTTP Status 403 - GSSException: Failure unspecified at GSS-API level (Mechanism level: Invalid argument (400) - Cannot find key of appropriate type to decrypt AP REP - AES256 CTS mode with HMAC SHA1-96)...
Keytab for user 'solr' contains:
2 27.04.2017 09:02:49 solr/<node>@<realm> (aes256-cts-hmac-sha1-96) 2 27.04.2017 09:02:49 solr/<node>@<realm> (des3-cbc-sha1) 2 27.04.2017 09:02:49 solr/<node>@<realm> (arcfour-hmac) 2 27.04.2017 09:02:49 solr/<node>@<realm> (des-hmac-sha1)
MIT-KDC config contains this enctype as well:
sudo cat /var/kerberos/krb5kdc/kdc.conf | grep supported_enctypes supported_enctypes = aes256-cts-hmac-sha1-96 des3-hmac-sha1 aes256-cts arcfour-hmac des-hmac-sha1
cat /etc/krb5.conf | grep _enctypes default_tgs_enctypes = aes256-cts-hmac-sha1-96 des3-hmac-sha1 aes256-cts arcfour-hmac des-hmac-sha1 default_tkt_enctypes = aes256-cts-hmac-sha1-96 des3-hmac-sha1 aes256-cts arcfour-hmac des-hmac-sha1 permitted_enctypes = aes256-cts-hmac-sha1-96 des3-hmac-sha1 aes256-cts arcfour-hmac des-hmac-sha1
What is going on there ?
Any help highly appreciated...
Created 04-28-2017 03:58 PM
Hello @Gerd Koenig,
I don't see any problem with the encryption type here. There are couple of reasons for this kind of error:
1. Please check the SOLR hostname in the curl request is exactly same as what is used in keytab "solr/<solr-hostname>". In ideal condition, both should be FQDN. Also check the same for SPNEGO keytab (HTTP/<solr-hostname>).
2. The Key Version Number (kvno) of solr/<sorl-hostname> and HTTP/<solr-hostname> should be same in the keytab and in MIT KDC database. You can do a 'klist -kt <keytab>' and 'kadmin.local -q "getprincs solr/<solr-hostname>" ' to compare the kvno.
In case the error persist, please set KRB5_TRACE and then run kinit & curl to get more debug output and paste here:
export KRB5_TRACE=/tmp/curl-krb.log kinit <user-principal> klist -eaf curl -iv --negotiate -u : http://<solr-hostname>:8983/solr
Hope this helps!
Created 04-28-2017 03:58 PM
Hello @Gerd Koenig,
I don't see any problem with the encryption type here. There are couple of reasons for this kind of error:
1. Please check the SOLR hostname in the curl request is exactly same as what is used in keytab "solr/<solr-hostname>". In ideal condition, both should be FQDN. Also check the same for SPNEGO keytab (HTTP/<solr-hostname>).
2. The Key Version Number (kvno) of solr/<sorl-hostname> and HTTP/<solr-hostname> should be same in the keytab and in MIT KDC database. You can do a 'klist -kt <keytab>' and 'kadmin.local -q "getprincs solr/<solr-hostname>" ' to compare the kvno.
In case the error persist, please set KRB5_TRACE and then run kinit & curl to get more debug output and paste here:
export KRB5_TRACE=/tmp/curl-krb.log kinit <user-principal> klist -eaf curl -iv --negotiate -u : http://<solr-hostname>:8983/solr
Hope this helps!
Created 04-28-2017 04:03 PM
The correct commands are -
kadmin.local -q "getprincs solr/<hostname>" kadmin.local -q "getprincs HTTP/<hostname>"
Created 04-28-2017 06:02 PM
Hello @Vipin Rathor ,
thank you sooo much. Your hint with the FQDN did the trick.
After putting the FQDN in the curl command, it works nice!
Created 05-01-2017 04:07 PM
Awesome ! Thanks @Gerd Koenig for the update. I'm glad that it worked out for you. Cheers.
Created 07-18-2017 09:01 AM
@Vipin Rathor:
Can you please help on issue reported in below ticket: