PDA

View Full Version : What about LDAP Input?



kettle_anonymous
03-09-2006, 01:49 AM
Hi,


I want to suggest a new feature for Kettle. It would be nice to have the possibility to grab data of a LDAP server as input, so you would have the possibility to transport LDAP data into a database or to export LDAP data to a file.

MattCasters
04-12-2006, 04:21 AM
Well, there are a couple of LDAP drivers available, so I'm guessing it wouldn't be TOO hard.
That being said, if I'm not mistaken the LDAP data is hierarchical in nature so it might not be too easy either.


Added feature request: #1961 (http://www.javaforge.com/proj/tracker/itemDetails.do?task_id=1961)



Matt

sarah
01-31-2007, 09:35 AM
LDAP input is key for me to pull most fields concerning my users.

Is this on a timeline yet?

MattCasters
01-31-2007, 11:24 AM
What's always nice to have is a more concrete use-case.
In this case we have an LDAP tree, how does this tree look like, what's the requirement, how would you like to see the data export, is there data conversion involved.
From the little I know of LDAP is that you can pretty much throw anything in there, so the GUI and engine would have to be pretty generic as well.
Then again, we could start with something simple, and go from there.

Whatever the case, thanks in advance for helping us out with defining these initial requirements.

Matt

sarah
01-31-2007, 12:15 PM
Standard inputs for dealing with LDAP:
* baseDN
* search string ( http://www.faqs.org/rfcs/rfc2254.html )
* attributes to pull

There is also the option to support something other than simple authentication, and to provide a bindDN and password. I would not use these features, but I imagine many others would.

LDAP can store binary data, but the only fields I would need to deal with are strings.

dhartford
09-04-2007, 03:23 PM
Just came across a real-world, I-needed-this use-case for this scenario. List all the users that have access to different applications (a report, and of course the datasource for said report).

Another thoeretical use-case would be mail-merge as some LDAP servers contain all the mailing information for all their users, seperated by departments/roles/etc to create a sample Excel/CSV to be used by various mail-merge programs.


Anyway,
There is a jdbc-ldap bridge, but it hasn't been maintained for over 4 years, so probably not a good idea unless someone has had success with it.

To solve immediate use-case, used raw java approach using the built-in JDK javax.naming package libraries.

sample java code:
==========
import javax.naming.*
......
Hashtable env = new Hashtable();
env.put(Context.INITIAL_CONTEXT_FACTORY,"com.sun.jndi.ldap.LdapCtxFactory");
env.put(Context.PROVIDER_URL, "ldap://server/dc=base,dc=scom");
env.put(Context.SECURITY_AUTHENTICATION, "simple");
env.put(Context.SECURITY_PRINCIPAL, "uid=admin");
env.put(Context.SECURITY_CREDENTIALS, "password");
DirContext ctx = null;
NamingEnumeration results = null;
ctx = new InitialDirContext(env);
SearchControls controls = new SearchControls();
controls.setSearchScope(SearchControls.SUBTREE_SCOPE);
results = ctx.search("", "(businessCategory=MyApp)", controls);

==========

This was on an OpenLDAP server, I think for AD you need to enable server-side to support simple authentication, otherwise something else (there's several articles about it).

Just appending to this existing thread related to a possible future LDAP datasource step.