FULL PRODUCT VERSION :
java version "1.5.0_06"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-b05)
Java HotSpot(TM) Client VM (build 1.5.0_06-b05, mixed mode, sharing)

and

java version "1.6.0-beta"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.6.0-beta-b59g)
Java HotSpot(TM) Client VM (build 1.6.0-beta-b59g, mixed mode, sharing)


ADDITIONAL OS VERSION INFORMATION :
Linux padwad-fc4a.ny.eq.gs.com 2.6.15-1.1833_FC4smp #1 SMP Wed Mar 1 23:56:51 EST 2006 i686 i686 i386 GNU/Linux


A DESCRIPTION OF THE PROBLEM :
If you have multiple TGTs in your Kerberos credentials cache (after having done a cross-realm authentication from native code), Java reads the wrong credential from the cache.   This results in no Kerberos operations being able to work.

The bug is in the getDefaultCreds() method of sun.security.krb5.internal.cache.   Note that cache is searched backwards (from list.length-1 to 0).   If it were simply searched forwards (from 0 to list.length-1) it would work, although it would still be Wrong.  Correct behavior would be to look for the proper credential (which means the function would have to take a realm as an argument), or at least a krbtgt whose subject and host realms matched.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :

  To reproduce, kinit in one realm (eg ALPHA.COM).  You'll get a TGT of the form krbtgt/###@###.### for principal ###@###.###.   If you try to use Java's Kerberos as a client, it can Do The Right Thing.

Now, from native code, access a resource in another realm (eg BETA.COM) with a native executable (eg rlogin).   Your credentials cache will now have three entries:
krbtgt/###@###.### - the main one
krbtgt/###@###.### - the cross-realm chain TGT
host/###@###.### - the service ticket

Now the kicker - at this point, no Java kerberos operations will work, even within the ALPHA.COM realm.   Why?   Because for some bizarre reason it looks for the last ticket in your cache that starts "krbtgt", and thus picks up the cross-realm chain TGT instead of your main one.


EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Java kerberos should still work if you have a cross-realm TGT in your cache in addition to your main one
ACTUAL -
Java kerberos doesn't work

ERROR MESSAGES/STACK TRACES THAT OCCUR :
GSSException: No valid credentials provided (Mechanism level: Failed to find any Kerberos Ticket)
        at sun.security.jgss.krb5.Krb5InitCredential.getInstance(Krb5InitCredential.java:133)
        at sun.security.jgss.krb5.Krb5MechFactory.getCredentialElement(Krb5MechFactory.java:72)
        at sun.security.jgss.GSSManagerImpl.getCredentialElement(GSSManagerImpl.java:149)
        at sun.security.jgss.GSSCredentialImpl.add(GSSCredentialImpl.java:389)
        at sun.security.jgss.GSSCredentialImpl.<init>(GSSCredentialImpl.java:60)
        at sun.security.jgss.GSSManagerImpl.createCredential(GSSManagerImpl.java:108)


REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
I can distill a small test case if it would help, but since it is dependent on having multiple linked Kerberos realms, I'm not sure if it would help you
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
None available