Using NT Security Context with JNDI to talk to AD

Question

Hello all,
Is there a way in JNDI to connect to Active Directory using the current NT Security Context like ADSI does?
I want to run a Java program as a service under Win2k.
I want to assign a user for it to run as (on service start).
When the program is executing, I need to access AD (wish it wasn't so, but out of my hands), preferrably with JNDI, to read/write data.
I would like to be able to connect without having to set SECURITY_AUTHENTICATION to "simple" and providing a username and password since as a service, I don't want to interract with the desktop.
In ADSI, I could set the ADS_SECURE_AUTHENTICATION flag and it would use the NTLM to access AD.
Is there something similar in JNDI? I've searched the forums, but have only found examples of people using JAAS and GSSAPI (which requires entering a username/password and authenticating against a Kerberos realm) or simple authentication (which requires entering a username/password).
Any help would be appreciated.
Regards,
plb

Answer 1

Thanks schmid03,
FYI, I am on Win2K Advanced Server running J2SDK 1.4.0_01.
Tried changing the conf file, but still a no go. Here's what's happening now...
Get a pop-up window titled "16 bit MS-DOS Subsystem"
Message: c:\WINNT\system32\ntvdm.exe Error while setting up environment for the application. Choose 'Close' to terminate the application.
Buttons: Close, Ignore
after calling "lc.login ();"
but then I can get the Subject and print out Principal (name) and it is correct.
However, in JNDI call "new InitialDirContext ();" I receive:
GSSException: No valid credentials provided (Mechanism level: Failed to find any Kerberos Ticket)
at sun.security.jgss.krb5.Krb5InitCredential.getInstance(Krb5InitCredential.java:142)
at sun.security.jgss.krb5.Krb5MechFactory.getCredentialElement(Krb5MechFactory.java:70)
at sun.security.jgss.GSSManagerImpl.getCredentialElement(GSSManagerImpl.java:149)
at sun.security.jgss.GSSCredentialImpl.add(GSSCredentialImpl.java:334)
at sun.security.jgss.GSSCredentialImpl.<init>(GSSCredentialImpl.java:59)
at sun.security.jgss.GSSCredentialImpl.<init>(GSSCredentialImpl.java:36)
at sun.security.jgss.GSSManagerImpl.createCredential(GSSManagerImpl.java:96)
at sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:178)
at sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:158)
at com.sun.security.sasl.gsskerb.GssKerberosV5.evaluateChallenge(GssKerberosV5.java:160)
at com.sun.jndi.ldap.sasl.LdapSasl.saslBind(LdapSasl.java:113)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at com.sun.jndi.ldap.LdapClient.saslBind(LdapClient.java:374)
at com.sun.jndi.ldap.LdapClient.authenticate(LdapClient.java:190)
at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2516)
at com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:263)
at com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:76)
at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:662)
at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:243)
at javax.naming.InitialContext.init(InitialContext.java:219)
at javax.naming.InitialContext.<init>(InitialContext.java:195)
at javax.naming.directory.InitialDirContext.<init>(InitialDirContext.java:80)
at Test$MyAction.run(Test.java:196)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:319)
at Test.go(Test.java:132)
at Test.main(Test.java:73)
I'll check these new messages against other posts in the forum to see if there are similar problems...
If anyone already knows this problem and a fix, please enlighten.
Regards,
plb