Re: (ITS#9052) ACL protections get lost if same identity uses different SSF levels
by quanah＠symas.com
For informational purposes, here's additional detail as the subject and
original problem description do not fully capture the extend of the
problem. In all 2.x releases prior to 2.4.48 (I.e., 2.0.x, 2.1.x, 2.2.x,
2.3.x, and 2.4.x up to 2.4.47), the SASL security factor layer was set
globally rather than per connection. So once a connection had been made
that sets a SASL SSF, any and all non SASL connections would inherit that
value.
If ACLs are used to limit access via setting restrictions with the sasl_ssf
parameter, connections with no sasl_ssf could match those ACLs incorrectly.
For example,
access to *
by users sasl_ssf=56 read
by users tls_ssf=128 read
by * none
Would allow a user who bound without any encryption full access to the
database as long as one SASL connection had been made that had a minimum
sasl_ssf value of 56.
Another contrived example:
access to attrs=userPassword
by self sasl_ssf=56 =xw
by * auth
Would allow a user to change their own password whether or not they had
performed a SASL bind with a sasl_ssf of 56.
--Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
4 years, 2 months
Re: (ITS#9056) Replication does not work with different schemas on primary and secondary LDAP
by quanah＠symas.com
--On Tuesday, July 23, 2019 8:10 AM +0000 alex.soloviov(a)wildix.com wrote:
> Actually, I have the configuration with several LDAP server without this =
> problem. But the version of these LDAPs is a bit less - 2.4.31.=20
> On this installation when I changed the schema on the main server, on =
> secondary I see fully replicated data and warnings about unknown =
> attributes like:
Yes, that was a known bug with older OpenLDAP versions.
In general:
a) Don't mix versions of OpenLDAP
b) Use current releases of OpenLDAP
c) Use delta-syncrepl for replication
d) Upgrade the schema on replicas first, then on masters
Regards,
Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
4 years, 2 months
Re: (ITS#9056) Replication does not work with different schemas on primary and secondary LDAP
by michael＠stroeder.com
On 7/23/19 12:42 PM, Alexander Soloviov wrote:
> I understood the risks but how can I resolve my issue?
As said: By fixing your schema setup on all replicas.
> My case I want to upgrade all servers step by step without lost data
> on secondary LDAP servers
You probably don't want to read this:
Fix schema on all replicas before the upgrade.
Ciao, Michael.
4 years, 2 months
Re: (ITS#9056) Replication does not work with different schemas on primary and secondary LDAP
by alex.soloviov＠wildix.com
Ciao, Michael
I understood the risks but how can I resolve my issue?
My case I want to upgrade all servers step by step without lost data on =
secondary LDAP servers
For now when I add the new attribute to some item in LDAP then this item =
lost on secondary servers.
Moreover, replication stops after receiving the first item with unknown =
data. So, I will lose not only one changed item and also all next
I have a few hundred of LDAPs servers which should be updated one-by-one =
and in this case, I will lose the data until upgrade all of them
Thank you in advance.
Best regards, Alex
> On Jul 23, 2019, at 12:52, Michael Str=C3=B6der <michael(a)stroeder.com> =
wrote:
>=20
> On 7/23/19 9:10 AM, alex.soloviov(a)wildix.com wrote:
>> Actually, I have the configuration with several LDAP server without =
this =3D
>> problem. But the version of these LDAPs is a bit less - 2.4.31.=3D20
>> On this installation when I changed the schema on the main server, on =
=3D
>> secondary I see fully replicated data and warnings about unknown =3D
>> attributes like:
>> 5d36b192 UNKNOWN attributeDescription "TESTTYPE" inserted.
>=20
> Mainly running a replication setup without consistent schema on all =
replicas is asking for trouble. It may work in some niche cases. But in =
most cases it will fail miserably.
>=20
> =3D> Fix your setup.
>=20
> Ciao, Michael.
>=20
4 years, 2 months
Re: (ITS#9056) Replication does not work with different schemas on primary and secondary LDAP
by michael＠stroeder.com
This is a cryptographically signed message in MIME format.
--------------ms070709080204010000080303
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
On 7/23/19 9:10 AM, alex.soloviov(a)wildix.com wrote:
> Actually, I have the configuration with several LDAP server without thi=
s =3D
> problem. But the version of these LDAPs is a bit less - 2.4.31.=3D20
> On this installation when I changed the schema on the main server, on =3D=
> secondary I see fully replicated data and warnings about unknown =3D
> attributes like:
>=20
> 5d36b192 UNKNOWN attributeDescription "TESTTYPE" inserted.
Mainly running a replication setup without consistent schema on all=20
replicas is asking for trouble. It may work in some niche cases. But in=20
most cases it will fail miserably.
=3D> Fix your setup.
Ciao, Michael.
--------------ms070709080204010000080303
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC
CyEwggUzMIIEG6ADAgECAhBcyYchBfxJZNzvHl+r2LoiMA0GCSqGSIb3DQEBCwUAMIGXMQsw
CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm
b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBD
bGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xODEyMTYwMDAw
MDBaFw0xOTEyMTYyMzU5NTlaMCUxIzAhBgkqhkiG9w0BCQEWFG1pY2hhZWxAc3Ryb2VkZXIu
Y29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvdaCPHlSjB9Wb51jh60x+6OO
lOP14FSXRNDYWcuaCwey30JdrJxw9VMiBEJo7Q7fHWcpna9l9oVKuvjO3VepiyTlQoinvwSG
gQrBburWskKupOJPwv0QH8nWpc9KnP7LnOqfepwHNrqhweijxeGg95TQeDfOVbQmGwqnaCtp
CBuCu3gyxe/wVkKnr6uqwHFUoGSNIrLAdLFcnFbpKGoYvZvahkdLNglCRLpeSVu9/O0MqkGt
gGp6nPcTHwbZYSoGqFJQjPeTlczubTKo9DWYhZ0vMB2fjdadSqZxUgqqdElLRWSqRD1jCm3U
xShVkPJDQg3tkQq6Yw4C1Z9+L9KxJQIDAQABo4IB6jCCAeYwHwYDVR0jBBgwFoAUgq9sjPjF
/pZhfOgfPStxSF7Ei8AwHQYDVR0OBBYEFLn0/ESCAOEV6clL6lYXzOwKIKlyMA4GA1UdDwEB
/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMF
AjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggr
BgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwWgYDVR0fBFMwUTBPoE2g
S4ZJaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGljYXRp
b25hbmRTZWN1cmVFbWFpbENBLmNybDCBiwYIKwYBBQUHAQEEfzB9MFUGCCsGAQUFBzAChklo
dHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFu
ZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5j
b20wHwYDVR0RBBgwFoEUbWljaGFlbEBzdHJvZWRlci5jb20wDQYJKoZIhvcNAQELBQADggEB
ALFD55CXI+vy81ngFjheHu+TjKJuxrYfw71qz54pmYwR4UYBTSLNvESJXwOfSi7UxBh97xjB
bjy5rDByXl1IWAFXcnoHPKJNZL8wOa0MNz4o3X0of7JHZHYlyXJRnZV90+KtZQdn5ZP2hBmg
SHxcjdgCMU9p6VoOlJLhpEKN1TmbHq/elcwZKknnGN+54Vn2RhVP0x3998yyhIkiHNAqQImT
cqY5QkpGxyocLz54NXudIZSvXyvQI4d7FYl4JKn6gw4PRXht0/xzB/GGGKGWSrgdPCUJ4Rif
cGpO43inEBxWlW19cjYSXjqZetq2ZIJnrADxTttTJoUQsGuoT5ZMf2UwggXmMIIDzqADAgEC
AhBqm+E4O/8ra58B1dm4p1JWMA0GCSqGSIb3DQEBDAUAMIGFMQswCQYDVQQGEwJHQjEbMBkG
A1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFD
T01PRE8gQ0EgTGltaXRlZDErMCkGA1UEAxMiQ09NT0RPIFJTQSBDZXJ0aWZpY2F0aW9uIEF1
dGhvcml0eTAeFw0xMzAxMTAwMDAwMDBaFw0yODAxMDkyMzU5NTlaMIGXMQswCQYDVQQGEwJH
QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYD
VQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0
aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEP
ADCCAQoCggEBAL6znlesKHZ1QBbHOAOY08YYdiFQ8yV5C0y1oNF9Olg+nKcxLqf2NHbZhGra
0D00SOTq9bus3/mxgUsg/Wh/eXQ0pnp8tZ8XZWAnlyKMpjL+qUByRjXCA6RQyDMqVaVUkbIr
5SU0RDX/kSsKwer3H1pT/HUrBN0X8sKtPTdGX8XAWt/VdMLBrZBlgvnkCos+KQWWCo63OTTq
Rvaq8aWccm+KOMjTcE6s2mj6RkalweyDI7X+7U5lNo6jzC8RTXtVV4/Vwdax720YpMPJQaDa
ElmOupyTf1Qib+cpukNJnQmwygjD8m046DQkLnpXNCAGjuJy1F5NATksUsbfJAr7FLUCAwEA
AaOCATwwggE4MB8GA1UdIwQYMBaAFLuvfgI9+qbxPISOre44mOzZMjLUMB0GA1UdDgQWBBSC
r2yM+MX+lmF86B89K3FIXsSLwDAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIB
ADARBgNVHSAECjAIMAYGBFUdIAAwTAYDVR0fBEUwQzBBoD+gPYY7aHR0cDovL2NybC5jb21v
ZG9jYS5jb20vQ09NT0RPUlNBQ2VydGlmaWNhdGlvbkF1dGhvcml0eS5jcmwwcQYIKwYBBQUH
AQEEZTBjMDsGCCsGAQUFBzAChi9odHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FB
ZGRUcnVzdENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMA0G
CSqGSIb3DQEBDAUAA4ICAQB4XLKBKDRPPO5fVs6fl1bsj6JrF/bz9kkIBtTYLzXN30D+03Hj
6OxCDBEaIeNmsBhrJmuubvyE7HtoSmR809AgcYboW+rcTNZ/8u/Hv+GTrNI/AhqX2/kiQNxm
gUPt/eJPs92Qclj0HnVyy9TnSvGkSDU7I5Px+TbO+88G4zipA2psZaWeEykgzClZlPz1FjTC
kk77ZXp5cQYYexE6zeeN4/0OqqoAloFrjAF4o50YJafX8mnahjp3I2Y2mkjhk0xQfhNqbzlL
WPoT3m7j7U26u7zg6swjOq8hITYc3/np5tM5aVyu6t99p17bTbY7+1RTWBviN9YJzK8HxzOb
XYWBf/L+VGOYNsQDTxAk0Hbvb1j6KjUhg7fO294F29QIhhmiNOr84JHoy+fNLpfvYc/Q9EtF
OI5ISYgOxLk3nD/whbUe9rmEQXLp8MB933Ij474gwwCPUpwv9mj2PMnXoc7mbrS22XUSeTwx
CTP9bcmUdp4jmIoWfhQm7X9w/Zgddg+JZ/YnIHOwsGsaTUgj7fIvxqith7DoJC91WJ8Lce3C
VJqb1XWeKIJ84F7YLXZN0oa7TktYgDdmQVxYkZo1c5noaDKH9Oq9cbm/vOYRUM1cWcef20Wk
yk5S/GFyyPJwG0fR1nRas3DqAf4cXxMiEKcff7PNa4M3RGTqH0pWR8p6EjGCBDUwggQxAgEB
MIGsMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYD
VQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09N
T0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQXMmH
IQX8SWTc7x5fq9i6IjANBglghkgBZQMEAgEFAKCCAlkwGAYJKoZIhvcNAQkDMQsGCSqGSIb3
DQEHATAcBgkqhkiG9w0BCQUxDxcNMTkwNzIzMDk1MjQwWjAvBgkqhkiG9w0BCQQxIgQglDZS
mcsh/ke5yJcOr5EccmPn63SBEDX4hL+766mh+EwwbAYJKoZIhvcNAQkPMV8wXTALBglghkgB
ZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG
9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBvQYJKwYBBAGCNxAEMYGvMIGsMIGX
MQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdT
YWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJT
QSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQXMmHIQX8SWTc
7x5fq9i6IjCBvwYLKoZIhvcNAQkQAgsxga+ggawwgZcxCzAJBgNVBAYTAkdCMRswGQYDVQQI
ExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9E
TyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBBdXRoZW50aWNhdGlv
biBhbmQgU2VjdXJlIEVtYWlsIENBAhBcyYchBfxJZNzvHl+r2LoiMA0GCSqGSIb3DQEBAQUA
BIIBADDtE2ilDUGAqmLXDxhJc074QlnHUEtum+sJOcRQVeuG6vp8fFXtW2IpDemTaxUPUN75
9dlqwnloME1lwVlH7VoGi3MuSWCKGwDZ+CPvi+M6O2tnvZOwklD3qdaOVrvuqNQ6U5aV8uF0
/O86V8GdywWjA7gniTXvh5GXIxauZYfYENjObtCjXdxpRzbJkpFbODsfWr5krQfCaNC0kzEJ
Odd+kbWg/FedTcR4m65BMwnLD5tQFDIe8OF4wduxMAqpPnnE61oTMfLweTS6rMD+UGDCc4Zg
/bzWgRn3fo8rZZg05fbdYTaSUf8CQSfnhEY3zDUdkGqQz/FM/TIWQXP6ZbkAAAAAAAA=
--------------ms070709080204010000080303--
4 years, 2 months
Re: (ITS#9056) Replication does not work with different schemas on primary and secondary LDAP
by alex.soloviov＠wildix.com
Hello, Howard
Thank you for a quick reply
Actually, I have the configuration with several LDAP server without this =
problem. But the version of these LDAPs is a bit less - 2.4.31.=20
On this installation when I changed the schema on the main server, on =
secondary I see fully replicated data and warnings about unknown =
attributes like:
5d36b192 UNKNOWN attributeDescription "TESTTYPE" inserted.
Can I get the same behavior on the current/latest version?
Thank you in advance.
Best regards, Alex
> On Jul 22, 2019, at 19:38, Howard Chu <hyc(a)symas.com> wrote:
>=20
> alex.s(a)wildix.com wrote:
>> Full_Name: Alex
>> Version: 2.4.44+dfsg-5+deb9u2
>> OS: Debian 9
>> URL: ftp://ftp.openldap.org/incoming/
>> Submission from: (NULL) (154.41.3.130)
>>=20
>>=20
>> Looks like schemachecking parameter does not work properly
>>=20
>> I have a few LDAPs
>> On main LDAP server I changed the schema with an additional =
attribute.
>>=20
>> On the secondary LDAPs I have a problem with replication (does not =
download
>> items which have new attribute)
>>=20
>> I have the following configuration on the secondary LDAP:
>>=20
>> olcSyncrepl: {0}rid=3D001 provider=3Dldap://remote_ldap_addr =
bindmethod=3Dsimple
>> timeout=3D0
>> network-timeout=3D0 binddn=3D"cn=3Dadmin,dc=3Dexample" =
credentials=3D"testPass"
>> starttls=3Dno filter=3D"(objectclass=3D*)" searchbase=3D"dc=3Dexample" =
scope=3Dsub
>> schemachecking=3Doff type=3DrefreshAndPersist interval=3D00:00:02:00 =
retry=3D"5 +"
>>=20
>>=20
>> I have the following errors in syslog:
>>=20
>> Jul 22 17:05:29 221100000e68 slapd[6838]: null_callback : error code =
0x50
>> Jul 22 17:05:29 221100000e68 slapd[6838]: syncrepl_entry: rid=3D001 =
be_add
>> uid=3D1326514,o=3Dcom0,dc=3Dexample failed (80)
>> Jul 22 17:05:29 221100000e68 slapd[6838]: do_syncrepl: rid=3D001 rc =
80 retrying
>> Jul 22 17:05:34 221100000e68 slapd[6838]: null_callback : error code =
0x50
>> Jul 22 17:05:34 221100000e68 slapd[6838]: syncrepl_entry: rid=3D001 =
be_add
>> uid=3D1326514,o=3Dcom0,dc=3Dexample failed (80)
>> Jul 22 17:05:34 221100000e68 slapd[6838]: do_syncrepl: rid=3D001 rc =
80 retrying
>> Jul 22 17:05:39 221100000e68 slapd[6838]: null_callback : error code =
0x50
>> Jul 22 17:05:39 221100000e68 slapd[6838]: syncrepl_entry: rid=3D001 =
be_add
>> uid=3D1326514,o=3Dcom0,dc=3Dexample failed (80)
>> Jul 22 17:05:39 221100000e68 slapd[6838]: do_syncrepl: rid=3D001 rc =
80 retrying
>=20
> syncrepl is ignoring the schema as you requested. However the =
underlying backend is refusing
> to store the entries that syncrepl passes to it.
>=20
> In general, turning off schema checking is only safe for overriding =
syntax validity checks
> on known attributes. You still have to at least define the existence =
of these attributes
> on all participating servers.
>=20
> --=20
> -- Howard Chu
> CTO, Symas Corp. http://www.symas.com
> Director, Highland Sun http://highlandsun.com/hyc/
> Chief Architect, OpenLDAP http://www.openldap.org/project/
4 years, 2 months
Re: (ITS#9056) Replication does not work with different schemas on primary and secondary LDAP
by hyc＠symas.com
alex.s(a)wildix.com wrote:
> Full_Name: Alex
> Version: 2.4.44+dfsg-5+deb9u2
> OS: Debian 9
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (154.41.3.130)
>
>
> Looks like schemachecking parameter does not work properly
>
> I have a few LDAPs
> On main LDAP server I changed the schema with an additional attribute.
>
> On the secondary LDAPs I have a problem with replication (does not download
> items which have new attribute)
>
> I have the following configuration on the secondary LDAP:
>
> olcSyncrepl: {0}rid=001 provider=ldap://remote_ldap_addr bindmethod=simple
> timeout=0
> network-timeout=0 binddn="cn=admin,dc=example" credentials="testPass"
> starttls=no filter="(objectclass=*)" searchbase="dc=example" scope=sub
> schemachecking=off type=refreshAndPersist interval=00:00:02:00 retry="5 +"
>
>
> I have the following errors in syslog:
>
> Jul 22 17:05:29 221100000e68 slapd[6838]: null_callback : error code 0x50
> Jul 22 17:05:29 221100000e68 slapd[6838]: syncrepl_entry: rid=001 be_add
> uid=1326514,o=com0,dc=example failed (80)
> Jul 22 17:05:29 221100000e68 slapd[6838]: do_syncrepl: rid=001 rc 80 retrying
> Jul 22 17:05:34 221100000e68 slapd[6838]: null_callback : error code 0x50
> Jul 22 17:05:34 221100000e68 slapd[6838]: syncrepl_entry: rid=001 be_add
> uid=1326514,o=com0,dc=example failed (80)
> Jul 22 17:05:34 221100000e68 slapd[6838]: do_syncrepl: rid=001 rc 80 retrying
> Jul 22 17:05:39 221100000e68 slapd[6838]: null_callback : error code 0x50
> Jul 22 17:05:39 221100000e68 slapd[6838]: syncrepl_entry: rid=001 be_add
> uid=1326514,o=com0,dc=example failed (80)
> Jul 22 17:05:39 221100000e68 slapd[6838]: do_syncrepl: rid=001 rc 80 retrying
syncrepl is ignoring the schema as you requested. However the underlying backend is refusing
to store the entries that syncrepl passes to it.
In general, turning off schema checking is only safe for overriding syntax validity checks
on known attributes. You still have to at least define the existence of these attributes
on all participating servers.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
4 years, 2 months
(ITS#9056) Replication does not work with different schemas on primary and secondary LDAP
by alex.s＠wildix.com
Full_Name: Alex
Version: 2.4.44+dfsg-5+deb9u2
OS: Debian 9
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (154.41.3.130)
Looks like schemachecking parameter does not work properly
I have a few LDAPs
On main LDAP server I changed the schema with an additional attribute.
On the secondary LDAPs I have a problem with replication (does not download
items which have new attribute)
I have the following configuration on the secondary LDAP:
olcSyncrepl: {0}rid=001 provider=ldap://remote_ldap_addr bindmethod=simple
timeout=0
network-timeout=0 binddn="cn=admin,dc=example" credentials="testPass"
starttls=no filter="(objectclass=*)" searchbase="dc=example" scope=sub
schemachecking=off type=refreshAndPersist interval=00:00:02:00 retry="5 +"
I have the following errors in syslog:
Jul 22 17:05:29 221100000e68 slapd[6838]: null_callback : error code 0x50
Jul 22 17:05:29 221100000e68 slapd[6838]: syncrepl_entry: rid=001 be_add
uid=1326514,o=com0,dc=example failed (80)
Jul 22 17:05:29 221100000e68 slapd[6838]: do_syncrepl: rid=001 rc 80 retrying
Jul 22 17:05:34 221100000e68 slapd[6838]: null_callback : error code 0x50
Jul 22 17:05:34 221100000e68 slapd[6838]: syncrepl_entry: rid=001 be_add
uid=1326514,o=com0,dc=example failed (80)
Jul 22 17:05:34 221100000e68 slapd[6838]: do_syncrepl: rid=001 rc 80 retrying
Jul 22 17:05:39 221100000e68 slapd[6838]: null_callback : error code 0x50
Jul 22 17:05:39 221100000e68 slapd[6838]: syncrepl_entry: rid=001 be_add
uid=1326514,o=com0,dc=example failed (80)
Jul 22 17:05:39 221100000e68 slapd[6838]: do_syncrepl: rid=001 rc 80 retrying
4 years, 2 months
