[Date Prev][Date Next]
Re: ldapsearch query via OpenLDAP proxy to AD
> I am trying to query the active directory (192.168.1.89) on my network
> using ldapsearch by way of an OpenLDAP proxy (192.168.1.73) using the
> following slapd.conf:
> *************slapd.conf on 192.168.1.73******************
> 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
> "ldap://192.168.1.89/cn=users,dc=corp,dc=mycompany,dc=com" pseudorootdn
> pseudorootpw 12345678
> When I try this it works (returns results from the AD):
> ldapsearch -h 192.168.1.73 -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 192.168.1.73 -x -b 'dc=corp,dc=mycompany,dc=com' 'cn=tim*'
> What should I change in my slapd.conf to make the second query return
> 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.