It was modified from the generation of slapd-chain2.conf which also didn't work (I was working off the assumption that the overlay needed to be on olcDatabase={1}frontend) This is the slapd-chain2.conf file I am using (modified slightly) The only differences between this and the unmodified slapd-chain2.conf is the directory and the addition of chain-tls and chain-idassert-authzFrom to the "overlay chain" section. I'm generating my config with it with $ slaptest -f slapd-chain2.conf -F ./slapd.d-test/ """ include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/openldap.schema include /etc/openldap/schema/nis.schema database hdb directory /srv/ldap/example.com/ suffix "dc=example,dc=com" rootdn "cn=admin,dc=example,dc=com" rootpw secret overlay chain chain-uri ldap://master.example.com chain-idassert-bind bindmethod=simple binddn="dc=example,dc=com" credentials=secret mode=self chain-tls start chain-idassert-authzFrom "*" """ The resulting cn=config doesn't generate objects on the olcDatabase={1}frontend database but rather the two following objects are generated within olcOverlay={0}chain,olcDatabase={1}hdb,cn=config olcDatabase={0}ldap,olcOverlay={0}chain,olcDatabase={1}hdb,cn=config """ # AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify. # CRC32 f3da9a85 dn: olcDatabase={0}ldap objectClass: olcLDAPConfig objectClass: olcChainDatabase olcDatabase: {0}ldap olcDbStartTLS: none starttls=no olcDbRebindAsUser: FALSE olcDbChaseReferrals: TRUE olcDbTFSupport: no olcDbProxyWhoAmI: FALSE olcDbProtocolVersion: 3 olcDbSingleConn: FALSE olcDbCancel: abandon olcDbUseTemporaryConn: FALSE olcDbConnectionPoolMax: 16 olcDbSessionTrackingRequest: FALSE olcDbNoRefs: FALSE olcDbNoUndefFilter: FALSE olcDbOnErr: continue olcDbKeepalive: 0:0:0 structuralObjectClass: olcLDAPConfig entryUUID: df7b759c-bb09-1032-82c9-adb6d4ef9266 creatorsName: cn=config createTimestamp: 20130926151258Z entryCSN: 20130926151258.900907Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20130926151258Z """ olcDatabase={1}ldap,olcOverlay={0}chain,olcDatabase={1}hdb,cn=config """ # AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify. # CRC32 b7a21479 dn: olcDatabase={1}ldap objectClass: olcLDAPConfig objectClass: olcChainDatabase olcDatabase: {1}ldap olcDbURI: "ldap://master.example.com" olcDbStartTLS: start starttls=no olcDbIDAssertBind: mode=self flags=prescriptive,proxy-authz-non-critical bindm ethod=simple timeout=0 network-timeout=0 binddn="dc=example,dc=com" credentials ="secret" keepalive =0:0:0 olcDbIDAssertAuthzFrom: * olcDbRebindAsUser: FALSE olcDbChaseReferrals: TRUE olcDbTFSupport: no olcDbProxyWhoAmI: FALSE olcDbProtocolVersion: 3 olcDbSingleConn: FALSE olcDbCancel: abandon olcDbUseTemporaryConn: FALSE olcDbConnectionPoolMax: 16 olcDbSessionTrackingRequest: FALSE olcDbNoRefs: FALSE olcDbNoUndefFilter: FALSE olcDbOnErr: continue olcDbKeepalive: 0:0:0 structuralObjectClass: olcLDAPConfig entryUUID: df7b7c90-bb09-1032-82ca-adb6d4ef9266 creatorsName: cn=config createTimestamp: 20130926151258Z entryCSN: 20130926151258.900907Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20130926151258Z """ The changes to relocate these objects to the olcDatabase{-1}fontend was in response to the things I had read online. -Russell J. Jancewicz University of Connecticut On 2013-09-26 13:02, "Quanah Gibson-Mount" <quanah(a)zimbra.com&gt; wrote:

On 2013-09-26 15:04, "Dieter Klünter" <dieter(a)dkluenter.de&gt; wrote: If that's the case what should I do to propagate writes/modifies from a *specific* database on my slave to a master? (ideally in cn=config style ldifs, not ldap.conf) Regardless if I apply it to the {-1}frontend or the {1}hdb both situations have resulted in the unwilling to perform error. -Russell J. Jancewicz University of Connecticut

On 2013-09-26 16:42, "Dieter Klünter" <dieter(a)dkluenter.de&gt; wrote: The system I am working on is already a syncrepl consumer from the master (hence the terminology master, slave). The master system is sends all data to the slave. I want any attempted writes to said save to be forwarded back to the master. I understand that individual LDAP clients can complete this via referral chasing however I would like (and maybe wrongly assumed) that chaining would provide me this functionality. If this is not how chaining behaves would someone please explain the intended use? the following configurations should accomplish what I am looking for however every variation on them results in Server unwilling to preform on modify dn: olcOverlay={0}chain,olcDatabase={1}hdb,cn=config objectClass: olcOverlayConfig objectClass: olcChainConfig olcOverlay: {0}chain olcChainCacheURI: FALSE olcChainMaxReferralDepth: 1 olcChainReturnError: FALSE dn: olcDatabase={0}ldap,olcOverlay={0}chain,olcDatabase={1}hdb,cn=config objectClass: olcLDAPConfig objectClass: olcChainDatabase olcDatabase: {0}ldap olcDbURI: "ldap://master.example.com" olcDbIDAssertBind: mode=self bindmethod=simple binddn="cn=admin,dc=example,dc=com" credentials="secret" I am trying to add said chaining to an already running server which was bootstrapped via cn=config. *** Is there any way to accomplish what I am looking to do? *** Should I modify the LDIF above in any way to make things work? -Russell J. Jancewicz University of Connecticut