Home.... | log in.... | Pub my question! | Sign-up....
Java-index >> Security >> Kerberos & Java GSS (JGSS)

Kerberos Authentication fails two hours before TGT expires

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 istrue storeKeyfalse useTicketCachetrue useKeyTabfalse doNotPrompttrue ticketCache isnull KeyTab isnull refreshKrb5Config isfalse principal isnull tryFirstPass isfalse useFirstPass isfalse storePass isfalse clearPass isfalse

Acquire TGT from Cache

>>>KinitOptions cache name is C:\Documents and Settings\PWL\krb5cc_pwl

>> Acquiredefaultnative 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 builtindefault etypesfor default_tgs_enctypes

default etypesfor 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 isnull

null credentials from Ticket Cache

[Krb5LoginModule] authentication failed

Unable to obtain Princpal Namefor authentication

GSSException: No valid credentials provided (Mechanism level: Attempt to obtainnew 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 Namefor 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

[7092 byte] By [peter_waerna] at [2007-10-3 8:00:35]
«« P2P media streaming
»» Calendar HOUR_OF_DAY
# 1

Hi again,

In connection with changing from daylight saving time I found out some more about this problem.

It seems like the Java interpretation of the TGT expiration time is dependent on the time zone of the client computer.

I set up my Active Directory to have a service ticket lifetime of 4 hours and then tried to change the

time zone on my client computer with the following results:

GMT+01:00

TGT information from klist.exe:

ServiceName: krbtgt

TargetName: krbtgt

FullServiceName: pwaern

DomainName: EXAMPLE.MAC

TargetDomainName: EXAMPLE.MAC

AltTargetDomainName: EXAMPLE.MAC

TicketFlags: 0xe00000

KeyExpirationTime: 1/1/1601 1:00:00

StartTime: 11/1/2006 10:20:22

EndTime: 11/1/2006 14:20:22

RenewUntil: 11/8/2006 10:20:22

TimeSkew: 1/1/1601 1:00:00

Java 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\pwaern\krb5cc_pwaern

>> Acquire default native Credentials

>>> Obtained TGT from LSA: Credentials:

client=pwaern@EXAMPLE.MAC

server=krbtgt/EXAMPLE.MAC@EXAMPLE.MAC

authTime=20061101082022Z

startTime=20061101082022Z

endTime=20061101122022Z

renewTill=20061108082022Z

flags: RENEWABLE;INITIAL;PRE-AUTHENT

EType (int): 3

Principal is pwaern@EXAMPLE.MAC

Commit Succeeded

Found ticket for pwaern@EXAMPLE.MAC to go to krbtgt/EXAMPLE.MAC@EXAMPLE.MAC expiring on Wed Nov 01 13:20:22 CET 2006

[...]

GMT+03:30

TGT information from klist.exe:

ServiceName: krbtgt

TargetName: krbtgt

FullServiceName: pwaern

DomainName: EXAMPLE.MAC

TargetDomainName: EXAMPLE.MAC

AltTargetDomainName: EXAMPLE.MAC

TicketFlags: 0xe00000

KeyExpirationTime: 1/1/1601 3:30:00

StartTime: 11/1/2006 12:41:02

EndTime: 11/1/2006 16:41:02

RenewUntil: 11/8/2006 12:41:02

TimeSkew: 1/1/1601 3:30:00

Java 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\pwaern\krb5cc_pwaern

>> Acquire default native Credentials

>>> Obtained TGT from LSA: Credentials:

client=pwaern@EXAMPLE.MAC

server=krbtgt/EXAMPLE.MAC@EXAMPLE.MAC

authTime=20061101054102Z

startTime=20061101054102Z

endTime=20061101094102Z

renewTill=20061108054102Z

flags: RENEWABLE;INITIAL;PRE-AUTHENT

EType (int): 3

Principal is pwaern@EXAMPLE.MAC

Commit Succeeded

Found ticket for pwaern@EXAMPLE.MAC to go to krbtgt/EXAMPLE.MAC@EXAMPLE.MAC expiring on Wed Nov 01 13:11:02 IRST 2006

[...]

GMT-08:00

TGT information from klist.exe:

ServiceName: krbtgt

TargetName: krbtgt

FullServiceName: pwaern

DomainName: EXAMPLE.MAC

TargetDomainName: EXAMPLE.MAC

AltTargetDomainName: EXAMPLE.MAC

TicketFlags: 0xe00000

KeyExpirationTime: 0/41/4 0:00:10776

StartTime: 11/1/2006 1:16:56

EndTime: 11/1/2006 5:16:56

RenewUntil: 11/8/2006 1:16:56

TimeSkew: 11/8/2006 1:16:56

Java 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\pwaern\krb5cc_pwaern

>> Acquire default native Credentials

>>> Obtained TGT from LSA: Credentials:

client=pwaern@EXAMPLE.MAC

server=krbtgt/EXAMPLE.MAC@EXAMPLE.MAC

authTime=20061101171759Z

startTime=20061101171759Z

endTime=20061101181759Z

renewTill=20061108171656Z

flags: RENEWABLE;PRE-AUTHENT

EType (int): 3

Principal is pwaern@EXAMPLE.MAC

Commit Succeeded

Found ticket for pwaern@EXAMPLE.MAC to go to krbtgt/EXAMPLE.MAC@EXAMPLE.MAC expiring on Wed Nov 01 10:17:59 PST 2006

[...]

As you can see the exiration time found by the Java application is highly dependent on the time zone.

I should add that if you are at GMT the Java expiration time matches the one from klist.exe.

So clearly there is a problem somewhere.

The question is whether it is something in my setup or it is a bug in either Active Directory or Java. Can anyone help?

Thanks,

peter_waerna at 2007-7-15 3:03:52 > top of Java-index,Security,Kerberos & Java GSS (JGSS)...
# 2

What version of JDK are you using ?

The native Kerberos time in the Kerberos ticket, which is different from

what you see in the native ticket cache via the MS Klist tool, is a known issue,

and is seen in non GMT time zone only. This has been fixed in Java SE 6, and

JDK 5.0 Update release. Please download the latest JDK release.

Seema

Seema-1a at 2007-7-15 3:03:52 > top of Java-index,Security,Kerberos & Java GSS (JGSS)...
# 3

> What version of JDK are you using ?

>

> The native Kerberos time in the Kerberos ticket,

> which is different from

> what you see in the native ticket cache via the MS

> Klist tool, is a known issue,

> and is seen in non GMT time zone only. This has been

> fixed in Java SE 6, and

> JDK 5.0 Update release. Please download the latest

> JDK release.

>

> Seema

Thank you for the reply.

Is there a bug report for this bug?

I've searched the bug database several times but haven't found anything that resembled my problem.

Anyway, I was using JDK 1.5_06 for the examples above but I've seen the same in 1.5_08.

I have now installed the JDK 5.0 Update 9, but it unfortunately it doesn't seem to change anything either.

So should I do something special when upgrading in order to get the bugfix?

Or is it perhaps not the same bug?

peter_waerna at 2007-7-15 3:03:52 > top of Java-index,Security,Kerberos & Java GSS (JGSS)...
# 4
This issue has been fixed in the next JDK 5.0 Update release, which should be available soon.Seema
Seema-1a at 2007-7-15 3:03:52 > top of Java-index,Security,Kerberos & Java GSS (JGSS)...
# 5
Sounds great. Thanks a lot./Peter
peter_waerna at 2007-7-15 3:03:52 > top of Java-index,Security,Kerberos & Java GSS (JGSS)...
# 6
Just an update. I've installed the 1.5_10 update and it solved the problem.
peter_waerna at 2007-7-15 3:03:52 > top of Java-index,Security,Kerberos & Java GSS (JGSS)...
Security
Kerberos & Java GSS (JGSS)

Security New Topic

Security Hot Topic

Security

All Classified