Skip to main content
rsheikh
rsheikh
Gold ⭐️
April 30, 2024
Solved

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

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.

 

 

rsheikh
rsheikhAnswer
Gold ⭐️
May 8, 2024

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 in thread

4 replies

ChethanYM
Gold ⭐️
ChethanYM
Gold ⭐️
May 1, 2024

@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

Translate
    rsheikh
    rsheikhAuthor
    Gold ⭐️
    May 2, 2024

    Dear @Former Member, 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!!!

    Translate
      rsheikh
      rsheikhAuthor
      Gold ⭐️
      May 2, 2024

      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.

      Translate
        rsheikh
        rsheikhAuthorAnswer
        Gold ⭐️
        May 8, 2024

        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.

        Translate
        Terms & ConditionsAccessibility statement