Created 04-30-2024 07:24 AM
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.
Created 05-01-2024 04:50 AM
Regards,
Chethan YM
Created 05-08-2024 02:43 PM
For doc purpose and if it could be helpful to someone
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.
Created 05-01-2024 04:50 AM
Regards,
Chethan YM
Created 05-01-2024 05:15 PM
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!!!
Created 05-02-2024 01:09 PM
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.
Created 05-08-2024 02:43 PM
For doc purpose and if it could be helpful to someone
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.