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

_______________________________________________
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Reply via email to