Support Questions
Find answers, ask questions, and share your expertise
Announcements
Alert: Welcome to the Unified Cloudera Community. Former HCC members be sure to read and learn how to activate your account here.

impala - kerberosed - jdbc connection from SQL Workbench on Windows

Highlighted

impala - kerberosed - jdbc connection from SQL Workbench on Windows

Contributor

We have a 15 Node Kerborised Impala Cluster with a HAProxy. We have no issue using HUE to run queries.

 

We are also able to use the ODBC Driver on a Windows Machine, authenticate with Kerberos and connect to the Impala via HA Proxy.

 

However, when we try to connect to the Impala HA Proxy using SQL Workbench via JDBC Driver. We get the following error message:

 

[Simba][ImpalaJDBCDriver](500310) Invalid operation: Unable to obtain Principal Name for authentication ;

 

The connection string is:

jdbc:impala://<PUBLIC IP ADDRESS>:21051;AuthMech=1;KrbRealm=<REALM>;KrbHostFQDN=<fqdn>;KrbServiceName=impala;

 

We tried adding the Principal parameter, but it doesn't help. Any ideas, on how to get Impala JDBC to work from a windows machine using Kerberos?

 

 

 

28 REPLIES 28

Re: impala - kerberosed - jdbc connection from SQL Workbench on Windows

Guru

Hi,


Please enable the JDBC trace log for further debugging:

 

jdbc:impala://{PUBLIC IP ADDRESS}:21051;AuthMech=1;KrbRealm={REALM};KrbHostFQDN={fqdn};KrbServiceName=impala;LogLevel=6;LogPath=/path/to/directory

 

and then provide errors in trace log under /path/to/directory for review.

 

Please also find the corresponding errors in impala daemon logs.

Re: impala - kerberosed - jdbc connection from SQL Workbench on Windows

Contributor

This is what I see in the JDBC Trace Log Files.

 

Oct 12 17:50:52.989 TRACE 27 com.cloudera.impala.dsi.core.impl.DSIConnection.DSIConnection(com.cloudera.impala.hivecommon.core.HiveJDBCEnvironment@1bbd56aa): +++++ enter +++++
Oct 12 17:50:52.989 TRACE 27 com.cloudera.impala.dsi.core.impl.DSIConnection.setProperty(101, Variant[type: TYPE_WSTRING, value: ImpalaJDBC]): +++++ enter +++++
Oct 12 17:50:52.989 TRACE 27 com.cloudera.impala.dsi.core.impl.DSIConnection.setProperty(139, Variant[type: TYPE_WSTRING, value: User]): +++++ enter +++++
Oct 12 17:50:52.989 TRACE 27 com.cloudera.impala.dsi.core.impl.DSIConnection.setProperty(22, Variant[type: TYPE_WSTRING, value: Impala]): +++++ enter +++++
Oct 12 17:50:52.989 TRACE 27 com.cloudera.impala.dsi.core.impl.DSIConnection.setProperty(58, Variant[type: TYPE_WSTRING, value: `]): +++++ enter +++++
Oct 12 17:50:52.989 TRACE 27 com.cloudera.impala.dsi.core.impl.DSIConnection.setProperty(66, Variant[type: TYPE_UINT16, value: -1]): +++++ enter +++++
Oct 12 17:50:52.989 TRACE 27 com.cloudera.impala.dsi.core.impl.DSIConnection.setProperty(68, Variant[type: TYPE_UINT16, value: -1]): +++++ enter +++++
Oct 12 17:50:52.989 TRACE 27 com.cloudera.impala.dsi.core.impl.DSIConnection.setProperty(76, Variant[type: TYPE_UINT16, value: -1]): +++++ enter +++++
Oct 12 17:50:52.989 TRACE 27 com.cloudera.impala.dsi.core.impl.DSIConnection.setProperty(81, Variant[type: TYPE_UINT16, value: -1]): +++++ enter +++++
Oct 12 17:50:52.989 TRACE 27 com.cloudera.impala.dsi.core.impl.DSIConnection.setProperty(83, Variant[type: TYPE_UINT16, value: -1]): +++++ enter +++++
Oct 12 17:50:52.989 TRACE 27 com.cloudera.impala.dsi.core.impl.DSIConnection.setProperty(80, Variant[type: TYPE_WSTRING, value: N]): +++++ enter +++++
Oct 12 17:50:52.989 TRACE 27 com.cloudera.impala.dsi.core.impl.DSIConnection.registerWarningListener(com.cloudera.impala.jdbc.common.SWarningListener@157abbad): +++++ enter +++++
Oct 12 17:50:52.989 TRACE 27 com.cloudera.impala.hivecommon.core.HiveJDBCConnection.updateConnectionSettings(): +++++ enter +++++
Oct 12 17:50:52.989 TRACE 27 com.cloudera.impala.hivecommon.core.HiveJDBCConnection.connect({AuthMech=Variant[type: TYPE_WSTRING, value: 1], ConnSchema=Variant[type: TYPE_WSTRING, value: NULL], DatabaseType=Variant[type: TYPE_WSTRING, value: Impala], HiveServerType=Variant[type: TYPE_WSTRING, value: 2], Host=Variant[type: TYPE_WSTRING, value: gateway.mygws.com], KrbHostFQDN=Variant[type: TYPE_WSTRING, value: ip-10-0-0-186.ec2.internal], KrbRealm=Variant[type: TYPE_WSTRING, value: MOBISTAT], KrbServiceName=Variant[type: TYPE_WSTRING, value: impala], LogLevel=Variant[type: TYPE_WSTRING, value: 6], LogPath=Variant[type: TYPE_WSTRING, value: D:\Mobistat\Log\], Port=Variant[type: TYPE_WSTRING, value: 21051], Principal=Variant[type: TYPE_WSTRING, value: krishnat/ip-10-0-0-186@MOBISTAT]}): +++++ enter +++++
Oct 12 17:50:52.989 ERROR 27 com.cloudera.impala.exceptions.ExceptionConverter.toSQLException: [Simba][ImpalaJDBCDriver](500310) Invalid operation: Unable to obtain Principal Name for authentication ;
java.sql.SQLException: [Simba][ImpalaJDBCDriver](500310) Invalid operation: Unable to obtain Principal Name for authentication ;
at com.cloudera.impala.hivecommon.api.HiveServer2ClientFactory.createTransport(HiveServer2ClientFactory.java:224)
at com.cloudera.impala.hivecommon.api.HiveServer2ClientFactory.createClient(HiveServer2ClientFactory.java:52)
at com.cloudera.impala.hivecommon.core.HiveJDBCConnection.connect(HiveJDBCConnection.java:597)
at com.cloudera.impala.jdbc.common.BaseConnectionFactory.doConnect(BaseConnectionFactory.java:219)
at com.cloudera.impala.jdbc.common.AbstractDriver.connect(AbstractDriver.java:216)
at workbench.db.DbDriver.connect(DbDriver.java:513)
at workbench.db.ConnectionMgr.connect(ConnectionMgr.java:244)
at workbench.db.ConnectionMgr.getConnection(ConnectionMgr.java:172)
Caused by: com.cloudera.impala.support.exceptions.GeneralException: [Simba][ImpalaJDBCDriver](500310) Invalid operation: Unable to obtain Principal Name for authentication ;
... 8 more
Caused by: javax.security.auth.login.LoginException: Unable to obtain Principal Name for authentication
at com.sun.security.auth.module.Krb5LoginModule.promptForName(Unknown Source)
at com.sun.security.auth.module.Krb5LoginModule.attemptAuthentication(Unknown Source)
at com.sun.security.auth.module.Krb5LoginModule.login(Unknown Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at javax.security.auth.login.LoginContext.invoke(Unknown Source)
at javax.security.auth.login.LoginContext.access$000(Unknown Source)
at javax.security.auth.login.LoginContext$4.run(Unknown Source)
at javax.security.auth.login.LoginContext$4.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.login.LoginContext.invokePriv(Unknown Source)
at javax.security.auth.login.LoginContext.login(Unknown Source)
at com.cloudera.impala.hivecommon.api.HiveServer2ClientFactory.createTransport(HiveServer2ClientFactory.java:113)
at com.cloudera.impala.hivecommon.api.HiveServer2ClientFactory.createClient(HiveServer2ClientFactory.java:52)
at com.cloudera.impala.hivecommon.core.HiveJDBCConnection.connect(HiveJDBCConnection.java:597)
at com.cloudera.impala.jdbc.common.BaseConnectionFactory.doConnect(BaseConnectionFactory.java:219)
at com.cloudera.impala.jdbc.common.AbstractDriver.connect(AbstractDriver.java:216)
at workbench.db.DbDriver.connect(DbDriver.java:513)
at workbench.db.ConnectionMgr.connect(ConnectionMgr.java:244)
at workbench.db.ConnectionMgr.getConnection(ConnectionMgr.java:172)
at workbench.gui.profiles.ConnectionGuiHelper$1.run(ConnectionGuiHelper.java:104)

 

 

I checked very worker node, did not see any errors in the Impala Daemon Logs.

 

 

Re: impala - kerberosed - jdbc connection from SQL Workbench on Windows

Guru

Hi,

 

Did you "kinit" as a valid user before attempting to connect impala on Windows?

Re: impala - kerberosed - jdbc connection from SQL Workbench on Windows

Contributor

Yes, I am KINITed. From the MIT Kerberos Desktop client, I can see both the Kerberos Tocket and the Windows Domain Account ticket. 

 

I also went to command prompt and verified that, C:\Program Files\MIT\Kerberos\bin\klist shows the ticket.

 

 

MIT_Ker.png

Re: impala - kerberosed - jdbc connection from SQL Workbench on Windows

New Contributor

Did you ever fix this issue? We have a similar sitation where impala/jdbc connections work for odbc and some users with jdbc. We have a few users that have this same problem with jdbc only and not sure what the difference is on thier connections. We've verified kinit and java versions are the same as for working users. So far a mystery. "[Simba][ImpalaJDBCDriver](500168) Error creating login context using ticket cache: Unable to obtain Principal Name for authentication.". From my test account, it works just fine, from many users it works but one user's account they get this error message.

Re: impala - kerberosed - jdbc connection from SQL Workbench on Windows

New Contributor


Hello, did you ever fix this issue?

[Simba][ImpalaJDBCDriver](500168)

Error creating login context using ticket cache: Unable to obtain Principal Name for authentication

Re: impala - kerberosed - jdbc connection from SQL Workbench on Windows

Contributor

We got ODBC Connection working with Kerberos. However, JDBC has issues identifying the Kerberos Principal. We thought about investigating the JDBC Connector source code, but other issues took priority.

 

I have heard from other Big Data Engineerins thru meetups, that JDBC only works with username-password. For which, we need to setup LDAP Authentication for Hive and Impala. Before which, we need to setup cross-realm trust between LDAP/Active Directory and Kerberos - which prooves to be a pain by itself. 

Re: impala - kerberosed - jdbc connection from SQL Workbench on Windows

Explorer

Hi,

 

We are facing the same issue while connecting through JDBC connection. Were you able to resolve the issue?

Please help me with your findings and resolution.

 

Error message: 

[Cloudera][HiveJDBCDriver](500168) Error creating login context using ticket cache: Unable to obtain Principal Name for authentication

 

 

Thanks in advance.

Re: impala - kerberosed - jdbc connection from SQL Workbench on Windows

Explorer

Hi,

 

I followed the following approaches after that:

  1. Deleted the KRB5CCNAME environment variable containing the path to the KerberosTickets.txt.
  2. Set up the Kerberos configuration file( krb5.ini) and  entered the values as per the krb5.conf file in the dev cluster node.
  3. Set up the JAAS login configuration file with the following fields:

Client {

com.sun.security.auth.module.Krb5LoginModule required

useKeyTab=false

principal=user@COMPANY.COM

doNotPrompt=true;

};

And set the environment variable java.security.auth.login.config to the location of the JAAS config file.

  • When I  tried connecting to hive in JAVA after making these changes, the connection was made successfully.
  • But when I  tried the same code in Rstudio, I  faced exception:
    • “Error in .jcall(drv@jdrv, "Ljava/sql/Connection;", "connect", as.character(url)[1],  : 

        java.sql.SQLException: [Cloudera][HiveJDBCDriver](500168) Error creating login context using ticket cache: Unable to obtain Principal Name for authentication .”

  • Also, I tried this code in R Console, but the following exception cropped up:

“java.sql.SQLException: [Cloudera][HiveJDBCDriver](500164) Error initialized or created transport for authentication: [Cloudera][HiveJDBCDriver](500169) Unable to connect to server: GSS initiate failed”

 

My understanding is that it is R is not able to get the environment variable path. correct me if i'm wrong.

I've seen many links in google but that didn't work.

 

I'm using 

Rconsole :3.4.1 and 

RStudio : version 1.1.353

 

Please suggest us how do we proceed further.

 

Thanks

Don't have an account?
Coming from Hortonworks? Activate your account here