Search results for "starttls" - openldap-technical

Re: SSL/TLS connection on port 389

by Buchan Milne

On Tuesday 29 January 2008 19:18:15 Carr, Chris wrote: > > It seems that no matter what you select here, if the port is > > 389, it does STARTTLS: > > > > Jan 29 17:59:16 seaknight slapd[840]: conn=0 fd=15 ACCEPT from > > IP=127.0.0.1:53243 (IP=0.0.0.0:389) > > Jan 29 17:59:16 seaknight slapd[840]: conn=0 op=0 STARTTLS > > Jan 29 17:59:16 seaknight slapd[840]: conn=0 op=0 RESULT oid= > > err=0 text= Jan 29 17:59:16 seaknight slapd[840]: conn=0 > > fd=15 TLS established tls_ssf=256 ssf=256 > > This is encouraging - I guess you are not using the same version of > slapd as I am? (I'm using 2.4.7, which apparently has a bug with > STARTTLS, at least in Debian it does). I don't use Debian, and on production platforms I don't use the packages supplied by the distro, but the rebuilds (which are available at http://staff.telkomsa.net/packages/) of the Mandriva package, for which I am the maintainer. The output in my reply was from my Mandriva 2008.0 x86_64, running the 2.3.38 package supplied with the distro. I will try and test the 2.4.7 packages sometime later today. > What log level are you choosing to get this output? Is it just "conns"? stats (256). > > However, if you select 636 as the port, it greys out the "Use secure > > connection" drop-down box, and does ldaps. > > Yes. > > > Jan 29 18:03:51 seaknight slapd[840]: conn=14 fd=27 ACCEPT from > > IP=127.0.0.1:54153 (IP=0.0.0.0:636) > > Jan 29 18:03:51 seaknight slapd[840]: conn=14 fd=27 closed > > (TLS negotiation > > failure) > > Jan 29 18:03:58 seaknight slapd[840]: conn=15 fd=27 ACCEPT from > > IP=127.0.0.1:45074 (IP=0.0.0.0:389) > > > > (Can't get it to work right right now with ldaps ...). Note that this may simply be due to me using self-signed certs ... > Me neither, though I had assumed that was password-related. > > > Note however that evo caches LDAP connections, it seems you > > need to restart it for your config changes to take effect. > > Ah, I didn't know that - thanks. > > > And, it will only prompt you for the password once the > > connection is up ... > > Hmmm. If I understand the output correctly, it's rejecting the > connection before asking for a password. I will have to investigate this > again. > > > > Could somebody explain to me how to tell slapd to accept secure > > > connections on port 389? > > > > start slapd with with no -h flag, or -h "ldaps:/// ldap:///" > > so it listens on port 636 for ldaps connections, and 389 for > > ldap connections (which could use START_TLS to upgrade). > > I just have -h "ldaps:///" - I presumed the ldap:/// was covered > automatically as the default. No, logically there should be a way to prevent the use of a port which could be used by some other application ... > > > Sorry if this is a really stupid question, but according to > > > the docs the "startTLS" process should be automatic if a > > > secure connection comes in on port 389. Something is > > > obviously not quite right. > > > > Hmm, SSL/TLS isn't really automatic ... > > Sorry, I meant that the connection is upgraded to SSL/TLS if the > STARTTLS command is sent by the client (which you have verified > Evolution does). > > Thanks muchly for your help. I will do some more testing with Evolution > until I lose the will to live once again. > > I am now even getting errors with Outlook. It seems to connect ok, but > whenever I do a search it says "The Properties dialog box could not be > displayed. To display the Properties dialog box, you must select exactly > one item." - I don't know what this is about, I get the same message > whether my search is gibberish (should return no matches), unique > (should return a single match) or general (should return multiple > matches). No results are returned. It seems to be a completely incorrect > error message. It seems Outlook doesn't like self-signed certs, so I'll look at this later once I've had time to sort out certificates for these boxes. Regards, Buchan

17 years, 5 months

Re: Syncrepl SSL fail

by Hugo Deprez

