[Freeipa-users] Limiting group/user visibility

[Lassi Pölönen]

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.
>

Replying to myself.. Actually I would think my goal would be pretty
typical setup for managed hosting companies like us as we are the ones
who manage all the accounts and servers for our customer organizations.
We grant customer access to servers we host and we should have our own
accounts on every server as well. Running multiple domains in this case
means we would need to replicate our admin accounts to every domain (not
sure if there's even a feasible solution to do that) and also manage
customer accounts on multiple FreeIPA installations. Running a single
domain would make it easier to provide a single account for customers
for services that are common to every customer, e.g ticketing system,
wikis and so on. It's just that they shouldn't be able to know about
each other. Anyway, looking at macro ACIs, it at least looks like it's
possible to accomplish with a few pretty simple rules.