Reply
Contributor
Posts: 27
Registered: ‎08-15-2016

impala - kerberosed - jdbc connection from SQL Workbench on Windows

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?

 

 

 

Cloudera Employee
Posts: 213
Registered: ‎03-23-2015

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

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
Posts: 27
Registered: ‎08-15-2016

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

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.

 

 

Cloudera Employee
Posts: 213
Registered: ‎03-23-2015

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

Hi,

 

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

Contributor
Posts: 27
Registered: ‎08-15-2016

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

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
Posts: 1
Registered: ‎12-03-2016

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

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
Posts: 1
Registered: ‎02-08-2017

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


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
Posts: 27
Registered: ‎08-15-2016

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

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. 

New Contributor
Posts: 1
Registered: ‎06-14-2017

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

[ Edited ]

hi @Diegolotr99
Did u fixed this issue?? im facing the same issue i cant find any solution..please help me...

Contributor
Posts: 42
Registered: ‎05-12-2016

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

Install JCE.

Announcements