Support Questions

Find answers, ask questions, and share your expertise

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

avatar
Contributor

Hello my client is a WIN server 2019, setup outbound Kerberos only, I have enabled WIN registry keys for TGT Session sharing, environment var pointing to CDP JARS, CONFIG paths and default Java_Home to the bundled Zulu private JRE which these days is using Java 11 and comes with unlimited strength JCE (per provider).  I could do kinit and receive klist.  

SAS is the application.  I have setup the CDP JDBC URI provided by CDP team and trustore w credentials.

I have not done krb5.ini, nor jaas config, nor pointed the env variable java.security.auth.login.config to jaas config.

I get this error:

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

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

I researched here and some questions are around 2017-18 and community manager responded to another user to start a new question, hence my question here.  

Thank you in advance for your time and suggestions.

 

 

2 ACCEPTED SOLUTIONS

avatar
Master Collaborator

@rsheikh 

  • Ensure that the Kerberos configuration (krb5.ini) is correctly set up on your Windows Server 2019 machine. The krb5.ini file should contain the necessary realm and KDC (Key Distribution Center) information for your Kerberos setup.
  • Set the java.security.auth.login.config environment variable to point to the JAAS (Java Authentication and Authorization Service) configuration file (jaas.conf). This file defines the login modules used for authentication.
  • Verify that the realm and principal settings in krb5.ini match the configuration of your Kerberos environment.

 

Regards,

Chethan YM

View solution in original post

avatar
Contributor

For doc purpose and if it could be helpful to someone

  1. We took krb5.ini that was used at the CDP cluster and saved it to client WIN server
  2. We used LogLevel=6 LogPath=<some-path> in our jdbc URI to enable trace level log

Based on findings from the trace level logs java.security.auth.login.config was pointing to an incorrect login module.  Since we turned on memory based cache, removing pointer to the java.security.auth.login.config forced correct tgt ticket to be picked.  We did not opt for a custom jaas.conf either.

There were minor tweak of domain & realm value.

This resolved our issue.

View solution in original post

4 REPLIES 4

avatar
Master Collaborator

@rsheikh 

  • Ensure that the Kerberos configuration (krb5.ini) is correctly set up on your Windows Server 2019 machine. The krb5.ini file should contain the necessary realm and KDC (Key Distribution Center) information for your Kerberos setup.
  • Set the java.security.auth.login.config environment variable to point to the JAAS (Java Authentication and Authorization Service) configuration file (jaas.conf). This file defines the login modules used for authentication.
  • Verify that the realm and principal settings in krb5.ini match the configuration of your Kerberos environment.

 

Regards,

Chethan YM

avatar
Contributor

Dear @chethan, much thanks for the reply.  I am using Kerberos outbound only setup and I have followed all steps including registry key change to allow TGTSession sharing (WIN Memory).  I have not se any jaas.conf.  The examples I find use file based cache.  Also, below is a debug output of what the session sees:

get normal credential
>>> KrbCreds found the default ticket granting ticket in credential cache.
Java config name: null
Native config name: C:\Windows\krb5.ini
Loaded from native config
>>> Obtained TGT from LSA: Credentials:
client=demo@DC1.PW.ORG
server=krbtgt/DC1.PW.ORG@DC1.PW.ORG
authTime=20240425145720Z
startTime=20240425145720Z
endTime=20240426005720Z
renewTill=null
flags=INITIAL;PRE-AUTHENT

Question, when I go to C:\Windows\krb5.ini (of demo user) there is no such file,  how should I interpret this?

#2 all jaas config sample I see are pointing to file-based cache or where IWA is enabled.  I have not, what I have done is enabled WIN memory sharing of the TGT ticket, enabled unconstrained delegation, ensure all steps & settings nuances for a WIN are placed.

I do appreciate the help!!!

avatar
Contributor

update: I have made some progress, placed the krb5.ini file.  Currently at:

 ERROR: Caused by: com.cloudera.hiveserver2.support.exceptions.GeneralException: [Cloudera][HiveJDBCDriver](500168) Error creating 
login context using ticket cache: Unable to obtain Principal Name for authentication .
ERROR: ... 12 more
ERROR: Caused by: javax.security.auth.login.LoginException: Unable to obtain Principal Name for authentication

 May I get an example of a jaas.conf file I did find some using keytab etc while my setup is memory based sharing of tgt tickets.  I appreciate your time.

Thank you in advance.

avatar
Contributor

For doc purpose and if it could be helpful to someone

  1. We took krb5.ini that was used at the CDP cluster and saved it to client WIN server
  2. We used LogLevel=6 LogPath=<some-path> in our jdbc URI to enable trace level log

Based on findings from the trace level logs java.security.auth.login.config was pointing to an incorrect login module.  Since we turned on memory based cache, removing pointer to the java.security.auth.login.config forced correct tgt ticket to be picked.  We did not opt for a custom jaas.conf either.

There were minor tweak of domain & realm value.

This resolved our issue.