Le 13/09/2012 14:16, arun.sasi1(a)wipro.com a écrit :
> Hello Team,
>
> I have an issue with OpenLDAP TLS based replication
>
> Getting below error
> slap_client_connect: URI=ldap://gb0135embldap01.emb.slb.com Error,
> ldap_start_tls failed (-11)
> Sep 13 16:13:34 ae0043app05 slapd[2582]: do_syncrepl: rid=365 rc -11
> retrying
>
> I have openLDAP in Ubuntu 9.04 version 2.4.19 then I thought to updgrade
> it and first I upgraded on my consumer openldap server which I migrated
> to Ubuntu 12.04 and version 2.4.28.
>
> I have created the certificate for my consumer from existing server. but
> when I go for TLS based replication, the database is not syncing and it
> is synching when remove starttls=no
What does the master log say, and did you try a manual connection with
the same credentials from the slave to the master, using TLS ?
--
BOFH excuse #166:
/pub/lunch
Dat Duong <datduong2000(a)yahoo.com> writes:
> Hi Hauke,
>
> I still can't get TLS to work. Here is the error message.
>
> TLS certificate verification: Error, self signed certificate
> tls_write: want=7, written=7
> 0000: 15 03 01 00 02 02 30 ......0
> TLS trace: SSL3 alert write:fatal:unknown CA
> TLS trace: SSL_connect:error in SSLv3 read server certificate B
> TLS trace: SSL_connect:error in SSLv3 read server certificate B
> TLS: can't connect: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
Please describe the parameters to create your certificate chain.
I presume you have not signed your certificates with a known
certificate authority.
-Dieter
--
Dieter Klünter | Systemberatung
http://www.dpunkt.de/buecher/2104.html
GPG Key ID:8EF7B6C6
53°08'09,95"N
10°08'02,42"E
Hi!
Most likely I misconfigured the accesslog databases used for delta syncrepl (I'm still working on it), but I have some trouble understanding the logs created.
I have two identical servers (SIDs 5 and 6) that also have an identical cn=config that is to be synced as well)
I created two accesslog databases, one for cn=config, and one for the main database.
For SDID=5 I see messages like:
Mar 14 15:17:39 v05 slapd[26377]: do_syncrep1: rid=006 starting refresh (sending cookie=rid=006,sid=005,csn=20250314000000.000000Z#000000#000#000000;20250314000000.000000Z#000000#001#000000;20200721123717.002866Z#000000#002#000000;20181031083258.073732Z#000000#003#000000;20250314000002.000000Z#000000#005#000000;20250227092006.790591Z#000000#006#000000)
Mar 14 15:17:39 v05 slapd[26377]: do_syncrep2: rid=006 LDAP_RES_SEARCH_RESULT
Mar 14 15:17:39 v05 slapd[26377]: do_syncrepl: rid=006 rc -101 retrying
Mar 14 15:17:39 v05 slapd[26377]: do_syncrep1: rid=006 starting refresh (sending cookie=rid=006,sid=005,csn=20130719093756.074776Z#000000#000#000000;20250217105250.345944Z#000000#001#000000;20250218171739.629994Z#000000#002#000000;20250217065706.238392Z#000000#003#000000;20250227092327.859231Z#000000#005#000000;20250227092348.803001Z#000000#006#000000)
Mar 14 15:17:39 v05 slapd[26377]: do_syncrep2: rid=006 got search entry without Sync State control (reqStart=20250314114001.000003Z,cn=changelog-1)
Mar 14 15:17:39 v05 slapd[26377]: do_syncrepl: rid=006 rc -1 retrying
For the same time interval I see for SID=6:
Mar 14 15:17:26 v06 slapd[14537]: do_syncrep1: rid=005 starting refresh (sending cookie=rid=005,sid=006,csn=20130719093756.074776Z#000000#000#000000;20250217105250.345944Z#000000#001#000000;20250218171739.629994Z#000000#002#000000;20250217065706.238392Z#000000#003#000000;20250227092327.859231Z#000000#005#000000;20250227092348.803001Z#000000#006#000000)
Mar 14 15:17:26 v06 slapd[14537]: do_syncrep2: rid=005 LDAP_RES_SEARCH_RESULT
Mar 14 15:17:26 v06 slapd[14537]: do_syncrepl: rid=005 rc -101 retrying
Mar 14 15:17:26 v06 slapd[14537]: do_syncrep1: rid=005 starting refresh (sending cookie=rid=005,sid=006,csn=20250314000000.000000Z#000000#000#000000;20250314000000.000000Z#000000#001#000000;20200721123717.002866Z#000000#002#000000;20181031083258.073732Z#000000#003#000000;20250314000002.000000Z#000000#005#000000;20250227092006.790591Z#000000#006#000000)
Mar 14 15:17:26 v06 slapd[14537]: do_syncrep2: rid=005 got search entry without Sync State control (reqStart=20250314123529.000001Z,cn=changelog-0)
Mar 14 15:17:26 v06 slapd[14537]: do_syncrepl: rid=005 rc -1 retrying
(no corelated messages on Node 1)
Mar 14 15:17:39 v06 slapd[14537]: send_search_entry: conn 1021 ber write failed.
Specifically I wonder what the "rc -101 retrying" is really about: the servers should be able to connect to each other.
Also what "got search entry without Sync State control" means.
Finally I also have a "rc -1 retrying" and the "ber write failed".
I really don't know where to start debugging.
The first syncprov is.
dn: olcOverlay={0}syncprov,olcDatabase={0}config,cn=config
objectClass: olcSyncProvConfig
olcOverlay: syncprov
olcSpCheckpoint: 100 10
olcSpSessionlog: 10
My first accesslog looks like:
dn: olcOverlay={1}accesslog,olcDatabase={0}config,cn=config
objectClass: olcOverlayConfig
objectClass: olcAccessLogConfig
olcOverlay: accesslog
olcAccessLogDB: cn=changelog-0
olcAccessLogOps: writes
olcAccessLogPurge: 60+00:00 1+00:00
olcAccessLogSuccess: FALSE
olcAccessLogOld: (objectClass=*)
The second syncprov is:
dn: olcOverlay={0}syncprov,olcDatabase={1}mdb,cn=config
objectClass: olcSyncProvConfig
olcOverlay: syncprov
olcSpCheckpoint: 100 10
olcSpSessionlog: 100
The second accesslog is:
dn: olcOverlay={1}accesslog,olcDatabase={1}mdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcAccessLogConfig
olcOverlay: accesslog
olcAccessLogDB: cn=changelog-1
olcAccessLogOps: writes
olcAccessLogPurge: 60+00:00 1+00:00
olcAccessLogSuccess: FALSE
olcAccessLogOld: (objectClass=*)
And the databases are:
dn: olcDatabase={3}mdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcMdbConfig
olcDatabase: mdb
olcDbDirectory: /var/lib/ldap/changelog-0
olcSuffix: cn=changelog-0
olcAccess: {0}to * by dn.exact="uid=syncrepl,..." read by * break
olcLimits: {0}dn.exact="uid=syncrepl,..." size.soft=unlimited
olcRootDN: cn=admin,cn=changelog-0
olcRootPW: log-0
dn: olcDatabase={4}mdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcMdbConfig
olcDatabase: mdb
olcDbDirectory: /var/lib/ldap/changelog-1
olcSuffix: cn=changelog-1
olcAccess: {0}to * by dn.exact="uid=syncrepl,..." read by * break
olcLimits: {0}dn.exact="uid=syncrepl,..." size.soft=unlimited
olcRootDN: cn=admin,cn=changelog-1
olcRootPW: log-1
The syncrepl definitions are like this:
olcSyncrepl: {0}rid=5 provider="ldap://v05 /" searchbase="cn=config" type="refreshAndPersist" \
retry="60 5 300 5 1800 +" logbase=cn=changelog-0 logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" \
schemachecking=on syncdata=accesslog starttls=critical tls_reqcert=demand bindmethod="simple" binddn="uid=syncrepl,..." credentials="replicationtest"
olcSyncrepl: {1}rid=6 provider="ldap://v06 /" searchbase="cn=config" type="refreshAndPersist" \
retry="60 5 300 5 1800 +" logbase=cn=changelog-0 logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" \
schemachecking=on syncdata=accesslog starttls=critical tls_reqcert=demand bindmethod="simple" binddn="uid=syncrepl,..." credentials="replicationtest"
olcSyncrepl: {0}rid=5 provider="ldap:// v05 /" searchbase="dc=..." type="refreshAndPersist" \
retry="60 5 300 5 1800 +" logbase=cn=changelog-1 logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" schemachecking=on syncdata=accesslog \
starttls=critical tls_reqcert=demand bindmethod="simple" binddn="uid=syncrepl,..." credentials="replicationtest"
olcSyncrepl: {1}rid=6 provider="ldap://v06 /" searchbase="dc=... " type="refreshAndPersist" \
retry="60 5 300 5 1800 +" logbase=cn=changelog-1 logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" schemachecking=on syncdata=accesslog \
starttls=critical tls_reqcert=demand bindmethod="simple" binddn="uid=syncrepl,..." credentials="replicationtest"
Kind regards,
Ulrich Windl
Il 18/11/2015 02:32, Quanah Gibson-Mount ha scritto:
> --On Tuesday, November 17, 2015 7:57 PM +0200 Fr3ddie
> <fr3ddie(a)fr3ddie.it> wrote:
>
>> Il 10/11/2015 13:06, Fr3ddie ha scritto:
>>> Hello to the list,
>>
>> Nobody has any hint?
>
> I suggest reading the code, because the answer is actually fairly
> obvious if you look at slapd-meta/config.c:
>
> "NAME 'olcMetaTargetConfig' "
> "MUST ( olcMetaSub $ olcDbURI ) "
>
> Yet you aren't using the olcMetaTargetConfig objectClass in your entry.
Thank you very much for your help Quanah.
Please excuse the delay, I have not been able to access the servers
to perform other tests during this period...
I tried your suggestion and read the code, as much as I could have been
able to.
Then I modified the ldif file in order to create the meta-DB and its sub-DBs
containing the URIs of the target servers (if I correctly understood):
version: 1
dn: olcDatabase={3}meta,cn=config
objectClass: olcDatabaseConfig
objectClass: olcMetaConfig
olcDatabase: {3}meta
olcSuffix: dc=loc1,dc=root
olcSuffix: dc=loc2,dc=root
olcSuffix: dc=loc3,dc=root
olcDbConnTtl: 240
olcDbRebindAsUser: FALSE
dn: olcMetaSub={0}uri,olcDatabase={3}meta,cn=config
objectClass: olcConfig
objectClass: olcMetaTargetConfig
olcMetaSub: {0}uri
olcDbUri: "ldap://server-loc1.loc1.root/dc=loc1,dc=root"
olcDbIdAssertBind: bindmethod=simple
binddn="cn=admin,dc=loc1,dc=root" credentials=xxxxxxxxx starttls=yes
tls_reqcert=demand
dn: olcMetaSub={1}uri,olcDatabase={3}meta,cn=config
objectClass: olcConfig
objectClass: olcMetaTargetConfig
olcMetaSub: {1}uri
olcDbUri: "ldap://server-loc2.loc2.root/dc=loc2,dc=root"
olcDbIdAssertBind: bindmethod=simple
binddn="cn=admin,dc=loc2,dc=root" credentials=xxxxxxxxx starttls=yes
tls_reqcert=demand
[...]
Modifying the ldif file as such I'm able to load it into the DB with no
complains by
slapd.
The problem is that I'm still unable to see the remote DITs using, e.g.,
Apache Directory Studio;
the log on the server reports this:
Mar 1 12:40:08 server-loc0 slapd[1210]: conn=149188 op=9
meta_search_dobind_init[0] mc=0xa119b38: non-empty dn with empty cred;
binding anonymously
On the target server the log reports nothing.
It seems slapd is ignoring my configuration for authentication to remote
targets (olcDbIdAssertBind): what can I try now?
Is it possible that this is a bug or, instead, it's still my
misconfiguration?
Thank you again for your help
btb(a)bitrate.net wrote:
>
> On Oct 2, 2013, at 11.47, Michael Ströder <michael(a)stroeder.com> wrote:
>
>> btb wrote:
>>> On 2013.10.02 07.29, Axel Grosse wrote:
>>>
>>>> when I test on the server itself ..
>>>> openssl s_client -connect 192.168.30.169:389 -showcerts -CAfile
>>>> ./ssl/VordelCA.crt
>>>> CONNECTED(00000003)
>>>> 710:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake
>>>> failure:s23_lib.c:188:
>>>
>>> ldaps [port 636] is deprecated.
>>> use starttls with the standard port [389].
>>> to test, just use ldapsearch [see the reference to -Z in the man page]
>>
>> This is nonsense.
>>
>> From a security perspective there's no reason not to use LDAPS. Well, I'd even
>> recommend LDAPS since SSL/TLS handshake is done *before* a client can send an
>> LDAP PDU.
>> With my deployments I always enable both but prefer LDAPS.
>>
>> I cannot imagine that any LDAP server or client will ever drop support for
>> LDAPS since this would immediately rule out this implementation from broader
>> market share.
>
> i'm not sure what exactly you mean by "this is nonsense". ldaps was never
> offered as a formal specification, and *is* deprecated.
I don't know of any document forbidding use of LDAPS.
I don't know any server which implements StartTLS which is not capable of
LDAPS (despite configuration choice).
> that's a fact: http://www.openldap.org/faq/data/cache/605.html .
FAQ entries are no formal specification. But you should read all of the FAQ:
"Although there is no technical specification for ldaps:// it is widely used."
> ldaps may well be in continued use even given its deprecation, but no one
> is debating that, and it's continued use in light of being deprecated does
> not change that it's deprecated. we all know it's still heavily used, and
> probably will continue to be for, at the very least, quite some time.
And because it's heavily used it's nonsense to teach everybody this pseudo
argument about "deprecated". And as said I find it even to be more secure.
Ciao, Michael.
> Am 2017-03-20 16:18, schrieb Dan White:
>> On 03/20/17 16:06 +0100, info(a)gwarband.de wrote:
>>> I don't have any idea how to set a higher debug level to dovecot. In
>>> my opinion I have the highest. So I can't deliver a greater log.
>>
>> I recommend consulting Dovecot's advice on how to run a debugger, or
>> dig
>> into the code which calls libldap.
> There isn't too much to "debug" in Dovecot's TLS implementation, it's
> not doing anything fancy asides from calling the ldap_start_tls_s.
>
> I am not sure what debugging you could try further.
>
> Aki
This was the answer of the dovecot mailing list.
Maybe it would be possible that people from this mailinglist
communicate directly with the dovecot mailinglist to find the soulution
together and easier.
Thanks
Tobias
Joshua Schaeffer wrote:
> On 02/18/2016 03:19 AM, Dieter Klünter wrote:
>> ssf=x specifies the overall security, a value '1' enables security.
>> This setting would meet your requirements:
>> olcSecurity: ssf=1 sasl=56 tls=256
>
> I updated olcSecurity
To the exact value Dieter mentioned above?
> and now I get the following when using simple auth:
>
> root@immortal:/var/log/kerberos# ldapsearch -LLL -x -D
> cn=admin,dc=harmonywave,dc=com -W -H
> ldap://baneling.harmonywave.com/????starttls -b dc=harmonywave,dc=com
> Enter LDAP Password:
> ldap_bind: Confidentiality required (13)
> additional info: SASL confidentiality required
You're not using a SASL bind mech at all. So no wonder why it fails due to sasl=56.
Do not guess. Read the man page for the exact meaning of all this.
Ciao, Michael.
--On Sunday, March 27, 2016 8:15 PM -0400 Xavier Landreville
<xavier(a)openconcept.ca> wrote:
>
>
>
> Hello,
>
> I am currently in the grips of trying to get syncrepl replication working
> with StartTLS. It was working fine until recently. The only change that
> occurred over the last 12 months (that relates to OpenLDAP) is that I've
> started requiring TLS for connections.
>
> My provider is running OpenLDAP 2.4.31 on Ubuntu 14.04, while one
> consumer is running the exact same version on a Ubuntu 14.04 machine and
> the other consumer is running OpenLDAP 2.4.28 on Ubuntu 12.04.
>
> Is there anything that I'm missing?
Probably a lot of data, given the fact you're doing replication with
verions known to be broken in regard to replication...
--Quanah
--
Quanah Gibson-Mount
Platform Architect
Zimbra, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration
A division of Synacor, Inc
HI!
We're using self-compiled OpenLDAP 2.4.27 under RHEL 6.1 linked against
OpenSSL 1.0.0 libs shipped with RHEL.
(some names are consistently obfuscated herein to keep real names confidential)
Unfortunately we can't get StartTLS to work. It always fails:
# /opt/xxxdir/bin/ldapsearch -x -ZZ ldap://ldap-srv01.rz.domain
ldap_start_tls: Connect error (-11)
additional info: TLS: hostname does not match CN in peer certificate
# /opt/xxxdir/bin/ldapsearch -x -ZZ ldap://ldap.domain
ldap_start_tls: Connect error (-11)
additional info: TLS: hostname does not match CN in peer certificate
But OpenSSL lists the (IMO correct) hostnames in the server's certificate:
---------------------------------- snip ----------------------------------
Subject: CN=ldap.domain,OU=xxx,O=xxx,C=DE
[..]
X509v3 Subject Alternative Name:
email:certificate@xxx.domain,
DNS:ldap.domain,
DNS:ldap-srv01.rz.domain,
DNS:ldap-srv02.rz.domain
---------------------------------- snip ----------------------------------
Is the hostname check confused by the email in the first subjectAltName
sequence value?
Ciao, Michael.
On 26/09/11 10:18 -0400, criderkevin(a)aol.com wrote:
>
>I'm struggling with the need for SSL...
>
>We will use our new LDAP for apps. These servers are all locally housed so
>each app server will talk to the LDAP server over our network. (why) Would
>we need SSL?
>
>What about for mail services? It seems to me that our mail server would
>also talk directly to the LDAP server...what am I missing here that
>dictates the use of SSL with LDAP? I could see if one had their LDAP open
>to be accessible direct access from off-network. Perhaps SSL is used
>simply as a means to authenitcate?
If you're performing TLS authentication, using client certificates, via
STARTTLS, then using X.509 provides for a strong authentication mechanism
using SASL (EXTERNAL).
That's the one benefit that I know of beyond the obvious session based
encryption that you obtain using certificates.
--
Dan White
