On my working master server openldap-2.3.27-8 under CentOS 5, I added:
overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100
On the slave server openldap-2.3.27-8.el5_2.4 under CentOS 5.2, I added:
syncrepl rid=123 provider=ldaps://primary-ldap-server:636 type=refreshOnly interval=01:00:00:00 searchbase="dc=mydomain,dc=com" filter="(objectClass=*)" scope=sub attrs="*" schemachecking=off bindmethod=simple binddn="cn=syncuser,dc=mydomain,dc=com" credentials=mysecret
ldap started on the slave server OK, and /var/lib/ldap has all of the database files. On that server, from the command line, I can:
[root@ldap2 ~]# ldapsearch -xLLL -b "dc=mydomain,dc=com" uid=joliver sn givenName cn dn: uid=joliver,ou=People,dc=mydomain,dc=com givenName: John sn: Oliver cn: John Oliver
But when I point another machine at that slave server, it won't authenticate:
Jul 23 03:06:28 localhost login(pam_unix)[9475]: check pass; user unknown Jul 23 03:06:28 localhost login(pam_unix)[9475]: authentication failure; logname=LOGIN uid=0 euid=0 tty=tty2 ruser= rhost= Jul 23 03:06:28 localhost login[9475]: pam_ldap: ldap_search_s No such object Jul 23 03:06:30 localhost login[9475]: FAILED LOGIN 1 FROM (null) FOR joliver, Authentication failure
[root@localhost ~]# ldapsearch -H ldaps://ldap2.mydomain.com -b "dc=mydomain,dc=com" uid=joliver sn givenName cn ldap_sasl_interactive_bind_s: Can't contact LDAP server (-1) additional info: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
[root@localhost ~]# ldapsearch -H ldap://ldap2.mydomain.com -b "dc=mydomain,dc=com" uid=joliver sn givenName cn SASL/DIGEST-MD5 authentication started Please enter your password: ldap_sasl_interactive_bind_s: Invalid credentials (49) additional info: SASL(-13): user not found: no secret in database
When using just ldap:// with ldapsearch, I don't know what password it's asking for. My LDAP password doesn't work, the LDAP admin password doesn't work, the local root password doesn't work...
Here's the odd thing. When I started setting this up, the machine that's the primary (and working) LDAP server now was running fedora-ds. I set up OpenLDAP on what is now the slave server, and it worked perfectly. I slapcat'ed it, installed OpenLDAP on the primary server, and slapadded the db. I never generated any certificates on it at all, and it works perfectly. I just regenerated the cert on the slave server, but no joy.
Hi,
John Oliver a écrit :
[root@localhost ~]# ldapsearch -H ldaps://ldap2.mydomain.com -b "dc=mydomain,dc=com" uid=joliver sn givenName cn ldap_sasl_interactive_bind_s: Can't contact LDAP server (-1) additional info: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
This is a SSL error message: your LDAP client can not identify the certificate authority that emitted the certificate presented by your server. Configure your ldap.conf file to include appropriate files (TLS_CACERT or TLS_CACERTDIR, etc).
[root@localhost ~]# ldapsearch -H ldap://ldap2.mydomain.com -b "dc=mydomain,dc=com" uid=joliver sn givenName cn SASL/DIGEST-MD5 authentication started Please enter your password: ldap_sasl_interactive_bind_s: Invalid credentials (49) additional info: SASL(-13): user not found: no secret in database
When using just ldap:// with ldapsearch, I don't know what password it's asking for. My LDAP password doesn't work, the LDAP admin password doesn't work, the local root password doesn't work...
This is because ldapsearch is trying to authenticate using SASL authentication layer. Add the "-x" option to your ldapsearch command, and you can use your LDAP password.
Here's the odd thing. When I started setting this up, the machine that's the primary (and working) LDAP server now was running fedora-ds. I set up OpenLDAP on what is now the slave server, and it worked perfectly. I slapcat'ed it, installed OpenLDAP on the primary server, and slapadded the db. I never generated any certificates on it at all, and it works perfectly. I just regenerated the cert on the slave server, but no joy.
I believe OpenSSL defaults have become more strict in certificate checking, over some recent (maybe up to 6 months ago) upgrade.
Jonathan
openldap-technical@openldap.org