[Freeipa-devel] FreeIPA and per-machine views

Sumit Bose sbose at redhat.com
Fri Sep 23 12:07:04 UTC 2011


On Fri, Sep 23, 2011 at 07:48:06AM -0400, Stephen Gallagher wrote:
> On Thu, 2011-09-22 at 21:55 -0400, Dmitri Pal wrote:
> > 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.
> > 
> 
> 
> I was thinking on similar lines, but rather than have an extra option on
> the client, it would be better if we could configure the IPA server so
> that SSSD client could request the set of bases that it needs to use.
> 
> For example, right now we're able to auto-detect our standard search
> base by asking the RootDSE for the namingContexts attribute. What we
> could do on the IPA server side is, in the cn=config tree or somewhere
> more appropriate, add a record that provides ordered naming contexts for
> each client (or hostgroup).
> 
> Something like:
> cn=override1,cn=searchbases,cn=config
> memberOf: cn=hostgroup1,cn=hostgroups,...
> memberOf: cn=hostA,cn=hosts,...
> searchBaseList: search_base?scope?filter
> priority: 100
> 
> Then at online connection, SSSD could issue a search request in the
> cn=searchbases tree for any override specification for which this host
> or its hostgroups are a member. They would order by priority and then
> include the standard search base as the last in the list.
> 
> There are two advantages to this approach:
> 1) It can take advantage of the same multiple search base work I'm doing
> for standard LDAP

I agree with Stephen that a solution should work with standard LDAP and
IPA as well.

Maybe we can start thinking how to store the sssd client configuration
in IPA as Simo suggested some time ago and handle this (and maybe other)
overide(s) in this context?

bye,
Sumit

> 2) It's centrally-managed and can be updated on any going_online event
> on the client. 
> 
> > 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?
> > 
> 
> There is at least one highly-visible modern application that has been
> cited to me as part of the impetus for doing the multiple search base
> work on the SSSD. I do not want to identify it here because I haven't
> had a chance to independently verify it yet, but trust me it's one we
> cannot ignore if so :)
> 
> > 
> > 
> > > 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
> > 
> > 
> 
> 



> _______________________________________________
> Freeipa-devel mailing list
> Freeipa-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-devel




More information about the Freeipa-devel mailing list