openldap-technical

openldap-technical@openldap.org

21 participants
9802 discussions

multi master no syncing.
by Sébastien Bernard 17 Oct '11

17 Oct '11

Hi, I've setup a multimaster cluster composed of two machine (in my example 192.168.0.204 and 192.168.0.197). Everything is working ok and both side are replicating ok. However, I've a problem I'd like to submit to your sagacity. When I put down a server, and modify the other server (delete or add), when the first server comes back, the modifications are not pushed in the old server. Server 1 says Entry cn=seb,ou=orgunit,o=org,dc=example,dc=com changed by peer, ignored Adding new entries works ok and synchronisation happens but for the nodes altered while one of the servers was down, the modifications are lost (or more precisely ignored by the other). My questions: Is this normal behaviour (Maybe I got the configuration wrong) ? How may I force the missing entries to be replicated to the other ? (Only solution I found is to wipe the entire database on the down server that force a replication from its peer). sincerely, Seb Here an extract of the slapd.log from server 1: Sep 22 10:12:32 dhcp204 slapd[2689]: do_syncrep2: rid=002 (-1) Can't contact LDAP server Sep 22 10:12:32 dhcp204 slapd[2689]: do_syncrepl: rid=002 rc -1 retrying (4 retries left) Sep 22 10:12:32 dhcp204 slapd[2689]: do_syncrep2: rid=004 (-1) Can't contact LDAP server Sep 22 10:12:32 dhcp204 slapd[2689]: do_syncrepl: rid=004 rc -1 retrying (4 retries left) Sep 22 10:12:32 dhcp204 slapd[2689]: conn=1002 op=2 UNBIND Sep 22 10:12:32 dhcp204 slapd[2689]: conn=1002 fd=19 closed Sep 22 10:12:32 dhcp204 slapd[2689]: conn=1003 op=2 UNBIND Sep 22 10:12:32 dhcp204 slapd[2689]: conn=1003 fd=20 closed Sep 22 10:12:37 dhcp204 slapd[2689]: slap_client_connect: URI=ldap://192.168.0.197 DN="cn=config" ldap_sasl_bind_s failed (-1) Sep 22 10:12:37 dhcp204 slapd[2689]: do_syncrepl: rid=002 rc -1 retrying (3 retries left) Sep 22 10:12:37 dhcp204 slapd[2689]: slap_client_connect: URI=ldap://192.168.0.197 DN="cn=manager,dc=example,dc=com" ldap_sasl_bind_s failed (-1) Sep 22 10:12:37 dhcp204 slapd[2689]: do_syncrepl: rid=004 rc -1 retrying (3 retries left) Sep 22 10:12:42 dhcp204 slapd[2689]: slap_client_connect: URI=ldap://192.168.0.197 DN="cn=manager,dc=example,dc=com" ldap_sasl_bind_s failed (-1) Sep 22 10:12:42 dhcp204 slapd[2689]: do_syncrepl: rid=004 rc -1 retrying (2 retries left) Sep 22 10:12:42 dhcp204 slapd[2689]: slap_client_connect: URI=ldap://192.168.0.197 DN="cn=config" ldap_sasl_bind_s failed (-1) Sep 22 10:12:42 dhcp204 slapd[2689]: do_syncrepl: rid=002 rc -1 retrying (2 retries left) Sep 22 10:12:47 dhcp204 slapd[2689]: slap_client_connect: URI=ldap://192.168.0.197 DN="cn=manager,dc=example,dc=com" ldap_sasl_bind_s failed (-1) Sep 22 10:12:47 dhcp204 slapd[2689]: do_syncrepl: rid=004 rc -1 retrying (1 retries left) Sep 22 10:12:47 dhcp204 slapd[2689]: slap_client_connect: URI=ldap://192.168.0.197 DN="cn=config" ldap_sasl_bind_s failed (-1) Sep 22 10:12:47 dhcp204 slapd[2689]: do_syncrepl: rid=002 rc -1 retrying (1 retries left) Sep 22 10:12:52 dhcp204 slapd[2689]: slap_client_connect: URI=ldap://192.168.0.197 DN="cn=config" ldap_sasl_bind_s failed (-1) Sep 22 10:12:52 dhcp204 slapd[2689]: do_syncrepl: rid=002 rc -1 retrying Sep 22 10:12:52 dhcp204 slapd[2689]: slap_client_connect: URI=ldap://192.168.0.197 DN="cn=manager,dc=example,dc=com" ldap_sasl_bind_s failed (-1) Sep 22 10:12:52 dhcp204 slapd[2689]: do_syncrepl: rid=004 rc -1 retrying Sep 22 10:12:57 dhcp204 slapd[2689]: slap_client_connect: URI=ldap://192.168.0.197 DN="cn=config" ldap_sasl_bind_s failed (-1) Sep 22 10:12:57 dhcp204 slapd[2689]: do_syncrepl: rid=002 rc -1 retrying (4 retries left) Sep 22 10:12:57 dhcp204 slapd[2689]: slap_client_connect: URI=ldap://192.168.0.197 DN="cn=manager,dc=example,dc=com" ldap_sasl_bind_s failed (-1) Sep 22 10:12:57 dhcp204 slapd[2689]: do_syncrepl: rid=004 rc -1 retrying (4 retries left) Sep 22 10:13:02 dhcp204 slapd[2689]: conn=1007 fd=13 ACCEPT from IP=192.168.0.197:55471 (IP=0.0.0.0:389) Sep 22 10:13:02 dhcp204 slapd[2689]: conn=1007 op=0 BIND dn="cn=manager,dc=example,dc=com" method=128 Sep 22 10:13:02 dhcp204 slapd[2689]: conn=1007 op=0 BIND dn="cn=manager,dc=example,dc=com" mech=SIMPLE ssf=0 Sep 22 10:13:02 dhcp204 slapd[2689]: conn=1007 op=0 RESULT tag=97 err=0 text= Sep 22 10:13:02 dhcp204 slapd[2689]: conn=1008 fd=15 ACCEPT from IP=192.168.0.197:55473 (IP=0.0.0.0:389) Sep 22 10:13:02 dhcp204 slapd[2689]: conn=1008 op=0 BIND dn="cn=config" method=128 Sep 22 10:13:02 dhcp204 slapd[2689]: conn=1008 op=0 BIND dn="cn=config" mech=SIMPLE ssf=0 Sep 22 10:13:02 dhcp204 slapd[2689]: conn=1008 op=0 RESULT tag=97 err=0 text= Sep 22 10:13:02 dhcp204 slapd[2689]: conn=1008 op=1 SRCH base="cn=config" scope=2 deref=0 filter="(objectClass=*)" Sep 22 10:13:02 dhcp204 slapd[2689]: conn=1008 op=1 SRCH attr=* + Sep 22 10:13:02 dhcp204 slapd[2689]: conn=1008 op=1 INTERM oid=1.3.6.1.4.1.4203.1.9.1.4 Sep 22 10:13:02 dhcp204 slapd[2689]: conn=1007 op=1 SRCH base="dc=example,dc=com" scope=2 deref=0 filter="(objectClass=*)" Sep 22 10:13:02 dhcp204 slapd[2689]: conn=1007 op=1 SRCH attr=* + Sep 22 10:13:02 dhcp204 slapd[2689]: srs csn 20110922081225.199039Z#000000#000#000000 Sep 22 10:13:02 dhcp204 slapd[2689]: log csn 20110922081225.199039Z#000000#000#000000 Sep 22 10:13:02 dhcp204 slapd[2689]: cmp 0, too old Sep 22 10:13:02 dhcp204 slapd[2689]: Entry cn=seb,ou=orgunit,o=org,dc=example,dc=com changed by peer, ignored Sep 22 10:13:02 dhcp204 slapd[2689]: syncprov_search_response: cookie=rid=003,csn=20110922081235.611410Z#000000#000#000000 Sep 22 10:13:02 dhcp204 slapd[2689]: conn=1007 op=1 INTERM oid=1.3.6.1.4.1.4203.1.9.1.4 Sep 22 10:17:57 dhcp204 slapd[2689]: do_syncrep2: rid=002 LDAP_RES_INTERMEDIATE - REFRESH_DELETE Sep 22 10:17:57 dhcp204 slapd[2689]: do_syncrep2: rid=004 LDAP_RES_INTERMEDIATE - REFRESH_DELET

