On Thu, 22 Mar 2012 14:22:45 +0100, Natalia nata.cs2@gmail.com wrote:
I have the following tree structure in LDAP: ou=people,dc=example,dc=com uid=user1,ou=people,dc=example,dc=com
cn=child1,uid=user1,ou=people,dc=example,dc=com cn=child2,uid=user1,ou=people,dc=example,dc=comuid=user2,ou=people,dc=example,dc=com ..
I would like to make access in such a way: if fathers account (uid=user1,ou=people,dc=example,dc=com) is inactivated (description=inaktiv), all children become inaccessible.
Something like this, I think. Untested, sorry.
to dn.regex=",(uid=[^,]+,ou=people,dc=example,dc=com)$" by set.expand="[$1]/description & inaktiv" none by group.exact="cn=ldapadmin,dc=example,dc=com" tls_ssf=128 sasl_ssf=56 write by * +0 break
I.e. access to: any children of an uid=... entry. 1. Look up 'description' in entry $1 ("uid=...), and refuse access if it matches 'inaktiv'. 2. For other entries, ldap admin over TLS+SASL gets full access. 3. For everyone else, skip this access statement and go on to check the following access 'to' statements.
Drop the regexps' initial "," to also control the uid=... entry. Swap (1) and (2) to also give admin access to inactive subtrees. Replace (3) with e.g. 'by * read' to instead give others read access.
I have tried with this, but it has not functioned: to dn.regex="uid=([^,]+),ou=people,dc=example,dc=com" filter="(description=inaktiv)" attrs=children by group.exact="cn=ldapadmin,dc=example,dc=com" tls_ssf=128 sasl_ssf=56 write by * none
That's not what "()" in regexps, filter, and children mean. See man slapd.access. The access syntax tries to make sensible access statements readable, but that doesn't mean any readable access statement is sensible:-)
This is what your access statement means:
When accessing e.g. the entry "cn=child1,...", your dn.regex is checked against the DN, and matches. But the filter is checked against the cn=child1 entry, not against a parent entry. That does not match. Nor does attrs=children usually match - that's a pseudo-attribute which Add/Delete/Rename check in the parent entry of the entry being added.
So this access statement is skipped, since the 'to' statement normally does not match. If it had matched, you'd then give write access to ldapadmin if they use TLS and SASL. Nobody else would get access.