[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: learning olcAccess

Hej

It is all documented in `man 5 slapd.access`.

The syntax:

  to <what> [ by <who> [ <access> ] [ <control> ] ]+

Each <who> clause is implicitly terminated by:

  by * none stop

Each <what> clause is implicitly terminated by:

  to *
  by * none

The controls mean:

- `stop`:     the default, access checking stops in case of match
- `continue`: allows for other <who> clauses in the same <access> clause
              to be considered, incrementally altering the privileges
- `break`:    allows for other <access> clauses that match the same
              target to be processed

The control `break`, breaks out of the current `<what>` line, and
continues with other <what> lines. Otherwise the the processing would
stop with the implicit `by * none stop`.

With this you can do something like this (simplified):

  to *
    by <admin> write stop
    by * break

  ...
  <many other acls>
  ...

  to *
    by * none stop

The first `to *` matches all entries/attrs, if by is the <admin>, grant
him full access and stop processing, all other <who> will continue with
the next `to`.

Regards
Sven

On 03/19/2018 04:17 PM, Lists Nethead wrote:


Quoting Sven Mäder <maeder@phys.ethz.ch>:

Thank you very much for this!
In our case we need access to dn.subtree I believe because admins are supposed to have full control, ie. add and delete accounts. What stopped me was the lack of documentation for the "control" keyword but after a bit of sleep and reading your answer I found a some deep down in the Faq-O-Matic bit it does not seem to cover all of it. 

So, as I gather, "by * none" is the default processing stops,

"by * continue" makes it possible to add rules to the same object and

"by * break" resets the processong?
And finally, there seems to be additional switches available for the control processing but I cannot find them documented *anywhere*. 

Thanks again,

//per


Hi

You could insert something like this:

to dn.exact="ou=somedomain,dc=example,dc=com"
  attrs=children
  by group="cn=admingroup,ou=ldap,dc=example,dc=com" write stop
  by * break
to dn.children="ou=somedomain,dc=example,dc=com"
  attrs=@inetOrgPerson,@organizationalUnit,@posixAccount,
 @shadowAccount,entry
  by group="cn=admingroup,ou=ldap,dc=example,dc=com" write stop
  by * break

This will grant administrative rights by the specified group to:

- the "children" attr of the entry: ou=somedomain,dc=example,dc=com
- all attrs of children of: ou=somedomain,dc=example,dc=com in the
  specified objectClasses plus the entries itself
- all other users/groups will continue with ACL evaluation (by * break)

This will prevent modifying the entry: ou=somedomain,dc=example,dc=com
If you do not need that, replace the two ACLs with:

to dn.subtree=ou=somedomain,dc=example,dc=com"
...

But you have to add these ACLs before the rule with:
to attrs=userPassword ...
otherwise if you add it at the end, the "by * none" will prevent all
access.

ou=ldap is just an ou that contains my slapd admin groups, for example:

dn: ou=ldap,dc=example,dc=com
objectClass: organizationalUnit
ou: ldap

dn: cn=admingroup,ou=ldap,dc=example,dc=com
objectClass: groupOfNames
member: uid=someuser,ou=somedomain,dc=example,dc=com
cn: admingroup

Hope that helps a bit with the bleeding :)
And carefully test your ACLs, I had to do a lot of try and error to
get it right.

Kind regards
Sven

On 03/18/2018 04:54 PM, Lists Nethead wrote:


Hi all,
First post here, and it is asking for advice on an access rule. Setup is, 

+-dc=example,dc=com
+--ou=somedomain
+---uid=someuser,ou=somedomain,dc=example,dc=com
+--ou=someotherdomain
+---uid=otheruser,ou=someotherdomain,dc=example,dc=com
+--ou=yetanotherdomain

The ruleset so far that seems to work is

to dn.base="" by * read
to dn.base="cn=subschema" by * read
to attrs=userPassword by dn.base="cn=admin,dc=example,dc=com"
&nbsp; write by dn.base="uid=otheradmin,ou=System,dc=example,dc=com" write by self 
&nbsp; write by anonymous auth&nbsp; by * none
to *&nbsp; by dn.base="uid=someadmin,ou=System,dc=example,dc=com" w
&nbsp;rite by self read&nbsp; by peername.ip=<address>%255.255.255.0 read by peern &nbsp;ame.ip=<address>%255.255.255.0 read by peername.ip=<address>%255.255.2 
&nbsp;55.0 read by users tls_ssf=256 read&nbsp; by * none
What I want next is that "uid=someuser,ou=somedomain,dc=example,dc=com" should be able to administer accounts in "ou=somedomain" and likewise for other "ou=".
My guess is that a group with admin accounts is the way to go but right now my eyes are bleeding after reading the whole day about access rules... 

Thanks,

//per








--
Sven Mäder <maeder@phys.ethz.ch>
Support: +41 44 633 2668   Voice: +41 44 633 7661
IT Services Group, HPT H 6
Physics Department, ETH Zurich
CH-8093 Zurich, Switzerland