Thanks Quanah for your reply. It answered a lot of questions.
I took a back step, and slapcat'd all my cn=configs and main_dbase from all three servers, then ran slapadd to put each into place. Taking one of the cn=configs (using mm-server2's) I modified it for each server pretty much based on your suggestions below to set up Syncreplication with mm-server1 as the master (right now). When I brought them up, they were replicating (I was so happy!) --> any change I made on mm-server1 was immediately replicated over to mm-server2 and 3.
I did learn a great deal over the last week or so. Patience being one of them. I will forward to you in a separate email my cn=configs.
When running slapadd, I did run into this error (which I resolved -- but am curious about) on mm-server1:
First had this (mm-server1):
5304e1ff olcMirrorMode: value #0: <olcMirrorMode> database is not a shadow
slapadd: could not add entry dn=olcDatabase={1}bdb,cn=config (line=2260)
Resolution: set olcMirrorMode to FALSE (made this change on the other servers' ldifs)
This caused an error when, later, running ldapmodify on the main dbase when all servers were running slapd.
ldap_modify: server unwilling to perform (53)
additional info: shadow context: no update referral
Resolution: Removed olcMirrorMode from all ldifs.
Why, even with it set to FALSE, would MirrorMode cause this issue?
Thanks,
John
-----Original Message-----
From: Quanah Gibson-Mount [mailto:quanah@zimbra.com]
Sent: Wednesday, February 19, 2014 2:02 PM
To: Borresen, John - 0442 - MITLL; openldap-technical(a)openldap.org
Subject: RE: Syncrepl and mmr
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
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
Janne Peltonen wrote:
> 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:
Looks odd indeed, but doesn't seem related to the other errors. Would need much finer
resolution timestamps to correlate what's going on, unless you know there are no other
active connections on the proxy when this occurred on the backend.
>
> --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:
These aren't spurious - your TLS library has genuinely failed to start a session. Which TLS library
are you using? What OS are you running on? The most common cause for periodic failures is
running out of entropy for the PRNG.
> --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--
> 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.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
Hi
current version of openldap 2.4.23-7.2 I have however built and used
2.4.31 with the same results.
I have a single provider that has multiple domians
ie dc=company
dc=subdivision1,dc=company
dc=subdivision2,dc=company
on some of the consumers, I have a single syncrepl config with the base,
so these servers have all the users and replication tends to work fine.
olcSyncrepl: {0}
rid=00x
provider=ldaps://x.x.x.x
bindmethod=simple
binddn="cn=replica,dc=repl_config,dc=company"
credentials="xxxxx"
filter="(objectclass=*)"
searchbase="dc=company"
scope=sub
attrs="*,+"
schemachecking=off
type=refreshAndPersist
retry="5 5 300 +"
starttls=yes
tls_reqcert=never
tls_cert=/etc/ldap/ssl/ca-cert.pem
tls_key=/etc/ldap/ssl/keys/ca-key.pem
on some of the consumers, I have multiple syncrepl configs so that I
replicate specific subdivision data to those servers.
olcSyncrepl: {0}
rid=001
provider=ldaps://x.x.x.x
bindmethod=simple
binddn="cn=replica,dc=repl_config,dc=company"
credentials="xxxxx"
filter="(objectclass=*)"
searchbase="dc=company"
scope=base
attrs="*,+"
schemachecking=off
type=refreshAndPersist
retry="5 5 300 +"
starttls=yes
tls_reqcert=never
tls_cert=/etc/ldap/ssl/ca-cert.pem
tls_key=/etc/ldap/ssl/keys/ca-key.pem
olcSyncrepl: {1}
rid=002
provider=ldaps://x.x.x.x
bindmethod=simple
binddn="cn=replica,dc=repl_config,dc=company"
credentials="xxxxx"
filter="(objectclass=*)"
searchbase="dc=repl_config,dc=company"
scope=base
attrs="*,+"
schemachecking=off
type=refreshAndPersist
retry="5 5 300 +"
starttls=yes
tls_reqcert=never
tls_cert=/etc/ldap/ssl/ca-cert.pem
tls_key=/etc/ldap/ssl/keys/ca-key.pem
olcSyncrepl: {2}
rid=002
provider=ldaps://x.x.x.x
bindmethod=simple
binddn="cn=replica,dc=repl_config,dc=company"
credentials="xxxxx"
filter="(objectclass=*)"
searchbase="dc=subdivision,dc=company"
scope=base
attrs="*,+"
schemachecking=off
type=refreshAndPersist
retry="5 5 300 +"
starttls=yes
tls_reqcert=never
tls_cert=/etc/ldap/ssl/ca-cert.pem
tls_key=/etc/ldap/ssl/keys/ca-key.pem
whats happening with these consumers is that the initial sync seems to
work and some changes to the provider do make it down to the consumer
but lately most changes are NOT making it down to the consumer, when I
log sync then I am seeing that the csn is committed for the change for
the first rid but then for the next rid it logs that the csn is too old?
Aug 22 09:56:59 fw1 slapd[30938]: do_syncrep2: rid=080
LDAP_RES_INTERMEDIATE - NEW_COOKIE
Aug 22 09:56:59 fw1 slapd[30938]: do_syncrep2: rid=080 NEW_COOKIE:
rid=080,csn=20120822075659.107448Z#000000#000#000000
Aug 22 09:56:59 fw1 slapd[30938]: slap_queue_csn: queing 0xb4230120
20120822075659.107448Z#000000#000#000000
Aug 22 09:56:59 fw1 slapd[30938]: do_syncrep2: rid=082
LDAP_RES_INTERMEDIATE - NEW_COOKIE
Aug 22 09:56:59 fw1 slapd[30938]: do_syncrep2: rid=082 NEW_COOKIE:
rid=082,csn=20120822075659.107448Z#000000#000#000000
Aug 22 09:56:59 fw1 slapd[30938]: do_syncrep2: rid=081
LDAP_RES_INTERMEDIATE - NEW_COOKIE
Aug 22 09:56:59 fw1 slapd[30938]: do_syncrep2: rid=081 NEW_COOKIE:
rid=081,csn=20120822075659.107448Z#000000#000#000000
Aug 22 09:56:59 fw1 slapd[30938]: do_syncrep2: rid=083
cookie=rid=083,csn=20120822075659.107448Z#000000#000#000000
Aug 22 09:56:59 fw1 slapd[30938]: slap_graduate_commit_csn: removing
0xb422e830 20120822075659.107448Z#000000#000#000000
Aug 22 09:56:59 fw1 slapd[30938]: do_syncrep2: rid=082
LDAP_RES_INTERMEDIATE - NEW_COOKIE
Aug 22 09:56:59 fw1 slapd[30938]: do_syncrep2: rid=083 CSN too old,
ignoring 20120822075659.107448Z#000000#000#000000
Aug 22 09:56:59 fw1 slapd[30938]: do_syncrep2: rid=082 NEW_COOKIE:
rid=082,csn=20120822075659.112753Z#000000#000#000000
Aug 22 09:56:59 fw1 slapd[30938]: do_syncrep2: rid=081
LDAP_RES_INTERMEDIATE - NEW_COOKIE
Aug 22 09:56:59 fw1 slapd[30938]: do_syncrep2: rid=081 NEW_COOKIE:
rid=081,csn=20120822075659.112753Z#000000#000#000000
Aug 22 09:56:59 fw1 slapd[30938]: do_syncrep2: rid=080
LDAP_RES_INTERMEDIATE - NEW_COOKIE
Aug 22 09:56:59 fw1 slapd[30938]: do_syncrep2: rid=080 NEW_COOKIE:
rid=080,csn=20120822075659.112753Z#000000#000#000000
Aug 22 09:56:59 fw1 slapd[30938]: do_syncrep2: rid=083
cookie=rid=083,csn=20120822075659.112753Z#000000#000#000000
Aug 22 09:56:59 fw1 slapd[30938]: slap_queue_csn: queing 0xb4f11d20
20120822075659.112753Z#000000#000#000000
Aug 22 09:56:59 fw1 slapd[30938]: slap_graduate_commit_csn: removing
0xb4f18508 20120822075659.112753Z#000000#000#000000
Aug 22 09:56:59 fw1 slapd[30938]: do_syncrep2: rid=083 CSN too old,
ignoring 20120822075659.112753Z#000000#000#000000
--
Thank you,
Mark Adrian Coetser
mark(a)pkfnet.co.za
Le 04/10/2023 à 14:46, Emmanuel Seyman a écrit :
> Hello, all.
>
> I have an instance of OpenLDAP in which I use groups to manage access
> controls, similar to the way the FAQ and admin guide describe it.
>
> My DIT layout:
>
> uid=userildr1,ou=people,o=gdAA,dc=example,dc=com
> uid=userildr2,ou=people,o=gdAA,dc=example,dc=com
> ...
> cn=readINT,ou=groups,o=gdAA,dc=example,dc=com
> cn=writeINT,ou=groups,o=gdAA,dc=example,dc=com
> cn=superadmin,ou=groups,o=gdAA,dc=example,dc=com
> ...
> ou=people,o=INT,dc=example,dc=com
> ...
> ou=groups,o=INT,dc=example,dc=com
>
>
> Outside of the DIT, my slapd.conf file (yes, I know) contains:
>
> access to dn.sub="o=INT,dc=example,dc=com"
> by self write
> by group/groupOfUniqueNames/uniqueMember="cn=superadmin,ou=groups,o=gdAA,dc=example,dc=com" write
> by group/groupOfUniqueNames/uniqueMember="cn=writeINT,ou=groups,o=gdAA,dc=example,dc=com" write
> by group/groupOfUniqueNames/uniqueMember="cn=readINT,ou=groups,o=gdAA,dc=example,dc=com" read
>
> The uid=userildr1,ou=people,o=gdAA,dc=example,dc=com entry is in the readINT
> group yet seems unable to run a search. I get an error 50 ("Operations are
> restricted to bind/unbind/abandon/StartTLS/modify password") and cannot
> figure out why this is happening. If anyone can tell me what's going on,
> I would appreciate it.
>
> I'm seeing "config_back_db_open: line 0: warning: cannot assess the validity of
> the ACL scope within backend naming context" in the log files but this looks
> harmless.
>
> This is OpenLDAP 2.5.14 running on RHEL 8, with the LTB packages.
> Logs and the configuration file are available if necessary.
>
Hello Emmanuel,
the error "Operations are restricted to
bind/unbind/abandon/StartTLS/modify password" means the account has the
pwdReset flag set to TRUE and must reset its password. It is linked to
password policy.
--
Clément Oudot | Identity Solutions Manager
clement.oudot(a)worteks.com
Worteks |https://www.worteks.com
William Brown wrote:
> On Fri, 2017-11-17 at 08:34 +0100, Michael Ströder wrote:
>> William Brown wrote:
>>> Just want to point out there are some security risks with ssf
>>> settings.
>>> I have documented these here:
>>>
>>> https://fy.blackhats.net.au/blog/html/2016/11/23/the_minssf_trap.ht
>>> ml
>>
>> Nice writeup. I always considered SSF values to be naive and somewhat
>> overrated. People expect too much when looking at these numbers -
>> especially regarding the "strength" of cryptographic algorithms which
>> changes over time anyway with new cryptanalysis results coming up.
>>
>> Personally I always try to implement a TLS-is-must policy and prefer
>> LDAPS (with correct protocol and ciphersuites configured) over
>> LDAP/StartTLS to avoid this kind of pre-TLS leakage.
>> Yes, I deliberately ignore "LDAPS is deprecated". ;-]
>
> I agree. If only there was a standards working group that could
> deprecate startTLS in favour of TLS .... :)
I have to agree as well. On my own servers I also use TLS on other "plaintext"
ports too (such as pop3 and others) that no one has any business connecting to
in plaintext.
>> Furthermore some LDAP server implementation (IIRC e.g. MS AD) refuse
>> to
>> accept SASL/GSSAPI bind requests sent over TLS-secured channel. Which
>> is
>> IMO also somewhat questionable.
>
> Yes, I really agree. While a plain text port exists, data leaks are
> possible. We should really improve this situation, where we have TLS
> for all data to prevent these mistakes.
>
> I think a big part of the issue is that GSSAPI forces the encryption
> layer, and can't work via an already encrypted channel. The people I
> know involved in this space are really resistant to changing this due
> to the "kerberos centric" nature of the products.
Interesting. Our libldap/liblber works fine with GSSAPI's encryption layered
over TLS and vice versa.
--
-- 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 4/8/21 4:07 PM, work(a)seyboldt.org wrote:
> i need to open my LDAP-Directory to a public available Server.
>
> What is the best secure way to connect my LDAP-Server to my Public
> server?
This is a pretty broad question.
Good answers usually need more info:
- which kind of data is stored inside the LDAP server?
- how do LDAP clients access the server?
- which OS is the LDAP server running on?
- against which attacks do you want to protect your deployment?
Some general security measures include:
- use TLS-protected connections everywhere (StartTLS or LDAPS)
- use decently secure authentication mechs
- implement secure OpenLDAP ACLs to protect the database content
- build stripped-down, specific OpenLDAP packages for your needs
- use systemd's sand-boxing options (if using systemd on Linux at all)
- use kernel-level MAC like SELinux or AppArmor (if OS is Linux)
Ciao, Michael.
On 3/2/22 11:49, Francesco Malvezzi wrote:
> on a consumer I spotted a zombie entry which was deleted on provider.
Which OpenLDAP version are you using?
> Replication is syncrepl:
>
> olcSyncrepl: {0}rid=003 provider=ldap://ldap-master.example.org
> binddn="cn=repluser,ou=agents,dc=example,dc=org" bindmethod=simple
> credentials="secret" searchbase="ou=people,dc=example,dc=org"
> type=refreshOnly interval=00:00:01:00 retry="5 5 30 +" timeout=1
> scope=sub schemachecking=on exattrs=sambaHomeDrive sizelimit=100000
> timelimit=7200 starttls=yes filter="....."
I cannot really tell what's going on in your deployment.
But I wonder why you added sizelimit= to the syncrepl directive. Do you
really have less than 100000 entries?
Ciao, Michael.
--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.
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.
--Quanah
Am Mon, 12 Dec 2011 15:51:38 +0530
schrieb Jayavant Patil <jayavant.patil82(a)gmail.com>:
> Hi,
>
> I am using openldap-2.4.19-4.x86_64 on fedora 12 machine. I have
> enabled openldap SSL/TLS. How do I know (test) that I am using
> SSL/TLS connections instead of normal ldap:///?
This is written to syslog
slapd[1276]: conn=1001 fd=17 ACCEPT from IP=[::1]:34267 (IP=[::]:389)
slapd[1276]: conn=1001 op=0 EXT oid=1.3.6.1.4.1.1466.20037
slapd[1276]: conn=1001 op=0 STARTTLS
slapd[1276]: conn=1001 op=0 RESULT oid= err=0 text=
slapd[1276]: conn=1001 fd=17 TLS established tls_ssf=256 ssf=256
-Dieter
--
Dieter Klünter | Systemberatung
http://dkluenter.de
GPG Key ID:DA147B05
53°37'09,95"N
10°08'02,42"E