3 4

adding monitor to cn=config on already running slapd
by Craig White 17 Oct '11

17 Oct '11

The openldap guide suggests that the configuration for dynamic configuration is yet to be written and it seems it is probably easy to get configured from the start but not intuitive enough for me to add to an already running server. (this is my consumer if that makes a difference) # cat monitor-add.ldif # Load dynamic backend modules dn: cn=module,cn=config changetype: add add: module olcModuleload: back_monitor - # http://www.openldap.org/doc/admin24/monitoringslapd.html dn: olcDatabase=monitor,cn=config #objectClass: olcDatabaseConfig changetype: add add: olcDatabase olcDatabase: {2}monitor # ./monitor-add.sh Enter LDAP Password: adding new entry "cn=module,cn=config" ldapmodify: update failed: cn=module,cn=config ldap_add: Bad parameter to an ldap routine (-9) I can't seem to find the right ldif combination to add monitor (Ubuntu Lucid / slapd 2.4.21-0ubuntu5.5) # grep ModulePath /etc/ldap/slapd.d/cn\=config/cn\=module\{0\}.ldif olcModulePath: /usr/lib/ldap -- Craig White ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ craig.white(a)ttiltd.com 1.800.869.6908 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ www.ttiassessments.com Need help communicating between generations at work to achieve your desired success? Let us help!

