Skip to Main Content

Java Security

Announcement

For appeals, questions and feedback about Oracle Forums, please email oracle-forums-moderators_us@oracle.com. Technical questions should be asked in the appropriate category. Thank you!

Kerberos Authentication fails two hours before TGT expires

843810Oct 23 2006 — edited Jan 4 2007
Hi,

We have implemented a Sinlge Sign On solution based on Kerberos and the Java GSS-API. The implementation pretty much follows the
examples given in the JAAS Tutorials. It is now running
in my company and it works fine except until there are less than two hours until your TGT expires. Then an exception is thrown
in the call to InitSecContext with the error "No valid credentials provided (Mechanism level: Attempt to obtain new INITIATE
credentials failed! (null))". Here is a transcript of the debug output:
Debug is  true storeKey false useTicketCache true useKeyTab false doNotPrompt true ticketCache is null KeyTab is null refreshKrb5Config is false principal is null tryFirstPass is false useFirstPass is false storePass is false clearPass is false
Acquire TGT from Cache
KinitOptions cache name is C:\Documents and Settings\PWL\krb5cc_pwl
Acquire default native Credentials
Obtained TGT from LSA: Credentials:
client=pwl@MACONOMY.COM server=krbtgt/MACONOMY.COM@MACONOMY.COM authTime=20061024024852Z startTime=20061024024852Z endTime=20061024124852Z renewTill=20061031024852Z flags: FORWARDABLE;RENEWABLE;INITIAL;PRE-AUTHENT EType (int): 23 Using builtin default etypes for default_tgs_enctypes default etypes for default_tgs_enctypes: 3 1 23 16 17.
CksumType: sun.security.krb5.internal.crypto.RsaMd5CksumType
EType: sun.security.krb5.internal.crypto.ArcFourHmacEType
KrbKdcReq send: kdc=dc2 UDP:88, timeout=30000, number of retries =3, #bytes=1307
KDCCommunication: kdc=dc2 UDP:88, timeout=30000,Attempt =1, #bytes=1307
KrbKdcReq send: #bytes read=1292
KrbKdcReq send: #bytes read=1292
EType: sun.security.krb5.internal.crypto.ArcFourHmacEType
Ticket could not be renewed : Message stream modified (41) Principal is null null credentials from Ticket Cache [Krb5LoginModule] authentication failed Unable to obtain Princpal Name for authentication GSSException: No valid credentials provided (Mechanism level: Attempt to obtain new INITIATE credentials failed! (null)) at sun.security.jgss.krb5.Krb5InitCredential.getTgtFromSubject(Unknown Source) at sun.security.jgss.krb5.Krb5InitCredential.getInstance(Unknown Source) at sun.security.jgss.krb5.Krb5MechFactory.getCredentialElement(Unknown Source) at sun.security.jgss.GSSManagerImpl.getCredentialElement(Unknown Source) at sun.security.jgss.GSSCredentialImpl.add(Unknown Source) at sun.security.jgss.GSSCredentialImpl.<init>(Unknown Source) at sun.security.jgss.GSSCredentialImpl.<init>(Unknown Source) at sun.security.jgss.GSSManagerImpl.createCredential(Unknown Source) at sun.security.jgss.GSSContextImpl.initSecContext(Unknown Source) at sun.security.jgss.GSSContextImpl.initSecContext(Unknown Source) at com.maconomy.gss.MKerberosSingleLoginCredentials.getTicket(MKerberosSingleLoginCredentials.java:102) at com.maconomy.gss.MKerberosSingleLoginCredentials.getTicket(MKerberosSingleLoginCredentials.java:30) at com.maconomy.client.portal.SingleLoginApplet$SingleLoginThread.run(SingleLoginApplet.java:97) Caused by: javax.security.auth.login.LoginException: Unable to obtain Princpal Name for authentication at com.sun.security.auth.module.Krb5LoginModule.promptForName(Unknown Source) at com.sun.security.auth.module.Krb5LoginModule.attemptAuthentication(Unknown Source) at com.sun.security.auth.module.Krb5LoginModule.login(Unknown Source) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at javax.security.auth.login.LoginContext.invoke(Unknown Source) at javax.security.auth.login.LoginContext.access$000(Unknown Source) at javax.security.auth.login.LoginContext$4.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.login.LoginContext.invokePriv(Unknown Source) at javax.security.auth.login.LoginContext.login(Unknown Source) at sun.security.jgss.LoginUtility.login(Unknown Source) at sun.security.jgss.krb5.Krb5Util.getTicketFromSubject(Unknown Source) at sun.security.jgss.krb5.Krb5InitCredential$1.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) ... 13 more
I've also used the Klist (Microsoft) tool to get information about the tickets and the information about the TGT looks like this:
Cached TGT:

ServiceName: krbtgt
TargetName: krbtgt
FullServiceName: pwl
DomainName: MACONOMY.COM
TargetDomainName: MACONOMY.COM
AltTargetDomainName: MACONOMY.COM
TicketFlags: 0x40e00000
KeyExpirationTime: 1/1/1601 2:00:00
StartTime: 10/24/2006 5:48:52
EndTime: 10/24/2006 15:48:52
RenewUntil: 10/31/2006 5:48:52
TimeSkew: 1/1/1601 2:00:00
Now we also have a C implemtation we use for our native Windows client, which uses the Microsoft version of GSS (SSPI),
and it works fine, so the problem must be connected to the Java implementation. I've used Ethereal to find out what happens
when login fails and I can see that two requests are send to the KDC and that the last one is a request for the renewal of the TGT.
The replies from the KDC looks fine and doesn't contain any error messages.

If anyone has an idea as to what is causing this problem I would be very grateful. I should mention that the KDC is Active Directory
running on a Windows 2003 server, and that we use JRE version 1.5_08. We haven't changed the default parameters in AD, so the default life time for a TGT is 10 hours.

Message was edited by:
peter_waern

Message was edited by:
peter_waern stack traces updated
peter_waern
Comments
Locked Post
New comments cannot be posted to this locked post.
Post Details
Locked on Feb 1 2007
Added on Oct 23 2006
6 comments
2,297 views