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

Ldap Autofs Connection Issue


Here is an interesting dilemma that we are trying to figure out.


All running 2.4.38, this is a test environment.  Server1 is a client to itself, server2 is a client to itself, and client1 is a client to server2.  

client1's LDAP Autofs (in the /etc/nsswitch.conf) is pointing to server2...and it works fine.

In the /etc/sysconfig/autofs file on the client (client1) the URI entry indicates:  "ldap://server2.example.ldap";; and the /etc/nsswitch.conf file shows "ldap"

On both server1 and server2, for now -- because if fails otherwise, the URI in the /etc/sysconfig/autofs shows "ldaps://server1.production.ldap"; and the /etc/nsswitch.conf file shows "ldap".

As you can see, the production server is using port 636 (SSL), the test environment is using TLS over port 389. Neither test environment server holds the production certificates, and the production side is not holding the test environment certs.

Another interesting tidbit, is all the Automount/NFS servers are NetApp filers and they hold certs for the Production Environment, except one which is a Test Filer (in the Test Environment).

Sorry if this sounds like an old "Abbott & Costello" routine from the 30's...

If anyone can shed some light on what to look for.  That would be great.  By the way, permission is not an issue.  I can explicitly mount all mountpoints to all three in the test environment.  The issue is LDAP and Autofs in the Test environment.

Thanks, in advance.

-----Original Message-----
From: openldap-technical-bounces@OpenLDAP.org [mailto:openldap-technical-bounces@OpenLDAP.org] On Behalf Of Dieter KlÃnter
Sent: Friday, January 24, 2014 4:09 PM
To: openldap-technical@openldap.org
Subject: Re: Ldap Connection Issue

Am Fri, 24 Jan 2014 14:45:25 -0500
schrieb "Borresen, John - 0442 - MITLL" <John.Borresen@ll.mit.edu>:

> All,
> Very similar issue that Warron was/is having.
> Server1: # ldapsearch -W -x -ZZ -b cn=config -v -D cn=admin,cn=config
> Server1: # ldapsearch -W -x -ZZ -H ldap://server2.example.ldap -b 
> cn=config -v -D cn=admin,cn=config
> These commands work (they returns the dbase as expect & desired), both 
> servers are clients to themselves and the other server (using 
> self-signed wildcard certificates) Both ldap.confs are identical, the 
> one on server1 was used on server2.  The URI directive looks like:
> uri ldap://server1.example.ldap ldap://server1.<FQDN> 
> ldap://server2.example.ldap ldap://server2.<FQDN>
> Server2:
> a)      # ldapsearch -W -x -ZZ -b cn=config -v -D cn=admin,cn=config
>       Fails with:
>       ldap_initialize( <DEFAULT> )
>              ldap_start_tls: Connect error (-11)
> b)      # ldapsearch -W -x -ZZ -H ldap://server2.example.ldap -b
> cn=config -v -D cn=admin,cn=config
> ldap_initialize( ldap://server2.example.ldap:389/??base )
> ldap_start_tls: Connect error (-11)
> c)       # ldapsearch -W -x -ZZ -h ldap://server1.example.ldap -b
> cn=config -v -D cn=admin,cn=config
> d)      ldap_initialize( ldap://ldap:%2F%2Fserver1.example.ldap)
> e)      Could not create LDAP session handle for
> URI=ldap://ldap:%2F%2Fgp42-admin4.llan.ll.mit.edu (-9): Bad parameter 
> to an ldap routine
> There is one other client that like server1 can search the dbase(s) on 
> both servers (it too is a client of both servers).
> Any ideas at what to look for?

read on ldapsearch(1) and distinction of -h and -H parameters.
furthermore read on LDAP URL and escape sequences (RFC-4516).


Dieter KlÃnter | Systemberatung
GPG Key ID: E9ED159B