4 5

Re: Syncrepl SSL fail
by Hugo Deprez 17 Oct '11

17 Oct '11

Hello, tls_reqcert=never is necessary for the replication. If it is not defined, I get an error. The weird thing, is that I do have the same configuration on another host, running Debian Lenny with slapd version 2.4.23-3 and I don't have to define this parameter. The server I report the error, is running 2.4.23-7 on Squeeze. Is there any way to explain this difference ? Regards, Hugo On 17 October 2011 04:27, Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > --On Sunday, October 16, 2011 12:51 AM -0700 Howard Chu <hyc(a)symas.com> > wrote: > >> Quanah Gibson-Mount wrote: >>> >>> >>> --On October 13, 2011 10:43:55 AM -0700 Josh Miller >>> <joshua(a)itsecureadmin.com> wrote: >>> >>>> >>>> On Oct 13, 2011, at 10:29 AM, Quanah Gibson-Mount wrote: >>>>> >>>>> I don't see any of the tls_* options to the syncrepl configuration >>>>> here. Likely the syncrepl client is unable to verify the master's >>>>> cert. I would note that using refreshOnly is ill-advised. >>>> >>>> Hi Quanah, >>>> >>>> Why is RefreshOnly ill-advised? That is the recommendation in the docs >>>> (very timely as I just set this up again myself). >>>> >>>> re: http://www.openldap.org/doc/admin24/replication.html >>> >>> The admin guide has examples, not recommendations. In any case, I fully >>> intend to change those examples to be refreshAndPersist so people stop >>> defaulting to refreshOnly. It is not always reliable, and your >>> significantly delay your replication by using it. >> >> Of course, it may be the only thing that works reliably if you have a >> firewall that silently kills old connections. >> >> The examples should stand as-is. We cannot predict what environment it's >> going to be deployed in. It's up to administrators to use their brains >> and know these details of their network. > > I think at the least we should document both. Virtually everyone takes the > admin guide verbatim without comprehending what it is they are doing. Giving > them two options would hopefully at least make them have to consider why > there are multiple options. > > --Quanah > > -- > > Quanah Gibson-Mount > Sr. Member of Technical Staff > Zimbra, Inc > A Division of VMware, Inc. > -------------------- > Zimbra :: the leader in open source messaging and collaboration > >

1 0

"TLS_REQCERT allow" rejects CN and hostname mismatch?
by Noël Köthe 16 Oct '11

16 Oct '11

