Hello Jan,
--On Monday, January 27, 2020 9:58 AM +0100 Jan Hugo Prins
<[email protected]> 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>