--On Monday, November 4, 2024 8:29 PM -0300 tmp 2810 <t2810mp(a)gmail.com>
wrote:
> Once again, I apologize; I ran so many tests that I accidentally copied
> one where the binddn was incorrect.
>
> The target looks more like this:
>
>## example.com
> uri "ldaps://ldap.google.com/dc=proxy"
> suffixmassage "dc=proxy" "dc=example,dc=com"
> lastmod off
> readonly on
> idassert-bind bindmethod=simple
> binddn="cn=ChiwewDaw"
cn, is by definition, case insensitive. If Google LDAP is forcing case
sensitivity in this attribute, it is gross violation of the LDAP RFCs.
However, having had to interface with it in the past, I don't believe that
is the case. I would generally suspect that this is not the full DN of the
user.
> idassert-bind bindmethod=sasl
> saslmech=EXTERNAL
> tls_reqcert=demand
> tls_reqsan=demand
> starttls=critical
This is not sufficient, please read the man page:
idassert-bind bindmethod=none|simple|sasl [binddn=<simple
DN>]
[credentials=<simple password>] [saslmech=<SASL
mech>]
[secprops=<properties>] [realm=<realm>]
[authcId=<authentication
ID>] [authzId=<authorization ID>]
[authz={native|proxyauthz}]
[mode=<mode>] [flags=<flags>]
[starttls=no|yes|critical]
[tls_cert=<file>] [tls_key=<file>]
[tls_cacert=<file>]
[tls_cacertdir=<path>]
[tls_reqcert=never|allow|try|demand]
[tls_reqsan=never|allow|try|demand]
[tls_cipher_suite=<ciphers>]
[tls_ecname=<names>]
[tls_protocol_min=<version>]
[tls_crlcheck=none|peer|all]
You *must* specify tls_cert, tls_key, and tls_cacert as a part of
idassert-bind as it provides the TLS identity to bind as. In your
configuration for simple bind, tls_cert and tls_key are unnecessary as
you're not doing SASL/EXTERNAL binds.
--Quanah
>>> <thomaswilliampritchard(a)gmail.com> schrieb am 31.03.2022 um 06:29 in Nachricht
<20220331042904.5262.30720(a)hypatia.openldap.org>:
> Quanah Gibson-Mount wrote:
>> --On Wednesday, March 30, 2022 8:28 PM +0200 Stefan Kania
>> <stefan(a)kania-online.de> wrote:
>>
>> > That's what can be found in the FAQ on openldap.org:
>> >
>> > https://www.openldap.org/faq/data/cache/605.html
>> >
>> > I would trust this more then any rumors on any stackxxxx page ;)
>> Unfortunately, the FAQ is dead weight we want to kill and not maintained in
>> any way, shape, or form. It's currently provided for historical purposes.
>>
>> As to this overall discussion, one of the primary issues with connections
>> over ldap:/// is that there's zero way with simple binds to prevent the
>> bind dn + password being sent in the clear by a client to the server. With
>> ldaps:/// the encryption is set up before the BIND occurs so you don't run
>> this risk.
>
> Is that true? Surely I can
> 1. connect to the server
> 2. Send starttls
> 3. Then bind bind can't I?
> I'm fairly certain I've used LDAP Client operating in that order.
I think the point was that you can bind even when not having started TLS before.
I don't know whether this can prevent it:
olcSecurity: ssf=0 update_ssf=128 simple_bind=64
(I can't remember why I put "ssf=0" there; maybe to allow anonymous DLAPv2)
Regards,
Ulrich
>
>>
>> So from that standpoint, I'd personally prefer to see ldaps:/// qualified
>> in an RFC so the standardization argument goes away and ldaps be noted as
>> the preferred method for sites that require encryption.
>
> I agree there is no technical reason LDAPS would not be better. It should be
> made standard.
Am 04.10.2011 18:59, schrieb Dan White:
> On 04/10/11 09:22 -0700, Howard Chu wrote:
>> Dan White wrote:
>>> On 03/10/11 21:43 +0200, Andreas Rudat wrote:
>>>> Am 03.10.2011 20:51, schrieb Dan White:
>>>>> On 03/10/11 19:41 +0200, Andreas Rudat wrote:
>>>>>> tls_cert
>>>>>> tls_key
>>>>>
>>>>> My mail client may have corrupted this part of your configuration.
>>>>> You'll
>>>>> of course need valid entries here.
>>>>>
>>>> These options are defaults in my conf. With some comments, after
>>>> installing the slapd package
>>>
>>> You'll need to create a (client) certificate and populate those two
>>> values,
>>> or otherwise find a way to specify them while performing your
>>> ldapsearch
>>> command.
>>>
>>> I don't see how you will will be able to obtain SASL EXTERNAL over
>>> STARTTLS
>>> otherwise.
>>
>> How did this conversation get to STARTTLS? The Subject is asking
>> about SASL EXTERNAL over ldapi, which does not need TLS.
>
> I was led down that path via the howto referenced in the original
> post, and
> made several, possibly incorrect, assumptions about what the end goal is.
>
Sorry for that confusion Howard and thanks for you help Dan, I will work
with the man page now and will create a new better topic if needed.
Andreas
On 11/23/2011 05:51 PM, Dan White wrote:
> On 23/11/11 17:06 +0100, Kasper Loopstra wrote:
>> Dear list,
>>
>> We are using PAM to authenticate posixUsers against OpenLDAP. This
>> works great, and allows 'local' (ssh) logins. However, we also use
>> LDAP for a number of other services, including remote access and
>> editing via other software. This means we would like to keep our
>> users passwords as secure as possible, and enforce encrypted logins
>> for all remote hosts. However, PAM should still be able to
>> authenticate. The manner of encryption is not really important, it
>> just has to be strong enough to be useful over the internet, and
>> usable for all (or most) clients.
>>
>> We have tried various solutions with ssf directives in
>> /etc/ldap/slapd.conf as well as the security tls=1 directive. All of
>> these attempts broke PAM.
>
> Which PAM ldap module are you using? with PADL's module, you'd want to
> configure 'ssl on' (for ldaps:///) or 'ssl starttls' (for starttls over
> ldap:///) and also configure the tls_* settings appropriately.
>
We're using libpam-ldap from Debian, which is indeed the PADL module according to the comments. Is it really necesary to use SSL when communicating within localhost? If it is, that's fine, it just doesn't seem to be the right way to handle local traffic.
> For your slapd configuration, see the slapd.conf manpage - the TLS*
> options, as well as the 'security' option. If you are wishing to perform
> secure connections over ldaps:///, verify that in your slapd init script,
> that you are passing 'ldaps:///' as one of your '-h' command line
> parameters.
>
According to the init file provided by Debian, it seems to be using the conf file for this information. Is that correct/possible, or should we be asking the Debian people?
Thanks for the quick response,
Kasper Loopstra
Hi John,
SIDs (server IDs) must be unique across servers.
RIDs (replication IDs) must be unique inside a single server.
So the answer to your question is essentially "no".
If you email me your full cn=config db bits from both servers (minus
passwords), there's some cleanup on them I can send back.
The serverID: 1 <URI> bit is only necessary if you are doing cn=config
replication, which you are not doing. If you are going to use the <#>
<URI> form, then the <URI> must EXACTLY MATCH the arguments slapd is being
started with.
Personally, since I do not do cn=config replication, and the URIs are
customizable by customers, I go with the much simpler:
olcServerID: <#>
form. Then each server only has a single value for olcServerID, which is
its specific serverID. This way I never have to worry that MMR replication
is going to get mesed up because of URI changes.
--Quanah
--On Tuesday, February 18, 2014 10:09 AM -0500 "Borresen, John - 0442 -
MITLL" <John.Borresen(a)ll.mit.edu> wrote:
> All,
>
> The long weekend didn't help...still at a loss. Question...
>
> If the olcServerIDs look like, on all three servers:
>
> olcServerID: 1 ldap://mm-server1.example.ldap
> olcServerID: 2 ldap://mm-server2.example.ldap
> olcServerID: 3 ldap://mm-server3.example.ldap
>
> Should the Replica IDs (rid) in the olcSycnrepl directive be:
>
> olcSyncrepl: {0} rid=001 provider=mm-server1.example.ldap
> bindmethod=simple binddn="cn=ldapadmin,dc=group42,dc=ldap"
> credentials=<password> interval=01:00:00:00
> searchbase="dc=example,dc=ldap" logbase="cn=accesslog" schemachecking=on
> type=refreshAndPersist retry="60 +" filter="(objectClass=*)" attrs=*,+"
> syncdata=accesslog starttls=no olcSyncrepl: {1} rid=002
> provider=mm-server2.example.ldap bindmethod=simple
> binddn="cn=ldapadmin,dc=group42,dc=ldap" credentials=<password>
> interval=01:00:00:00 searchbase="dc=example,dc=ldap"
> logbase="cn=accesslog" schemachecking=on type=refreshAndPersist retry="60
> +" filter="(objectClass=*)" attrs=*,+" syncdata=accesslog starttls=no
> olcSyncrepl: {0} rid=003 provider=mm-server3.example.ldap
> bindmethod=simple binddn="cn=ldapadmin,dc=group42,dc=ldap"
> credentials=<password> interval=01:00:00:00
> searchbase="dc=example,dc=ldap" logbase="cn=accesslog" schemachecking=on
> type=refreshAndPersist retry="60 +" filter="(objectClass=*)" attrs=*,+"
> syncdata=accesslog starttls=no
>
> OR
>
> olcSyncrepl: {0} rid=1 provider=mm-server1.example.ldap bindmethod=simple
> binddn="cn=ldapadmin,dc=group42,dc=ldap" credentials=<password>
> interval=01:00:00:00 searchbase="dc=example,dc=ldap"
> logbase="cn=accesslog" schemachecking=on type=refreshAndPersist retry="60
> +" filter="(objectClass=*)" attrs=*,+" syncdata=accesslog starttls=no
> olcSyncrepl: {1} rid=2 provider=mm-server2.example.ldap bindmethod=simple
> binddn="cn=ldapadmin,dc=group42,dc=ldap" credentials=<password>
> interval=01:00:00:00 searchbase="dc=example,dc=ldap"
> logbase="cn=accesslog" schemachecking=on type=refreshAndPersist retry="60
> +" filter="(objectClass=*)" attrs=*,+" syncdata=accesslog starttls=no
> olcSyncrepl: {0} rid=3 provider=mm-server3.example.ldap bindmethod=simple
> binddn="cn=ldapadmin,dc=group42,dc=ldap" credentials=<password>
> interval=01:00:00:00 searchbase="dc=example,dc=ldap"
> logbase="cn=accesslog" schemachecking=on type=refreshAndPersist retry="60
> +" filter="(objectClass=*)" attrs=*,+" syncdata=accesslog starttls=no
>
> OR
>
> Does it matter?
>
> Also, should the all three olcSycrepl directives be loaded on all three
> servers so they look identical. What I mean by that is should each
> Server "replicate" to itself? There is confusion on this matter. I
> asked Quanah that back in late January, and he stated that the system
> knows about itself so it knows what to ignore. Then last week, he asked
> why I had the master replicating to itself.
>
> Also, since I have refreshAndPersist configured do I need an interval as
> well?
>
> Thanks in advance,
>
> John
>
> -----Original Message-----
> From: openldap-technical-bounces(a)OpenLDAP.org
> [mailto:openldap-technical-bounces@OpenLDAP.org] On Behalf Of Borresen,
> John - 0442 - MITLL Sent: Friday, February 14, 2014 4:28 PM
> To: Quanah Gibson-Mount; openldap-technical(a)openldap.org
> Subject: RE: Syncrepl and mmr
>
> All,
>
> I just created an mm-server3, using the config_dbase and main_dbase from
> mm-server2 -- copied the ldif's I created from mm-server2 then ran
> slapadd.
>
> On mm-server3:
> olcServerID: 1 ldap://mm-server1.example.ldap
> olcServerID: 2 ldap://mm-server2.example.ldap
> olcServerID: 3 ldap://mm-server3.example.ldap
>
> olcSyncrepl: {0} rid=001 provider=mm-server1.example.ldap
> bindmethod=simple binddn="cn=ldapadmin,dc=group42,dc=ldap"
> credentials=<password> interval=01:00:00:00
> searchbase="dc=example,dc=ldap" logbase="cn=accesslog" schemachecking=on
> type=refreshAndPersist retry="60 +" filter="(objectClass=*)" attrs=*,+"
> syncdata=accesslog starttls=no olcSyncrepl: {1} rid=002
> provider=mm-server2.example.ldap bindmethod=simple
> binddn="cn=ldapadmin,dc=group42,dc=ldap" credentials=<password>
> interval=01:00:00:00 searchbase="dc=example,dc=ldap"
> logbase="cn=accesslog" schemachecking=on type=refreshAndPersist retry="60
> +" filter="(objectClass=*)" attrs=*,+" syncdata=accesslog starttls=no
> olcSyncrepl: {0} rid=003 provider=mm-server3.example.ldap
> bindmethod=simple binddn="cn=ldapadmin,dc=group42,dc=ldap"
> credentials=<password> interval=01:00:00:00
> searchbase="dc=example,dc=ldap" logbase="cn=accesslog" schemachecking=on
> type=refreshAndPersist retry="60 +" filter="(objectClass=*)" attrs=*,+"
> syncdata=accesslog starttls=no
>
> Started slapd, no errors. It immediately sync'd up with mm-server1!
> Changes that I made on mm-server1 days ago which have never replicated
> over to mm-server2...replicated to mm-server3 immediately on startup.
>
> I had not even got around to adding mm-server3 to mm-server1 (or
> mm-server2) yet.
>
> The olcServerIDs and olcSyncrepl on both mm-server1 and 2 show:
> olcServerID: 1 ldap://mm-server1.example.ldap
> olcServerID: 2 ldap://mm-server2.example.ldap
>
> olcSyncrepl: {0} rid=001 provider=mm-server1.example.ldap
> bindmethod=simple binddn="cn=ldapadmin,dc=group42,dc=ldap"
> credentials=<password> interval=01:00:00:00
> searchbase="dc=example,dc=ldap" logbase="cn=accesslog" schemachecking=on
> type=refreshAndPersist retry="60 +" filter="(objectClass=*)" attrs=*,+"
> syncdata=accesslog starttls=no olcSyncrepl: {1} rid=002
> provider=mm-server2.example.ldap bindmethod=simple
> binddn="cn=ldapadmin,dc=group42,dc=ldap" credentials=<password>
> interval=01:00:00:00 searchbase="dc=example,dc=ldap"
> logbase="cn=accesslog" schemachecking=on type=refreshAndPersist retry="60
> +" filter="(objectClass=*)" attrs=*,+" syncdata=accesslog starttls=no
>
> So...now, I am at even more of a loss. Why would mm-server1 be
> replicating to mm-server3 and not 2? When the configs are the same
> between mm-server2 and 3???
>
>
>
> Thanks in advance...
> John
>
>
> -----Original Message-----
> From: openldap-technical-bounces(a)OpenLDAP.org
> [mailto:openldap-technical-bounces@OpenLDAP.org] On Behalf Of Borresen,
> John - 0442 - MITLL Sent: Friday, February 14, 2014 1:34 PM
> To: Quanah Gibson-Mount; openldap-technical(a)openldap.org
> Subject: RE: Syncrepl and mmr
>
> All,
>
> If I went off the beaten' path...where did I go wrong? (my config and
> error messages are in a previous posting)
>
> Thanks in advance,
> John
>
> -----Original Message-----
> From: openldap-technical-bounces(a)OpenLDAP.org
> [mailto:openldap-technical-bounces@OpenLDAP.org] On Behalf Of Borresen,
> John - 0442 - MITLL Sent: Friday, February 14, 2014 8:40 AM
> To: Quanah Gibson-Mount; openldap-technical(a)openldap.org
> Subject: RE: Syncrepl and mmr
>
> Thanks Quanah,
>
> A few weeks back I asked that question (on 1/30):
>> All Masters in the chain have the olcServerID's and olcSynRepl for
>> itself and its partner? I can understand having each knowing about
>> the others but why itself? It's replicating to itself?
> -You replied
> -It knows about itself so it knows what to ignore.
>
> Even in the Admin Guide is specifies setting it up that way...each server
> has all the others and itself listed. I was following the procedures
> delineated in the Admin Guide and in the man-pages (including how I
> understood what was put out on the board): From the Admin Guide:
> 8.3.3. N-Way Multi-Master
>
> For the following example we will be using 3 Master nodes. Keeping in
> line with test050-syncrepl-multimaster of the OpenLDAP test suite, we
> will be configuring slapd(8) via cn=config
>
> This sets up the config database:
>
> dn: cn=config
> objectClass: olcGlobal
> cn: config
> olcServerID: 1
>
> dn: olcDatabase={0}config,cn=config
> objectClass: olcDatabaseConfig
> olcDatabase: {0}config
> olcRootPW: secret
>
> second and third servers will have a different olcServerID obviously:
>
> dn: cn=config
> objectClass: olcGlobal
> cn: config
> olcServerID: 2
>
> dn: olcDatabase={0}config,cn=config
> objectClass: olcDatabaseConfig
> olcDatabase: {0}config
> olcRootPW: secret
>
> This sets up syncrepl as a provider (since these are all masters):
>
> dn: cn=module,cn=config
> objectClass: olcModuleList
> cn: module
> olcModulePath: /usr/local/libexec/openldap
> olcModuleLoad: syncprov.la
>
> Now we setup the first Master Node (replace $URI1, $URI2 and $URI3 etc.
> with your actual ldap urls):
>
> dn: cn=config
> changetype: modify
> replace: olcServerID
> olcServerID: 1 $URI1
> olcServerID: 2 $URI2
> olcServerID: 3 $URI3
>
> dn: olcOverlay=syncprov,olcDatabase={0}config,cn=config
> changetype: add
> objectClass: olcOverlayConfig
> objectClass: olcSyncProvConfig
> olcOverlay: syncprov
>
> dn: olcDatabase={0}config,cn=config
> changetype: modify
> add: olcSyncRepl
> olcSyncRepl: rid=001 provider=$URI1 binddn="cn=config"
> bindmethod=simple credentials=secret searchbase="cn=config"
> type=refreshAndPersist retry="5 5 300 5" timeout=1
> olcSyncRepl: rid=002 provider=$URI2 binddn="cn=config"
> bindmethod=simple credentials=secret searchbase="cn=config"
> type=refreshAndPersist retry="5 5 300 5" timeout=1
> olcSyncRepl: rid=003 provider=$URI3 binddn="cn=config"
> bindmethod=simple credentials=secret searchbase="cn=config"
> type=refreshAndPersist retry="5 5 300 5" timeout=1
> -
> add: olcMirrorMode
> olcMirrorMode: TRUE
>
> I followed what is put in the Admin Guide, etc...
>
> Thanks
>
> -----Original Message-----
> From: openldap-technical-bounces(a)OpenLDAP.org
> [mailto:openldap-technical-bounces@OpenLDAP.org] On Behalf Of Quanah
> Gibson-Mount Sent: Thursday, February 13, 2014 1:57 PM
> To: Borresen, John - 0442 - MITLL; openldap-technical(a)openldap.org
> Subject: Re: Syncrepl and mmr
>
> --On Thursday, February 13, 2014 10:54 AM -0500 "Borresen, John - 0442 -
> MITLL" <John.Borresen(a)ll.mit.edu> wrote:
>
>> All,
>
> Your configuration is very confused. Why do you have the master
> replicate to itself, for example?
>
> --Quanah
>
>
> --
>
> Quanah Gibson-Mount
> Architect - Server
> Zimbra, Inc.
> --------------------
> Zimbra :: the leader in open source messaging and collaboration
>
>
>
>
--
Quanah Gibson-Mount
Architect - Server
Zimbra, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration
PJunod(a)mediageneral.com wrote:
> I have setup two ldap servers for authentication and access control in a
> multi-master configuration. I am concerned about the number of contextcsn
> entries that are supposed to be present in each database. Right now there are
> two servers participating in the multi-master configuration. From my
> understanding, there should be one contextCSN entry per database per host. My
> cn=config database has two contextCSN entries as I would expect. One for each
> syncrepl rid configured. My bdb database only has one contextCSN entry though,
> with an rid of just “000”. (my rid’s are 001, 002, 101, and 102)
ContextCSN is an attribute. Attributes have values, they do not have entries.
CSNs carry SIDs not RIDs.
If you don't use the correct terminology no one will understand what you're
talking about.
If a database contains changes from more than one server, then its contextCSN
should contain more than one value, and each value should have distinct SIDs.
But the SIDs will only be used correctly if the URLs in the ServerID directive
match the actual URLs given to the slapd -h option.
> Replication seems to work fine on both databases. I can write to either one
> and the changes are replicated over immediately. I am just curious about this
> discrepancy in the number of contextCSN entries. Could someone confirm the
> number of contextCSN entries per database and if it should match the number of
> hosts participating in the multi-master replication? Here are some relevant
> settings for the replication:
>
> dn: cn=config
>
> olcServerID: 1 ldap://<server1>
>
> olcServerID: 2 ldap://<server2>
>
> #######################
>
> # module{0}, config
>
> dn: cn=module{0},cn=config
>
> objectClass: olcModuleList
>
> cn: module{0}
>
> olcModulePath: /usr/lib64/openldap2.4
>
> olcModuleLoad: {0}syncprov.la
>
> #######################
>
> # {0}config, config
>
> dn: olcDatabase={0}config,cn=config
>
> olcSyncrepl: {0}rid=001 provider=ldap://<server1> binddn="cn=Ma
>
> nager,cn=config" bindmethod=simple credentials=<password> searchbase="cn=config
>
> " type=refreshAndPersist retry="5 500 5 +" timeout=1 starttls=yes
>
> olcSyncrepl: {1}rid=002 provider=ldap://<server2> binddn="cn=Ma
>
> nager,cn=config" bindmethod=simple credentials=<password> searchbase="cn=config
>
> " type=refreshAndPersist retry="5 500 5 +" timeout=1 starttls=yes
>
> olcMirrorMode: TRUE
>
> #######################
>
> # {0}syncprov, {0}config, config
>
> dn: olcOverlay={0}syncprov,olcDatabase={0}config,cn=config
>
> objectClass: olcOverlayConfig
>
> objectClass: olcSyncProvConfig
>
> olcOverlay: {0}syncprov
>
> #######################
>
> # {1}bdb, config
>
> dn: olcDatabase={1}bdb,cn=config
>
> olcSyncrepl: {0}rid=101 provider=ldap://<server1> binddn="cn=Ma
>
> nager,dc=mgcorp,dc=net" bindmethod=simple credentials=<password> searchbase="dc
>
> =mgcorp,dc=net" type=refreshAndPersist interval=00:00:00:10 retry="5 500 5 +"
>
> timeout=1 starttls=yes
>
> olcSyncrepl: {1}rid=102 provider=ldap://<server2> binddn="cn=Ma
>
> nager,dc=mgcorp,dc=net" bindmethod=simple credentials=<password> searchbase="dc
>
> =mgcorp,dc=net" type=refreshAndPersist interval=00:00:00:10 retry="5 500 5 +"
>
> timeout=1 starttls=yes
>
> olcMirrorMode: TRUE
>
> ##############################
>
> Here are the results of searches for contextCSN in cn=config and dc=mgcorp,dc=net:
>
> ldapsearch -x -W -s base -D "cn=Manager,cn=config" -h "<server2>" -b
> "cn=config" contextCSN
>
> contextCSN: 20101110214932.998233Z#000000#000#000000
>
> contextCSN: 20101028121213.444193Z#000000#001#000000
>
> ldapsearch -x -W -s base -D "cn=Manager,dc=mgcorp,dc=net" -h "<server2>" -b
> "dc=mgcorp,dc=net" contextCSN
>
> contextCSN: 20101110213409.736943Z#000000#000#000000
>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
--On Friday, January 31, 2014 8:54 AM -0500 "Borresen, John - 0442 - MITLL"
<John.Borresen(a)ll.mit.edu> wrote:
> Thanks Quanah
>
> I'm sure it isn't 100% correct, but I added the following ACL to my
> accesslog DB on both MM servers:
>
> olcAccess: to * by dn="cn=ldapadmin,dc=group42,dc=ldap" read by * none
Well, it may not have been this issue, but it definite would become an
issue then. ;)
> I'm still seeing
> gp42-admin3 (MM server1)
> Jan 31 08:25:17 gp42-admin3 slapd[3599]: conn=5551 op=2 SRCH
> base="cn=accesslog" scope=2 deref=0 filter="(objectClass=*)" Jan 31
> 08:25:17 gp42-admin3 slapd[3599]: conn=5551 op=2 SRCH attr=reqDN reqType
> reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN Jan 31 08:25:17
> gp42-admin3 slapd[3599]: do_syncrep2: rid=001 got empty syncUUID with
> LDAP_SYNC_ADD (cn=accesslog) Jan 31 08:25:17 gp42-admin3 slapd[3599]:
> do_syncrepl: rid=001 rc -1 retrying Jan 31 08:25:17 gp42-admin3
> slapd[3599]: send_search_entry: conn 5551 ber write failed. Jan 31
> 08:25:17 gp42-admin3 slapd[3599]: conn=5551 fd=32 closed (connection lost
> on write) Jan 31 08:25:17 gp42-admin3 slapd[3599]: do_syncrep2: rid=002
> got empty syncUUID with LDAP_SYNC_ADD (cn=accesslog) Jan 31 08:25:17
> gp42-admin3 slapd[3599]: do_syncrepl: rid=002 rc -1 retrying
Your masters are unable to talk to each other. You need to determine why.
This will take debugging on your part, as I've never seen anything like
this before.
> gp42-admin4 (MM server2)
> Jan 31 08:25:19 gp42-admin4 slapd[26000]: conn=8050 fd=101 ACCEPT from
> IP=155.34.133.73:10446 (IP=0.0.0.0:389) Jan 31 08:25:19 gp42-admin4
> slapd[26000]: conn=8050 op=0 BIND dn="dc=group42,dc=ldap" method=163 Jan
> 31 08:25:19 gp42-admin4 slapd[26000]: conn=8050 op=0 RESULT tag=97 err=13
> text=TLS confidentiality required Jan 31 08:25:19 gp42-admin4
> slapd[26000]: conn=8050 op=1 BIND dn="cn=ldapadmin,dc=group42,dc=ldap"
> method=128 Jan 31 08:25:19 gp42-admin4 slapd[26000]: conn=8050 op=1
> RESULT tag=97 err=13 text=TLS confidentiality required Jan 31 08:25:19
> gp42-admin4 slapd[26000]: conn=8050 op=2 UNBIND
> Jan 31 08:25:19 gp42-admin4 slapd[26000]: conn=8050 fd=101 closed
> Jan 31 08:25:51 gp42-admin4 slapd[26000]: do_syncrep2: rid=001 got empty
> syncUUID with LDAP_SYNC_ADD (cn=accesslog) Jan 31 08:25:51 gp42-admin4
> slapd[26000]: do_syncrepl: rid=001 rc -1 retrying
This says that your consumer is connecting without sending a startTLS,
while you've configured the master to require startTLS. Clearly you need
to either enable startTLS in the syncrepl statement, or not require
starttls on your master.
--Quanah
> -----Original Message-----
> From: Quanah Gibson-Mount [mailto:quanah@zimbra.com]
> Sent: Thursday, January 30, 2014 5:10 PM
> To: Borresen, John - 0442 - MITLL; openldap-technical(a)openldap.org
> Subject: RE: Syncrepl and mmr
>
> --On Thursday, January 30, 2014 4:51 PM -0500 "Borresen, John - 0442 -
> MITLL" <John.Borresen(a)ll.mit.edu> wrote:
>
>> Well, that was helpful -- lol
>
>
> Looking at your previously supplied configuration, it is clearly apparent
> that you provided your replication user no ACLs to read the accesslog DB,
> so the error you see makes sense. It can't read the data out of
> accesslog, so it throws an error stating that fact.
>
> --Quanah
>
> --
>
> Quanah Gibson-Mount
> Architect - Server
> Zimbra, Inc.
> --------------------
> Zimbra :: the leader in open source messaging and collaboration
--
Quanah Gibson-Mount
Architect - Server
Zimbra, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration
This is the first testing call for OpenLDAP 2.5.20. Depending on the
results, this may be the only testing call.
Generally, get the code for RE25:
<https://git.openldap.org/openldap/openldap/-/archive/OPENLDAP_REL_ENG_2_5/o…>
Extract, configure, and build.
Execute the test suite (via make test) after it is built. Optionally, cd
tests && make its to run through the regression suite.
Thanks!
OpenLDAP 2.5.20 Engineering
Fixed lloadd handling of starttls critical (ITS#10323)
Fixed slapd regression with certain searches (ITS#10307)
Fixed slapo-pcache caching behaviors (ITS#10270)
Minor Cleanup
ITS#9934
ITS#10020
ITS#10226
ITS#10279
ITS#10309
ITS#10320
ITS#10327
ITS#10328
ITS#10331
Regards,
Quanah
Joshua Schaeffer wrote:
>> Michael Ströder wrote:
>>>
>>> Simply use LDAPS (on separate port). It was never defined in a standard but
>>> most
>>> LDAP-enabled software supports it.
>
> I did ended up doing this. I had an application that didn't support start_tls
> on an ldap URI, but did support ldaps (or at least I couldn't find a way to
> get it to issue start_tls).
In OpenLDAP's libldap just use a URL extension:
ldap://host/????starttls
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