Hello, (openldap 2.4.25 on Debian GNU/Linux) TLS_REQCERT allow is documented with "The server certificate is requested. If no certificate is provided, the session proceeds normally. If a bad certificate is provided, it will be ignored and the session proceeds normally." But if I test it it looks like the common name (CN) is checked against the hostname of the server: $ cat /etc/ldap/ldap.conf BASE dc=domain,dc=lan URI ldaps://localhost TLS_CACERT /etc/ldap/ca.crt TLS_REQCERT allow $ ldapsearch -x -d320 cn=* TLS: hostname (thinker.domain.lan) does not match common name in certificate (localhost). ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) If I change TLS_REQCERT to never the ldapsearch command works like expected. Is it correct that "TLS_REQCERT allow" checks the CN and the hostname and stops when they mismatch? I found this old ITS entry with a patch which would document my described behaviour in the manpage. http://www.openldap.org/its/index.cgi/Documentation?id=4941;selectid=4941 Is this part of "TLS_REQCERT allow" just missing in the documentation or do I have a problem to understand this correctly? thx for your answer. -- Noël Köthe <noel debian.org> Debian GNU/Linux, www.debian.org

3 2

Adding new Indexes while the directory is running
by Diego Lima 16 Oct '11

16 Oct '11

Hello all, I've recently migrated my OpenLDAP servers configurations to the online configuration (cn=config) and I have a question on how to deal with indexes. I can add a new index directive while the base is running, but should I do this? Don't I need to stop the directory and reindex the whole database when I add the new index entry? Or can I add it and postpone running slapindex to a later time? Thank you! -- Diego Lima http://www.diegolima.org

5 5

Re: Syncrepl SSL fail
by Nick Milas 15 Oct '11

15 Oct '11

On 15/10/2011 2:30 μμ, Olivier Guillard wrote: > If you youldaps:// add this : > > tls_reqcert=demand > and add starttls=critical In my installations, syncrepl doesn't work with these directives (although ldapsearch using ldaps: works fine). I wonder what may be the cause... Nick

2 1

FW: Request for Support to Create new Object Class in OpenLDAP
by Hitesh Gondalia 15 Oct '11

15 Oct '11

Dear OpenLDAP Gurus OpenLDAP Softwares:==> Openldap-2.3.11.zip We have compiled OpenLDAP in Redhat Linux Platform with Back-sql (with Oracle11g) We have one session management table in our schema and which contain the 75 columns and all of them are number, varchar and timestamp data types Whether we need any extra object class in OpenLDAP or we are able to do with existing sample objects class which is available with OpenLDAP!!!!!! Please guide for create new auxiliary class for support the extra attributes in OpenLDAP. Yours valuable suggestions and Supports will appreciate for testing the same. Thanks & Regards Hitesh Gondalia DBA | CSM Dept EliteCore Technologies Pvt. Ltd. www.elitecore.com <http://www.elitecore.com/>

1 0

Re: TLS very strange behaviour
by Rich Megginson 14 Oct '11

14 Oct '11

