[Freeipa-users] Limiting group/user visibility

[Rob Crittenden]

Lassi Pölönen wrote:
> On 7.12.2011 21:28, Dmitri Pal wrote:
>>> I think I found at least one solution, that probably isn't the most
>>> elegant one. On the other hand I don't think with the current
>>> limitations of FreeIPA it is even possible to do much better. Any
>>> comments/suggestions are of course welcome.
>>>
>>> My first approach was to remove the default aci:
>>> (targetattr != "userPassword || krbPrincipalKey || sambaLMPassword ||
>>> sambaNTPassword || passwordHistory || krbMKey || userPKCS12")(version
>>> 3.0; acl "Enable Anonymous access"; allow (read, search, compare) userdn
>>> = "ldap:///anyone";)
>>>
>>> and add needed permissions to specified user groups. But it appeared
>>> that there are other things that rely on this aci and as a result e.g
>>> "ipa user-find foo" stopped working as well (executed from the FreeIPA
>>> server with admin session). I figured it might be a bit too painful to
>>> try to find out all the needed aci rules if the default one is removed.
>>>
>>> So I came in to conclusion I just create a role for each customer, e.g
>>> "Customer1" and assign that role to all customer's user groups and hosts
>>> (too bad it isn't possible to assign a role to a hostgroup) . This
>>> requires an aci to be created for each customer though:
>>>
>>> aci: (target =
>>> "ldap:///uid=*,cn=users,cn=accounts,dc=test")(targetfilter="(!(memberOf=cn=Customer1,cn=roles,cn=accounts,dc=test))")(targetattr
>>>
>>> = "*")(version 3.0;acl "permission:View only Customer1";deny(all)
>>> groupdn = "ldap:///cn=Customer1,cn=roles,cn=accounts,dc=test";)
>>>
>>> Well, actually not just one aci, but probably one for groups and so on,
>>> but with the same idea. The actual amount of required ACIs is still
>>> unclear since I just started testing this out, but even though there
>>> were 10 ACIs per customer I find it easier to manage than the amount of
>>> FreeIPA installations it would take to run an own domain for each.
>>>
>>> With this setup, customer's users and hosts shouldn't see data outside
>>> of their role. 389-ds's aci macros seem to have a limitation that if
>>> ($dn) is used in targetfilter, there has to be ($dn) in target as well.
>>> But since the user tree is flat, it doesn't seem to be possible to take
>>> the advantage of macro ACIs even though there's a obvious pattern in the
>>> way I'd like things to work. It is easily scripted though.
>>>
>>> I think the elegant solution would require FreeIPA to support multiple
>>> domains or configurable directory structure. I've seen some discussion
>>> about the latter and I do understand why many people are not fans of it.
>>>
>>>
>> Seems like the right direction to me.
>> Would you mind creating a wiki page that would outline the solution when
>> it is ready.
>> It seems that other people would benefit from your experience.
>>
>> Also it would be great to understand how we can make the process of
>> configuring ACIs simpler for someone.
>> There is definitely a room for improvement so if you can file a trac
>> ticket or BZ (or several) with your enhancement recommendations would be
>> great.
>
> Sure thing, once I figure out all the bits and pieces. My use case
> doesn't cover e.g mounts but will try to look into all the aspects.
> Currently the possible caveats are still unknown as well.

Unless you need per-object acis you can probably simplify the filter to 
cover the entire DIT by dropping the target and using just the targetfilter.

I'd recommend verifying that data doesn't leak via schema compat if you 
have that enabled.

rob