How to get renewable kerberos tickets using java GSS + JAAS

Question

I am using jTDS to connect to SQLServer. Inside jTDS uses GSS to get the kerberos service ticket and create a secure context. Since my application has been living for a long time, and my connections are maintained for the whole time when I need the kerberos service ticket to be renewable in order to allow the SQL server to update them myself (in accordance with kdc policies, all tickets expire after 12 hours).

What jTDS does to get the kerberos token (more or less):

GSSManager manager = GSSManager.getInstance(); // Oids for Kerberos5 Oid mech = new Oid("1.2.840.113554.1.2.2"); Oid nameType = new Oid("1.2.840.113554.1.2.2.1"); // Canonicalize hostname to create SPN like MIT Kerberos does GSSName serverName = manager.createName("MSSQLSvc/" + host + ":" + port, nameType); GSSContext gssContext = manager.createContext(serverName, mech, null, GSSContext.DEFAULT_LIFETIME); gssContext.requestMutualAuth(false); gssContext.requestCredDeleg(true); byte[] ticket = gssContext.initSecContext(new byte[0], 0, 0); 

I suspect that the ticket I receive is not renewable. I check this by doing the following:

 ExtendedGSSContext extendedContext = (ExtendedGSSContext) gssContext; boolean[] flags = (boolean[]) extendedContext.inquireSecContext(InquireType.KRB5_GET_TKT_FLAGS); System.out.println("Renewable = " + flags[8]); 

In our specific configuration, GSS gets the kerberos TGT from the JAAS login module. We have the following set of variables: false -Djavax.security.auth.useSubjectCredsOnly=false , and the following login module is installed in the login.cfg file:

 com.sun.security.jgss.krb5.initiate { com.sun.security.auth.module.Krb5LoginModule required useKeytTab=true keyTab="/home/batman/.batman.ktab" principal=" [e-mail] " storeKey=true doNotPrompt=true debug=false }; 

Another thing I notice is that the getLifetime() GSSContext does not work. It always returns 2147483647 (max int) no matter what the real life time of the ticket is.

I feel comfortable with the jTDS branching driver, so I can change the way it sets the GSS context if necessary.

What I tried:

Use your own implementation of GSS api:

This is great for me in terms of getting renewable tickets, but it poses another set of problems (in terms of ensuring the correct set of ticket cache and proper ticket updates). If I can get around this option, it would be nice. As I observe here, the getLifetime() method actually returns the real life time in seconds of the ticket.

Repeated execution of KerberosLoginModule:

Based on the answer to this question Jaas - Request for renewable Kerberos tickets I re-executed LoginModule to install RENEW KDCOption in KrbAsReqBuilder before requesting TGT. This works great in the sense that I get a renewable TGT, but the ticket received from that TGT GSS is still not renewable. If I set a breakpoint in the constructor of the KDCOption object and set the RENEW flag manually for every request (even KrbTgsReq made by GSS), it works, but for this change to take place, it requires a serious rewrite to GSS, which I don’t feel comfortable with.

Answer 1

For administrators, the fact that Kerberos tickets have a lifetime is an important security feature. The user knows the password, so he can get a new ticket at any time. But for an attacker, this is a problem - after the ticket expires, it cannot be used to crack the system. Administrators want this lifetime to be as short as possible, but not too short (for example, 1 hour), because users would generate as many as 10x more login requests than now, and it would be difficult to handle ActiveDirectory.

When we need to authenticate with Kerberos, we need to use the connection pool (and DataSource). To use this function in jTDS, you need to add ConnectionPoolImplementation (recommended: DBCP or c3p0, see http://jtds.sourceforge.net/features.html ).

If you want to write your application using an older way of connecting to a database (without a data source, that is, creating a connection and saving it, because it is expensive to create ..), the next hurdle will be "extend the life of the device." In ActiveDirectory, Kerberos tickets can be renewed by default for 7 days. In AD, there is a global setting that allows you to set 0 there (indefinite extension of the service life), but you will need to convince the domain administrator to reduce the security of the entire domain only because one service will not work without it.