On 10/14/2011 01:48 AM, Olivier Guillard wrote: > Hi Rich > > as far as I remember, when I used this version : > openldap-servers-2.4.23-15.el6_1.1.x86_64 > > I could use external mecanism in syncrepl and was > able to present the client certificate without asking for > the server one. > > My syncrepl sections looked like this : > > syncrepl rid=121 > provider=ldap://ldap2.example.fr > searchbase="dc=example,dc=fr" > schemachecking=on > type=refreshOnly > interval=00:00:00:05 > retry="10 +" > bindmethod=sasl > saslmech=external > tls_cert=/etc/openldap/cacerts/syncrepl.crt > tls_key=/etc/openldap/cacerts/syncrepl.key > > And that worked. BTW, I'm not sure that his should have > worked since I think normaly the protocole indicates that > the client should check the server cert before sending its. Yes, that's odd. > Anyway that worked (-: > > With openldap-servers-2.4.23-15.el6_1.3.x86_64, I'm not > able to use the external mecanism anymore if I don't add > explicitely the following directives in syncrepl: "starttls=yes", > "tls_cacert=.../cacerts/CA.crt" and "tls_reqcert=allow/try/demand" I don't think it ever should have worked without at least specifying starttls=yes (and assuming that didn't fallback - I think starttls=yes is misleading, as it will just silently fallback to plain LDAP if it doesn't establish a TLS connection - everything will seem to be working, but unless you have set up the server to require a TLS connection, it will just work and you won't know that it is not using TLS). I recommend always using starttls=critical to make sure your client will only work if TLS was successfully established. > That works in master/slave mode, that doesn't in multimaster. > > Now last thing : I've never been able to make work syncrepl > with : "starttls=yes", "tls_cacert=.../cacerts/CA.crt" and > "tls_reqcert=allow/try/demand" in multimaster N-WAY mode > anyway (nor now, nor before). > > I only made it work in master/salve and that weither using > simple or sasl bindmethod. > > So the problem is not linked to sasl in my view but with > tls in synchrepl (may be both slapd try to use the first > TLS session opened to exchange in both direction in > multimaster, a shared variable mixing information about > certicates ? something like that). Would it be possible for you to get it working with simple binddn/password auth first, to see if that is working? Then we could at least narrow down the problem to being related to sasl/external auth. > I just realise that I had a core dump collected by abrtd (not > sure if that could help nor how to use it, I'm not familiar with > this kind of debugging) : let me know if that file could help > (or if I could try to run any gdb command using that file). Yes indeed that would be very helpful. https://bugzilla.redhat.com/show_bug.cgi?id=701678#c6 has some information about handling openldap core dumps on RHEL6 > Best, > > --- > Olivier > > On Wed, Oct 12, 2011 at 10:25 PM, Rich Megginson > <rich.megginson(a)gmail.com> wrote: >> On 10/11/2011 02:38 AM, Olivier Guillard wrote: >>> Thanks Rich, see below : >>> >>>> -12272 is SSL_ERROR_BAD_MAC_ALERT and -12273 is SSL_ERROR_BAD_MAC_READ >>>> I've seen this when the client and server do not have the same SSL >>>> certificate signature algorithm support. Is everything running on RHEL6 >>>> and/or Fedora 14 and later? >>> [root@ldap2 ~]# cat /etc/issue >>> Red Hat Enterprise Linux Server release 6.1 (Santiago) >>> Kernel \r on an \m >>> >>> [root@ldap2 ~]# rpm -qa | grep -i openldap >>> openldap-2.4.23-15.el6_1.3.x86_64 >>> openldap-servers-2.4.23-15.el6_1.3.x86_64 >>> openldap-debuginfo-2.4.23-15.el6_1.1.x86_64 >>> openldap-clients-2.4.23-15.el6_1.3.x86_64 >>> >>> [root@ldap1 ~]# cat /etc/issue >>> Red Hat Enterprise Linux Server release 6.1 (Santiago) >>> Kernel \r on an \m >>> >>> [root@ldap1 ~]# rpm -qa | grep -i openldap >>> openldap-debuginfo-2.4.23-15.el6_1.1.x86_64 >>> openldap-clients-2.4.23-15.el6_1.3.x86_64 >>> openldap-2.4.23-15.el6_1.3.x86_64 >>> openldap-servers-2.4.23-15.el6_1.3.x86_64 >>> >>> [root@ldap2 cacerts]# rpm -qa | grep openssl >>> openssl-1.0.0-10.el6_1.4.x86_64 >>> >>> [root@ldap1 ldap1]# rpm -qa | grep openssl >>> openssl-1.0.0-10.el6_1.4.x86_64 >>> >>> Not sure if that made a difference but I "yum-updated" >>> on last friday and openldap servers version passed : >>> >>> from >>> openldap-servers-2.4.23-15.el6_1.1.x86_64 >>> to >>> openldap-servers-2.4.23-15.el6_1.3.x86_64 >> Was it working before you yum updated? >>> --- >>> Olivier >>> >>> On Mon, Oct 10, 2011 at 9:54 PM, Rich Megginson >>> <rich.megginson(a)gmail.com> wrote: >>> >>>>> here is what I get : >>>>> >>>>> ldap1 # /usr/sbin/slapd -f slapd.conf -h ldap:/// -u ldap -d Sync >>>>> ... >>>>> TLS: error: accept - force handshake failure: errno 11 - moznss error >>>>> -12273 >>>>> TLS: can't accept: TLS error -12273:Unknown code ___P 15. >>>>> TLS: error: connect - force handshake failure: errno 0 - moznss error >>>>> -12272 >>>>> TLS: can't connect: TLS error -12272:Unknown code ___P 16. >>>>> slap_client_connect: URI=ldap://ldap2.example.fr Warning, >>>>> ldap_start_tls failed (-11) >>>>> slap_client_connect: URI=ldap://ldap2.example.fr >>>>> ldap_sasl_interactive_bind_s failed (-6) >>>>> do_syncrepl: rid=121 rc -6 retrying >>>>> >>>>> ldap2 # /usr/sbin/slapd -f slapd.conf -h ldap:/// -u ldap -d Sync >>>>> ... >>>>> TLS: error: connect - force handshake failure: errno 0 - moznss error >>>>> -12272 >>>>> TLS: can't connect: TLS error -12272:Unknown code ___P 16. >>>>> slap_client_connect: URI=ldap://ldap1.eaxample.fr:389 Warning, >>>>> ldap_start_tls failed (-11) >>>>> slap_client_connect: URI=ldap://ldap1.example.fr:389 >>>>> ldap_sasl_interactive_bind_s failed (-6) >>>>> do_syncrepl: rid=211 rc -6 retrying >>>>> TLS: error: accept - force handshake failure: errno 11 - moznss error >>>>> -12273 >>>>> TLS: can't accept: TLS error -12273:Unknown code ___P 15. >>>>> >>>>> Any idea ? >>

