Kerberos Auth connection attempt results in Server Not Found in Kerberos database error

[wjdecorte]

We are trying to connect to a kerberized cluster using Impyla. When trying to connect, we get a vague error message.

conn = connect(host='hiveserver2.host.com',port=10000,auth_mechanism='GSSAPI',kerberos_service_name='hive/hiveserver2.host.com@REALM.COM')

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/opt/venv/COUNTACH/lib/python2.7/site-packages/impala/dbapi.py", line 147, in connect
    auth_mechanism=auth_mechanism)
  File "/opt/venv/COUNTACH/lib/python2.7/site-packages/impala/hiveserver2.py", line 758, in connect
    transport.open()
  File "/opt/venv/COUNTACH/lib/python2.7/site-packages/thrift_sasl/__init__.py", line 72, in open
    message=("Could not start SASL: %s" % self.sasl.getError()))
thrift.transport.TTransport.TTransportException: Could not start SASL: Error in sasl_client_start (-1) SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure.  Minor code may provide more information (Server not found in Kerberos database)

We are able to use the same kerberos service principle and host for Beeline and connect successfully. I saw another post mentioning this same issue, but no resolution was given (Issue #149).

Environment:

CDH-5.8.3
impyla      0.14.0
sasl        0.2.1
six         1.10.0
thrift      0.10.0
thrift-sasl 0.2.1

Any help or suggestions would be greatly appreciated. We are at a loss as to whether it is a bug or a configuration issue or something else.

Thanks, Jason

[wfowlks]

I am also having this issue. I was able to get it to work not using kerberos.

After kiniting and verifying using klist:

Ticket cache: FILE:/tmp/krb5cc_1000
Default principal: impala@HOST.COM

Valid starting       Expires              Service principal
09/27/2017 11:34:57  09/28/2017 11:34:52  krbtgt/HOST.COM@HOST.COM
    renew until 10/04/2017 11:34:52

(venv) [centos@test-haproxy supersets]$ python sql2test.py 
Traceback (most recent call last):
  File "sql2test.py", line 15, in <module>
    ca_cert='/home/centos/supersets/TEST.pem')
  File "/home/centos/supersets/venv/lib/python2.7/site-packages/impala/dbapi.py", line 147, in connect
    auth_mechanism=auth_mechanism)
  File "/home/centos/supersets/venv/lib/python2.7/site-packages/impala/hiveserver2.py", line 758, in connect
    transport.open()
  File "/home/centos/supersets/venv/lib/python2.7/site-packages/thrift_sasl/__init__.py", line 72, in open
    message=("Could not start SASL: %s" % self.sasl.getError()))
thrift.transport.TTransport.TTransportException: Could not start SASL: Error in sasl_client_start (-1) SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure.  Minor code may provide more information (Server not found in Kerberos database)

Here is the script that we are running:

from impala.dbapi import connect

conn = connect(
  host='worker1.host.com',
  port=21050, 
  auth_mechanism='GSSAPI', 
  use_ssl='true',
  kerberos_service_name='impala', 
  ca_cert='/home/centos/supersets/TEST.pem')
cursor = conn.cursor()
cursor.execute('SELECT * FROM lookup.test LIMIT 100')
print cursor.description  # prints the result set's schema
results = cursor.fetchall()

Were you able to resolve this?

[natedogs911]

+1 on the issue for me

[kingbase]

while using kerberos, impala-shell works fine but impyla doesn't work.

Could you please check this?

Thanks.

[pramodvspk]

Anyone who was able to solve this? Can you please share a code snippet.

[sathishsms]

Facing the same issue. what could be the problem ? "msg": "kerberos: authGSSClientStep() failed: (('Unspecified GSS failure. Minor code may provide more information', 851968), ('Server not found in Kerberos database', -1765328377))",

[natedogs911]

This error is typically always related to something being wrong in your value used to get a ticket. for example if you use all of the connection parameters specified in your code to get a ticket with kinit it will likely fail. Specifically i would guess it's the hostname in a service ticket or something of that nature. But again i suggest simulating the kinit and you'll likely get the same or similar error from kinit itself.

On Mon, May 7, 2018 at 11:50 PM, satheesh notifications@github.com wrote:

Facing the same issue. what could be the problem ? "msg": "kerberos: authGSSClientStep() failed: (('Unspecified GSS failure. Minor code may provide more information', 851968), ('Server not found in Kerberos database', -1765328377))",

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/cloudera/impyla/issues/262#issuecomment-387302610, or mute the thread https://github.com/notifications/unsubscribe-auth/AL-_Exic4F5Enn0GPaHWWorXQBwcXtgnks5twUA9gaJpZM4Nf4Rm .

[gordoncoaleCWT]

Hi All, The cause of this issue is the usually the hostname you are using. You need to use the actual hostname of the server that has been registered with kerberos rather than the service name, its doubly confusing because impala-shell isn't this picky.
For example - my service name is impala.somereference.internaldomainref.com this will work fine for impala shell and PLAIN auth for impyla but it will not work for GSSAPI/kerberos Auth. My impala server node is cloud based so its FQDN is ip-xxx-xxx-xxx-xxx.internaldomainref.com if you put this in the hostname parameter and kinit beforehand it should work.

[KleinerKobold]

+1 from me

[timarmstrong]

It's interesting that impala-shell is reportedly behaving differently, maybe there's something we can do for Impyla.

[gordoncoaleCWT]

@timarmstrong - Tim its not just that Impyla and Impala-shell behave differently its that within impyla the PLAIN and GSSAPI options behave inconsistently too. Example expanding on my comment from 25th Oct :

  host='impala.somereference.internaldomainref.com',   <---   service name will **fail**
  port=21050, 
  auth_mechanism='GSSAPI', 

  host='ip-xxx-xxx-xxx-xxx.internaldomainref.com',   <---   host name will **work**
  port=21050, 
  auth_mechanism='GSSAPI', 
------------
  host='impala.somereference.internaldomainref.com',   <---   service name will **work**
  port=21050, 
  auth_mechanism='PLAIN', 

  host='ip-xxx-xxx-xxx-xxx.internaldomainref.com',   <---   host name will **work**
  port=21050, 
  auth_mechanism='PLAIN', 

[torquey66]

I was attempting to use the TSasl code from impala in another context and could not get Kerberos auth to work properly until I discovered the undef.cpp file which appears to stub out the gss_ calls. Once I stopped linking against that, everything worked swimmingly for me. I suspect impala-shell refrains from linking against this file and hence works as expected.

[repudi8or]

try adding rdns = false to the [libdefaults] section of your /etc/krb5.conf

[rohit6261]

Is this issue resolved? As i am getting the same error. Please help