All,
Here is an interesting dilemma that we are trying to figure out.
server1.example.ldap server2.example.ldap client1.example.ldap
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
-- Dieter Klünter | Systemberatung http://dkluenter.de GPG Key ID: E9ED159B 53°37'09,95"N 10°08'02,42"E