Authenticating LDAP connection with current windows user's credentials?

B

bugnthecode

Hi, I know this may be slightly off topic as it relates to using
windows authentication and credentials, but I'm writing a program that
needs to access an Active Directory LDAP, run a few queries, make some
changes, etc... The problem I'm having is that the system admins do
not like the idea of storing the username and password used for
authenticating to the LDAP in a file on the file system (even though
access can be restricted using file permissions). The goal is to use
the program I'm creating as a system job to be run once a day for some
maintenance, and do all of the operations with the credentials of the
"user" running the job.

I can authenticate with my own credentials (read-only access in the
ldap) and perform most of my queries with no problems. What I can't
quite figure out is how to (if it is even possible) use the jndi but
authenticate with the credentials of the user running the tool.

Any ideas? Can you point me anywhere?

Thanks for your help,
Will
 
B

bugnthecode


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
 
B

Brandon McCombs

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
 
B

bugnthecode

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

Brandon, thanks so much for the code! This was killing me trying to
figure out on my own. I've been playing with this for the past couple
of days, and every once in a while I experience a period of time where
I get some kind of privileged exception being thrown, and in the debug
output the cause is something along the lines of not being able to
find the kerberos server, or that it get response 126 when expecting
14.

I've been able to make slight modifications to the configuration
(specifying the type of encryption in the krb5.ini file) and it will
start working again. I still need to do some extensive testing before
allowing this to run by itself unattended though. Have you seen this
before? It just happens with no modifications being made! I run it,
and it's fine, then run it 2 minutes later and it won't authenticate
properly.

Thanks again for your help with this.
Will
 
B

Brandon McCombs

bugnthecode said:
Brandon, thanks so much for the code! This was killing me trying to
figure out on my own. I've been playing with this for the past couple
of days, and every once in a while I experience a period of time where
I get some kind of privileged exception being thrown, and in the debug
output the cause is something along the lines of not being able to
find the kerberos server, or that it get response 126 when expecting
14.

I've been able to make slight modifications to the configuration
(specifying the type of encryption in the krb5.ini file) and it will
start working again. I still need to do some extensive testing before
allowing this to run by itself unattended though. Have you seen this
before? It just happens with no modifications being made! I run it,
and it's fine, then run it 2 minutes later and it won't authenticate
properly.

Thanks again for your help with this.
Will

I haven't seen that behavior before. Maybe I got lucky with mine. You
may want to make sure that the kerberos server it uses is the right
server all the time (in case it is contacting the wrong server
sometimes). Java doesn't use the OS's DNS cache from what I can tell so
it is possible to use a hostname and to have it resolve to a different
IP every time you run the program. If you are specifying an IP address
that will mitigate those issues.

Also check the ADS Security log to see if it reports anything useful.

I don't recall having to make any changes to the server-side but if I
think of anything I'll post it.

I'm glad I could be of some help.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,743
Messages
2,569,478
Members
44,899
Latest member
RodneyMcAu

Latest Threads

Top