Hello Jan,
--On Monday, January 27, 2020 9:58 AM +0100 Jan Hugo Prins jhp@jhprins.org wrote:
The complete config on a running node looks like this:
dn: cn=config objectClass: olcGlobal objectClass: olcConfig objectClass: top cn: config olcLogLevel: 16512 olcPidFile: /var/run/openldap/slapd.pid olcServerID: 1 ldap://ldap01.internal olcServerID: 2 ldap://ldap02.internal olcServerID: 3 ldap://ldap03.internal
dn: cn=module{0},cn=config objectClass: olcModuleList objectClass: olcConfig objectClass: top cn: module{0} olcModuleLoad: {0}syncprov.la olcModulePath: /usr/lib64/openldap/
dn: olcDatabase={-1}frontend,cn=config objectClass: olcDatabaseConfig objectClass: olcConfig objectClass: olcFrontendConfig objectClass: top olcAccess: {0}to dn.subtree="dc=domain,dc=com" attrs=userPassword,shadowLastChange by self write by dn.base="cn=bbsyncrepl, dc=domain,dc=com" read by anonymous auth by * none olcAccess: {1}to dn.subtree="dc=domain,dc=com" attrs=sambaNTPassword by self write by dn.base="cn=bbsyncrepl, dc=domain,dc=com" read by anonymous auth by * none olcAccess: {2}to dn.subtree="dc=domain,dc=com" attrs=sambaLMPassword by self write by dn.base="cn=bbsyncrepl, dc=domain,dc=com" read by anonymous auth by * none olcAccess: {3}to dn.subtree="dc=domain,dc=com" by dn.base="cn=bbsyncrepl,dc=domain,dc=com" read by self write by * read olcAddContentAcl: FALSE olcDatabase: {-1}frontend olcLastMod: TRUE olcMaxDerefDepth: 0 olcMonitoring: TRUE olcReadOnly: FALSE olcSchemaDN: cn=Subschema olcSyncUseSubentry: FALSE
Your domain ACLs should be contained within the domain database section, not in the global configuration section.
dn: olcDatabase={0}config,cn=config objectClass: olcDatabaseConfig objectClass: olcConfig objectClass: top olcDatabase: {0}config olcMirrorMode: TRUE olcMonitoring: TRUE olcRootDN: cn=config olcRootPW: XXXXXX olcSyncrepl: {0}rid=001 provider=ldap://ldap01.internal binddn="cn=config" bindmethod=simple credentials=XXXXXX searchbase="cn=config" type=refreshAndPersist retry="5 5 300 +" timeout=1 olcSyncrepl: {1}rid=002 provider=ldap://ldap02.internal binddn="cn=config" bindmethod=simple credentials=XXXXXX searchbase="cn=config" type=refreshAndPersist retry="5 5 300 +" timeout=1 olcSyncrepl: {2}rid=003 provider=ldap://ldap03.internal binddn="cn=config" bindmethod=simple credentials=XXXXXX searchbase="cn=config" type=refreshAndPersist retry="5 5 300 +" timeout=1
dn: olcOverlay={0}syncprov,olcDatabase={0}config,cn=config objectClass: olcSyncProvConfig objectClass: olcOverlayConfig objectClass: olcConfig objectClass: top olcOverlay: {0}syncprov
dn: olcOverlay={1}syncprov,olcDatabase={0}config,cn=config objectClass: olcSyncProvConfig objectClass: olcOverlayConfig objectClass: olcConfig objectClass: top olcOverlay: {1}syncprov
This second syncprov overlay needs to be removed. It should only occur once.
dn: olcDatabase={1}bdb,cn=config
back-bdb is deprecated and should not be used. back-mdb should be used instead.
dn: olcOverlay={0}syncprov,olcDatabase={1}bdb,cn=config objectClass: olcSyncProvConfig objectClass: olcOverlayConfig objectClass: olcConfig objectClass: top olcOverlay: {0}syncprov
Something else I see, when I use jxplorer to look at the content of a server using the cn=config credentials I would expect to see all values including the empty values. On a server without olcAccess lines I see this, but when there are olcAccess lines I only see the configured values. All unset values are not visible.
I have no idea what this statement means. All values of what? What's an empty/unset value mean?
Finally, with OpenLDAP 2.4, YMMV with cn=config replication as there are missing rules necessary for it to work correctly. This has been fixed for OpenLDAP 2.5. Unless you really need to replicate cn=config, I advise against it.
Regards, Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com