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:

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.

Freeipa-users mailing list

Reply via email to