[Freeipa-devel] FreeIPA and per-machine views

Dmitri Pal dpal at redhat.com
Fri Sep 23 01:55:45 UTC 2011


On 09/21/2011 10:07 PM, Stephen Gallagher wrote:
> I've ben working on the multiple search base feature in SSSD and I've had some thoughts that might be relevant to the FreeIPA v3 core effort. The idea behind multiple search bases is fairly simple; instead of simply checking one subtree for user or group information, you check several in series, stopping at the first match.
>
> I was looking into this to identify the primary reasons why a deployment might use such an approach and I came up with two important use-cases.
>
> 1) This is a fairly simple way to extend a network you don't fully control. A classic example might be a Computer Science department at a university. They would want to use the campus user accounts (probably provided by the university IT department), but also add new groups for sharing or access control on CS department machines. This could be done with multiple search bases by setting the first base to the CS department subtree and the second base to a replicated university subtree.

I do not think we want to deal with multiple subtrees of users in the
same IPA instance. We already decided against it in the past when we
flattened the tree. At least I am not convinced that this is actually
needed. I am actually aware of one more use case why people do different
subtrees for users. It is because they have duplication of the uid/gid.
Though it is bad it is a reality that people deal with. And they deal
with it by having subtrees in DS. But it will not help in our case as
IPA is built with the notion of the unified uid/gid namespace. The only
thing will help in both cases is different IPA domains with trust
relations so I suggest we focus on that part rather than support of
multiple subtrees for users. If IPA trusts still do not work for the
user may be staying with a free from DS server is a better choice. 

> 2) The second important use-case is for dealing with third-party applications with hard-coded groups. For a hypothetical example, let's say that a closed-source database program requires a user to be in the group 'dbadmins' in order to access a shell for editing the database. However, there may be more than one such database deployed in the network, possibly among different teams. Having multiple search bases allows different machines to have different views of this group.

That is an interesting use case. But rather than creating views I would
suggest a different approach. In IPA we create a way to specify
alternative location for specific override groups. For example we now
have "cn=groups, cn=accounts,..." where all groups live.
we can have "cn=overridegroups, cn=accounts,..." and allow creation of
the special subtrees like we do with locations for maps. UI and CLI can
be modified to allow to manage these areas. I do not think that would be
a rocket science.

On the SSSD side we can have an sssd_group_override_base parameter that
would define an override base for that machine. The logic in the SSSD
will be to read groups from override base first (it is expected that
there will be a small subset of groups that are used by specific app
like DB for example) and then the normal groups from the search base but
discard the groups that already have been fetched from the override
location (or something like this. I bet it is more complex and I will
leave it to you to define actual implementation, but I hope it
illustrates good enough what I am trying to propose). May be Jan's
delete group functionality would be really handy for this use case.

The alternative however is to create and support group aliases and use
group aliases as names.

But before we go into all of this we need to realize that contemporary
versions of software most likely would allow configurable groups. Id it
is an old software than SSSD might not be in the picture anyways so it
should be a pure server side solution so may be we should just allow
alternative subtrees for groups but then how we are going to deal with
gids or it does not matter for the apps?



> I think it's definitely worth discussing how we might address these same use-cases in FreeIPA v3. My thought was that we might want to implement custom "views" of LDAP based on the hostgroups to which a client belongs. I can see a lot of implementation difficulties with this, however. Alternate ideas are most welcome.
>
> _______________________________________________
> Freeipa-devel mailing list
> Freeipa-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-devel


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IPA project,
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/






More information about the Freeipa-devel mailing list