> 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. -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ _______________________________________________ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
