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@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/ _______________________________________________ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel