Support Questions

Find answers, ask questions, and share your expertise

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

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.

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.

 

 

Guru

Hi,

 

Did you "kinit" as a valid user before attempting to connect impala 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

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.

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

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. 

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.

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

Rising Star

Do you have JCE installed in you system?

Explorer
As I mention JASS config approach is working for me from Java code.
Problem I am facing from R Code JCE is install on my machine still i am not able to connect from R.
Could anyone help on the same

Rising Star

Do you connect from Windows or Linux box?

 

Are you sure that you have valid kerberos ticket on your machine? Could you run klist, please?

 

If you want to use jaas they config should more like this:

 

Client {
com.sun.security.auth.module.Krb5LoginModule required
useKeyTab=true
keyTab="PathToTheKeyTab"
principal="cloudera@CLOUDERA"
doNotPrompt=true;
};

 

Explorer

Hi,

 

We're trying to connect from windows machine. We have a valid ticket listed from klist. The error we are getting from rstudio is :

“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 .”

Rising Star

Could you show me the output of the klist command, please?

 

Where do you cache kerberos tickets? Do you have env variable to set this up?

Explorer

Hi,

 

I'm not able to klist now. After i run kdestroy -a and then i generate a ticket, the ticket is created successfully but the the ticket is not displayed through klist and the error happens to be the same. 

Rising Star
If you can not klist then sth is wrong. Do you have environment varialbe that points to kerberos cache path?

Explorer

Hi,

 

Just wanted to add a point: after kinit the ticket is generated succefully. It is shown in the MIT Kerberos Ticket Manager but it is not viewed in klist. We're following this link: https://www.cloudera.com/documentation/other/connectors/hive-jdbc/latest/Cloudera-JDBC-Driver-for-Ap...

 

Just few things:

1) Set an environment variable that points to kerberostickets.txt

After it didn't work:

1) Removed the environment variable and followed the next step of JAAS conf. This led to successful hive connectivity through java but in R we're getting the error

2) After running kdestroy, and then kinit. The klist does not give anything. It gives null or empty. Now unable to run it through java too. 

2) Set the environment variable again to point to CredentialCache file. It again gives empty klist.

This is in Windows machine

 

Rising Star
Do you have KRB5CCNAME in your system right now or not?

Explorer

Yes we have the environment variable set:

KRB5CCNAME: C:\KerberosTickets.txt

 

We also tried removing it for the JAAS conf requirement.

We have the env variable set currently

Explorer

Hi,

 

We added the path of CacheCredential in JAAS file and then re-run the R script by setting the the environment variable of JAAS file in R

Now we're running into following error:

Error in .jcall(drv@jdrv, "Ljava/sql/Connection;", "connect", as.character(url)[1], : 
  java.sql.SQLException: [Cloudera][HiveJDBCDriver](500164) Error initialized or created transport for authentication: [Cloudera][HiveJDBCDriver](500169) Unable to connect to server: GSS initiate failed.

 

GSS initiated failed. I've JCE installed

Take a Tour of the Community
Don't have an account?
Your experience may be limited. Sign in to explore more.