[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: ldapsearch query via OpenLDAP proxy to AD
Perhaps I still don't understand. The username and password that the linux clients would be putting in are the same as their Active Directory usernames and passwords. My thought was that I would be able to not have to setup the pam_ldap and nss_ldap on every linux client, but rather point them at an OpenLDAP server setup as a proxy that will take care of passing these credentials back and forth from the AD to the respective linux clients.
Is this not how it works?
In order to do authenticate linux clients to the AD, from what you are indicating below, I cannot use OpenLDAP in this way using either back-meta or back-ldap because they cannot pass the original username and password "as-is" over to the AD and the approval or denial back to the originating client. Please clarify.
Thanks,
Tim
-----Original Message-----
From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]
Sent: Tuesday, April 27, 2004 1:34 PM
To: Lank, Tim
Cc: ando@sys-net.it; openldap-software@OpenLDAP.org
Subject: RE: ldapsearch query via OpenLDAP proxy to AD
At 06:44 AM 4/27/2004, Lank, Tim wrote:
>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.
Except for the proxy piece, this isn't specific to OpenLDAP Software.
>1. Knowing that Windows Active Directory does not allow anonymous connections - only bound authenticated ones, can this scenario be done?
Well, I assume the anonymous access bit is policy issue.
(e.g., one likely can reconfigure AD to allow anonymous).
So, assuming that, clients likely should be authenticating
to the proxy as they would to AD, otherwise you are just
circumventing policy (your own or some else's).
I believe back-ldap supports simple bind proxying.
>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)
The PAM & NSS questions are for other lists.
OpenLDAP's ldap.conf(5) provides defaults for ldapsearch(1) and
other LDAP clients, but it likely doesn't factor in this problem.
(A separate ldap.conf(5) belonging to pamldap and nssldap likely
does, but that's a topic for other lists.)
>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?
I not sure back-ldap supports proxying an anonymous request (it received)
as some authenticated user.
>3. Are there any changes that need to be made in the active directory schema? If so, what are they exactly?
Questions for MS AD forum mostly. If your intent is to allow
anonymous users to access information held in AD, seems you
could just reconfigure AD to allow that. How to do that is,
again, a question for a MS AD forum.
>4. Since ldapsearch evidently cannot be used to test this, what tools can be used to test this?
ldapsearch(1) can be used to test the slapd(8). And, as you
are having trouble understanding how slapd(8) itself works,
it is best to stick with ldapsearch(1) than to complicate
things by other things you don't yet understand (until you
really understand what slapd(8) does).
>-----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.
>***************************************************************************************************
***************************************************************************************************
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.
***************************************************************************************************