[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Meta to Ldap loopback not working.





Pierangelo Masarati wrote:

On Tue, 2005-12-20 at 12:41 -0500, Matthew Stier wrote:


I am almost successfull in implementing a metadirectory server, however, I am running into a "loopback" problem.

The purpose of this metadirectory is to query three other directory servers (labelled NY, TX and CORP) and return a composite of their results. The NY and TX directory servers permit anonymous access. The CORP directory does not.

To implement this, the slapd.conf file I have created has two 'databases'. The first is the 'meta' database, and implements the querying, and compositing the results. The second is the 'ldap' database which is used to provide anonymous access to the non-anonymous server.

I am using OpenLDAP 2.3.13 and it is running on port 3389 on the 'ldap.ny.example.com' server.

Here is a list of what works:

      Queries to the 'ldap' proxy ("OU=Users,OU=Enterprise") work

      Queries to the NY proxy (dc=ny,dc=example,dc=com) work

      Queries to the TX proxy (dc=tx,dc=example,dc=com) work

      Queries to the CORP proxy (dc=corp,dc=example,dc=com) fail

      Queries to the 'meta' proxy (dc=example,dc=com) returns NY and TX.
	(Should return NY, TX and CORP)



<slapd.conf>
include  /opt/openldap/2.3.13/etc/openldap/schema/core.schema
include  /opt/openldap/2.3.13/etc/openldap/schema/cosine.schema
include  /opt/openldap/2.3.13/etc/openldap/schema/inetorgperson.schema
include  /opt/openldap/2.3.13/etc/openldap/schema/ad.schema

pidfile  /opt/openldap/2.3.13/var/run/slapd.pid
argsfile /opt/openldap/2.3.13/var/run/slapd.args
loglevel -1

access to *
         by * read

allow bind_v2
defaultsearchbase "dc=example,dc=com"
lastmod off
readonly on

#######################################################################
# database definitions
#######################################################################

database meta
suffix "dc=example,dc=com"

uri "ldap://ldap.ny.example.com:3389/dc=corp,dc=example,dc=com";
suffixmassage "dc=corp,dc=example,dc=com" "OU=Users,OU=Enterprise"

uri "ldap://ldap.ny.example.com:389/dc=ny,dc=example,dc=com";
suffixmassage "dc=ny,dc=example,dc=com" "o=ny"

uri "ldap://ldap.tx.example.com:389/dc=tx,dc=example,dc=com";
suffixmassage "dc=tx,dc=example,dc=com" "o=tx"

database ldap
suffix  "OU=Users,OU=Enterprise"
uri ldap://ldap.fnc.net.local:3268/
acl-bind
          bindmethod=simple
          binddn="CN=LDAP Search Only User,OU=Users,OU=Enterprise"
          credentials="<LDAP SEARCH Only password>"
          authzID="LDAP Search Only User"
idassert-bind
          bindmethod=simple
          binddn="CN=LDAP Search Only User,OU=Users,OU=Enterprise"
          credentials="LDAP Search Only User"
          mode=none

# This controls what attribs can be accessed by the LDAP proxy.
# The last rwm-map line maps all other attributes to nothing.
overlay rwm
rwm-map objectclass account user
rwm-map attribute uid sAMAccountname
rwm-map attribute cn name
rwm-map attribute sn sn
rwm-map attribute mail mail
rwm-map attribute company company
rwm-map attribute entry entry
rwm-map attribute givenName givenName
rwm-map attribute telephoneNumber telephoneNumber
rwm-map attribute *
</slapd.conf>



I couldn't narrow down your issue. I've set up a similar meta backend, including the rwm stuff on the local ldap, and it works as expected (a bit too much, since I had to file ITS#4272, because back-ldap was letting anonymous connections be asserted without an explicit authorization; the "right" syntax, as of per the upcoming 2.3.14 will need a

idassert-authzFrom "dn:"

to allow anonymous to be asserted as the binddn in the "idassert-bind"
directive you're using).

I suggest you try to single out the point of failure of the entire
setup.  For example, if you run test003 from the OpenLDAP suite with

./run test003

from the tests/ directory, then add

<testrun/slapd.1.conf>
access to attrs=userPassword
       by * =x
access to *
       by users read
</testrun/slapd.1.conf>

so that only auth'd users can read the database, then create a
slapd.2.conf like

<slapd.2.conf>
database        meta
suffix          o=Meta

uri             "ldap://:9012/o=Meta";
suffixmassage   "o=Meta" "dc=example,dc=com"

database        ldap
suffix          "dc=example,dc=com"
uri             "ldap://:9011";
idassert-bind   bindmethod=simple
               binddn="cn=Bjorn Jensen,ou=Information Technology Division,ou=People,dc=example,dc=com"
               credentials=bjorn
               mode=none
#will be required by 2.3.14 to allow anonymous to authcID idassert
#idassert-authzFrom      "dn.regex:.*"

overlay rwm
rwm-map attribute    uid     uid
rwm-map attribute    cn      cn
rwm-map attribute    sn      sn
rwm-map attribute    mail    mail
rwm-map attribute    company company
rwm-map attribute    entry   entry
rwm-map attribute    givenName givenName
rwm-map attribute    telephoneNumber telephoneNumber
rwm-map attribute    *
</slapd.2.conf>

This works for me with 2.3.12 up to upcoming 2.3.14 out of the CVS.  Do
you think this compares to your setup, or can you point out relevant
differences, to proceed further with investigations?

Could there be any typos in your config that are not obvious to others?
Are you sure "ldap.ny.example.com:3389" resolves to the slapd that
contains the meta database?  What about using "ldap://localhost:3389";,
or even "ldapi://"?

p.




Ing. Pierangelo Masarati Responsabile Open Solution OpenLDAP Core Team

SysNet s.n.c.
Via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
------------------------------------------
Office: +39.02.23998309 Mobile: +39.333.4963172
Email: pierangelo.masarati@sys-net.it
------------------------------------------



There is a single point of failure here.


The 'corp' uri of the 'meta' database is suppose to loopback to the 'ldap' database. This loopback is failing, however, I'm not entirely sure were. (I'm still trying to figure out the the command line debug option, and the output it generates.)

As to subtituting 'localhost', I have tried that also, but it didn't change the results. (I switched back to the fully qualified hostname, to ensure I wasn't inducing a rewrite error.)


-- Matthew Lee Stier * Fujitsu Network Communications Unix Systems Administrator | Two Blue Hill Plaza Ph: 845-731-2097 Fx: 845-731-2011 | Sixth Floor Matthew.Stier@us.fujitsu.com * Pearl River, NY 10965

begin:vcard
fn:Matthew Stier
n:Stier;Matthew
org:Fujitsu Network Communications
adr;quoted-printable:;;Two Blue Hill Plaza=0D=0A=
	Sixth Floor;Pearl River;New York;10965;United States of America
email;internet:Matthew.Stier@us.fujitsu.com
title:Principal Engineer
tel;work:845-731-2097
tel;fax:845-731-2011
tel;cell:845-893-0575
x-mozilla-html:FALSE
version:2.1
end:vcard