impala-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sailesh Mukil <>
Subject Re: Using JDBC with Impala, Kerberos and Sentry
Date Wed, 12 Jul 2017 17:25:01 GMT
> "When using the Cloudera driver does it successfully connect with other

Do you mean 'KrbServiceName' ? Or do you mean the client principal, i.e.
whatever you kinit-ed with?

With the Cloudera JDBC driver, kinit-ing with a non-impala principal:
kinit systest

and using the following jdbc string works fine for me:

Looking at the logs of [HOST], I see the following:

I0710 22:36:23.381333 16462] Successfully
authenticated client user "systest@[REALM]"
So, it does work with other client principals than 'impala'.

Unfortunately, I've not used the Hive JDBC driver, so I don't have the
required knowledge to comment on that.

On Tue, Jul 11, 2017 at 4:03 PM, Russell Harlin <> wrote:

> Hi Sailesh,
> Thanks, for the response.
> Just for reference, I'm actually using the Hive JDBC driver, rather than
> the Cloudera JDBC driver.  As you mentioned, I've been able to get it to
> attempt with different credentials by running kinit before my application.
> The issue that I'm having is that if I use any principal other than the one
> the impalad daemon was started with, it won't successfully connect.  I get
> a Kerberos auth error.  I'm guessing this is a known limitation, as it
> mentions the following in the docs with respect to the krb principal used
> for the JDBC connection: "The principal must be the same user principal you
> used when starting Impala." (From:
> documentation/enterprise/5-10-x/topics/impala_jdbc.html#jdbc_connect).  I
> did just notice that this limitation is only in the "Using the Hive JDBC
> Driver" section and not the "Using the Cloudera JDBC Connector" section.
> Perhaps this this only a limitation for the Hive JDBC driver?  When using
> the Cloudera driver does it successfully connect with other principals?
> Thanks again,
> Russell
> On Mon, Jul 10, 2017 at 11:01 PM, Sailesh Mukil <>
> wrote:
>> Hi Russell,
>> Did you happen to look at the 'KrbAuthType' from Page 86 in the docs?
>> impala-jdbc/latest/Cloudera-JDBC-Driver-for-Impala-Install-Guide.pdf
>> If you don't specify the KrbAuthType, it would look for the principal
>> in the following order (pasting from the doc):
>> 1. First, the driver tries to obtain the Subject from the current
>> thread's inherited AccessControlContext. If the AccessControlContext
>> contains multiple Subjects, the driver uses the most recent Subject.
>> 2. If the first method does not work, then the driver checks the
>> system property for a JAAS
>> configuration. If a JAAS configuration is specified, the driver uses
>> that information to create a LoginContext and then uses the Subject
>> associated with it.
>> 3. If the second method does not work, then the driver checks the
>> KRB5_CONFIG and KRB5CCNAME system environment variables for a Kerberos
>> ticket cache. The driver uses the information from the cache to create
>> a LoginContext and then uses the Subject associated with it.
>> In the default case, when you don't have a JAAS conf file, I've
>> noticed that it picks the last kinit-ed user from the kerberos
>> credential cache (step 3) and uses that as the client principal (i.e.
>> the principal you're connecting as). Note that the 'KrbServiceName' is
>> the service principal name of the Impala server and not of the client.
>> Eg:
>> kinit foo
>> <Run JDBC app>
>> In the above case, 'foo' will be used as the client principal and will
>> be used against all the Sentry authorization checks.
>> On Wed, Jun 21, 2017 at 10:04 AM, Russell Harlin <>
>> wrote:
>> >
>> > Hi,
>> >
>> > Based on the Impala documentation, it seems like it's required that
>> JDBC connections use the same Kerberos principal used to start the impalad
>> daemon.  This seems to work fine for me.  My questions is, though, if I
>> also want to use Sentry authorization how does impala distinguish users,
>> since they're all using the same Kerberos principal?  Do we have to pass in
>> the desired user to the JDBC connection?  Does this mean that we have to
>> enable AD as well or can we use local users?
>> >
>> > Thanks,
>> >
>> > Russell

View raw message