Hello, if I don't sepcify the key path I get the following error when starting slpad : slap_client_connect: URI=ldaps://ldap.domain.fr:1024/ TLS context initialization failed (-1) slapd[31043]: do_syncrepl: rid=003 rc -1 retrying (9 retries left) So I need the tls_key=/etc/ldap/ssl/ldap-key.pem pointing to the key of the provider. Any idea why I should specify the private key of the provider ? Regards, On 2 December 2011 15:11, Raffael Sahli <public(a)raffaelsahli.com> wrote: > On 12/02/2011 02:50 PM, Hugo Deprez wrote: >> >> Hello Philip, >> >> thank you for your explanation. >> >> This is more clear now. >> >> So I changed my configuration like : >> >> Syncrepl rid=003 >> provider=ldaps://my.server:1024/ >> type=refreshOnly >> retry="60 10 600 +" >> interval=00:00:00:10 >> searchbase="dc=my,dc=domain" >> scope=sub >> schemachecking=on >> bindmethod=simple >> tls_reqcert=demand >> tls_cert=/etc/ssl/certs/ldap-cert.pem >> tls_cacert=/etc/ssl/certs/ldap-cert.pem >> tls_key=/etc/ldap/ssl/ldap-key.pem >> binddn="cn=syncrepluser..." >> credentials=******** >> >> I added the tls_key, tls_cacert, tls_reqcert parameter. >> The tls option are using the certificate and the key of the LDAP Provider. >> >> The last thing I don't understand is that the tls_key is needed. So I >> need to deploy the private key of the provider to each consumer. >> >> I though the certificate would be sufficient ? > > > No you don't have to deploy the private key! > In syncrepl, just define the tls_cacert, and it works. > > > >> >> Regards, >> >> >> >> >> >> On 18 October 2011 06:28, Philip Guenther >> <guenther+ldaptech(a)sendmail.com> wrote: >>> >>> On Sun, 16 Oct 2011, Hugo Deprez wrote: >>>> >>>> It seems that the proper configuration for my case is : >>>> >>>> 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_reqcert=never >>>> binddn="cn=syncrepluser,o=others,dc=mydomain,dc=fr" >>>> credentials=my_password >>>> >>>> It works, but I am confuse with those parameters. If I understand >>>> well, I will never use TLS here, but only ssl ? >>>> Hence, it was a TLS issue ? >>> >>> No, you're using TLS. You're just not using the StartTLS operation. >>> >>> There are two ways to use SSL/TLS: "negotiate-on-connect" and "upgrade >>> from clear". The former is what you get when you use an ldaps:// URL, >>> where the first data the client sends is the raw SSL/TLS ClientHello >>> packet. The latter is what you get when you use an ldap:// URL and have >>> starttls=yes or starttls=critical, where the first data the client sends >>> is LDAP protocol data in the clear, including a StartTLS request. If the >>> server sends a success response to that StartTLS request, then the client >>> starts the SSL/TLS handshake with its ClientHello packet. >>> >>> This should answer why it failed when you tried to combine an ldaps:// >>> URL >>> with starttls=yes: the exchange was already using SSL/TLS and (rightly) >>> libldap won't let you negotiate multiple levels of SSL/TLS encryption. >>> >>> (You may note that I write "SSL/TLS". That's because they're just >>> different versions of the same protocol. Using 'SSL' as a shorthand for >>> "negotiate on connect" and 'TLS' for "upgrade from clear" is poor naming, >>> as the choice of method is orthogonal to the protocol version. Your >>> ldaps:// connection is probably negotiating the TLS 1.0 protocol (aka SSL >>> version 3.1), just as an ldap:// connection using StartTLS may, on a >>> poorly configured server, negotiate SSL 3.0) >>> >>> >>> Next: the fact that you need tls_reqcert=never for TLS negotiation to >>> succeed strongly suggests the problem is either >>> a) the subject and subjectAltName of the cert don't match the hostname in >>> the URL, OR >>> b) the client doesn't have the self-signed CA cert at the root of the >>> signing chain for the server's cert. >>> >>> Those are both necessary to protect the server against Man-in-the-Middle >>> attacks. >>> >>> (It used to be that tls_reqcert=allow would disable check (b) and only >>> perform check (a), or at least that was the case when using the OpenSSL >>> crypto backend, but that behavior has apparently been removed from the >>> version in git as of August. Given the vagaries of the error reporting >>> of >>> the underlying crypto libraries, this was a useful tool in tracking down >>> which check was causing TLS failures. Oh well.) >>> >>> So, does the server's certificate subject or subjectAltName match the >>> hostname from the URL the client is using? Have you verified that the CA >>> at the root of the server's cert's chain really is configured for the >>> client? >>> >>> >>> Philip Guenther > > > > -- > Raffael Sahli > public(a)raffaelsahli.com > Switzerland >

13 years, 7 months

Re: ldap PDC -- Failed to issue the StartTLS instruction

by Ivan Ordonez

Quanah Gibson-Mount wrote: > > > --On August 4, 2009 3:51:18 PM -0700 Ivan Ordonez > <iordonez(a)nature.berkeley.edu> wrote: > >> Hello, >> >> We've been using an ldap based PDC from quite a while. Now we're >> suddenly having trouble getting our main fileserver to talk with the >> PDC. >> >> samba-3.2.13 on solaris 10. >> >> Here is our smb.conf global defs: >> >> Server role: ROLE_DOMAIN_MEMBER >> [global] >> workgroup = CNRDOM >> server string = nature (Samba %v) >> security = DOMAIN >> passdb backend = ldapsam:ldaps://169.229.xxx.yyy >> log level = 5 >> log file = /var/log/samba/log.%m >> name resolve order = wins host lmhosts >> os level = 65 >> local master = No >> domain master = No >> dns proxy = No >> wins support = Yes >> ldap ssl = start tls > > ldaps:// and startTLS are mutually exclusive. Pick one and only one. We tried removing the "s" on ldaps:// and still no go. > > --Quanah > > > -- > > Quanah Gibson-Mount > Principal Software Engineer > Zimbra, Inc > -------------------- > Zimbra :: the leader in open source messaging and collaboration

15 years, 11 months

openldap to AD proxy

by Alex Samad - Yieldbroker

Hi I am still struggling with the my openldap to AD proxy connection. I have successfully connected such that I can do search when I bind to openldap with an AD dn, but I want to be able to do anon search and I want anon to map through to a dn I have created in AD which has read only rights. dn: olcDatabase={3}ldap,cn=config objectClass: olcDatabaseConfig objectClass: olcLDAPConfig olcDatabase: {3}ldap olcAccess: {0}to * by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" manage by * read olcReadOnly: TRUE olcRootDN: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth olcSizeLimit: 500 olcSuffix: dc=xyz,dc=com olcDburi: "ldap://ldap. xyz.com " olcDbRebindAsUser: TRUE olcDbChaseReferrals: TRUE olcdbaclbind: bindmethod=simple binddn="CN=ad readonly,OU=YB Services,OU= xyz,DC= xyz,DC=com" credentials=":)" starttls=no olcDbIDAssertBind: bindmethod=none binddn="CN=ad readonly,OU=YB Services,OU= xyz,DC= xyz,DC=com" credentials=":)" starttls=no I have a subordinate db at ou=external, DC= xyz,DC=com I can do a ldapsearch -x -D " CN=ad readonly,OU=YB Services,OU= xyz,DC= xyz,DC=com" -b " DC= xyz,DC=com" -w :) what I can't do is ldapsearch -x -b " DC= xyz,DC=com" I am thinking I want to map anon request through to the readonly DN. But still leave it such that when people bind to openldap as themselves they bind to AD as themselves How would I do that ? Thanks Alex

13 years, 2 months

Re: Ubuntu Server 12.04: StartTLS

by Dan White

On 11/05/12 08:29 +0100, Admus wrote: >On 11/04/2012 11:59 PM, Dan White wrote: >>On 11/04/12 23:13 +0100, admus wrote: >>>Hello, >>>I'm following https://help.ubuntu.com/12.04/serverguide/openldap-server.html#openldap-tls… >>>how to: >>>LDAP serwer starts correctly but when I tries to test StartTLS: >>>ldapsearch -x -H ldap:/// -ZZ -d -1 >>>I gets the following error: >>>TLS: peer cert untrusted or revoked (0x42) >>>TLS: can't connect: (unknown error code). >>>ldap_err2string >>>ldap_start_tls: Connect error (-11) >>> additional info: (unknown error code) >>>Any idea? >> >>Your hostname will need to match the certificate you have installed. '-H >>ldap:///' will, instead, need to include the hostname matching your >>certificate. >> >>For project documentation, see chapter 16 of the OpenLDAP Administrator's >>Guide, slapd-config(5), ldap.conf(5), and ldapsearch(1). >> > >ldapsearch -x -H ldap://ldap1.example.com -ZZ -d -1 > >Does not help, same error. CN in my certificate is ldap1.example.com. Assuming that your OpenLDAP was compiled against GnuTLS, use the GnuTLS tools to trouble shoot your certificate. A google search for "peer cert untrusted or revoked (0x42)" finds users who also received that error. -- Dan White

12 years, 8 months

Re: Understanding TLS SSF

by Patrick Patterson

Hello On Wed, Jul 30, 2008 at 9:59 AM, J Davis <mrsalty0(a)gmail.com> wrote: > Greetings, > > I'm testing an installation of openldap 2.4.9. I want to enforce TLS for > all access to the directory. > My problem is that I cannot get the client to meet the ssf restictions I > have in place. The documentation I've seen on ssf and tls_ssf is very sparse > so I don't really understand what it does. > > I'm using self signed cert created using the openssl CA.sh script. > > Relevant portions of the slapd.conf... > > TLSCACertificateFile /etc/ldap/ssl/cacert.pem > TLSCertificateFile /etc/ldap/ssl/servercrt.pem > TLSCertificateKeyFile /etc/ldap/ssl/serverkey.pem > ... > access to * > by tls_ssf=128 ssf=128 anonymous auth > by tls_ssf=128 ssf=128 self write > > Relevant portions of the lapd.conf... > > TLS_CACERT /etc/ldap/ssl/cacert.pem > > With those ACLs in place I get the following error: > > $ ldapsearch -x -ZZ -D "uid=jake,ou=people,dc=example,dc=com" -W -b > "uid=jake,ou=people,dc=example,dc=com" > ldap_bind: Invalid credentials (49) > You may want to try adding -q as one of the options to your ldapsearch. It appears that the tls_ssf turns on STARTTLS, instead of LDAP over SSL and in order to use that, you need to tell the client to use starttls as well, which is what (if I read the man page correctly), -q does. Have fun. -- Personal Mail from Patrick Patterson No company affiliation

16 years, 11 months

RE: [EXT] RE: OpenLDAP Pass-through Authentication

by Quanah Gibson-Mount

--On Friday, February 14, 2025 7:01 AM +0000 "Windl, Ulrich" <u.windl(a)ukr.de> wrote: > Can you explain the intentions for " olcRemoteAuthTLS: starttls=yes > tls_reqcert=never"? Starting TLS without a certificate? Do you expect > encryption then? Just means it doesn't check the cert for validity AFAIK. AD often uses its own cert system so the end client may not be aware of the CA chain for the provided cert on the AD server. --Quanah

4 months, 2 weeks

Ipad/iPhone ldap setup

by Chris Jackson

I am having trouble accessing my openldap server over SSL using an iPhone/iPad/iPod Touch using ios 4.2.1. If I check the SSL box in the client setup on the iPhone/iPad/iPod Touch I get an error in the slapd log -- TLS negotiation Failure. With logging level 9 I get TLS accept failure error=-1 id=1. Other clients work fine over SSL/StartTLS. Outlook, addressbook in osX 10.6, jxplorer. I am using openldap 2.4.19-15 on RHEL6 with a comodo wildcard SSL cert. Chris Jackson

14 years, 4 months

Spurious Start TLS failed errors on proxyed bind OpenLDAP 2.4.40

by Janne Peltonen

Hi! We've got a proxy OpenLDAP setup using the "ldap" proxy database (the newer "meta" backend had some issues, so I couldn't use that one). Most of the time, the proxy bind goes OK, but sometimes, the connection goes like this (proxy log, using ldaps): --clip-- Jan 7 16:01:12 ldap-r-1 slapd[16851]: conn=7716 fd=96 ACCEPT from IP=128.214.54.152:36460 (IP=0.0.0.0:636) Jan 7 16:01:12 ldap-r-1 slapd[16851]: conn=7716 fd=96 TLS established tls_ssf=256 ssf=256 Jan 7 16:01:12 ldap-r-1 slapd[16851]: conn=7716 op=0 BIND dn="<removed>" method=128 Jan 7 16:01:12 ldap-r-1 slapd[16851]: conn=7716 op=0 RESULT tag=97 err=52 text=Start TLS failed Jan 7 16:01:12 ldap-r-1 slapd[16851]: conn=7716 fd=96 closed (connection lost) --clip-- On the backend, this appears to be the case that a new connection kind of overruns the old one; see what happens with connection 6983: --clip-- Jan 7 16:01:12 ldap-v-2 slapd[61739]: conn=6983 fd=23 ACCEPT from IP=128.214.222.155:46144 (IP=0.0.0.0:389) Jan 7 16:01:12 ldap-v-2 slapd[61739]: conn=6984 fd=41 ACCEPT from IP=128.214.222.155:46146 (IP=0.0.0.0:389) Jan 7 16:01:12 ldap-v-2 slapd[61739]: conn=6983 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Jan 7 16:01:12 ldap-v-2 slapd[61739]: conn=6983 op=0 STARTTLS Jan 7 16:01:12 ldap-v-2 slapd[61739]: conn=6983 op=1 UNBIND Jan 7 16:01:12 ldap-v-2 slapd[61739]: conn=6983 fd=23 closed Jan 7 16:01:12 ldap-v-2 slapd[61739]: conn=6984 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Jan 7 16:01:12 ldap-v-2 slapd[61739]: conn=6984 op=0 STARTTLS Jan 7 16:01:12 ldap-v-2 slapd[61739]: conn=6984 op=0 RESULT oid= err=0 text= Jan 7 16:01:12 ldap-v-2 slapd[61739]: conn=6984 fd=41 TLS established tls_ssf=256 ssf=256 Jan 7 16:01:12 ldap-v-2 slapd[61739]: conn=6984 op=1 BIND dn="<removed>" method=128 Jan 7 16:01:12 ldap-v-2 slapd[61739]: conn=6984 op=1 BIND dn="<removed>" mech=SIMPLE ssf=0 Jan 7 16:01:12 ldap-v-2 slapd[61739]: conn=6984 op=1 RESULT tag=97 err=0 text= [SRCH and result lines] Jan 7 16:01:12 ldap-v-2 slapd[61739]: conn=6984 op=3 UNBIND Jan 7 16:01:12 ldap-v-2 slapd[61739]: conn=6984 fd=41 closed --clip-- This doesn't seem to have any correlation to the amount of binds of server load, at least that I'm aware - and anyway, the servers are nowhere near at capacity - we only get ~2 binds per second. Normal connection would look like this: --clip-- Jan 7 16:00:55 ldap-r-1 slapd[16851]: conn=7650 fd=159 ACCEPT from IP=128.214.54.152:36362 (IP=0.0.0.0:636) Jan 7 16:00:55 ldap-r-1 slapd[16851]: conn=7650 fd=159 TLS established tls_ssf=256 ssf=256 Jan 7 16:00:55 ldap-r-1 slapd[16851]: conn=7650 op=0 BIND dn="<removed>" method=128 Jan 7 16:00:55 ldap-r-1 slapd[16851]: conn=7650 op=0 BIND dn="<removed>" mech=SIMPLE ssf=0 Jan 7 16:00:55 ldap-r-1 slapd[16851]: conn=7650 op=0 RESULT tag=97 err=0 text= [SRCH and SEARCH RESULT lines] Jan 7 16:01:12 ldap-r-1 slapd[16851]: conn=7650 op=219 UNBIND Jan 7 16:01:12 ldap-r-1 slapd[16851]: conn=7650 fd=159 closed --clip-- So this far, it looks as if the problem was that if we accept a second connection for the same client before the proxy has had time to do a bind (or indeed, a STARTTLS for the bind) on the backend for the second connection. But we seem to be getting spurious Start TLS failed messages also without any competing connections. Here's one using ldap+STARTTLS but no other ACCEPTs anywhere near: --clip-- Jan 17 17:46:20 ldap-r-1 slapd[28738]: conn=529684 fd=62 ACCEPT from IP=128.214.173.135:43148 (IP=0.0.0.0:389) Jan 17 17:46:20 ldap-r-1 slapd[28738]: conn=529684 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Jan 17 17:46:20 ldap-r-1 slapd[28738]: conn=529684 op=0 STARTTLS Jan 17 17:46:20 ldap-r-1 slapd[28738]: conn=529684 op=0 RESULT oid= err=0 text= Jan 17 17:46:20 ldap-r-1 slapd[28738]: conn=529684 fd=62 TLS established tls_ssf=256 ssf=256 Jan 17 17:46:20 ldap-r-1 slapd[28738]: conn=529684 op=1 BIND dn="ou=shibboleth,ou=login,dc=helsinki,dc=fi" method=128 Jan 17 17:46:20 ldap-r-1 slapd[28738]: conn=529684 op=1 RESULT tag=97 err=52 text=Start TLS failed Jan 17 17:46:22 ldap-r-1 slapd[28738]: conn=529684 fd=62 closed (connection lost) --clip-- on the proxy, and backend: --clip-- Jan 17 17:46:20 ldap-v-2 slapd[40089]: conn=406149 fd=92 ACCEPT from IP=128.214.222.155:48996 (IP=0.0.0.0:389) Jan 17 17:46:20 ldap-v-2 slapd[40089]: conn=406149 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Jan 17 17:46:20 ldap-v-2 slapd[40089]: conn=406149 op=0 STARTTLS Jan 17 17:46:20 ldap-v-2 slapd[40089]: conn=406149 op=0 RESULT oid= err=0 text= Jan 17 17:46:20 ldap-v-2 slapd[40089]: conn=406149 fd=92 closed (TLS negotiation failure) --clip-- Succesful ldap+starttls connection on proxy: --clip-- Jan 17 18:11:01 ldap-r-1 slapd[28738]: conn=531181 fd=54 ACCEPT from IP=128.214.173.137:48700 (IP=0.0.0.0:389) Jan 17 18:11:01 ldap-r-1 slapd[28738]: conn=531181 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Jan 17 18:11:01 ldap-r-1 slapd[28738]: conn=531181 op=0 STARTTLS Jan 17 18:11:01 ldap-r-1 slapd[28738]: conn=531181 op=0 RESULT oid= err=0 text= Jan 17 18:11:01 ldap-r-1 slapd[28738]: conn=531181 fd=54 TLS established tls_ssf=256 ssf=256 Jan 17 18:11:01 ldap-r-1 slapd[28738]: conn=531181 op=1 BIND dn="<removed>" method=128 Jan 17 18:11:01 ldap-r-1 slapd[28738]: conn=531181 op=1 BIND dn="<removed>" mech=SIMPLE ssf=0 Jan 17 18:11:01 ldap-r-1 slapd[28738]: conn=531181 op=1 RESULT tag=97 err=0 text= [SRCH and SEARCH RESULT lines] Jan 17 18:11:01 ldap-r-1 slapd[28738]: conn=531181 op=3 UNBIND Jan 17 18:11:01 ldap-r-1 slapd[28738]: conn=531181 fd=54 closed --clip-- Any ideas what could be causing these? It's a bit hard to pinpoint the problem, since it happens so rarely - we seem to get a couple dozen of these every hour to around 16 000 succesful binds, not really depending on system load. This is RHEL 7 and OpenLDAP 2.4.40. It may be the case that the same DN binding very often increases the probability of a Start TLS failed error, which I guess would be the first case (a new ACCEPT + BIND for a DN too soon after the previous one). But as I said, these seem to also sometimes appear even without any other connections being opened at the same time. (Although there might be some old connections open for the same DN.) --Janne Peltonen University of Helsinki