1 0

Re: Syncrepl SSL fail
by Hugo Deprez 14 Oct '11

14 Oct '11

Hello, On the provider I have the following settings : TLSCACertificateFile /etc/ssl/certs/ldap-cert.pem TLSCertificateFile /etc/ssl/certs/ldap-cert.pem TLSCertificateKeyFile /etc/ldap/ssl/ldap-key.pem but no TLSCipherSuite defined. I added the starttls=yes on the consumer : Syncrepl rid=003 provider=ldaps://ldap.mydomain.fr:1024/ type=refreshOnly retry="60 10 600 +" interval=00:00:00:10 searchbase="dc=mydomain,dc=fr" scope=sub schemachecking=on bindmethod=simple starttls=yes tls_cert=/etc/ssl/certs/ldap-cert.pem tls_cacert=/etc/ssl/certs/ldap-cert-ca.pem binddn="cn=syncrepluser,o=others,dc=mydomain,dc=fr" credentials=my_password But still the same error. Any idea ? Hugo On 14 October 2011 13:52, Olivier Guillard <olivier(a)guillard.nom.fr> wrote: > Hi, > > Have you set up the follwing appropriately : > > TLSCertificateFile > TLSCertificateKeyFile > TLSCipherSuite > > On the provider ? > > You probably also want to set this up correctly in > your syncrepl section : > > starttls=yes > tls_cacert=/path/to/certificate > > I suspect better if TLS_CACERT is also properly > set up in both ldap server slapd config. > > --- > Olivier > > On Thu, Oct 13, 2011 at 6:38 PM, Hugo Deprez <hugo.deprez(a)gmail.com> wrote: >> Dear community, >> >> I setup a syncrepl between my master openldap server and a consumer. >> >> I am trying to use SSL for this syncrepl >> I got the following error in the log when I start slapd on the consumer : >> >> Oct 13 17:04:59 server slapd[16905]: slapd starting >> Oct 13 17:04:59 server slapd[16905]: slap_client_connect: >> URI=ldaps://ldap.mydomain.fr:1024/ >> DN="cn=syncrepluser,o=others,dc=mydomain,dc=fr" ldap_sasl_bind_s >> failed (-1) >> Oct 13 17:04:59 server slapd[16905]: do_syncrepl: rid=003 rc -1 >> retrying (9 retries left) >> >> >> I don't understand why it is failing as a single ldapsearch from the >> same server with the syncrepl user is working. >> >> here is my syncrepl configuration : >> >> Syncrepl rid=003 >> provider=ldaps://ldap.mydomain.fr:1024/ >> type=refreshOnly >> retry="60 10 600 +" >> interval=00:00:00:10 >> searchbase="dc=mydomain,dc=fr" >> scope=sub >> schemachecking=on >> bindmethod=simple >> binddn="cn=syncrepluser,o=others,dc=mydomain,dc=fr" >> credentials=my_password >> >> >> Any idea ? >> >> Regards, >> >> Hugo >> >> >

