I'm migrating a poorly configured LDAP (flat with no ou's)
I wouldn't call this "poor": in many cases, it might be the wisest.
think of LDAP as a container with contraints on how to access it.
Then, to use a flat data organization, leaving high level abstract
organization to wise clients is really better. But this is rather
a philosophical topic.
one that
has structure. My problem is that several of the applications that use
the LDAP can't handle users/groups in ou's. I need an temporary
solution so that I can go ahead with migrating the LDAP, without having
to wait for the vendors to fix their clients. I've been playing around
with slapd-ldap but can't figure out how to do the following.
Here is my structure
O=company,c=us
ou=sales
ou=engineers
ou=admin
ou=groups
When the user "jdoe" logs on the application tries the following
>BIND dn=""
>SRCH base="o=company,c=us" scope=1 filter="(uid=jdoe)"
User jdoe can be in any of the ou's. So here are some questions
1. Is there a way to change the search scope with slapd-ldap?
2. Can I change the base depending on the filter?
3. Can I use slapd-ldap to completely flatten the ldap?
In short:
1) not directly; but with back-meta you can spawn each search
in four, looking below each organzational unit of your organization.
2) yes; with back-ldap/back-meta you can write carefully tailored
and consistent rewrite rules that do the trick for you.
3) if you reverse the rules of (1), and fllow that approach, the
database will appear as if organized in a "flattened" way.
For (1+3), try something like
suffix "o=company,c=us"
uri "ldap://realDSA/o=company,c=us";
suffixmassage "o=company,c=us" "ou=sales,o=company,c=us"
uri "ldap://realDSA/o=company,c=us";
suffixmassage "o=company,c=us" "ou=engineers,o=company,c=us"
uri "ldap://realDSA/o=company,c=us";
suffixmassage "o=company,c=us" "ou=admin,o=company,c=us"
uri "ldap://realDSA/o=company,c=us";
suffixmassage "o=company,c=us" "ou=groups,o=company,c=us"
This has a number of drawbacks, of course:
- performance penalty: each searc actually turns into 4,
of which only one must succeed
- you're stuck with binding and modifications, because
these operations assume the location of the entry can
be univoquely identifid by looking at its DN. In this
case all the locations hve exactly the same base, the
worst scenario. You can partially cure this by declaring
one of the targets as the default one, the one that gets
all the univoque operations. Of course, ony th operations
that relly refer to that loction will succeeed.
For (2) you really need to read slapd-meta(5) and learn
a bit about rewrite rules.
p.