On 2011-12-01 19:01, Lassi Pölönen wrote:
> On 1.12.2011 15:12, Stephen Gallagher wrote:
>> On Thu, 2011-12-01 at 13:46 +0100, Jakub Hrozek wrote:
>>> On Wed, Nov 30, 2011 at 01:18:46PM +0200, Lassi Pölönen wrote:
>>>> Hi,
>>>>
>>>> I'm looking for implementing FreeIPA in an environment where there are
>>>> multiple customers in multiple organizations and a single organization
>>>> that manages the users, sets the access rights etc.
>>>>
>>>> We don't have a centralized system currently so I will be starting
>>>> from
>>>> the scratch in that sense. The first concern I've had so far is
>>>> that we
>>>> don't want different customers to be able to find information about
>>>> each
>>>> other. Currently in my test setup any user can find out every user
>>>> in a
>>>> group if they know the group name and all the groups for each user if
>>>> they know the username. In some cases this might reveal information
>>>> the
>>>> customer is not willing to share.
>>>>
>>>> So are there ways to limit that e.g certain hosts/hostgroups or
>>>> users/usergroups see some defined subset of the directory? Or are
>>>> there
>>>> some other suggested approaches? As the current setup relies on local
>>>> authentication, users naturally are able to find users/groups only on
>>>> servers they are able to log in and that is the level of
>>>> confidentiality
>>>> we are looking for if possible
>>>>
>>>>
>>>> -Lassi Pölönen
>>>>
>>>>
>>> If you insist on a single instance for multiple organizations, then I
>>> agree with Stephen Ingram that the correct way would be to setup ACIs.
>>>
>>> You could also abuse the ldap_user_search_filter and
>>> ldap_group_search_filter
>>> parameters to limit NSS lookups performed by SSSD. However, nothing
>>> would prevent clients from looking at the directory structure with
>>> ldapsearch or using the IPA UI.
>> Please note that the *search_filter options aren't fully functional yet.
>> We're improving them substantially for the 1.7.0 release of SSSD.
>>
>> But Jakub is right: if you manipulate the ACIs of your user entries,
>> then you can restrict which client machines can see those entries.
>
> Ok, thanks for the replies. ACIs sound like pretty much the only
> feasible solution and still less things to maintain than completely
> dedicated setups. Will look in to 389's documentation for more.
>
>

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.




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

Reply via email to