Article

(View Disclaimer)

In order to get this to work properly I required the newest version of OpenLDAP that ships with Suse Linux Enterprise Server 11. The following two packages need to be installed along with all of their dependencies:

openldap2
openldap2-back-meta version

The versions I used were version 2.4.12-7.14

Once installed, you will find the configuration files in the /etc/openldap directory. The configuration file we will be working with will be the slapd.conf file. So, using this as an example, you should be able to present the data from both sources in any form that you would like. Here is what the actual sources look like:

eDirectory - Flat tree used strickly for user authorization
o=Corp
    cn=user1
    cn=user2
    cn=user3

Active Directory - Partner Site
dc=partner,dc=net
     ou=Alaska
          cn=user1
          cn=user2
     ou=Texas
          cn=user1
          cn=user2
     ou=Miami
#
# See slapd.conf(5) for details on configuration options.
# This file should NOT be world readable.
#
include		/etc/openldap/schema/core.schema
include		/etc/openldap/schema/cosine.schema
include		/etc/openldap/schema/inetorgperson.schema
include		/etc/openldap/schema/rfc2307bis.schema
include		/etc/openldap/schema/yast.schema
# Define global ACLs to disable default read access.

# Do not enable referrals until AFTER you have a working directory
# service AND an understanding of referrals.
#referral	ldap://root.openldap.org

pidfile		/var/run/slapd/slapd.pid
argsfile	/var/run/slapd/slapd.args

# Load dynamic backend modules:
modulepath	/usr/lib/openldap/modules
# moduleload	back_bdb.la
# moduleload	back_hdb.la
# moduleload	back_ldap.la
moduleload	back_meta.la
###By default, moduleload back_meta.la is not enabled
# Sample security restrictions
#	Require integrity protection (prevent hijacking)
#	Require 112-bit (3DES or better) encryption for updates
#	Require 63-bit encryption for simple bind
# security ssf=1 update_ssf=112 simple_bind=64

# Sample access control policy:
#       Root DSE: allow anyone to read it
#       Subschema (sub)entry DSE: allow anyone to read it
#       Other DSEs:
#               Allow self write access to user password
#               Allow anonymous users to authenticate
#               Allow read access to everything else
#       Directives needed to implement policy:
access to dn.base=""
        by * read

access to dn.base="cn=Subschema"
        by * read

access to attrs=userPassword,userPKCS12
        by self write
        by * auth

access to attrs=shadowLastChange
        by self write
        by * read

access to *
        by * read

# if no access controls are present, the default policy
# allows anyone and everyone to read anything but restricts
# updates to rootdn.  (e.g., "access to * by * read")
#
# rootdn can always read and write EVERYTHING!

#######################################################################
# Database definitions
#######################################################################
loglevel -1
database        meta
suffix          "o=ldap"
uri             "ldap://ldap.partner.net/ou=partner,o=ldap"
suffixmassage   "ou=partner,o=ldap" "dc=partner,dc=net"
# The rootdn DOES NOT exist in either active directory or eDirectory.  This will be the account
# used to bind to the ldap proxy server.  It MUST fall under the suffix above, which in our
# example is o=ldap. 
rootdn "cn=Manager,o=ldap"
rootpw {CRYPT}apWnGPe0qW5BE
#  To generate an encrypted password, use the slapdpasswd command
chase-referrals no
nretries 100
bind-timeout 1000000

#######################################################################
idassert-bind bindmethod=simple
   binddn="cn=tech,ou=TechSupport,dc=partner,dc=net"
   credentials="tech-user-password-here"
   mode=none
   flags=non-prescriptive
idassert-authzFrom "dn.exact:cn=Manager,o=ldap"
## binddn is the actual dn of the user in the tree.  Although logically it might seem that 
## you would use the massaged dn of that user, it will not work.
#######################################################################

map attribute uid userprincipalname
#The map statement is used to map the userprincipal name to uid for AD.  Since our 
# web application uses uid as the attribute for searching for users, we want the uid 
# for partners to appear as username@partner.net in order to avoid the possibility
# of duplicate uids

####################Beginning of second Directory#######################
uri "ldap://ldap/ou=Corporate,o=ldap"
suffixmassage "ou=Corporate,o=ldap" "o=Corp"
idassert-bind bindmethod=simple
  binddn="cn=MBruner,o=Corp"
  credentials="L3tm31n2"
  mode=none
  flags=none
idassert-authzFrom "dn.exact:cn=Manager,o=ldap"

To start the slapd daemon, isse the following command at the prompt:

/usr/lib/openldap/slapd -d -1  # that is minus 1 to turn on debugging level of -1

Here is the connection information for connecting to the LDAP PROXY Server:

With a basedn of o=ldap, this is what is produced:

To test if it is working correctly, you can use a free program called ldap proxy. It is available for download from http://www.lavasoftware.net/en/content/ezproxy/download.htm.

Once you have it downloaded, do the following:

1. Setup the software per the instructions.
2. Run the software by clicking on the ezproxy.exe file.
3. Launch a browser and go to http://localhost:2048/admin
4. Log in as the user you set up in the user.txt file.
5. Click on continue.
6. At the bottom of the page you will see a link for Test LDAP. Click on the link.
7. Fill out the page.
8. After selecting Search, if successful, you will see a listing of the user attributes and most importantly, you will see "Password Successful". This means that password authentication is working properly.

Click to view.

Click to view.

The above image demonstrates successful authentication to Partners AD Tree

A helpful tip for troubleshooting is to start the slapd daemon manually with logging turned on. This way, you can see the output when the daemon starts. To do this, type the following command:

/usr/lib/openldap/slapd -d -1 # that is minus 1 to turn on debugging level of -1

Once you have everything working the way you want it to, you can have the ldap service start the slapd daemon for you. To do this, edit the /etc/init.d/ldap file. Find the line beginning with SLAPD_CONFIG_ARG=’-F /etc/openldap/slapd.d’. Change this to read:
SLAPD_CONFIG_ARG=’-f /etc/openldap/slapd.conf’. Stop any running SLAPD Process by typing "killall slapd” at the command prompt. Then type rcldap start to start ldap. If the service starts successfully, you will receive the following:

Starting ldap-server                                           done

You can check to see if the slapd daemon is running by issuing the following command:

"ps ax | grep slapd

You should see a line like the following:

14794 ?          Ssl         0:00   /usr/lib/openldap/slapd –h ldap:// ldaps:// ldapi:// -f /etc/openldap/slapd.conf –u ldap –g ldap –o slp=off

This log can be helpful should the daemon not start properly.

OpenLdap Documentation:
http://www.openldap.org/doc/admin24/

Softerra LDAP Browser for Testing
http://www.softerra.com/download.htm

EZProxy Download
http://www.lavasoftware.net/en/content/ezproxy/download.htm.

Special thanks goes out to Fred Patterson from Novell Technical Services for his assistance with the final details in getting this up and functional.

Disclaimer: As with everything else at Cool Solutions, this content is definitely not supported by Novell (so don't even think of calling Support if you try something and it blows up).

It was contributed by a community member and is published "as is." It seems to have worked for at least one person, and might work for you. But please be sure to test, test, test before you do anything drastic with it.