I have encountered an effect that I believe is a bug, but I might be wrong. It would be nice if someone could confirm that my acls should be working, or in case they should not, give me a hint what I am doing wrong.
Here is what I am trying to archive:
* there is one ldap provider (master) server that contains all attributes that
are relevant for my organisation
* on the master there is a user allowing a highly secured consumer(slave) ldap
server the replication of all attributes from the
master
* on the master there is a user allowing a low-security consumer(slave) ldap
server the replication of all attributes from the
master except some critical ones
* on the master there is a user (cn=provisioninguser) that can read the
accesslog. it is used by scripts to e.g. notify non-ldap
systems of password changes.
I would like to put the acls for the replication users (high and low security
ldap slaves) on the databases and not the frontend to
avoid accidental modifications. All other acls should be on the frontend.
If I configure all my acls on the frontend only everything works as I think it
should. If some acls are on the database the results
are rather weird (
the cn=provisioninguser can see only one value of the multi-valued reqMod
attribte)
The following acl snippet only deals with accesslog access which is where I
encounter the problem:
dn: olcDatabase={2}hdb,cn=config
olcAccess: {0}to dn.subtree="cn=accesslog"
attrs=reqMod val.regex="^topSecretAttribute:.*"
by dn.base="cn=replicationuser,dc=organisation,dc=com" read
by dn.base="cn=replication_low_security,dc=organisation,dc=com" none
by * break
dn: olcDatabase={2}hdb,cn=config
olcAccess: {1}to dn.subtree="cn=accesslog"
by dn.base="cn=replicationuser,dc=organisation,dc=com" read
by dn.base="cn=replication_low_security,dc=organisation,dc=com" read
by * break
dn: olcDatabase={-1}frontend,cn=config
olcAccess: {0}to dn.subtree="cn=accesslog"
by dn.base="cn=provisioninguser,dc=organisation,dc=com" read
by * none
*if the acls 1,2 and 3 are on "olcDatabase={-1}frontend,cn=config" (which they
are not in the example above)
cn=provisioninguser,dc=organisation,dc=com can read all values from the
multi-valued attribute reqMod (which is what I want).
>ldapsearch -D cn=provisioninguser,dc=organisation,dc=com -w 123 -b
>cn=accesslog reqDN=cn=user1,dc=organisation,dc=com reqMod
dn: reqStart=20131227145130.000001Z,cn=accesslog
reqMod: userPassword:= {SSHA}bmyaw8Xy1UftlTorPDQE9yLzruoxDnGq
reqMod: topSecretAttribute:= topsecret
reqMod: pwdChangedTime:= 20131227145130Z
reqMod: entryCSN:= 20131227145130.917649Z#000000#000#000000
reqMod: modifiersName:= cn=admin
reqMod: modifyTimestamp:= 20131227145130Z
*if the acls 1 and 2 are on "olcDatabase={2}hdb,cn=config" and the 3rd one is
on "olcDatabase={-1}frontend,cn=config"
cn=provisioninguser,dc=organisation,dc=com can read only one value from the
multi-valued attribute reqMod (why?).
>ldapsearch -D cn=provisioninguser,dc=organisation,dc=com -w 123 -b
>cn=accesslog reqDN=cn=user1,dc=organisation,dc=com reqMod
dn: reqStart=20131227145130.000001Z,cn=accesslog
reqMod: userPassword:= {SSHA}bmyaw8Xy1UftlTorPDQE9yLzruoxDnGq
Best regards,
Marvin Mundry
University of Hamburg
Regional Computer Center (RRZ)
Division Zentrale Dienste
Schlueterstrasse 70
20146 Hamburg
+49 (0)40 42838-9109
smime.p7s
Description: S/MIME cryptographic signature
