Name: nt126004 Date: 07/17/2002


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

FULL OPERATING SYSTEM VERSION :Microsoft Windows 2000
[Version 5.00.2195]


A DESCRIPTION OF THE PROBLEM :
I am using the GSS examples provided by Sun to connect to
the default KDC installed on the Windows 2000 domain
controller. Everything seems to run fine if I dont have the
useTicketCache flag set in the client login configuration.
However if I set the useTicketCache flag to "true" in the
login configuration file (to achieve single sign on), the
the application crashes with an error dialog with the
following text:
C:\WINNT\system32\ntvdm.exe
Error while setting up environment for the application.
Choose "Close" to terminate he application.
This box has "Close" and "ignore" buttons. Choosing any one
of them causes the client to output:
>>> Found no TGT's in LSA
However this is incorrect as a C client can properly use
the ticket cache without any problem on the same machine.
Configuration file:
/****************************************************/
/**
* Login Configuration for JAAS.
*/

SampleClient {
com.sun.security.auth.module.Krb5LoginModule required
useTicketCache=true ;
};

SampleServer {
com.sun.security.auth.module.Krb5LoginModule required
storeKey=true ;
};
/*********************************************************/


STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1.Use any GSS client-server examples on the Sun site
2.Set the useTicketCache flag to true in the client conf.
3.Run the client. The acquiring of credentials fails with
the error mentioned.

EXPECTED VERSUS ACTUAL BEHAVIOR :
The Login Module should be properly able to get the ticket
to connect to the server from the ticket cache on windows
2000.

ERROR MESSAGES/STACK TRACES THAT OCCUR :
C:\WINNT\system32\ntvdm.exe
Error while setting up environment for the application.
>>> Found no TGT's in LSA


REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
CODE: Login.java
/******************************************************************/
import java.io.*;
import java.lang.reflect.*;
import java.util.Arrays;

import javax.security.auth.callback.*;
import javax.security.auth.login.*;
import javax.security.auth.Subject;
import com.sun.security.auth.callback.TextCallbackHandler;

/**
* <p> This class authenticates a <code>Subject</code> and then
* executes a specified application as that <code>Subject</code>.
* To use this class, the java interpreter would typically be invoked as:
*
* <pre>
* % java -Djava.security.manager * Login * <applicationclass> <applicationClass_args>
* </pre>
*
* <p> <i>applicationClass</i> represents the application to be executed
* as the authenticated <code>Subject</code>,
* and <i>applicationClass_args</i> are passed as arguments to
* <i>applicationClass</i>.
*
* <p> To perform the authentication, <code>Login</code> uses a
* <code>LoginContext</code>. A <code>LoginContext</code> relies on a
* <code>Configuration</code> to determine the modules that should be used
* to perform the actual authentication. The location of the Configuration
* is dependent upon each Configuration implementation.
* The default Configuration implementation
* (<code>com.sun.security.auth.login.ConfigFile</code>)
* allows the Configuration location to be specified (among other ways)
* via the <code>java.security.auth.login.config</code> system property.
* Therefore, the <code>Login</code> class can also be invoked as:
*
* <pre>
* % java -Djava.security.manager * -Djava.security.auth.login.config=<configuration_url> * Login * <your_application_class> <your_application_class_args>
* </pre>
*/

public class Login {

/**
* <p> Instantate a <code>LoginContext</code> using the
* provided application classname as the index for the login
*