GSSContext with null SrcName

Question

I\'m working a web appliaction with SSO based on the Windows domain login, for this purpose I have chosen to validate Kerberos tickets. But now I\'m facing a problem for whi

Answer 1

I faced the same Checksum failed error when implementing my GSSAPI socket demo that is a modification of the Oracle GSSAPI tutorial code. I executed my code on a Linux machine enrolled into a FreeIPA kerberos realm. I have used the vanilla krb5.conf file of my Linux system. No constraints on ticket etype are there:

...
[libdefaults]
  default_realm = AUTHDEMO.IT
  dns_lookup_realm = true
  dns_lookup_kdc = true
  rdns = false
  ticket_lifetime = 24h
  forwardable = true
  udp_preference_limit = 0 
...

The FreeIPA realm default is to use type 18 tickets (AES-256).

About my application, it has this policy file configured:

grant CodeBase "file:./app.jar" {
        permission java.security.AllPermission;
};

grant CodeBase "file:./app.jar" 
    Principal javax.security.auth.kerberos.KerberosPrincipal 
        "servicename@AUTHDEMO.IT" {

    permission java.net.SocketPermission "*", "accept";

    permission javax.security.auth.kerberos.ServicePermission
        "servicename@AUTHDEMO.IT", "accept";
};

When executing the application I got this error on the acceptor side:

GSSException: Failure unspecified at GSS-API level (Mechanism level: Encryption type AES256CTS mode with HMAC SHA1-96 is not supported/enabled)

In my case the error arises in the GSS acceptor side. In my application I generate the Jaas configuration programmatically (I'll refer at this as DConfig) and I don't use a config file. The first solution, I found, is to use config files instead of DConfig and the problem disappeared, it worked fine. The temporary solution, Jaas Config file:

DemoServer {
  com.sun.security.auth.module.Krb5LoginModule required
   principal="servicename@AUTHDEMO.IT"
   storeKey=true
   debug=true; #not mandatory
};

With this configuration, no problem arises on the acceptor side and the application were able to check the service ticket validity and accept the connection.

I asked myself.. WHY?

I checked differences in the Subject(s) acquired with the two configurations. In the working case, with the config file, the subject contains, into the private credentials, both the password hashes credentials and the principal TGT ticket. With DConfig, I obtain a Subject with only password hashes but there is no principal TGT ticket in private credentials.

My fix

DConfig contains the same settings of the configuration file and the other options are the replica of Krb5LoginModule defaults, at first I cannot see a reason for the misbehaviour.

Setting isInitiator = true, into the acceptor side DConfig, solved the issue. `isInitiator = true has forced the persistence of TGT ticket into the subject.

With this workaround the error has disappeared with no change into the system krb5.conf.

My cent is... after Jaas login, let's check your subject private credentials for lacking creds (You need the service principal TGT into your acceptor side subject!) and in case try to set isInitiator = true to the acceptor side too.

Regards