On 01/02/2013 11:41 AM, Matti Alho wrote:
>> What is the correct way to use allow/deny because if I use
default
>> deny on ou=Projects..., it overrides allows.
> deny always has precedence, it cannot be overridden by an allow rule. So
> you should model your acis with allow rules (defining exceptions from
> the default deny).
So basically default allow and deny only entries that are confidential?
>> 2. custom attribute
>> Add a custom attribute somewhere and use that for ACI?
>>
>> I could use some concrete examples. I couldn't find any relevant
>> guides or I'm just blind. :) Thanks for help.
> you could look at the examples here:
>
http://port389.org/wiki/Howto:AccessControl
>
> Either use an attribute in the entries you want to allow to be modified
> and use a targetfilter to restrict the allow aci only to those entries.
> Or use a userattr rule, like in the manager example.
How would that translate in practise?
What kind of ACI I would need to achieve the following:
"uid=serveruser1,ou=ServerUsers,dc=domain,dc=com"
==> has access to
"cn=Project1,ou=Projects,dc=domain,dc=com"
AND
"cn=Project2,ou=Projects,dc=domain,dc=com"
==> deny access to other entries in "ou=Projects,dc=domain,dc=com"
you
could use targetfilter like:
(targetfilter = "(|(cn=Project1)(cn=Project2))"
to restrict application of the aci to these entries and list several useers in the bind
rules, or
you could add na attribute like manager to hese entries, eg:
cn=Project2,ou=Projects,dc=domain,dc=com
...
manager: uid=serveruser1,ou=ServerUsers,dc=domain,dc=com
and create an aci like:
aci: (target="ldap:///dc=domain,dc=com")(targetattr=*)(version 3.0;acl
"manag
er-write"; allow (all) userattr = "manager#USERDN";)
If the attribute you're using is multivalued, it should work defining several users.
Ludwig
If I add an attribute, can I define certain bind users as values?
Thanks for helping out!
-Matti
--
389 users mailing list
389-users(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users