6 years, 5 months

Error: CSN too old and replication fails

by Jérémy Wagner

Hello, I'm facing some issues with syncrepl... The simplest situation in which I was able to reproduce the problem consists of 1 provider and 1 consumer. I have configured syncrepl to do a partial replication : olcSyncrepl: {0}rid=105 provider=ldaps://****:636 bindmethod=simple timeout=0 network-timeout=0 starttls=no filter="(mail=*)" searchbase="ou=groups,o=mydir" scope=sub schemachecking=off attrs="cn description mail member +" type=refreshAndPersist retry="60 +" tls_cert=**** tls_cacert=**** tls_key=**** olcSyncrepl: {1}rid=107 provider=ldaps://****:636 bindmethod=simple timeout=0 network-timeout=0 starttls=no filter="(objectclass=*)" searchbase="ou=operators,o=mydir" scope=sub schemachecking=off type=refreshAndPersist retry="60 +" tls_cert=**** tls_cacert=**** tls_key=**** olcSyncrepl: {2}rid=104 provider=ldaps://****:636 bindmethod=simple timeout=0 network-timeout=0 starttls=no filter="(uid=mytestuser)" searchbase="ou=people,o=mydir" scope=sub schemachecking=off type=refreshAndPersist retry="60 +" tls_cert=**** tls_cacert=**** tls_key=**** The initial sync (i.e. from an empty base) is fine, but then when I modify an entry (uid=mytestuser), it is not updated on the consumer, and I get the following messages: Feb 16 15:42:32 do_syncrep2: rid=107 NEW_COOKIE: rid=107,csn=20110216144232.222152Z#000000#000#000000 Feb 16 15:42:32 do_syncrep2: rid=104 cookie=rid=104,csn=20110216144232.222152Z#000000#000#000000 Feb 16 15:42:32 slap_graduate_commit_csn: removing 0x7fb58c0227d0 20110216144232.222152Z#000000#000#000000 Feb 16 15:42:32 do_syncrep2: rid=104 CSN too old, ignoring 20110216144232.222152Z#000000#000#000000 Feb 16 15:43:05 do_syncrep2: rid=105 LDAP_RES_INTERMEDIATE - NEW_COOKIE Feb 16 15:43:05 do_syncrep2: rid=105 NEW_COOKIE: rid=105,csn=20110216144305.545784Z#000000#000#000000 Feb 16 15:43:05 slap_queue_csn: queing 0x7fb58c020b50 20110216144305.545784Z#000000#000#000000 Feb 16 15:43:05 do_syncrep2: rid=107 LDAP_RES_INTERMEDIATE - NEW_COOKIE Feb 16 15:43:05 do_syncrep2: rid=107 NEW_COOKIE: rid=107,csn=20110216144305.545784Z#000000#000#000000 Feb 16 15:43:05 do_syncrep2: rid=104 cookie=rid=104,csn=20110216144305.545784Z#000000#000#000000 Feb 16 15:43:05 slap_graduate_commit_csn: removing 0x7fb58c0227d0 20110216144305.545784Z#000000#000#000000 Feb 16 15:43:05 do_syncrep2: rid=104 CSN too old, ignoring 20110216144305.545784Z#000000#000#000000 (both servers are perfectly in sync with an NTP daemon) It looks like ITS #6619 is quite similar, and unresolved. What do these messages mean ? Is there a way to force the update ? Regards, Jeremy W.

14 years, 4 months

openldap-technical search results for query "starttls"