3 2

Re: Syncrepl SSL fail
by Hugo Deprez 14 Oct '11

14 Oct '11

Hello, I use the following ldapsearch command : ldapsearch -H ldaps://ldap.mydomain.fr:1024 -x -W -D "cn=syncrepluser,o=others,dc=mydomain,dc=fr" I did configure TLS cert file before syncrepl configuration : TLSCACertificateFile /etc/ssl/certs/ldap-replic-cert.pem TLSCertificateFile /etc/ssl/certs/ldap-replic-cert.pem TLSCertificateKeyFile /etc/ssl/certs/ldap-replic-cert.pem But those certificate are for the ldap consumer if I'm not wrong. I am currently trying the following configuration thanks to your information : Syncrepl rid=003 provider=ldaps://ldap.mydomain.fr:1024/ type=refreshOnly retry="60 10 600 +" interval=00:00:00:10 searchbase="dc=mydomain,dc=fr" scope=sub schemachecking=on bindmethod=simple tls_cert=/etc/ssl/certs/ldap-cert.pem tls_cacert=/etc/ssl/certs/ldap-cert-ca.pem binddn="cn=syncrepluser,o=others,dc=mydomain,dc=fr" credentials=my_password where tls_cert and tls_cacert provide the cert from the master server. It seems that the replication is working but I get an other error confusing : ct 14 12:46:53 server slapd[32470]: slap_client_connect: URI=ldaps://ldap.mydomain.fr:1024/ TLS context initialization failed (-1) Oct 14 12:46:53 server slapd[32470]: do_syncrepl: rid=003 rc -1 retrying (9 retries left) Oct 14 12:47:53 server slapd[32470]: do_syncrep2: rid=003 LDAP_RES_INTERMEDIATE - SYNC_ID_SET Oct 14 12:47:53 server slapd[32470]: do_syncrep2: rid=003 LDAP_RES_INTERMEDIATE - SYNC_ID_SET Oct 14 12:47:53 server slapd[32470]: do_syncrep2: rid=003 LDAP_RES_INTERMEDIATE - SYNC_ID_SET I don't really understand the TLS context initialization failed (-1) as my replication is working ? Thanks for the tips. Hugo On 13 October 2011 19:29, Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > --On Thursday, October 13, 2011 6:38 PM +0200 Hugo Deprez > <hugo.deprez(a)gmail.com> wrote: > >> Dear community, >> >> I setup a syncrepl between my master openldap server and a consumer. >> >> I am trying to use SSL for this syncrepl >> I got the following error in the log when I start slapd on the consumer : >> >> Oct 13 17:04:59 server slapd[16905]: slapd starting >> Oct 13 17:04:59 server slapd[16905]: slap_client_connect: >> URI=ldaps://ldap.mydomain.fr:1024/ >> DN="cn=syncrepluser,o=others,dc=mydomain,dc=fr" ldap_sasl_bind_s >> failed (-1) >> Oct 13 17:04:59 server slapd[16905]: do_syncrepl: rid=003 rc -1 >> retrying (9 retries left) >> >> >> I don't understand why it is failing as a single ldapsearch from the >> same server with the syncrepl user is working. >> >> here is my syncrepl configuration : >> >> Syncrepl rid=003 >> provider=ldaps://ldap.mydomain.fr:1024/ >> type=refreshOnly >> retry="60 10 600 +" >> interval=00:00:00:10 >> searchbase="dc=mydomain,dc=fr" >> scope=sub >> schemachecking=on >> bindmethod=simple >> binddn="cn=syncrepluser,o=others,dc=mydomain,dc=fr" >> credentials=my_password >> >> >> Any idea ? > > I don't see any of the tls_* options to the syncrepl configuration here. > Likely the syncrepl client is unable to verify the master's cert. I would > note that using refreshOnly is ill-advised. > > --Quanah > > > > -- > > Quanah Gibson-Mount > Sr. Member of Technical Staff > Zimbra, Inc > A Division of VMware, Inc. > -------------------- > Zimbra :: the leader in open source messaging and collaboration >

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical