While we have enabled LDAP authentication for Impala (just for one of the Daemon nodes),and trying to connect to that node from impala shell (impala-shell -i <hostname> -s <service id> -l -u <userid>, we are getting the following error, but obviously it is not found in kerberos because we disabled kerberos. Looking around for some inputs, I am not sure if I am missing some fundamentals here
Starting Impala Shell using LDAP-based authentication
LDAP password for <user>:
Error connecting: TTransportException, TSocket read 0 bytes
Kerberos ticket found in the credentials cache, retrying the connection with a secure transport.
Error connecting: 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 /xxx not foundin Kerberos database)
Any inputs appreciated.
Hi Sreeman -
You're right, this is unrelated to Kerberos. The Impala shell is able to detect a Kerberos ticket in the cache, and tries to authenticate using that even though Kerberos isn't specified on the remote host. I think this is probably a bug if a separate kind of authentication (i.e. LDAP) is specified.
What's probably happening is that the password you are typing is not recognised for the user. The reason for that with LDAP is usually that the userid you're trying isn't actually the userid present in the LDAP database. For example, many deployments require usernames in the form user@DOMAIN.COM.
In Impala 1.4, there are options to map short userids onto the longer strings that an LDAP server requires. See http://www.cloudera.com/content/cloudera-content/cloudera-docs/Impala/latest/Installing-and-Using-Im... under "Support for custom bind strings".