[Freeipa-devel] FreeIPA and per-machine views

[Simo Sorce]

On Fri, 2011-09-23 at 07:48 -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.

I am mostly fine with the general ideas here, except I do not agree at
all that these should be complete group definitions.

They should also probably be rooted under a completely different tree
than cn=accounts

Finally I think they cannot use member/memberof as that would pollute
the regular users.

Overrides should be something that overrides a specific group and may
override only a subset of options for that group.
So they will need a new objectclass (not posixGroup) and a new attribute
to "reference" the original group.

If someone needs to access this information through legacy software that
can only read posixGroup info we should probably expose it through the
compat tree in a special subtree there.

> 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

I definitely agree on this, we do not want to add any more amnual
configuration in sssd for stuff that is clearly easy to discover through
ldap calls, and much more easy to manage.

I do not see any reason for this "priority" attribute though.

> 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

No, it should definitely not. Overrides are a completely different
concept and they should not be mixed with multiple search bases.

> 2) It's centrally-managed and can be updated on any going_online event
> on the client. 

Yes this is a main point we must work with, no local configuration for
sssd-ipa backends.

> > 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 :)

You can certainly say it is the Oracle database IIRC. If they changed
this in a new version all the better, but as far as I know this info is
still valid for the current versions, and is certainly valid for older
versions still in wide use and still supported.


But whatever we do , I do not want to make a *quick* hack (using
multiple search bases for example), because then we will get in real
trouble supporting all corner cases that will spill out and kill us for
maintaining the feature.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York