title: Using a Sun or Red Hat DS into a simple LDAP proxy link: https://onemoretech.wordpress.com/2010/03/02/using-a-sun-or-red-hat-ds-into-a-simple-ldap-proxy/ author: lembobro description: post_id: 186 created: 2010/03/02 05:41:10 created_gmt: 2010/03/02 05:41:10 comment_status: open post_name: using-a-sun-or-red-hat-ds-into-a-simple-ldap-proxy status: publish post_type: post

Using a Sun or Red Hat DS into a simple LDAP proxy

While Oracle’s Virtual Directory and Sun’s Directory Proxy Server have lots of features that make deploying them worthwhile, if all you need is a simple pass-through LDAP proxy the standard Sun and Red Hat (a/k/a Netscape or 389 Directory) servers support a feature called Chaining that does the job.

Basically chaining involves substituting a remote Sun/Red Hat LDAP directory for the usual local database back-end. When an LDAP client requests something from the directory that’s configured to do chaining, the directory responds by performing LDAP operations on the remote directory and then returning the result to the client. This is transparent to the client, unlike standard LDAP v3 referrals that require the client to handle the process on its own. The analogy that immediately comes to mind is where a DNS server handles queries recursively.

Making this work is a two stage process. First you have to prepare the remote directory, then you configure the directory that will do the chaining.

Preparing the Remote Directory

A few points here. First, just as with setting up a replication admin account it’s always best to put your proxy user entry someplace off the main tree. I created mine as “cn=proxyadmin, cn=proxy, cn=config”. You also need to give this user proxy rights to the target suffix (e.g. “dc=example,dc=com”). I found that I had to loosen up some of my access constraints to make things work properly. Here are two acis (
access control instructions”) I set at the top of the target suffix and “cn=config”:

(targetattr!="userPassword")(version 3.0; acl "Enable anonymous access"; allow (read, search, compare) userdn="ldap:///anyone";)


(targetattr="carLicense || description || displayName || facsimileTelephoneNumber || homePhone || homePostalAddress || initials || jpegPhoto || labeledURL || mail || mobile || pager || photo || postOfficeBox || postalAddress || postalCode || preferredDeliveryMethod || preferredLanguage || registeredAddress || roomNumber || secretary || seeAlso || st || street || telephoneNumber || telexNumber || title || userCertificate || userPassword || userSMIMECertificate || x500UniqueIdentifier")(version 3.0; acl "Enable self write for common attributes"; allow (write) userdn="ldap:///self";)


(targetattr = "*") (version 3.0;acl "proxy acl";allow (proxy)(userdn = "ldap:///cn=proxyadmin, cn=proxy, cn=config");)

The first two acis are taken from the defaults that ship with the Sun or Red Hat Directory server. I also place them at the root of the “cn=config” tree. You’re going to want to look carefully at that list of attributes in both these. They’re going to violate many very good security designs out there. As with anything having to do with LDAP the key is to “test, test, test and test again”.

That last aci is specially designed to enable the proxy account to … “proxy”: perform operations “on behalf” of the user binding to the chaining directory as that user.

Configuring a Chaining Directory

The simplest way I found to get a chaining directory up and running is to create a new instance with a different root suffix than my target’s root will be. For example, “o=proxy”.

Once the instance is up and running you need to create a new root suffix named for your target, like “dc=example, dc=com”. When you do this uncheck the box labeled “Create associated database automatically”.

Then right click on the new suffix and select “New Database Link”. Provide a name for the database link (e.g. “exampleproxy”) and fill out the bind dn and password for the proxy user account you created on the remote server.

The form also includes a field for the remote server and port (early versions asked for the “URL”, by which they meant the LDAP URI, like “ldap://ldap1.example.com:389/” — that last slash being significant). A nice touch where you don’t have an application load balancer is the ability to list more than one server for failover.

Although it’s not technically required, I usually restart the chaining instance before testing, to make sure everything is properly applied.

Copyright 2004-2019 Phil Lembo