Thanks, Quanah Not sure what you meant by " Well, it may not have been this issue, but it definite would become an issue then." Was what I did a good thing or not? Curious minds want to know. <lol> MM Server1: # ldapsearch -H ldap://mm-server1.example.ldap -d 256 -x -D cn=admin,cn=config -W -ZZ -b olcDatabase=\{1\}bdb,cn=config olcSyncrepl Enter LDAP Password: # extended LDIF # # LDAPv3 # base <olcDatabase={1}bdb,cn=config> with scope subtree # filter: (objectclass=*) # requesting: olcSyncrepl # # {1}bdb, config dn: olcDatabase={1}bdb,cn=config olcSyncrepl: {0}rid=002 provider=ldap://mm-server2.example.ldap bindmethod=simple binddn="cn=ldapadmin,dc=example,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=yes tls_cacert=/usr/local/openldap/etc/openldap/CA/cacert.pem olcSyncrepl: {1}rid=001 provider=ldap://mm-server1.example.ldap bindmethod=simple binddn="cn=ldapadmin,dc=example,dc=ldap" credentials=<password> interva l=01:00:00:00 searchbase="dc=example,dc=ldap" logbase="cn=accesslog" schemachecking=on type=refreshAndPersist retry="60 +" filter="(objectClass=*)" attrs= "*,+" syncdata=accesslog starttls=yes tls_cacert=/usr/local/openldap/etc/openldap/CA/cacert.pem # {0}syncprov, {1}bdb, config dn: olcOverlay={0}syncprov,olcDatabase={1}bdb,cn=config # {1}accesslog, {1}bdb, config dn: olcOverlay={1}accesslog,olcDatabase={1}bdb,cn=config # search result search: 3 result: 0 Success # numResponses: 4 # numEntries: 3 MM Server2: # ldapsearch -H ldap://mm-server2.example.ldap -d 256 -x -D cn=admin,cn=config -W -ZZ -b olcDatabase=\{1\}bdb,cn=config olcSyncrepl Enter LDAP Password: # extended LDIF # # LDAPv3 # base <olcDatabase={1}bdb,cn=config> with scope subtree # filter: (objectclass=*) # requesting: olcSyncrepl # # {1}bdb, config dn: olcDatabase={1}bdb,cn=config olcSyncrepl: {0}rid=001 provider=ldap://mm-server1.example.ldap bindmethod=simple binddn="cn=ldapadmin,dc=example,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=yes tls_cacert=/usr/local/openldap/etc/openldap/CA/cacert.pem olcSyncrepl: {1}rid=002 provider=ldap://mm-server2.example.ldap bindmethod=simple binddn="cn=ldapadmin,dc=example,dc=ldap" credentials=<password> interva l=01:00:00:00 searchbase="dc=example,dc=ldap" logbase="cn=accesslog" schemachecking=on type=refreshAndPersist retry="60 +" filter="(objectClass=*)" attrs= "*,+" syncdata=accesslog starttls=yes tls_cacert=/usr/local/openldap/etc/openldap/CA/cacert.pem # {0}accesslog, {1}bdb, config dn: olcOverlay={0}accesslog,olcDatabase={1}bdb,cn=config # {1}syncprov, {1}bdb, config dn: olcOverlay={1}syncprov,olcDatabase={1}bdb,cn=config # search result search: 3 result: 0 Success # numResponses: 4 # numEntries: 3 I modified, the "starttls" statement (just to test) to no. and now receiving the following Jan 31 12:39:15 gp42-admin4 slapd[26000]: do_syncrepl: rid=001 rc 13 retrying Jan 31 12:39:40 gp42-admin4 slapd[26000]: conn=8615 fd=101 ACCEPT from IP=<mm-server1-ip>:48899 (IP=0.0.0.0:389) Jan 31 12:39:40 gp42-admin4 slapd[26000]: conn=8615 op=0 BIND dn="cn=ldapadmin,dc=example,dc=ldap" method=128 Jan 31 12:39:40 gp42-admin4 slapd[26000]: conn=8615 op=0 RESULT tag=97 err=13 text=TLS confidentiality required Jan 31 12:39:40 gp42-admin4 slapd[26000]: conn=8615 op=1 UNBIND Jan 31 12:39:40 gp42-admin4 slapd[26000]: conn=8615 fd=101 closed Jan 31 12:40:15 gp42-admin4 slapd[26000]: conn=8616 fd=106 ACCEPT from IP=<mm-server2-ip>:43431 (IP=0.0.0.0:389) Jan 31 12:40:15 gp42-admin4 slapd[26000]: conn=8616 op=0 BIND dn="cn=ldapadmin,dc=example,dc=ldap" method=128 Jan 31 12:40:15 gp42-admin4 slapd[26000]: conn=8616 op=0 RESULT tag=97 err=13 text=TLS confidentiality required Jan 31 12:40:15 gp42-admin4 slapd[26000]: slap_client_connect: URI=ldap://mm-server2.example.ldap DN="cn=ldapadmin,dc=example,dc=ldap" ldap_sasl_bind_s failed (13) Very similar on MM-Server1. I am at a loss. The TLS configuration, files, are exactly as they are in the standard client configuration...as far as I can tell. Three other SysAdmins, for sanity sake, have checked that the paths are identical between the various files. I turned on a flood of debugging (-1) and on "mm-server1 and 2", seeing: tls_write: want=810 error=Broken pipe ldap_write: want=732 error=Broken pipe 52ebe8e0 ber_flush2 failed errno=32 reason="Broken pipe" and TLS trace: SSL3 alert write:warning:close notify ldap_free_connection: actually freed tls_read: want=5 error=Bad file descriptor Thanks in advance -----Original Message----- From: Quanah Gibson-Mount [mailto:quanah@zimbra.com] Sent: Friday, January 31, 2014 12:07 PM To: Borresen, John - 0442 - MITLL; openldap-technical(a)openldap.org Subject: RE: Syncrepl and mmr --On Friday, January 31, 2014 8:54 AM -0500 "Borresen, John - 0442 - MITLL" <John.Borresen(a)ll.mit.edu&gt; wrote: Well, it may not have been this issue, but it definite would become an issue then. ;) Your masters are unable to talk to each other. You need to determine why. This will take debugging on your part, as I've never seen anything like this before. This says that your consumer is connecting without sending a startTLS, while you've configured the master to require startTLS. Clearly you need to either enable startTLS in the syncrepl statement, or not require starttls on your master. --Quanah -- Quanah Gibson-Mount Architect - Server Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration