Syncrepl and mmr
by Borresen, John - 0442 - MITLL
For some reason the original never made it. Not sure why.
________________________________________
From: Borresen, John - 0442 - MITLL
Sent: Wednesday, January 29, 2014 4:41 PM
To: openldap-technical(a)openldap.org
Subject: Syncrepl -- MMR
All,
Troubleshooting some issues, not to mention to verify that Syncrepl are working as they should, following setting up a 2-way multi-master in our test environment.
1) I noticed that the “userPassword” attributes have all disappeared?!
2) On one of the masters I was able to add it back in (for my account, of course) and added a password (SHA). It has not propagated over to the other master.
-->Here is the slapd.log from server#1:
Jan 29 16:10:06 gp42-admin3 slapd[3599]: do_syncrep2: rid=002 got empty syncUUID with LDAP_SYNC_ADD (cn=accesslog)
Jan 29 16:10:06 gp42-admin3 slapd[3599]: do_syncrepl: rid=002 rc -1 retrying
Jan 29 16:10:34 gp42-admin3 slapd[3599]: conn=1216 fd=30 ACCEPT from IP=155.34.133.44:54271 (IP=0.0.0.0:389)
Jan 29 16:10:34 gp42-admin3 slapd[3599]: conn=1216 op=0 EXT oid=1.3.6.1.4.1.1466.20037
Jan 29 16:10:34 gp42-admin3 slapd[3599]: conn=1216 op=0 STARTTLS
Jan 29 16:10:34 gp42-admin3 slapd[3599]: conn=1216 op=0 RESULT oid= err=0 text=
Jan 29 16:10:34 gp42-admin3 slapd[3599]: conn=1216 fd=30 TLS established tls_ssf=256 ssf=256
Jan 29 16:10:34 gp42-admin3 slapd[3599]: conn=1216 op=1 BIND dn="cn=ldapadmin,dc=group42,dc=ldap" method=128
Jan 29 16:10:34 gp42-admin3 slapd[3599]: conn=1216 op=1 BIND dn="cn=ldapadmin,dc=group42,dc=ldap" mech=SIMPLE ssf=0
Jan 29 16:10:34 gp42-admin3 slapd[3599]: conn=1216 op=1 RESULT tag=97 err=0 text=
Jan 29 16:10:34 gp42-admin3 slapd[3599]: conn=1216 op=2 SRCH base="cn=accesslog" scope=2 deref=0 filter="(objectClass=*)"
Jan 29 16:10:34 gp42-admin3 slapd[3599]: conn=1216 op=2 SRCH attr=reqDN reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN
Jan 29 16:10:34 gp42-admin3 slapd[3599]: send_search_entry: conn 1216 ber write failed.
Jan 29 16:10:34 gp42-admin3 slapd[3599]: conn=1216 fd=30 closed (connection lost on write)
Jan 29 16:11:02 gp42-admin3 slapd[3599]: conn=1217 fd=31 ACCEPT from IP=172.25.91.233:36144 (IP=0.0.0.0:389)
Jan 29 16:11:02 gp42-admin3 slapd[3599]: conn=1217 op=0 EXT oid=1.3.6.1.4.1.1466.20037
Jan 29 16:11:02 gp42-admin3 slapd[3599]: conn=1217 op=0 STARTTLS
Jan 29 16:11:02 gp42-admin3 slapd[3599]: conn=1217 op=0 RESULT oid= err=0 text=
Jan 29 16:11:02 gp42-admin3 slapd[3599]: conn=1217 fd=31 TLS established tls_ssf=256 ssf=256
Jan 29 16:11:02 gp42-admin3 slapd[3599]: conn=1217 op=1 BIND dn="cn=ldapadmin,dc=group42,dc=ldap" method=128
Jan 29 16:11:02 gp42-admin3 slapd[3599]: conn=1217 op=1 BIND dn="cn=ldapadmin,dc=group42,dc=ldap" mech=SIMPLE ssf=0
Jan 29 16:11:02 gp42-admin3 slapd[3599]: conn=1217 op=1 RESULT tag=97 err=0 text=
Jan 29 16:11:02 gp42-admin3 slapd[3599]: conn=1217 op=2 SRCH base="cn=accesslog" scope=2 deref=0 filter="(objectClass=*)"
Jan 29 16:11:02 gp42-admin3 slapd[3599]: conn=1217 op=2 SRCH attr=reqDN reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN
Jan 29 16:11:02 gp42-admin3 slapd[3599]: do_syncrep2: rid=001 got empty syncUUID with LDAP_SYNC_ADD (cn=accesslog)
Jan 29 16:11:02 gp42-admin3 slapd[3599]: do_syncrepl: rid=001 rc -1 retrying
Jan 29 16:11:02 gp42-admin3 slapd[3599]: conn=1217 op=3 UNBIND
Jan 29 16:11:02 gp42-admin3 slapd[3599]: conn=1217 fd=31 closed
Jan 29 16:11:06 gp42-admin3 slapd[3599]: do_syncrep2: rid=002 got empty syncUUID with LDAP_SYNC_ADD (cn=accesslog)
Jan 29 16:11:06 gp42-admin3 slapd[3599]: do_syncrepl: rid=002 rc -1 retrying
Jan 29 16:11:34 gp42-admin3 slapd[3599]: conn=1218 fd=30 ACCEPT from IP=155.34.133.44:54273 (IP=0.0.0.0:389)
Jan 29 16:11:34 gp42-admin3 slapd[3599]: conn=1218 op=0 EXT oid=1.3.6.1.4.1.1466.20037
Jan 29 16:11:34 gp42-admin3 slapd[3599]: conn=1218 op=0 STARTTLS
Jan 29 16:11:34 gp42-admin3 slapd[3599]: conn=1218 op=0 RESULT oid= err=0 text=
Jan 29 16:11:34 gp42-admin3 slapd[3599]: conn=1218 fd=30 TLS established tls_ssf=256 ssf=256
Jan 29 16:11:34 gp42-admin3 slapd[3599]: conn=1218 op=1 BIND dn="cn=ldapadmin,dc=group42,dc=ldap" method=128
Jan 29 16:11:34 gp42-admin3 slapd[3599]: conn=1218 op=1 BIND dn="cn=ldapadmin,dc=group42,dc=ldap" mech=SIMPLE ssf=0
Jan 29 16:11:34 gp42-admin3 slapd[3599]: conn=1218 op=1 RESULT tag=97 err=0 text=
Jan 29 16:11:34 gp42-admin3 slapd[3599]: conn=1218 op=2 SRCH base="cn=accesslog" scope=2 deref=0 filter="(objectClass=*)"
Jan 29 16:11:34 gp42-admin3 slapd[3599]: conn=1218 op=2 SRCH attr=reqDN reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN
Jan 29 16:11:34 gp42-admin3 slapd[3599]: send_search_entry: conn 1218 ber write failed.
Jan 29 16:11:34 gp42-admin3 slapd[3599]: conn=1218 fd=30 closed (connection lost on write)
Jan 29 16:11:41 gp42-admin3 slapd[3599]: conn=1032 op=27 SRCH base="cn=accesslog" scope=1 deref=3 filter="(objectClass=*)"
Jan 29 16:11:41 gp42-admin3 slapd[3599]: conn=1032 op=27 SRCH attr=hasSubordinates objectClass
Jan 29 16:11:41 gp42-admin3 slapd[3599]: conn=1032 op=27 SEARCH RESULT tag=101 err=0 nentries=36 text=
Jan 29 16:11:41 gp42-admin3 slapd[3599]: conn=1032 op=28 SRCH base="cn=accesslog" scope=0 deref=3 filter="(objectClass=*)"
Jan 29 16:11:41 gp42-admin3 slapd[3599]: conn=1032 op=28 SRCH attr=*
Jan 29 16:11:41 gp42-admin3 slapd[3599]: conn=1032 op=28 SEARCH RESULT tag=101 err=0 nentries=1 text=
Jan 29 16:12:02 gp42-admin3 slapd[3599]: conn=1219 fd=31 ACCEPT from IP=172.25.91.233:36146 (IP=0.0.0.0:389)
Jan 29 16:12:02 gp42-admin3 slapd[3599]: conn=1219 op=0 EXT oid=1.3.6.1.4.1.1466.20037
Jan 29 16:12:02 gp42-admin3 slapd[3599]: conn=1219 op=0 STARTTLS
Jan 29 16:12:02 gp42-admin3 slapd[3599]: conn=1219 op=0 RESULT oid= err=0 text=
Jan 29 16:12:02 gp42-admin3 slapd[3599]: conn=1219 fd=31 TLS established tls_ssf=256 ssf=256
Jan 29 16:12:02 gp42-admin3 slapd[3599]: conn=1219 op=1 BIND dn="cn=ldapadmin,dc=group42,dc=ldap" method=128
Jan 29 16:12:02 gp42-admin3 slapd[3599]: conn=1219 op=1 BIND dn="cn=ldapadmin,dc=group42,dc=ldap" mech=SIMPLE ssf=0
Jan 29 16:12:02 gp42-admin3 slapd[3599]: conn=1219 op=1 RESULT tag=97 err=0 text=
Jan 29 16:12:02 gp42-admin3 slapd[3599]: conn=1219 op=2 SRCH base="cn=accesslog" scope=2 deref=0 filter="(objectClass=*)"
Jan 29 16:12:02 gp42-admin3 slapd[3599]: conn=1219 op=2 SRCH attr=reqDN reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN
Jan 29 16:12:02 gp42-admin3 slapd[3599]: do_syncrep2: rid=001 got empty syncUUID with LDAP_SYNC_ADD (cn=accesslog)
Jan 29 16:12:02 gp42-admin3 slapd[3599]: do_syncrepl: rid=001 rc -1 retrying
Jan 29 16:12:02 gp42-admin3 slapd[3599]: conn=1219 op=3 UNBIND
Jan 29 16:12:02 gp42-admin3 slapd[3599]: conn=1219 fd=31 closed
Jan 29 16:12:06 gp42-admin3 slapd[3599]: do_syncrep2: rid=002 got empty syncUUID with LDAP_SYNC_ADD (cn=accesslog)
Jan 29 16:12:06 gp42-admin3 slapd[3599]: do_syncrepl: rid=002 rc -1 retrying
Jan 29 16:12:34 gp42-admin3 slapd[3599]: conn=1220 fd=30 ACCEPT from IP=155.34.133.44:54275 (IP=0.0.0.0:389)
Jan 29 16:12:34 gp42-admin3 slapd[3599]: conn=1220 op=0 EXT oid=1.3.6.1.4.1.1466.20037
Jan 29 16:12:34 gp42-admin3 slapd[3599]: conn=1220 op=0 STARTTLS
Jan 29 16:12:34 gp42-admin3 slapd[3599]: conn=1220 op=0 RESULT oid= err=0 text=
Jan 29 16:12:34 gp42-admin3 slapd[3599]: conn=1220 fd=30 TLS established tls_ssf=256 ssf=256
Jan 29 16:12:34 gp42-admin3 slapd[3599]: conn=1220 op=1 BIND dn="cn=ldapadmin,dc=group42,dc=ldap" method=128
Jan 29 16:12:34 gp42-admin3 slapd[3599]: conn=1220 op=1 BIND dn="cn=ldapadmin,dc=group42,dc=ldap" mech=SIMPLE ssf=0
Jan 29 16:12:34 gp42-admin3 slapd[3599]: conn=1220 op=1 RESULT tag=97 err=0 text=
Jan 29 16:12:34 gp42-admin3 slapd[3599]: conn=1220 op=2 SRCH base="cn=accesslog" scope=2 deref=0 filter="(objectClass=*)"
Jan 29 16:12:34 gp42-admin3 slapd[3599]: conn=1220 op=2 SRCH attr=reqDN reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN
Jan 29 16:12:34 gp42-admin3 slapd[3599]: send_search_entry: conn 1220 ber write failed.
Jan 29 16:12:34 gp42-admin3 slapd[3599]: conn=1220 fd=30 closed (connection lost on write)
Jan 29 16:13:02 gp42-admin3 slapd[3599]: conn=1221 fd=31 ACCEPT from IP=172.25.91.233:36149 (IP=0.0.0.0:389)
Jan 29 16:13:02 gp42-admin3 slapd[3599]: conn=1221 op=0 EXT oid=1.3.6.1.4.1.1466.20037
Jan 29 16:13:02 gp42-admin3 slapd[3599]: conn=1221 op=0 STARTTLS
Jan 29 16:13:02 gp42-admin3 slapd[3599]: conn=1221 op=0 RESULT oid= err=0 text=
Jan 29 16:13:03 gp42-admin3 slapd[3599]: conn=1221 fd=31 TLS established tls_ssf=256 ssf=256
Jan 29 16:13:03 gp42-admin3 slapd[3599]: conn=1221 op=1 BIND dn="cn=ldapadmin,dc=group42,dc=ldap" method=128
Jan 29 16:13:03 gp42-admin3 slapd[3599]: conn=1221 op=1 BIND dn="cn=ldapadmin,dc=group42,dc=ldap" mech=SIMPLE ssf=0
Jan 29 16:13:03 gp42-admin3 slapd[3599]: conn=1221 op=1 RESULT tag=97 err=0 text=
Jan 29 16:13:03 gp42-admin3 slapd[3599]: conn=1221 op=2 SRCH base="cn=accesslog" scope=2 deref=0 filter="(objectClass=*)"
Jan 29 16:13:03 gp42-admin3 slapd[3599]: conn=1221 op=2 SRCH attr=reqDN reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN
Jan 29 16:13:03 gp42-admin3 slapd[3599]: do_syncrep2: rid=001 got empty syncUUID with LDAP_SYNC_ADD (cn=accesslog)
Jan 29 16:13:03 gp42-admin3 slapd[3599]: do_syncrepl: rid=001 rc -1 retrying
Jan 29 16:13:03 gp42-admin3 slapd[3599]: conn=1221 op=3 UNBIND
Jan 29 16:13:03 gp42-admin3 slapd[3599]: conn=1221 fd=31 closed
Jan 29 16:13:06 gp42-admin3 slapd[3599]: do_syncrep2: rid=002 got empty syncUUID with LDAP_SYNC_ADD (cn=accesslog)
Jan 29 16:13:06 gp42-admin3 slapd[3599]: do_syncrepl: rid=002 rc -1 retrying
Jan 29 16:13:34 gp42-admin3 slapd[3599]: conn=1222 fd=30 ACCEPT from IP=155.34.133.44:54277 (IP=0.0.0.0:389)
Jan 29 16:13:34 gp42-admin3 slapd[3599]: conn=1222 op=0 EXT oid=1.3.6.1.4.1.1466.20037
Jan 29 16:13:34 gp42-admin3 slapd[3599]: conn=1222 op=0 STARTTLS
Jan 29 16:13:34 gp42-admin3 slapd[3599]: conn=1222 op=0 RESULT oid= err=0 text=
Jan 29 16:13:34 gp42-admin3 slapd[3599]: conn=1222 fd=30 TLS established tls_ssf=256 ssf=256
Jan 29 16:13:34 gp42-admin3 slapd[3599]: conn=1222 op=1 BIND dn="cn=ldapadmin,dc=group42,dc=ldap" method=128
Jan 29 16:13:34 gp42-admin3 slapd[3599]: conn=1222 op=1 BIND dn="cn=ldapadmin,dc=group42,dc=ldap" mech=SIMPLE ssf=0
Jan 29 16:13:34 gp42-admin3 slapd[3599]: conn=1222 op=1 RESULT tag=97 err=0 text=
Jan 29 16:13:34 gp42-admin3 slapd[3599]: conn=1222 op=2 SRCH base="cn=accesslog" scope=2 deref=0 filter="(objectClass=*)"
Jan 29 16:13:34 gp42-admin3 slapd[3599]: conn=1222 op=2 SRCH attr=reqDN reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN
Jan 29 16:13:34 gp42-admin3 slapd[3599]: conn=1222 op=3 UNBIND
Jan 29 16:13:34 gp42-admin3 slapd[3599]: conn=1222 fd=30 closed
-->Here is the log from the other server, same time frame:
Jan 29 16:10:06 gp42-admin4 slapd[26000]: conn=3232 fd=108 ACCEPT from IP=172.25.91.233:41849 (IP=0.0.0.0:389)
Jan 29 16:10:06 gp42-admin4 slapd[26000]: conn=3232 op=0 EXT oid=1.3.6.1.4.1.1466.20037
Jan 29 16:10:06 gp42-admin4 slapd[26000]: conn=3232 op=0 STARTTLS
Jan 29 16:10:06 gp42-admin4 slapd[26000]: conn=3232 op=0 RESULT oid= err=0 text=
Jan 29 16:10:06 gp42-admin4 slapd[26000]: conn=3232 fd=108 TLS established tls_ssf=256 ssf=256
Jan 29 16:10:06 gp42-admin4 slapd[26000]: conn=3232 op=1 BIND dn="cn=ldapadmin,dc=group42,dc=ldap" method=128
Jan 29 16:10:06 gp42-admin4 slapd[26000]: conn=3232 op=1 BIND dn="cn=ldapadmin,dc=group42,dc=ldap" mech=SIMPLE ssf=0
Jan 29 16:10:06 gp42-admin4 slapd[26000]: conn=3232 op=1 RESULT tag=97 err=0 text=
Jan 29 16:10:06 gp42-admin4 slapd[26000]: conn=3232 op=2 SRCH base="cn=accesslog" scope=2 deref=0 filter="(objectClass=*)"
Jan 29 16:10:06 gp42-admin4 slapd[26000]: conn=3232 op=2 SRCH attr=reqDN reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN
Jan 29 16:10:06 gp42-admin4 slapd[26000]: send_search_entry: conn 3232 ber write failed.
Jan 29 16:10:06 gp42-admin4 slapd[26000]: conn=3232 fd=108 closed (connection lost on write)
Jan 29 16:10:26 gp42-admin4 slapd[26000]: conn=3233 fd=109 ACCEPT from IP=155.34.133.44:38468 (IP=0.0.0.0:389)
Jan 29 16:10:26 gp42-admin4 slapd[26000]: conn=3233 op=0 EXT oid=1.3.6.1.4.1.1466.20037
Jan 29 16:10:26 gp42-admin4 slapd[26000]: conn=3233 op=0 STARTTLS
Jan 29 16:10:26 gp42-admin4 slapd[26000]: conn=3233 op=0 RESULT oid= err=0 text=
Jan 29 16:10:26 gp42-admin4 slapd[26000]: conn=3233 fd=109 TLS established tls_ssf=256 ssf=256
Jan 29 16:10:26 gp42-admin4 slapd[26000]: conn=3233 op=1 BIND dn="cn=ldapadmin,dc=group42,dc=ldap" method=128
Jan 29 16:10:26 gp42-admin4 slapd[26000]: conn=3233 op=1 BIND dn="cn=ldapadmin,dc=group42,dc=ldap" mech=SIMPLE ssf=0
Jan 29 16:10:26 gp42-admin4 slapd[26000]: conn=3233 op=1 RESULT tag=97 err=0 text=
Jan 29 16:10:26 gp42-admin4 slapd[26000]: conn=3233 op=2 SRCH base="cn=accesslog" scope=2 deref=0 filter="(objectClass=*)"
Jan 29 16:10:26 gp42-admin4 slapd[26000]: conn=3233 op=2 SRCH attr=reqDN reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN
Jan 29 16:10:26 gp42-admin4 slapd[26000]: do_syncrep2: rid=002 got empty syncUUID with LDAP_SYNC_ADD (cn=accesslog)
Jan 29 16:10:26 gp42-admin4 slapd[26000]: do_syncrepl: rid=002 rc -1 retrying
Jan 29 16:10:26 gp42-admin4 slapd[26000]: send_search_entry: conn 3233 ber write failed.
Jan 29 16:10:26 gp42-admin4 slapd[26000]: conn=3233 fd=109 closed (connection lost on write)
Jan 29 16:10:34 gp42-admin4 slapd[26000]: do_syncrep2: rid=001 got empty syncUUID with LDAP_SYNC_ADD (cn=accesslog)
Jan 29 16:10:34 gp42-admin4 slapd[26000]: do_syncrepl: rid=001 rc -1 retrying
Jan 29 16:11:06 gp42-admin4 slapd[26000]: conn=3234 fd=108 ACCEPT from IP=172.25.91.233:41852 (IP=0.0.0.0:389)
Jan 29 16:11:06 gp42-admin4 slapd[26000]: conn=3234 op=0 EXT oid=1.3.6.1.4.1.1466.20037
Jan 29 16:11:06 gp42-admin4 slapd[26000]: conn=3234 op=0 STARTTLS
Jan 29 16:11:06 gp42-admin4 slapd[26000]: conn=3234 op=0 RESULT oid= err=0 text=
Jan 29 16:11:06 gp42-admin4 slapd[26000]: conn=3234 fd=108 TLS established tls_ssf=256 ssf=256
Jan 29 16:11:06 gp42-admin4 slapd[26000]: conn=3234 op=1 BIND dn="cn=ldapadmin,dc=group42,dc=ldap" method=128
Jan 29 16:11:06 gp42-admin4 slapd[26000]: conn=3234 op=1 BIND dn="cn=ldapadmin,dc=group42,dc=ldap" mech=SIMPLE ssf=0
Jan 29 16:11:06 gp42-admin4 slapd[26000]: conn=3234 op=1 RESULT tag=97 err=0 text=
Jan 29 16:11:06 gp42-admin4 slapd[26000]: conn=3234 op=2 SRCH base="cn=accesslog" scope=2 deref=0 filter="(objectClass=*)"
Jan 29 16:11:06 gp42-admin4 slapd[26000]: conn=3234 op=2 SRCH attr=reqDN reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN
Jan 29 16:11:06 gp42-admin4 slapd[26000]: send_search_entry: conn 3234 ber write failed.
Jan 29 16:11:06 gp42-admin4 slapd[26000]: conn=3234 fd=108 closed (connection lost on write)
Jan 29 16:11:26 gp42-admin4 slapd[26000]: conn=3235 fd=109 ACCEPT from IP=155.34.133.44:38470 (IP=0.0.0.0:389)
Jan 29 16:11:26 gp42-admin4 slapd[26000]: conn=3235 op=0 EXT oid=1.3.6.1.4.1.1466.20037
Jan 29 16:11:26 gp42-admin4 slapd[26000]: conn=3235 op=0 STARTTLS
Jan 29 16:11:26 gp42-admin4 slapd[26000]: conn=3235 op=0 RESULT oid= err=0 text=
Jan 29 16:11:26 gp42-admin4 slapd[26000]: conn=3235 fd=109 TLS established tls_ssf=256 ssf=256
Jan 29 16:11:26 gp42-admin4 slapd[26000]: conn=3235 op=1 BIND dn="cn=ldapadmin,dc=group42,dc=ldap" method=128
Jan 29 16:11:26 gp42-admin4 slapd[26000]: conn=3235 op=1 BIND dn="cn=ldapadmin,dc=group42,dc=ldap" mech=SIMPLE ssf=0
Jan 29 16:11:26 gp42-admin4 slapd[26000]: conn=3235 op=1 RESULT tag=97 err=0 text=
Jan 29 16:11:26 gp42-admin4 slapd[26000]: conn=3235 op=2 SRCH base="cn=accesslog" scope=2 deref=0 filter="(objectClass=*)"
Jan 29 16:11:26 gp42-admin4 slapd[26000]: conn=3235 op=2 SRCH attr=reqDN reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN
Jan 29 16:11:26 gp42-admin4 slapd[26000]: do_syncrep2: rid=002 got empty syncUUID with LDAP_SYNC_ADD (cn=accesslog)
Jan 29 16:11:26 gp42-admin4 slapd[26000]: do_syncrepl: rid=002 rc -1 retrying
Jan 29 16:11:26 gp42-admin4 slapd[26000]: send_search_entry: conn 3235 ber write failed.
Jan 29 16:11:26 gp42-admin4 slapd[26000]: conn=3235 fd=109 closed (connection lost on write)
Jan 29 16:11:34 gp42-admin4 slapd[26000]: do_syncrep2: rid=001 got empty syncUUID with LDAP_SYNC_ADD (cn=accesslog)
Jan 29 16:11:34 gp42-admin4 slapd[26000]: do_syncrepl: rid=001 rc -1 retrying
Jan 29 16:11:47 gp42-admin4 slapd[26000]: conn=3036 op=20 SRCH base="cn=accesslog" scope=0 deref=3 filter="(objectClass=*)"
Jan 29 16:11:47 gp42-admin4 slapd[26000]: conn=3036 op=20 SRCH attr=*
Jan 29 16:11:47 gp42-admin4 slapd[26000]: conn=3036 op=20 SEARCH RESULT tag=101 err=0 nentries=1 text=
Jan 29 16:11:49 gp42-admin4 slapd[26000]: conn=3036 op=21 SRCH base="cn=accesslog" scope=1 deref=3 filter="(objectClass=*)"
Jan 29 16:11:49 gp42-admin4 slapd[26000]: conn=3036 op=21 SRCH attr=hasSubordinates objectClass
Jan 29 16:11:49 gp42-admin4 slapd[26000]: conn=3036 op=21 SEARCH RESULT tag=101 err=4 nentries=500 text=
Jan 29 16:11:49 gp42-admin4 slapd[26000]: conn=3036 op=22 SRCH base="cn=accesslog" scope=0 deref=3 filter="(objectClass=*)"
Jan 29 16:11:49 gp42-admin4 slapd[26000]: conn=3036 op=22 SRCH attr=*
Jan 29 16:11:49 gp42-admin4 slapd[26000]: conn=3036 op=22 SEARCH RESULT tag=101 err=0 nentries=1 text=
Jan 29 16:12:06 gp42-admin4 slapd[26000]: conn=3236 fd=108 ACCEPT from IP=172.25.91.233:41854 (IP=0.0.0.0:389)
Jan 29 16:12:06 gp42-admin4 slapd[26000]: conn=3236 op=0 EXT oid=1.3.6.1.4.1.1466.20037
Jan 29 16:12:06 gp42-admin4 slapd[26000]: conn=3236 op=0 STARTTLS
Jan 29 16:12:06 gp42-admin4 slapd[26000]: conn=3236 op=0 RESULT oid= err=0 text=
Jan 29 16:12:06 gp42-admin4 slapd[26000]: conn=3236 fd=108 TLS established tls_ssf=256 ssf=256
Jan 29 16:12:06 gp42-admin4 slapd[26000]: conn=3236 op=1 BIND dn="cn=ldapadmin,dc=group42,dc=ldap" method=128
Jan 29 16:12:06 gp42-admin4 slapd[26000]: conn=3236 op=1 BIND dn="cn=ldapadmin,dc=group42,dc=ldap" mech=SIMPLE ssf=0
Jan 29 16:12:06 gp42-admin4 slapd[26000]: conn=3236 op=1 RESULT tag=97 err=0 text=
Jan 29 16:12:06 gp42-admin4 slapd[26000]: conn=3236 op=2 SRCH base="cn=accesslog" scope=2 deref=0 filter="(objectClass=*)"
Jan 29 16:12:06 gp42-admin4 slapd[26000]: conn=3236 op=2 SRCH attr=reqDN reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN
Jan 29 16:12:06 gp42-admin4 slapd[26000]: send_search_entry: conn 3236 ber write failed.
Jan 29 16:12:06 gp42-admin4 slapd[26000]: conn=3236 fd=108 closed (connection lost on write)
Jan 29 16:12:18 gp42-admin4 slapd[26000]: conn=2702 op=23 SRCH base="dc=group42,dc=ldap" scope=1 deref=3 filter="(objectClass=*)"
Jan 29 16:12:18 gp42-admin4 slapd[26000]: conn=2702 op=23 SRCH attr=hasSubordinates objectClass
Jan 29 16:12:18 gp42-admin4 slapd[26000]: conn=2702 op=23 SEARCH RESULT tag=101 err=0 nentries=15 text=
Jan 29 16:12:18 gp42-admin4 slapd[26000]: conn=2702 op=24 SRCH base="dc=group42,dc=ldap" scope=0 deref=3 filter="(objectClass=*)"
Jan 29 16:12:18 gp42-admin4 slapd[26000]: conn=2702 op=24 SRCH attr=*
Jan 29 16:12:18 gp42-admin4 slapd[26000]: conn=2702 op=24 SEARCH RESULT tag=101 err=0 nentries=1 text=
Jan 29 16:12:21 gp42-admin4 slapd[26000]: conn=2702 op=25 SRCH base="ou=Users,dc=group42,dc=ldap" scope=1 deref=3 filter="(objectClass=*)"
Jan 29 16:12:21 gp42-admin4 slapd[26000]: conn=2702 op=25 SRCH attr=hasSubordinates objectClass
Jan 29 16:12:21 gp42-admin4 slapd[26000]: conn=2702 op=25 SEARCH RESULT tag=101 err=0 nentries=123 text=
Jan 29 16:12:26 gp42-admin4 slapd[26000]: conn=3237 fd=109 ACCEPT from IP=155.34.133.44:38472 (IP=0.0.0.0:389)
Jan 29 16:12:26 gp42-admin4 slapd[26000]: conn=2702 op=26 SRCH base="uid=daveb,ou=Users,dc=group42,dc=ldap" scope=0 deref=3 filter="(objectClass=*)"
Jan 29 16:12:26 gp42-admin4 slapd[26000]: conn=2702 op=26 SRCH attr=*
Jan 29 16:12:26 gp42-admin4 slapd[26000]: conn=2702 op=26 SEARCH RESULT tag=101 err=0 nentries=1 text=
Jan 29 16:12:26 gp42-admin4 slapd[26000]: conn=3237 op=0 EXT oid=1.3.6.1.4.1.1466.20037
Jan 29 16:12:26 gp42-admin4 slapd[26000]: conn=3237 op=0 STARTTLS
Jan 29 16:12:26 gp42-admin4 slapd[26000]: conn=3237 op=0 RESULT oid= err=0 text=
Jan 29 16:12:26 gp42-admin4 slapd[26000]: conn=3237 fd=109 TLS established tls_ssf=256 ssf=256
Jan 29 16:12:26 gp42-admin4 slapd[26000]: conn=3237 op=1 BIND dn="cn=ldapadmin,dc=group42,dc=ldap" method=128
Jan 29 16:12:26 gp42-admin4 slapd[26000]: conn=3237 op=1 BIND dn="cn=ldapadmin,dc=group42,dc=ldap" mech=SIMPLE ssf=0
Jan 29 16:12:26 gp42-admin4 slapd[26000]: conn=3237 op=1 RESULT tag=97 err=0 text=
Jan 29 16:12:26 gp42-admin4 slapd[26000]: conn=3237 op=2 SRCH base="cn=accesslog" scope=2 deref=0 filter="(objectClass=*)"
Jan 29 16:12:26 gp42-admin4 slapd[26000]: conn=3237 op=2 SRCH attr=reqDN reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN
Jan 29 16:12:26 gp42-admin4 slapd[26000]: do_syncrep2: rid=002 got empty syncUUID with LDAP_SYNC_ADD (cn=accesslog)
Jan 29 16:12:26 gp42-admin4 slapd[26000]: do_syncrepl: rid=002 rc -1 retrying
Jan 29 16:12:26 gp42-admin4 slapd[26000]: conn=3237 op=3 UNBIND
Jan 29 16:12:26 gp42-admin4 slapd[26000]: conn=3237 fd=109 closed
Jan 29 16:12:34 gp42-admin4 slapd[26000]: do_syncrep2: rid=001 got empty syncUUID with LDAP_SYNC_ADD (cn=accesslog)
Jan 29 16:12:34 gp42-admin4 slapd[26000]: do_syncrepl: rid=001 rc -1 retrying
Jan 29 16:13:06 gp42-admin4 slapd[26000]: conn=3238 fd=108 ACCEPT from IP=172.25.91.233:41857 (IP=0.0.0.0:389)
Jan 29 16:13:06 gp42-admin4 slapd[26000]: conn=3238 op=0 EXT oid=1.3.6.1.4.1.1466.20037
Jan 29 16:13:06 gp42-admin4 slapd[26000]: conn=3238 op=0 STARTTLS
Jan 29 16:13:06 gp42-admin4 slapd[26000]: conn=3238 op=0 RESULT oid= err=0 text=
Jan 29 16:13:06 gp42-admin4 slapd[26000]: conn=3238 fd=108 TLS established tls_ssf=256 ssf=256
Jan 29 16:13:06 gp42-admin4 slapd[26000]: conn=3238 op=1 BIND dn="cn=ldapadmin,dc=group42,dc=ldap" method=128
Jan 29 16:13:06 gp42-admin4 slapd[26000]: conn=3238 op=1 BIND dn="cn=ldapadmin,dc=group42,dc=ldap" mech=SIMPLE ssf=0
Jan 29 16:13:06 gp42-admin4 slapd[26000]: conn=3238 op=1 RESULT tag=97 err=0 text=
Jan 29 16:13:06 gp42-admin4 slapd[26000]: conn=3238 op=2 SRCH base="cn=accesslog" scope=2 deref=0 filter="(objectClass=*)"
Jan 29 16:13:06 gp42-admin4 slapd[26000]: conn=3238 op=2 SRCH attr=reqDN reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN
Jan 29 16:13:06 gp42-admin4 slapd[26000]: conn=3238 op=3 UNBIND
Jan 29 16:13:06 gp42-admin4 slapd[26000]: conn=3238 fd=108 closed
Jan 29 16:13:26 gp42-admin4 slapd[26000]: conn=3239 fd=109 ACCEPT from IP=155.34.133.44:38474 (IP=0.0.0.0:389)
Jan 29 16:13:26 gp42-admin4 slapd[26000]: conn=3239 op=0 EXT oid=1.3.6.1.4.1.1466.20037
Jan 29 16:13:26 gp42-admin4 slapd[26000]: conn=3239 op=0 STARTTLS
Jan 29 16:13:26 gp42-admin4 slapd[26000]: conn=3239 op=0 RESULT oid= err=0 text=
Jan 29 16:13:26 gp42-admin4 slapd[26000]: conn=3239 fd=109 TLS established tls_ssf=256 ssf=256
Jan 29 16:13:26 gp42-admin4 slapd[26000]: conn=3239 op=1 BIND dn="cn=ldapadmin,dc=group42,dc=ldap" method=128
Jan 29 16:13:26 gp42-admin4 slapd[26000]: conn=3239 op=1 BIND dn="cn=ldapadmin,dc=group42,dc=ldap" mech=SIMPLE ssf=0
Jan 29 16:13:26 gp42-admin4 slapd[26000]: conn=3239 op=1 RESULT tag=97 err=0 text=
Jan 29 16:13:26 gp42-admin4 slapd[26000]: conn=3239 op=2 SRCH base="cn=accesslog" scope=2 deref=0 filter="(objectClass=*)"
Jan 29 16:13:26 gp42-admin4 slapd[26000]: conn=3239 op=2 SRCH attr=reqDN reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN
Jan 29 16:13:26 gp42-admin4 slapd[26000]: do_syncrep2: rid=002 got empty syncUUID with LDAP_SYNC_ADD (cn=accesslog)
Jan 29 16:13:26 gp42-admin4 slapd[26000]: do_syncrepl: rid=002 rc -1 retrying
Jan 29 16:13:26 gp42-admin4 slapd[26000]: conn=3239 op=3 UNBIND
Jan 29 16:13:26 gp42-admin4 slapd[26000]: conn=3239 fd=109 closed
Jan 29 16:13:34 gp42-admin4 slapd[26000]: do_syncrep2: rid=001 got empty syncUUID with LDAP_SYNC_ADD (cn=accesslog)
Jan 29 16:13:34 gp42-admin4 slapd[26000]: do_syncrepl: rid=001 rc -1 retrying
-->When trying to get a copy of the olcDatabase={0}bdb,cn=config from server#1, I receive the following:
# slapcat -s olcDatabase=\{1\}bdb,cn=config
52e97450 ldif_read_file: checksum error on "/usr/local/openldap/etc/openldap/slapd.d/cn=config.ldif"
52e97450 ldif_read_file: checksum error on "/usr/local/openldap/etc/openldap/slapd.d/cn=config.ldif"
dn: olcDatabase={1}bdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcBdbConfig
olcDatabase: {1}bdb
olcSuffix: dc=group42,dc=ldap
olcAddContentAcl: FALSE
olcLastMod: TRUE
olcMaxDerefDepth: 15
olcReadOnly: FALSE
olcRootDN: cn=ldapadmin,dc=group42,dc=ldap
olcRootPW:: _____________________________________=
olcSyncUseSubentry: FALSE
olcMonitoring: TRUE
olcDbDirectory: /var/lib/openldap/openldap-data
olcDbCacheSize: 1000
olcDbConfig: {0}# $OpenLDAP$
olcDbConfig: {1}# Example DB_CONFIG file for use with slapd(8) BDB/HDB databas
es.
olcDbConfig: {2}#
olcDbConfig: {3}# See the Oracle Berkeley DB documentation
olcDbConfig: {4}# <http://www.oracle.com/technology/documentation/berkeley-d
b/db/ref/env/db_config.html>
olcDbConfig: {5}# for detail description of DB_CONFIG syntax and semantics.
olcDbConfig: {6}#
olcDbConfig: {7}# Hints can also be found in the OpenLDAP Software FAQ
olcDbConfig:: ezh9Iwk8aHR0cDovL3d3dy5vcGVubGRhcC5vcmcvZmFxL2luZGV4LmNnaT9maWxl
PTI+
olcDbConfig: {9}# in particular:
olcDbConfig: {10}# <http://www.openldap.org/faq/index.cgi?file=1075>
olcDbConfig: {11}
olcDbConfig: {12}# Note: most DB_CONFIG settings will take effect only upon re
building
olcDbConfig: {13}# the DB environment.
olcDbConfig: {14}
olcDbConfig: {15}# one 0.25 GB cache
olcDbConfig: {16}set_cachesize 0 268435456 1
olcDbConfig: {17}
olcDbConfig: {18}# Data Directory
olcDbConfig: {19}#set_data_dir db
olcDbConfig: {20}
olcDbConfig: {21}# Transaction Log settings
olcDbConfig: {22}set_lg_regionmax 262144
olcDbConfig: {23}set_lg_bsize 2097152
olcDbConfig: {24}#set_lg_dir logs
olcDbConfig: {25}
olcDbConfig: {26}# Note: special DB_CONFIG flags are no longer needed for "qui
ck"
olcDbConfig:: ezI3fSMgc2xhcGFkZCg4KSBvciBzbGFwaW5kZXgoOCkgYWNjZXNzIChzZWUgdGhl
aXIgLXEgb3B0aW9uKS4g
olcDbNoSync: FALSE
olcDbDirtyRead: FALSE
olcDbIDLcacheSize: 0
olcDbIndex: objectClass eq
olcDbIndex: entryUUID eq
olcDbIndex: entryCSN eq
olcDbIndex: cn eq,sub
olcDbIndex: uid eq
olcDbIndex: uidNumber eq
olcDbIndex: gidNumber eq
olcDbIndex: sn eq,sub
olcDbIndex: mail eq,sub
olcDbIndex: departmentNumber eq
olcDbIndex: automountKey eq
olcDbIndex: memberUid eq
olcDbIndex: printerURI eq
olcDbLinearIndex: FALSE
olcDbMode: 0600
olcDbSearchStack: 16
olcDbShmKey: 0
olcDbCacheFree: 1
olcDbDNcacheSize: 0
structuralObjectClass: olcBdbConfig
entryUUID: 5a87b5f1-c445-4e0e-ba97-6d2d63093704
creatorsName: cn=config
createTimestamp: 20140122200748Z
olcSyncrepl: {0}rid=001 provider=ldap://gp42-admin3.group42.ldap bindmethod=si
mple binddn="cn=ldapadmin,dc=group42,dc=ldap" credentials=<password> interva
l=01:00:00:00 searchbase="dc=group42,dc=ldap" logbase="cn=accesslog" schemach
ecking=on type=refreshAndPersist retry="60 +" filter="(objectClass=*)" attrs=
"*,+" syncdata=accesslog starttls=yes tls_cacert=/usr/local/openldap/etc/open
ldap/CA/cacert.pem
olcSyncrepl: {1}rid=002 provider=ldap://gp42-admin4.group42.ldap bindmethod=si
mple binddn="cn=ldapadmin,dc=group42,dc=ldap" credentials=<password> interva
l=01:00:00:00 searchbase="dc=group42,dc=ldap" logbase="cn=accesslog" schemach
ecking=on type=refreshAndPersist retry="60 +" filter="(objectClass=*)" attrs=
"*,+" syncdata=accesslog starttls=yes tls_cacert=/usr/local/openldap/etc/open
ldap/CA/cacert.pem
olcMirrorMode: TRUE
entryCSN: 20140129193518.096476Z#000000#001#000000
modifiersName: cn=admin,cn=config
modifyTimestamp: 20140129193518Z
dn: olcOverlay={0}syncprov,olcDatabase={1}bdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: {0}syncprov
olcSpNoPresent: TRUE
structuralObjectClass: olcSyncProvConfig
entryUUID: 04afe1bf-40c7-425a-8b25-74f8687323fc
creatorsName: cn=admin,cn=config
createTimestamp: 20140129180447Z
entryCSN: 20140129180447.701059Z#000000#001#000000
modifiersName: cn=admin,cn=config
modifyTimestamp: 20140129180447Z
dn: olcOverlay={1}accesslog,olcDatabase={1}bdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcAccessLogConfig
olcOverlay: {1}accesslog
olcAccessLogDB: cn=accesslog
olcAccessLogOps: writes
olcAccessLogPurge: 07+00:00 01+00:00
olcAccessLogSuccess: TRUE
structuralObjectClass: olcAccessLogConfig
entryUUID: 54b5fa00-8244-41d3-923d-0743a10bf192
creatorsName: cn=admin,cn=config
createTimestamp: 20140129180903Z
entryCSN: 20140129180903.479192Z#000000#001#000000
modifiersName: cn=admin,cn=config
modifyTimestamp: 20140129180903Z
-->From server#2:
# slapcat -s olcDatabase=\{1\}bdb,cn=config
dn: olcDatabase={1}bdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcBdbConfig
olcDatabase: {1}bdb
olcSuffix: dc=group42,dc=ldap
olcAddContentAcl: FALSE
olcLastMod: TRUE
olcMaxDerefDepth: 15
olcReadOnly: FALSE
olcRootDN: cn=ldapadmin,dc=group42,dc=ldap
olcRootPW:: ________________________________=
olcSyncUseSubentry: FALSE
olcMonitoring: TRUE
olcDbDirectory: /var/lib/openldap/openldap-data
olcDbCacheSize: 1000
olcDbConfig: {0}# $OpenLDAP$
olcDbConfig: {1}# Example DB_CONFIG file for use with slapd(8) BDB/HDB databas
es.
olcDbConfig: {2}#
olcDbConfig: {3}# See the Oracle Berkeley DB documentation
olcDbConfig: {4}# <http://www.oracle.com/technology/documentation/berkeley-d
b/db/ref/env/db_config.html>
olcDbConfig: {5}# for detail description of DB_CONFIG syntax and semantics.
olcDbConfig: {6}#
olcDbConfig: {7}# Hints can also be found in the OpenLDAP Software FAQ
olcDbConfig:: ezh9Iwk8aHR0cDovL3d3dy5vcGVubGRhcC5vcmcvZmFxL2luZGV4LmNnaT9maWxl
PTI+
olcDbConfig: {9}# in particular:
olcDbConfig: {10}# <http://www.openldap.org/faq/index.cgi?file=1075>
olcDbConfig: {11}
olcDbConfig: {12}# Note: most DB_CONFIG settings will take effect only upon re
building
olcDbConfig: {13}# the DB environment.
olcDbConfig: {14}
olcDbConfig: {15}# one 0.25 GB cache
olcDbConfig: {16}#set_cachesize 0 268435456 1
olcDbConfig: {17}set_cachesize 0 2147483648 1
olcDbConfig: {18}
olcDbConfig: {19}# Data Directory
olcDbConfig: {20}#set_data_dir db
olcDbConfig: {21}
olcDbConfig: {22}# Archive/deletion
olcDbConfig: {23}set_flags DB_LOG_AUTOREMOVE
olcDbConfig: {24}
olcDbConfig: {25}# Transaction Log settings
olcDbConfig: {26}set_lg_regionmax 262144
olcDbConfig: {27}set_lg_bsize 2097152
olcDbConfig: {28}#set_lg_dir logs
olcDbConfig: {29}
olcDbConfig: {30}# Note: special DB_CONFIG flags are no longer needed for "qui
ck"
olcDbConfig:: ezMxfSMgc2xhcGFkZCg4KSBvciBzbGFwaW5kZXgoOCkgYWNjZXNzIChzZWUgdGhl
aXIgLXEgb3B0aW9uKS4g
olcDbNoSync: FALSE
olcDbDirtyRead: FALSE
olcDbIDLcacheSize: 0
olcDbIndex: objectClass eq
olcDbIndex: entryUUID eq
olcDbIndex: entryCSN eq
olcDbIndex: cn eq,sub
olcDbIndex: uid eq
olcDbIndex: uidNumber eq
olcDbIndex: gidNumber eq
olcDbIndex: sn eq,sub
olcDbIndex: departmentNumber eq
olcDbIndex: mail eq,sub
olcDbIndex: automountKey eq
olcDbIndex: memberUid eq
olcDbIndex: printerURI eq
olcDbLinearIndex: FALSE
olcDbMode: 0600
olcDbSearchStack: 16
olcDbShmKey: 0
olcDbCacheFree: 1
olcDbDNcacheSize: 0
structuralObjectClass: olcBdbConfig
entryUUID: 94ff450b-aa70-4507-9ca6-51cdd740ea3e
creatorsName: cn=config
createTimestamp: 20131218155313Z
olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by anonymou
s auth by * none
olcAccess: {1}to * by * read
olcSyncrepl: {0}rid=001 provider=ldap://gp42-admin3.group42.ldap bindmethod=si
mple binddn="cn=ldapadmin,dc=group42,dc=ldap" credentials=<password> interva
l=01:00:00:00 searchbase="dc=group42,dc=ldap" logbase="cn=accesslog" schemach
ecking=on type=refreshAndPersist retry="60 +" filter="(objectClass=*)" attrs=
"*,+" syncdata=accesslog starttls=yes tls_cacert=/usr/local/openldap/etc/open
ldap/CA/cacert.pem
olcSyncrepl: {1}rid=002 provider=ldap://gp42-admin4.group42.ldap bindmethod=si
mple binddn="cn=ldapadmin,dc=group42,dc=ldap" credentials=<password> interva
l=01:00:00:00 searchbase="dc=group42,dc=ldap" logbase="cn=accesslog" schemach
ecking=on type=refreshAndPersist retry="60 +" filter="(objectClass=*)" attrs=
"*,+" syncdata=accesslog starttls=yes tls_cacert=/usr/local/openldap/etc/open
ldap/CA/cacert.pem
olcMirrorMode: TRUE
entryCSN: 20140129193241.088847Z#000000#002#000000
modifiersName: cn=admin,cn=config
modifyTimestamp: 20140129193241Z
dn: olcOverlay={0}accesslog,olcDatabase={1}bdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcAccessLogConfig
olcOverlay: {0}accesslog
olcAccessLogDB: cn=accesslog
olcAccessLogOps: writes
olcAccessLogPurge: 07+00:00 01+00:00
olcAccessLogSuccess: TRUE
structuralObjectClass: olcAccessLogConfig
entryUUID: 6e4e1508-5eb9-4372-bbd1-813f859b0acc
creatorsName: cn=admin,cn=config
createTimestamp: 20140129182321Z
entryCSN: 20140129182321.004272Z#000000#002#000000
modifiersName: cn=admin,cn=config
modifyTimestamp: 20140129182321Z
dn: olcOverlay={1}syncprov,olcDatabase={1}bdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: {1}syncprov
olcSpNoPresent: TRUE
structuralObjectClass: olcSyncProvConfig
entryUUID: 9108e0db-ba9e-4b40-b743-4016c61582bc
creatorsName: cn=admin,cn=config
createTimestamp: 20140129183014Z
entryCSN: 20140129183014.073365Z#000000#002#000000
modifiersName: cn=admin,cn=config
modifyTimestamp: 20140129183014Z
Thank you in advance, let me know if any expanding information is needed.
John D. Borresen (Dave)
Linux/Unix Systems Administrator
MIT Lincoln Laboratory
Surveillance Systems Group
244 Wood St
Lexington, MA 02420
email: john.borresen(a)ll.mit.edu<mailto:john.borresen@ll.mit.edu>
12 years, 9 months
Re: Syncrepl partial replication based on attribute problem
by Jeffrey Crawford
Ok I think I got this to work I didn't add a filter to the syncrepl
parameter so I'm using ACL's as before, however I changed the acls to
allow the replica account access to the attributes entry and entryUUID
only on every item in the directory, now setting attributes to values
so that they no longer match the access to the rest of the acls seem
to do what I wan't however I'm not quite sure how. so in short the
provider looks something like this:
olcAccess: to dn.subtree="dc=example,dc=org"
attrs=entry,entryUUID
by dn.base="cn=replica,ou=admins,dc=example,dc=org" ssf=128 read
by * none break
olcAccess: to dn.subtree="dc=example,dc=org"
filter="(replicateMe=TRUE)"
attrs=@inetOrgPerson,@posixAccount,entryCSN,contextCSN,createTimestamp,modifyTimestamp,structuralObjectClass
by dn.base="cn=replica,ou=admins,dc=example,dc=org" ssf=128 read
by * none break
And the replicas are configured as so:
dn: olcDatabase={1}hdb,cn=config
changeType: modify
replace: olcSyncrepl
olcSyncrepl: rid=1
provider=ldap://ldap-!!!!ENV!!!!-1.example.org:1389/
starttls=critical
tls_reqcert=never
bindmethod=simple
retry="60 10 900 92 86400 3"
binddn="cn=replica,ou=admins,dc=example,dc=org"
credentials=!!!!PW!!!!
schemachecking=off
searchbase="dc=example,dc=org"
type=refreshAndPersist
olcSyncrepl: rid=2
provider=ldap://ldap-!!!!ENV!!!!-2.example.org:1389/
starttls=critical
tls_reqcert=never
bindmethod=simple
retry="60 10 900 92 86400 3"
binddn="cn=replica,ou=admins,dc=example,dc=org"
credentials=!!!!PW!!!!
schemachecking=off
searchbase="dc=example,dc=org"
type=refreshAndPersist
now the following will add a record to the replica:
dn: uid=user,ou=people,dc=example,dc=org
changeType: modify
replace: replicateMe
replicateMe: TRUE
And the following will take it away (delete):
dn: uid=user,ou=people,dc=example,dc=org
changeType: modify
replace: replicateMe
replicateMe: FALSE
However I don't know enough about the underlying code to be sure the
following is working as designed. Meaning I don't want to be relying
on a bug that might get fixed later.
Thanks
Jeffrey
access:
On Fri, Jun 1, 2012 at 9:26 AM, Jeffrey Crawford <jeffreyc(a)ucsc.edu> wrote:
>
> Humm and taking this one step further I'm guessing that the replication account probably needs to see at least the entryUUID and entryCSN for all accounts to make sure that it can see the records it needs to delete. Okay at least I have some direction to go on now.
>
> Jeffrey
>
>
> On Fri, Jun 1, 2012 at 9:06 AM, Nick Milas <nick(a)eurobjects.com> wrote:
>>
>> On 1/6/2012 8:54 πμ, Jeffrey Crawford wrote:
>>
>>> Are you saying that syncprov looks at the account that is bound and sends deletes if a record would become invisible after a modification?
>>
>>
>> I understand the opposite: syncprov will only send add/delete message based on base/scope/filter and not on ACL-visibility. So in essence Howard says that ACL-based filtering in replication does not result in proper results to consumers.
>>
>> This is tricky! (I didn't know either.) It means that we should *not* design our replication based on ACL-filtering (which, unfortunately, we have done too), but, on the contrary, that we should design our DIT so that it can cover our replication needs based on consumer base/scope/filter configuration, and we should design/adapt our ACLs with the above rule in mind.
>>
>> Please confirm the above thoughts.
>>
>> Thanks,
>> Nick
>
>
>
>
> --
> I fly because it releases my mind from the tyranny of petty things . . .
>
> — Antoine de Saint-Exupéry
>
> Jeffrey E. Crawford
> ITS Application Administrator (IDM)
> 831-459-4365
> jeffreyc(a)ucsc.edu
--
I fly because it releases my mind from the tyranny of petty things . . .
— Antoine de Saint-Exupéry
Jeffrey E. Crawford
ITS Application Administrator (IDM)
831-459-4365
jeffreyc(a)ucsc.edu
14 years, 5 months
AW: syncrepl connection / reconnect
by Thorsten Mueller
Here you are, the config of the second machine is identical, apart from the different provider
#######################################################################
#
# Global settings
#
#######################################################################
pidfile /var/run/slapd.pid
argsfile /var/run/slapd.args
ucdata-path /usr/ucdata
serverID 1
moduleload syncprov
###################################
# Useful settings for enabling LDAPS (i.e. LDAP over SSL/TLS) access to this server
###################################
TLSCACertificateFile /etc/TLS/ca-certs/trusted_CAs.pem
TLSCACertificatePath /etc/TLS/links
TLSCertificateFile /etc/TLS/server/server.pem
TLSCertificateKeyFile /etc/TLS/server/server_key.pem
TLSCipherSuite HIGH:MEDIUM:SSLv3
TLSVerifyClient try
###################################
# Public LDAP schemas
###################################
include /etc/schema/core.schema
include /etc/schema/cosine.schema
include /etc/schema/inetorgperson.schema
###################################
# Gateway specific LDAP schemas
###################################
include /etc/schema/database.schema
loglevel 256
###################################
# Access control
###################################
access to attrs=userPassword
by anonymous auth
by * none
access to dn.subtree="dc=SpecialBranch,dc=head"
by dn.base="cn=SpecialBranchUser,dc=SpecialBranch,dc=head" write
by dn.base="cn=Replicator,dc=DatabaseReplication,dc=head" write
by * none
access to *
by dn.base="cn=Replicator,dc=DatabaseReplication,dc=head" write
by * none
access to * by * none
#######################################################################
#
# Database definitions
#
#######################################################################
###################################
# Database for SpecialBranch
###################################
database bdb
suffix "dc=SpecialBranch,dc=head"
subordinate
rootdn "cn=admin,dc=head"
directory /var/db-SpecialBranch
monitoring off
index objectClass eq
index entryCSN eq
index entryUUID eq
index contextCSN eq
index DatabaseAttrRuleID eq
overlay syncprov
syncprov-checkpoint 100 10
syncprov-sessionlog 100
# syncrepl directiv
syncrepl rid=001
provider=ldap://192.168.120.237:388
bindmethod=simple
binddn="cn=Replicator,dc=DatabaseReplication,dc=head"
credentials="fdet2zS3"
searchbase="dc=SpecialBranch,dc=head"
starttls=critical
tls_cacert=/etc/TLS/ca-certs/trusted_CAs.pem
tls_cert=etc/TLS/client/client.pem
tls_key=etc/TLS/client/client_key.pem
schemachecking=on
type=refreshAndPersist
retry="5 12 60 +"
mirrormode on
###################################
# Database for the general configuration
###################################
database bdb
suffix "dc=head"
rootdn "cn=admin,dc=head"
rootpw "{SSHA}fO7A1sCrZzhy2IpNCvoVrQ9oRFpFY8Uj"
directory /var/db-general
monitoring off
index objectClass eq
index entryCSN eq
index entryUUID eq
index contextCSN eq
index mail eq,sub
index DatabaseAttrIssuerDN eq,sub
index DatabaseAttrSubjectDN eq,sub
index DatabaseAttrSerial eq
index DatabaseAttrFingerprint eq,sub
index DatabaseAttrKeyID eq,sub
index DatabaseAttrKeySigner pres
index DatabaseAttrKeyHash eq
overlay syncprov
syncprov-checkpoint 100 10
syncprov-sessionlog 100
# syncrepl directiv
syncrepl rid=001
provider=ldap://192.168.120.237:388
bindmethod=simple
binddn="cn=Replicator,dc=DatabaseReplication,dc=head"
credentials="fdet2zS3"
searchbase="dc=head"
starttls=critical
tls_cacert=/etc/TLS/ca-certs/trusted_CAs.pem
tls_cert=etc/TLS/client/client.pem
tls_key=etc/TLS/client/client_key.pem
schemachecking=on
type=refreshAndPersist
retry="5 12 60 +"
mirrormode on
#eof
Von: Benjamin Griese [mailto:der.darude@gmail.com]
Gesendet: Freitag, 26. März 2010 10:05
An: Thorsten Mueller
Cc: openldap-technical(a)openldap.org
Betreff: Re: syncrepl connection / reconnect
Hi Thorsten,
please provide more information for example your slapd.conf / slapd.d. The more infos you give the more feedback you get.
Bye.
On Fri, Mar 26, 2010 at 09:40, Thorsten Mueller <Thorsten.Mueller(a)aachen.utimaco.de<mailto:Thorsten.Mueller@aachen.utimaco.de>> wrote:
Hi,
I am using two slapd 2.4.20 in mirror mode. Everything seem to work fine. When I shut down slapd_A, I can see the connection retries in the log of B. After restarting A everything is fine. Replication works in both directions.
When I switch off the machine hosting A, B does not log anything. After starting machine A, replication only works from B to A and not from A to B. Only after restarting slapd_B the connection is reestablished and the changes are synced. I see the same behavior, if I just do a "ifconfig eth0 down". The remaining slapd seems not to recognize a loss of the network connection.
Is this a bug in openldap, or a configuration issue on my side?
Thanks,
Thorsten
--
To be or not to be -- Shakespeare | To do is to be -- Nietzsche | To be is to do -- Sartre | Do be do be do -- Sinatra
16 years, 7 months
ldap_sasl_interactive_bind_s failed (-2) using openldap v2.3.43 when trying to replicate via syncrepl.
by Kristian Kostecky
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi guys,
I have a configuration that consists of 3 ldap servers. One is the provider and there are 2 consumers. I am using syncrepl to do the synchronization. simple and anonymous binds are totally disabled and Kerberos must be used via SASL (GSSAPI) and TLS to connect to the LDAP server.
distro: centos 5.4
openldap 2.3.43
cyrus-sasl 2.1.22
Other things:
- - clocks are all in sync
- - hostnames all have forward and reverse mappings and all dns servers in /etc/resolv.conf respond with proper entries on the consumer and both providers.
Here's the catch, the two providers are configured the same (except for hostnames/ips) and the first one works perfect. What is really frustrating is the lack of logging that is available to tell me what the problem is. I've tried loglevel -1 and it gave me even less info in regards to the SASL authentication than leaving it off.
The affected consumer is giving me:
Mar 31 22:41:00 ZZZ slapd[2442]: slapd starting
Mar 31 22:41:02 ZZZ slapd[2442]: do_syncrep1: rid 010 ldap_sasl_interactive_bind_s failed (-2)
Mar 31 22:41:02 ZZZ slapd[2442]: do_syncrepl: rid 010 quitting
On the "Provider":
Mar 31 17:49:54 XXX slapd[3494]: conn=212 fd=21 ACCEPT from IP=10.130.1.230:60288 (IP=0.0.0.0:389)
Mar 31 17:49:54 XXX slapd[3494]: conn=212 op=0 STARTTLS
Mar 31 17:49:54 XXX slapd[3494]: conn=212 op=0 RESULT oid= err=0 text=
Mar 31 17:49:54 XXX slapd[3494]: conn=212 fd=21 TLS established tls_ssf=256 ssf=256
Mar 31 17:49:54 XXX slapd[3494]: conn=212 op=1 UNBIND
Mar 31 17:49:54 XXX slapd[3494]: conn=212 fd=21 closed
This is what's REALLY weird - from the affected/broken box, ZZZ, after I kinit, I can do an LDAP search or ldapwhoami, no problems! So, kerberos and GSSAPI via SASL is working fine. ie:
ldapsearch -H ldaps://XXX/ -Y GSSAPI -> will dump the entries.
or
ldapwhoami -H ldaps://XXX/ -Y GSSAPI -> shows me that proper creds
If I destroy the credentials, it doesn't work as would be expected.
ON the working consumer, the behaviour is that I can ldapsearch and ldapwhoami properly after I kinit and when I start ldap it will authenticate properly with the provider via SASL GSSAPI and replicates the DB. If I kdestroy the credentials and start it, I get the same error that I'm struggling with on the box that doesn't work ->ldap_sasl_interactive_bind_s failed (-2) This behaviour leads me to believe that for some reason the ldap server on the box that doesn't work is having problems transmitting the kerberos credentials to the provider, whereas the ldapsearch and ldapwhoami binaries are not having problems.
There are some suspicious differences between the consumer that works and the broken one. The provider and consumer that works both have TLDs that match - '.com' and the consumer whose synrepl process won't authenticate is part of the .eu TLD. However, as you can see below in the krb5.conf files, the .com and .eu TLDS are always mapped to the same authentication realm. PLUS, again, ldapsearch and ldapwhoami WORK. It's just the syncrepl process that isn't quite getting the auth right.
This is the provider's pertinent configs:
slapd.conf:
overlay syncprov
syncprov-checkpoint 100 10
syncprov-sessionlog 100
This is the consumer's pertinent configs (WORKS ON one, not on the other)
slapd.conf:
syncrepl rid=10
provider=ldap://xxx.XXX.com
starttls=yes
type=refreshOnly
interval=00:00:01:00
searchbase="dc=XXX,dc=com"
schemachecking=off
bindmethod=sasl
saslmech=GSSAPI
krb5.conf [same as provider and kerb server]:
[libdefaults]
default_realm = BOUNCE.AAA.COM
encrypt = true
allow_weak_crypto = false
clockskew = 600
dns_lookup_realm = false
dns_lookup_kdc = false
ticket_lifetime = 8h
forwardable = no
proxiable = no
[realms]
BOUNCE.AAA.COM = {
kdc = XXX.com
kdc = YYY.com
kdc = ZZZ.eu
admin_server = XXX.com
}
[domain_realm]
.com = BOUNCE.AAA.COM
.eu = BOUNCE.AAA.COM
All help is greatly appreciated! This has been going on for days and I've already yanked out most of my hair. Thank you.
Kris.
PGP Key: 4CC63A18
PGP Server: pool.sks-keyservers.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.14 (Darwin)
iEYEARECAAYFAkuzyroACgkQ2C/J5/UUQWEuUACdH/BhiZgTXFWbNMXS7Q99k8Rg
VY8An3YWKcpnkxVYvZMlelkT0TIpYuAP
=O9KI
-----END PGP SIGNATURE-----
16 years, 7 months
Re: Ldap is up, trying to get tls working.
by Juan Miscaro
On 1 November 2011 11:53, John Tobin <jtobin(a)po-box.esu.edu> wrote:
> Certificates verify.
> That's a neat tool, put that information somewhere useful.
> I had been trying to prove that the certificates were good for a long time.
>
> I changed from nscd, to nslcd by installing via yast, nss-pam-ldapd
>
> That wasn't too bad.
>
> I configured nslcd with:
>
> Uri ldap://nightmare.dark.net:389/
>
> Base "dc=dark,dc=net"
>
> Ssl start_tls
> Tls_req never
> Tls_cacertfile /var/lib/ldap/cacert.pem
>
> Tls_cert /var/lib/ldap/server.pem
> Tls_key /var/lib/ldap/server.key
>
> Ldapsearch still works .... With -ZZ
>
> But su - jtobin
> Gets the same error message this time from kdeinit:
>
> nightmare:/var/log # tail -f messages |grep tls
> Nov 1 11:48:11 nightmare kdeinit4: nss-ldap: do_open: do_start_tls
> failed:stat=-1
> Nov 1 11:48:11 nightmare kdeinit4: nss-ldap: do_open: do_start_tls
> failed:stat=-1
>
> I guess I am wondering if I configured something wrong....
> Why am I seeing nss-ldap in here...
>
> I installed nslcd, configured it, and didn't change any thing in ldap.conf
> or nsswitch.conf, should anything else be changed?
>
> tob
>
>
> nighttrain:~ johntobin$
>
>
>
>
>
>
>
> On 10/28/11 12:08 PM, "Christopher Wood" <christopher_wood(a)pobox.com> wrote:
>
>> Cheap advice inline.
>>
>> On Fri, Oct 28, 2011 at 11:44:25AM -0400, John Tobin wrote:
>>> Folks,
>>>
>>> I have openldap up, it supports vsftpd, sshd, and 5 client linux machines
>>> for remote login.
>>>
>>> I would like to get tls working. I would support either ldaps [port 636],
>>> or the tls available on port 389, I am aware of the differences in
>>> implementation, and the fact that an administrator effectively has to make
>>> a decision to support one or the other in most cases.
>>>
>>> Currently:
>>> I have slapd running configured for tls under ldap [std port 389].
>>> I am testing it on the slapd machine, with a client on the same machine.
>>> I am pointing to the same cacertificate in slapd.d [cn=config.ldif] and
>>> ldap.conf.
>>>
>>> With that in place, and the ldap.conf below:
>>> nightmare:/etc # cat ldap.conf
>>>
>>> base dc=dark,dc=net
>>> uri ldap://nightmare.dark.net
>>> # scope sub
>>> # binddn "cn=admin,dc=dark,dc=net"
>>> # bindpw jackie
>>> bind_policy soft
>>> # The user ID attribute (defaults to uid)
>>> pam_login_attribute uid
>>> pam_lookup_policy yes
>>> pam_password exop
>>> nss_schema rfc2307bis
>>> tls_reqcert never
>>> pam_filter objectClass=posixAccount
>>> ldap_version 3
>>> nss_map_attribute uniqueMember uniqueMember
>>> ssl start_tls
>>> tls_cacert /var/lib/ldap/cacert.pem
>>> tls_cert /var/lib/server.crt
>>> tls_key /var/lib/ldap/server.key
>>>
>>> I have run ldapsearch:
>>> nightmare:/media # ldapsearch -v -x -H ldap://nightmare.dark.net:389/ -b
>>> "dc=dark,dc=net" -Z
>>
>> Always test starttls with -ZZ, so if your starttls isn't working the
>> connection will fail.
>>
>>> ldap_initialize( ldap://nightmare.dark.net:389/??base )
>>> filter: (objectclass=*)
>>> requesting: All userApplication attributes
>>> # extended LDIF
>>> #
>>> # LDAPv3
>>> # base <dc=dark,dc=net> with scope subtree
>>> # filter: (objectclass=*)
>>> # requesting: ALL
>>> #
>>>
>>> # dark.net
>>> dn: dc=dark,dc=net
>>> dc: dark
>>> o: dark
>>> objectClass: organization
>>> objectClass: dcObject
>>>
>>> # admin, dark.net
>>> dn: cn=admin,dc=dark,dc=net
>>> objectClass: organizationalRole
>>> cn: admin
>>>
>>> # Default Policy, dark.net
>>> dn: cn=Default Policy,dc=dark,dc=net
>>> objectClass: namedObject
>>> objectClass: pwdPolicy
>>> cn: Default Policy
>>>
>>> # People, dark.net
>>> dn: ou=People,dc=dark,dc=net
>>> objectClass: organizationalUnit
>>> ou: People
>>> description: People is used in mapping the /etc/passwd entries
>>>
>>> # jtobin, People, dark.net
>>> dn: uid=jtobin,ou=People,dc=dark,dc=net
>>> uid: jtobin
>>> cn: John C. Tobin
>>> objectClass: account
>>> objectClass: posixAccount
>>> objectClass: top
>>> objectClass: shadowAccount
>>> loginShell: /bin/ksh
>>> uidNumber: 5000
>>> gidNumber: 100
>>> homeDirectory: /home/jtobin
>>> gecos: John C. Tobin
>>>
>>> # defaultDNS, dark.net
>>> dn: cn=defaultDNS,dc=dark,dc=net
>>> cn: defaultDNS
>>> objectClass: top
>>> objectClass: suseDnsConfiguration
>>> suseDefaultBase: ou=DNS,dc=dark,dc=net
>>>
>>> # DNS, dark.net
>>> dn: ou=DNS,dc=dark,dc=net
>>> objectClass: top
>>> objectClass: organizationalUnit
>>> ou: DNS
>>>
>>> # search result
>>> search: 3
>>> result: 0 Success
>>>
>>> # numResponses: 8
>>> # numEntries: 7
>>>
>>> nightmare:~ #
>>> #####
>>>
>>> So I am assuming the ldapserver on ldap://nightmare.dark.net:389/ with tls
>>> works.
>>> [I looked through the message output in /var/log/message and see the
>>> ³STARTTLS² and ³TLS established tls_ssf=256²]
>>> I have done a number of similar ldapsearches. This appears to work
>>> correctly.
>>>
>>> On the client machine I now do :
>>>
>>> nightmare:/media # su - jtobin
>>> su: user jtobin does not exist
>>> nightmare:/media #
>>>
>>> /var/log/message - output......
>>>
>>> nightmare:/var/log # tail f |grep I tls
>>>
>>> Oct 28 11:29:01 nightmare slapd[11118]: conn=1217 op=0 STARTTLS
>>> Oct 28 11:29:01 nightmare worker_nscd: nss-ldap: do_open: do_start_tls
>>> failed:stat=-1
>>> Oct 28 11:29:01 nightmare slapd[11118]: connection_read(14): TLS accept
>>> failure error=-1 id=1217, closing
>>> Oct 28 11:29:01 nightmare slapd[11118]: conn=1217 fd=14 closed (TLS
>>> negotiation failure)
>>> Oct 28 11:29:01 nightmare slapd[11118]: conn=1218 op=0 STARTTLS
>>> Oct 28 11:29:01 nightmare worker_nscd: nss-ldap: do_open: do_start_tls
>>> failed:stat=-1
>>
>> Augh. If you can stop using nscd all this will be much easier for you. I
>> personally like nslcd rather than nss-ldap, but each to their own.
>>
>> If not, restart nscd before you start every troubleshooting round.
>>
>>> Oct 28 11:29:01 nightmare slapd[11118]: connection_read(14): TLS accept
>>> failure error=-1 id=1218, closing
>>> Oct 28 11:29:01 nightmare slapd[11118]: conn=1218 fd=14 closed (TLS
>>> negotiation failure)
>>
>> First I would test that all the CA certs and server certs in use are
>> understandable by each other. Does the server cert on the machine running
>> slapd validate against the CA cert on the machine running ldapsearch? Does the
>> server cert on the machine running slapd validate against the CA cert on the
>> client machine?
>>
>> openssl verify -CAfile cacert.pem servercert.pem
>>
>> If the output says "ok" then the actual cert part is fine.
>>
>> At this point I would crank up the slapd debug level (run it in the
>> foreground) and match it again your ldap client debug logs. See if you can
>> reproduce the error above using a client like ldapsearch, using the same
>> search parameters as the nss-ldap client would use.
>>
>>> [if you want more of the log, I can obviously get it, but these appear to
>>> be the important parts.]
>>>
>>> This is probably a configuration error, or a logical / architecture
>>> misunderstanding, ok, I Œm a newbie.
>>> Do I have certificates incorrectly generated? [certificates were generated
>>> via [1]http://www.openldap.org/faq/data/cache/185.html].
>>> What did I do wrong?
>>>
>>> This is running openldap 2.4.26 off of Suse 12.1 milestone 5.
>>
>> I'm getting a puppetized starttls working with 2.4.26/openssl on debian, but
>> much the same thing.
>>
>>> Thanks in advance.
>>> tob
>>>
>>> References
>>>
>>> Visible links
>>> 1. http://www.openldap.org/faq/data/cache/185.html
>>
>
>
Did you ever get this to work?
--
/jm
14 years, 10 months
Re: TLS hostname check failure and subjectAltname extension
by Andrew Findlay
On Thu, Jan 12, 2012 at 05:31:31PM +0100, Michael Ströder wrote:
> We're using self-compiled OpenLDAP 2.4.27 under RHEL 6.1 linked
> against OpenSSL 1.0.0 libs shipped with RHEL.
> 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?
Probably not. I have just set up a test case like that and it works.
All software is current versions on Debian Squeeze:
@(#) $OpenLDAP: slapd 2.4.23 (Jun 15 2011 13:31:57) $
@incagijs:/home/thijs/debian/p-u/openldap-2.4.23/debian/build/servers/slapd
OpenSSL 0.9.8o 01 Jun 2010
I usually find that the problem is with the client-side setup,
probably not getting the right TLS_CACERT value (i.e. in your case
maybe /opt/xxxdir/bin/ldapsearch is reading
/opt/xxxdir/etc/openldap/ldap.conf rather than
/etc/openldap/ldap.conf
Andrew
--
-----------------------------------------------------------------------
| From Andrew Findlay, Skills 1st Ltd |
| Consultant in large-scale systems, networks, and directory services |
| http://www.skills-1st.co.uk/ +44 1628 782565 |
-----------------------------------------------------------------------
14 years, 9 months
Re: Security between server and client nodes.
by Jayavant Patil
On Tue, Nov 29, 2011 at 6:26 PM, Jayavant Patil
<jayavant.patil82(a)gmail.com>wrote:
>
> >>Mon, 28 Nov 2011 11:25:16 +0100 Raffael Sahli <public(a)raffaelsahli.com>
> wrote:
> >>Hi
>
> >>I think you mean SSL connection or the STARTTLS Layer...?
> >>Please read the manual http://www.openldap.org/doc/admin24/tls.html
> >Ok.
>
> >>And tree security:
> >>On my server, a client user can only see his own object:
> >Are you using simple authentication mechanism?
>
> >>Maybe create a rule like this:
> >>access to filter=(objectClass=
> >>simpleSecurityObject)
> >> by self read
> >> by * none
>
> >I am not getting what the ACL rule specifies. Any suggestions?
>
I have two users ldap_6 and ldap_7. I want to restrict a user to see
his own data only.
In slapd.conf, I specified the rule as follows:
access to *
by self write
by * none
But ldap_6 can see the ldap_7 user entries (or vice versa) with
$ldapsearch -x -v -D "cn=root,dc=abc,dc=com" -b
"ou=People,dc=abc,dc=com" "uid=ldap_7"
Any suggestions?
>
> --
>
> Thanks & Regards,
>
> Jayavant Ningoji Patil
> Engineer: System Software
> Computational Research Laboratories Ltd.
> Pune-411 004.
> Maharashtra, India.
> +91 9923536030.
>
>
--
Thanks & Regards,
Jayavant Ningoji Patil
Engineer: System Software
Computational Research Laboratories Ltd.
Pune-411 004.
Maharashtra, India.
+91 9923536030.
14 years, 11 months
Problems with syncrepl state
by Berthold Cogel
Hello,
we have a cluster of LDAP servers consisting of one provider and 4
consumer. We're upgrading the os of the systems by proving an
replacement system for each of the five systems.
Then we stop the slapd on the system that should be replaced, dump the
database with slapcat, copy it to new system, switch hostname and ip of
both systems. We shut down the old and reboot the new system. Then we
slapadd the database on the new system. So far so good...
We started with the provider. After importing the database and starting
the slapd on the new provider, we get errors for the syncrepl state on
all consumer systems: "Can't get Context CSN with SID <x> from
ldap+tls://localhost. Please set SID with -I option."
We're using check_ldap_syncrepl_status from ltb-project with icinga2 to
monitor the replication.
I don't know how to fix this. When I modify an entry in the provider, it
is synced to the consumer. But the status error stays. On all four
consumers.
I've then 'upgraded' a consumer by starting the slapd on the replacment
system without any database. The system started the sync and after
completion the error was gone.
But syncing takes more time than importing a dump from a local file. And
in a case where we have to rebuild the provider from scratch after a
crash, it might be not an option to resync one consumer after the other
to rebuild the complete cluster.
Is there a method to fix the problem?
Syncrepl configuration on the provider
overlay syncprov
syncprov-checkpoint 100 10
syncprov-sessionlog 100
Syncrepl configuration on the consumer
syncrepl rid=<x>
provider=ldap://yxz:389
binddn="cn=xxxxxxx"
credentials="xxxxxxx"
tls_cacertdir=/etc/pki/tls/certs
tls_reqcert=demand
bindmethod=simple
starttls=critical
searchbase="xxxxxx"
type=refreshAndPersist
retry="10 10 300 +"
filter="(objectClass=*)"
scope=sub
attrs="*,+"
sizelimit=unlimited
timelimit=unlimited
schemachecking=off
Regards
Berthold Cogel
6 years, 1 month
Re: syncrepl not propagating changes
by Howard Chu
Mark Coetser wrote:
> 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.
That is not supported. You can only use multiple consumers in the same
database if they are all pointing at different providers (and each of those
providers uses a unique serverID).
> 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?
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
14 years, 2 months
Re: Openldap for proxy AD
by Willy Ramos
Em 22/11/2013 09:21, Andrew Findlay escreveu:
> On Wed, Nov 20, 2013 at 02:55:43PM -0200, Willy Ramos wrote:
>
>> Subject: Re: Openldap for proxy AD
> Have you tried following the examples in the Admin Guide?
>
> http://www.openldap.org/doc/admin24/security.html#Pass-Through%20authentica…
>
> There is a detailed setup and diagnosic guide there which should help you
> to isolate the problem.
>
> Andrew
Thanks Andrew,
I was testing based in this Admin Guide.
When I Check that the user can bind to AD:
ldapsearch -x -H ldap://dc1.example.com/ \
-D cn=user,cn=Users,DC=ad,DC=example,DC=com \
-w userpassword \
-b cn=user,cn=Users,DC=ad,DC=example,DC=com \
Or with
-s base \
"(objectclass=*)"
Or
testsaslauthd -u user -p userpassword
It´s works.
I was reading about and Seems don´t find the schemas of objectclass or
userPassword attribute;
But I could not resolve yet.
See the logs
Nov 22 11:57:30 mail slapd[18370]: conn=1192 fd=11 ACCEPT from
IP=127.0.0.1:51698 (IP=0.0.0.0:636)
Nov 22 11:57:30 mail slapd[18370]: conn=1192 fd=11 TLS established
tls_ssf=256 ssf=256
Nov 22 11:57:30 mail slapd[18370]: conn=1192 op=0 EXT
oid=1.3.6.1.4.1.1466.20037
Nov 22 11:57:30 mail slapd[18370]: conn=1192 op=0 STARTTLS
Nov 22 11:57:30 mail slapd[18370]: conn=1192 op=0 RESULT oid= err=1
text=TLS already started
Nov 22 11:57:30 mail slapd[18370]: conn=1192 op=1 UNBIND
Nov 22 11:57:30 mail slapd[18370]: conn=1192 fd=11 closed
Thanks.
--
Att.
Willy R. M
CDTN/System Software
12 years, 11 months