[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: ldapsearch query via OpenLDAP proxy to AD
Here is what I've been trying to do for the last month:
have a user sitting at the text login for a linux client box use LDAP authentication over to our Windows Active Directory to gain access to this linux box (i.e. login and get a shell).
A. I do not wish to have the pam_ldap and nss_ldap solution on the box.
B. I wish to have the linux client send its LDAP authentication calls to a Linux server running OpenLDAP server which in turn proxies the authentication calls to the Windows Active Directory and when properly authenticated, allow login to the linux client.
1. Knowing that Windows Active Directory does not allow anonymous connections - only bound authenticated ones, can this scenario be done?
2. what are the exact changes that need to be made to the linux client (/etc/ldap.conf, /etc/pam.d/login, /etc/nsswitch.conf maybe) and the server's OpenLDAP slapd.conf (back-ldap? or back-meta? - also, what additional parameters need to be used - I've read the man pages repeatedly and tried numerous scenarios - the man pages are not clear enough for me) to make this happen?
3. Are there any changes that need to be made in the active directory schema? If so, what are they exactly?
4. Since ldapsearch evidently cannot be used to test this, what tools can be used to test this?
-----Original Message-----
From: Pierangelo Masarati [mailto:ando@sys-net.it]
Sent: Tue 4/27/2004 7:33 AM
To: Lank, Tim
Cc: openldap-software@OpenLDAP.org
Subject: 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
>
> uri
> "ldap://192.168.1.89/cn=users,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 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
> 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.
p.
--
Pierangelo Masarati
mailto:pierangelo.masarati@sys-net.it
***************************************************************************************************
The information in this email is confidential and may be legally privileged. Access to this email by anyone other than the intended addressee is unauthorized. If you are not the intended recipient of this message, any review, disclosure, copying, distribution, retention, or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you are not the intended recipient, please reply to or forward a copy of this message to the sender and delete the message, any attachments, and any copies thereof from your system.
***************************************************************************************************