Re: Authenticating LDAP connection with current windows user's credentials?

bugnthecode wrote:


I've implemented JNDI using Kerberos in my LDAP application. The
Kerberos only works with ADS right now but that is sufficient for your
situation. However it currently works (read: tested) when the user has
logged in interactively and therefore has a valid Kerberos ticket cached
in Windows logon credential cache. Whether it works for your case in a
batch job is another story. It is complicated nonetheless and requires a
lot of small pieces. Beware...this message is long. Don't be afraid to
ask for clarification on anything; it is tedious and the formatting of
stuff below may get messed up but I tried to prevent that.

Here is the steps you need to do outside of the code for it to even work
(Windows doesn't use Kerberos the standard way, no surprise right?)

Step 1. modified registry for session keys

On the Windows Server 2003 and Windows 2000 SP4, here is the required
registry setting:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\Kerberos\Parameters
     Value Name: allowtgtsessionkey
      Value Type: REG_DWORD
      Value: 0x01 ( default is 0 )
      By default, the value is 0; setting it to "0x01" allows a
session key to be included in the TGT.

Here is the location of the registry setting on Windows XP SP2:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\Kerberos\
     Value Name: allowtgtsessionkey
      Value Type: REG_DWORD
      Value: 0x01

Step 2. modified java.security file to provide path to JAAS .conf file
    login.config.url.1=file:z:/share1/ldapclass/login.conf

Step 3. created login.conf in jar location to specify kerb5 options
     JAAS login configuation for LDAPKerbService (class name) and GSS
API (jgss.initiate).

     LDAPKerbService {
          com.sun.security.auth.module.Krb5LoginModule required
client=true useTicketCache=true;
     };
     com.sun.security.jgss.initiate {
         com.sun.security.auth.module.Krb5LoginModule required
useTicketCache=true;
     };
  LDAPKerbService is the name of whatever class you created to do the
Kerberos code initialization. Code for that is listed below.

Step 4. created krb5.ini file and placed in c:\winnt (create it).
Change to fit your domain configuration. It is case sensitive.

  [libdefaults]
    default_realm = MYDOMAIN.COM
  [realms]
    MYDOMAIN.COM = {
       kdc = dc1.mydomain.com
  }

  [domain_realm]
    mydomain.com = MYDOMAIN.COM
       .mydomain.com = MYDOMAIN.COM

=======================================================================

Here is the class mentioned above. It ties in to the normal
InitialLdapContext class so you still need to use that.

import javax.naming.NamingException;
import javax.naming.ldap.InitialLdapContext;
import javax.naming.ldap.LdapContext;
import javax.security.auth.Subject;
import javax.security.auth.callback.CallbackHandler;
import javax.security.auth.login.LoginContext;
import javax.security.auth.login.LoginException;
import javax.swing.JOptionPane;

import java.security.PrivilegedAction;

public class LDAPKerbService implements PrivilegedAction {
   private LdapContext ldapContext;
   public LDAPKerbService() { }

  /*
  * Login to LDAP using the current Logged in user's information. Before
  * invoking this method, you must set an environment variable called
  * java.security.auth.login.config. This value should be set to the name
  * of the security configuration file that you are using, for example,
  * security.conf. You may have an entry that looks like the following:
  * <br/>
  *System.setProperty("java.security.auth.login.config","security.conf");
  * <br/>
  * This is required for the LDAP Login to process correctly.
  * <br/>
  */

//this is the one that does the most work
   public void login() {

     try {
    LoginContext loginContext = null;
    CallbackHandler callbackHandler = new KerbCallback();
    loginContext = new
LoginContext(LDAPKerbService.class.getName(),callbackHandler);
    loginContext.login();
    Subject subject = loginContext.getSubject();
    ldapContext = (LdapContext) Subject.doAs(subject, this);
     }
     catch (LoginException le) {
      JOptionPane.showMessageDialog(null,
        le.getMessage(),"Login Error",
        JOptionPane.ERROR_MESSAGE);
     }
     catch (SecurityException se) {
      JOptionPane.showMessageDialog(null,
        se.getMessage(),Security Error",
        JOptionPane.ERROR_MESSAGE);
     }
   }

//this is called automatically by login()
   public Object run() {
     try {
         LdapContext ctx = new InitialLdapContext(null, null);
         return ctx;
       }
       catch (NamingException ne) {
        return null;
       }
   }

===============================================================
And then there is this class (KerbCallback mentioned above):

import java.io.IOException;
import javax.security.auth.callback.Callback;
import javax.security.auth.callback.CallbackHandler;
import javax.security.auth.callback.UnsupportedCallbackException;

/* A callback is used when the kerberos auth. fails and
  * the fallback position is to use regular username/password
  * but for this app there will be no fallback which means
  * the Callback has nothing to do but we still need it for
  * the loginContext object.
  */
public class KerbCallback implements CallbackHandler {
    public KerbCallback() {}
    public void handle(Callback[] arg0) throws IOException,
            UnsupportedCallbackException {}

}

================================================================

You'll need to do the following to configure your Hashtable that you
will pass into your InitialLdapContext when you construct it. There is
also something in here for older java versions.

ldapEnv is a Hashtable<Object,Object> object.

if (authType.equals("Kerberos")) {

ldapEnv.put(Context.SECURITY_AUTHENTICATION,"GSSAPI");
ldapEnv.put(Context.SECURITY_PRINCIPAL,"");
ldapEnv.put(Context.SECURITY_CREDENTIALS,"");
System.setProperty("sun.security.krb5.debug", "false");
// This tells the GSS-API to use the cached ticket as
// credentials, if it is available
System.setProperty("javax.security.auth.useSubjectCredsOnly", "false");

// Get the version of Java being used in the runtime environment.
// If it is 1.4, set the system property os.name to Windows 2000.
// This is because there is a bug with the 1.4 JRE that does not
// properly handle Kerberos ticket caching with Windows XP
     String javaVer = System.getProperty("java.version");
     if (javaVer == null || javaVer.startsWith("1.4"))
       System.setProperty("os.name", "Windows 2000");
}

=================================================================
To use that mess of code you then can do something like this:

public void connect() throws Exception {
    ctx = new InitialLdapContext(ldapEnv,null);
    kerbSvc = new LDAPKerbService();
    kerbSvc.login();
}

=====================================================================

If you need help understanding this let me know. I'll do what I can.
The program kinit.exe in your JDK will help in making sure that your
java installation can properly read your kerberos ticket. Again, this
may or may not work with a batch job since I don't know if Windows will
store the Kerberos ticket the same way (or at all) for a batch job user
who authenticates. A rendition of the code above was given to me by a
co-worker who also used it in an application that was meant to be run by
users interactively. It works fine for me (as long as you do the
configuration in krb5.ini exactly and of course if you get the code
right too).

HTH
Brandon