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

Re: ldapsearch query via OpenLDAP proxy to AD

> I am trying to query the active directory ( on my network
> using ldapsearch by way of an OpenLDAP proxy ( using the
> following slapd.conf:
> *************slapd.conf on******************
> database        meta
> suffix          "dc=corp,dc=mycompany,dc=com"
> dncache-ttl     forever
> lastmod         off
> rootdn         "cn=Administrator,cn=users,dc=corp,dc=mycompany,dc=com"
> rootpw          12345678
> uri
> "ldap://,dc=corp,dc=mycompany,dc=com"; pseudorootdn
>   "cn=admin2,cn=users,dc=corp,dc=mycompany,dc=com"
> pseudorootpw    12345678
> When I try this it works (returns results from the AD):
> ldapsearch -h -x -D
> cn=administrator,cn=users,dc=corp,dc=mycompany,dc=com -W -b
> 'dc=corp,dc=mycompany,dc=com' ''cn=tim*'
> When I try this it doesn't return any results at all:
> ldapsearch -h -x -b 'dc=corp,dc=mycompany,dc=com' 'cn=tim*'
> What should I change in my slapd.conf to make the second query return
> results?
> In other words, how do I successfully get the  back-meta to authenticate
> properly to the AD?
> I have been told (if I understood correctly) that the back-meta with the
> pseduorootdn parameter will allow this type of proxied authenticated
> query to work.

As far as I remember, you were told to read the slapd-meta(5)
manual about pseudorootdn; since apparently you didn't,
I'm attaching it below.  It says that pseudorootdn is the
identity the backend will use to proxy the remote server
when you bind as the backend's rootdn.

       pseudorootdn <substitute DN in case of rootdn bind>
              This  directive,  if present, sets the DN that will
              be substituted to the bind DN if a  bind  with  the
              backend's  "rootdn" succeeds.  The true "rootdn" of
              the target server ought not be used;  an  arbitrary
              administrative DN should used instead.

       pseudorootpw <substitute password in case of rootdn bind>
              This  directive  sets  the  credential that will be
              used in case a bind  with  the  backend's  "rootdn"
              succeeds,  and the bind is propagated to the target
              using the "pseudorootdn" DN.

So you still need to bind, but you don't need to know what identity
is legal on the remote server.  If you bind as a privileged user
to the proxy, the proxy on turn will bind as another privileged user
to the remote server.  This option is basically useless unless it's
used with care and only when appropriate.  What is essentially does
is hide the real identity on the remote host, while allowing anyone
who knows the privileged identity on the proxy to perform privileged
operations.  To obtain what I suppose you need, i.e. make an
unauthenticated client request be proxied as an authenticated one,
I think you need to hack the code.  In any case, you don't need
back-meta since you're proxying only one remote server.  Look at
back-ldap; you'll see that an unauthenticated request doesn't trigger
back-ldap's bind, so you'll basically get to back-ldap's search as
anonymous.  There is a ldap_back_dobind() func that does the bind
if required.  You may hack it to force an identity with a valid
password for anonymous requests, which you might want to make
configurable.  I think you're on your own because I don't think this
change is eve useful.  If you use OpenLDAP 2.2, you could also
implement an overlay that turns anonymous requests into authenticated
ones with a configurable privileged user.  This change could be
a bit more useful for special braindead clients, but in general
I think your approach is very dangerous.  I think clients should
be able to bind, and a client that is not, is not worth using.


Pierangelo Masarati