Java client and Kerberos / SSO - Krb5LoginModule - not re-using tickets

Question

I'm running JMeter which depends on JDK 1.8's Krb5LoginModule.

It seems to me that the Krb5LoginModule can't maintain a kerberos session across multiple requests. This results in a HTTP 401 and renewed handshaking before every request.

I'm trying to reproduce a production environment which has severe intermittent performance issues and I would like to include the Kerberos / SSO authentication in my testing but I can't set it up to run like the Windows clients that use my REST server.

The REST server provides data to hundreds of Excel add-in clients, which are set up to authenticate with Kerberos. In the access logs, I see each client initially triggers an HTTP status 401 response, followed by a 200, and further 200s for the duration of the client's activity.

Just to avoid confusion, the server is handling the Kerberos hand-shaking and is NOT using servlet container sessions.

When my test runs though, I see that every request is rejected by a 401 from the server, Java goes off to the Kerberos KDC to get another ticket, and then resubmits it. While this works, my KDC server can't handle more than a couple of requests every second and times out the requests, so I can't ramp up my load test very much.

So why isn't Krb5LoginModule keeping the kerberos ticket it gets from the KDC and pre-authenticating every call, like Excel does?

This is what I've tried for the config:

JMeter {
    com.sun.security.auth.module.Krb5LoginModule required
        useTicketCache=true
        ticketCache="FILE:krb.cache"
        useKeyTab=true
        keyTab="FILE:krb.keytab"
        storeKey=true
        principal="-tsk-thing-ldap-dev@DO.AD.DUM.COM"
        debug=true;
};

I've tried with keytabs and without, with ticket caching and without. I hope I'm just doing the config wrong, but I can't see how.

This is what I'm basing my assumption on: Oracle: Single sign-on using Kerberos

and the API: Krb5LoginModule - Oracle JDK 1.8 API docs

score 0 · Answer 1 · answered May 17 '17 at 04:38

0

I don't think you need the quotation marks around paths and this FILE: bit is not required as well, like:
```
ticketCache=/path/to/your/krb.cache
```
Why you are using both ticket cache and keytabs, one should be enough (unless you need to test fallback scenario)
What operating system you are using?

I recall solving the problem with something like:

com.sun.security.jgss.krb5.initiate {
    com.sun.security.auth.module.Krb5LoginModule required
    debug=true
    doNotPrompt=true
    useTicketCache=true        
};

And setting the following registry key (Windows 7)

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\Kerberos\Parameters
Value Name: allowtgtsessionkey
Value Type: REG_DWORD
Value: 0x01  ( default is 0 )

References:

answered May 17 '17 at 04:38

Dmitri T

159,985
5
83
133

"... provides data to hundreds of Excel add-in clients, which are set up to authenticate with Kerberos.." - if the clients close their connection and on a new request the clients don't provide the authorization header, it starts all over. The clients need to cache the connection and/or to keep the connection open. I have a bad feeling that JMeter closes the connection after each request – gusto2 May 17 '17 at 06:55
This is on linux. What would be the equivalent config for that registry setting? "Allowing the target session key" to do what? – Adam May 17 '17 at 10:03
@gusto2 surely keeping the connection alive or closing it is irrelevant, it's the header with the auth ticket that is important. Krb5LoginModule only provides it on the first request after the 401, and then next time it forgets it again. I guess I could use keep-alive in JMeter, but then I won't be truly replicating the prod environment. – Adam May 17 '17 at 10:07
We were using JMeter for some IAM testing but as far I remember the JMeter simply resent the Authorization header in subsequent requests :( – gusto2 May 17 '17 at 10:45

Fabiano Tarlao · Answer 2 · 2017-08-16T16:56:16.767

Jaas is not going to persist the ticket into the cache, it is only able to acquire already saved tickets. More info in my question/answer here

You need to use kinit tool (bundled with Java distribution or the Linux tool) in order to persist tickets into a cache file, you can also rewrite your own Krb5LoginManger in order to perform this (hard way).

But I suppose there is something broken in the Adam workflow, in my understating of GSS, for the same session, both server and client, have to refer always to the same GSSContext object that they created during initialization.

score 0 · Answer 3 · edited Nov 21 '21 at 20:12

You must divide your issue to 2 parts.

infinite TGT. If you use native jaas so this module ignores Linux or Windows gss library and tries to re-initiate using keytab defined in jaas.conf. For KDC it means DDoS. If you use your application like gateway between user and target service so your service becomes intermediate initiator and it needs to re-initiate own TGT for TGS. It can be solved by adding useTicketCache to jaas.conf. However it doesn't solve TGS DDoS -> TGS amount can be much more than TGT.
infinite TGS. Oracle wrote native library for own ecosystem and they aren't interested of your optimization. If you want one ticket per day - pay Oracle to develop exclusive library. However there is classic lifehack that break Oracle weather by the way there is on Oracle doc website. It's called native JGSS over external MIT/MS Kerberos gss library.

You only need to add 2 -D arguments after java command or to use JAVA_OPTS

https://docs.oracle.com/en/java/javase/15/security/jaas-authentication.html#GUID-EF86E769-AFAF-4341-B9B0-4E122A0BFCEC

Java client and Kerberos / SSO - Krb5LoginModule - not re-using tickets

3 Answers3