Hitachi Vantara Pentaho Community Forums
Results 1 to 6 of 6

Thread: What about LDAP Input?

  1. #1
    Join Date
    Sep 2005

    Default What about LDAP Input?


    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.

  2. #2
    Join Date
    Nov 1999

    Default RE: What about LDAP Input?

    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


  3. #3
    Join Date
    Aug 2006


    LDAP input is key for me to pull most fields concerning my users.

    Is this on a timeline yet?

  4. #4
    Join Date
    Nov 1999

    Default Use-case

    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.


  5. #5
    Join Date
    Aug 2006


    Standard inputs for dealing with LDAP:
    * baseDN
    * search string ( )
    * 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.

  6. #6


    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.

    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.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();
    results ="", "(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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
Privacy Policy | Legal Notices | Safe Harbor Privacy Policy

Copyright © 2005 - 2019 Hitachi Vantara Corporation. All Rights Reserved.