bugnthecode said:
I just looked over that, and though I didn't read that when setting up
my code initially I had something very similar. Much of the meat of
that article covers the installation, setup and theory behind an ldap
server. It does have some Java code at the bottom, but it uses the
"simple" method of authenticating passing in a user name and password
via a hashset.
My code already does all of that correctly, the problem is that the
sys admins won't give me the username and password to store in the
code (which would be a bad idea anyway), and the user name and
password can't sit in a file on disk. The program must obtain a
connection to the ldap using the currently logged on credentials, or
the credentials of the person running the job.
Thanks for your help though!
Will
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
