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: https://www.cloudera.com/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 <[email protected]> wrote: > Hi Russell, > > Did you happen to look at the 'KrbAuthType' from Page 86 in the docs? > https://www.cloudera.com/documentation/other/ > connectors/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 > java.security.auth.login.config 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 <[email protected]> > 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 >
