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