Hi folks -
first, a simple, direct question. I'm trying to use the meta backend, and exclude part of the back-end directory (which is AD, if that matters).
I tried the following config:
-------------------------- include /usr/local/pkg/openldap-2.4.39/etc/openldap/schema/core.schema include /usr/local/pkg/openldap-2.4.39/etc/openldap/schema/cosine.schema include /usr/local/pkg/openldap-2.4.39/etc/openldap/schema/inetorgperson.schema include /usr/local/pkg/openldap-2.4.39/etc/openldap/schema/nis.schema
pidfile /var/run/openldap/slapd-filter.pid argsfile /var/run/openldap/slapd-filter.args
loglevel any
access to * by * read
database meta suffix "dc=adsroot,dc=itd,dc=umich,dc=edu" uri "ldap://adsroot.itd.umich.edu/dc=adsroot,dc=itd,dc=umich,dc=edu" rootdn "cn=Manager,dc=adsroot,dc=itd,dc=umich,dc=edu"
#subtree-exclude "ou=ICPSR,ou=Organizations,ou=UMICH,dc=adsroot,dc=itd,dc=umich,dc=edu" #subtree-exclude "ou=ICPSR,ou=Accounts,ou=UMICH,dc=adsroot,dc=itd,dc=umich,dc=edu" subtree-exclude "dn.subtree:ou=ICPSR,ou=Organizations,ou=UMICH,dc=adsroot,dc=itd,dc=umich,dc=edu" subtree-exclude "dn.subtree:ou=ICPSR,ou=Accounts,ou=UMICH,dc=adsroot,dc=itd,dc=umich,dc=edu" --------------------------
As you can see i tried two syntaxes for subtree-exclude. with either one, a search for "cn=danno" returns dn: cn=danno,ou=ICPSR,ou=Accounts,ou=UMICH,dc=adsroot,dc=itd,dc=umich,dc=edu
What am I doing wrong? Or do I misunderstand what subtree-exclude is supposed to be doing?
openldap 2.4.39 on centos 6, x64.
The larger question -
As I posted last week I am trying to put a proxy in front of Active Directory. AD has most of the required attributes for my application, but I need to fill in a couple that are missing. Translucent proxy makes sense, combined with the collect overlay. Unfortunately, slapd crashes when it encounters a DN from AD that has one of the collect attributes (its 7797). Not just a lookup failure, a hard crash. :(
So, it next occurred to me to use another instance of slapd with rwm as a "filter" to remove the attributes I am trying to use with collect.
It's complicated further by the fact that some subtrees have different attributes that I want to filter, or not.
I tried soemthing like this: -------------------------- database ldap uri ldap://foo suffix ou=foo,dc=example,dc=edu [ rwm entries to leave only the attributes i want for ou=foo ]
database ldap uri ldap://foo suffix ou=bar,dc=example,dc=edu [ rwm entries to leave only the attributes i want for ou=bar ]
database meta uri ldap://foo suffix dc=example,dc=edu subtree-exclude ou=foo subtree-exclude ou=bar --------------------------
I had to add the third database entry, with the root dn, before auth would work.
Presuming that i can actually make meta work with the subtree-exclude like I want, should a config like this work?
As it is, everything is being returned from the third database entry, with the suffix at the root DN. So, I'm not sure if this idea of combining multiple ldap databases would work.
thanks for any input!
danno
Dan Pritts wrote:
As I posted last week I am trying to put a proxy in front of Active Directory. AD has most of the required attributes for my application, but I need to fill in a couple that are missing. Translucent proxy makes sense, combined with the collect overlay. Unfortunately, slapd crashes when it encounters a DN from AD that has one of the collect attributes (its 7797). Not just a lookup failure, a hard crash. :(
That's expected, the collective attribute is not allowed to already exist.
Crash reports without stack traces are also less than helpful...
Howard Chu wrote:
Dan Pritts wrote:
As I posted last week I am trying to put a proxy in front of Active Directory. AD has most of the required attributes for my application, but I need to fill in a couple that are missing. Translucent proxy makes sense, combined with the collect overlay. Unfortunately, slapd crashes when it encounters a DN from AD that has one of the collect attributes (its 7797). Not just a lookup failure, a hard crash. :(
That's expected, the collective attribute is not allowed to already exist.
A crash is expected? ouch.
Crash reports without stack traces are also less than helpful...
I sent one along to the ITS.
openldap-technical@openldap.org