[Freeipa-devel] [RFC] Migrating existing environments to Trust
sbose at redhat.com
Fri Apr 18 11:39:30 UTC 2014
On Thu, Apr 17, 2014 at 11:50:57AM -0400, Simo Sorce wrote:
> On Thu, 2014-04-17 at 17:20 +0200, Sumit Bose wrote:
> > On Thu, Apr 17, 2014 at 01:25:08PM +0300, Alexander Bokovoy wrote:
> > > On Thu, 17 Apr 2014, Sumit Bose wrote:
> > > >On Wed, Apr 16, 2014 at 09:02:00PM -0400, Dmitri Pal wrote:
> > > >>On 04/15/2014 05:13 AM, Sumit Bose wrote:
> > > >>>Hi,
> > > >>>
> > >
> > >
> > > >>>#* Shall we allow different UIDs/GIDs in different views?
> > > >>
> > > >>Yes.
> > > >
> > > >I hope the admin knows what he does in this case. I think it's similar
> > > >like with the user name, is there really a user-case for this with
> > > >cannot be solved better by creating a new user with the given UID? Think
> > > >about what happens if a host is moved to a new host group e.g. to change
> > > >the HBAC rules but by chance has now a different view with different
> > > >UIDs?
Thank you for the comments. So it looks like supporting legacy setups
where a single user has different POSIX IDs on different servers is a
use case we want to support. It's fine by me, nevertheless I think it is
bad admin practice to keep this kind of setups running and do a proper
> Clearly this and administration mistake, and not something we should try
> to address.
> Use different groups for HBAC and UID views, period.
If you really think it should be done this way we should make them
different group types like hbac_hostgroups and view_hostsgroups (do we
need sudo_hostgroups as well :-?). Seriously, I think the purpose of the
hostgroups is to collect hosts with the same profile to allow easy
management so that when a new host with the same profile is created it
has to be put in only one group and automatically get the right HBAC and
sudo rules, the right view etc.
> > > Again, question is what purpose would such view serve? Given that only
> > > new SSSD version can resolve these views properly and a likely reason
> > > for deviating would be to present such a user somewhere on a legacy
> > > system, I see certain conflict of use case wishes.
> We cannot do anything for legacy clients, short of presenting multiple
> "views" in LDAP, but *how* do you know which view to show a client ?
> > It just came to my mind that it is even more complicated. Although the
> > use case is to provide UIDs and GIDs if they are not set in AD we have
> > to handle the case where they are set in AD. What if there are now two
> > different override views for this AD user one with one without a
> > override UID .
> If you centralize them, each view needs its own cache, that is quite
> > In the case where a override UID is given imo the
> > override UID should be used.
> > But I wonder what would be the right way if
> > e.g. there is only a shell attribute in the override view for the user?
> The process is simple.
> for any one client only one view exist. A view is taking the original
> user, and then overlaying on top only the attributes explicitly set for
> that user on the specific view. So any attribute that is not overridden
> is maintained.
> > Shall we assume that the user will have the UID set in AD and have
> > different UIDs in different views again or none at all, because there is
> > none given in the view?
> Yes, you shall assume that.
> > I think the best way to solve this is to say that in all views the UID
> > will be the same.
> Absolutely not, it would completely defeat the point of having views.
> > If the override UID is set the AD user will get this
> > UID. If the override UID is not set then it depends on the AD settings.
> This is correct.
> > If a UID is set in AD the user will get this one from AD if not he will
> > have none at all, which is fine for the web apps use-case.
> If there is none and SSSD does automatic mapping, then that's what SSSD
> will set.
As mentioned before we decided some time ago to not mix manual and
automatically (algorithmic) mapping for the same domain. If we wanr to
change this it might result in additional effort on the SSSD side. But
as said before I do not see a problem to support user without POSIX IDs.
> > If we can agree on this we should consider to modify the suggested LDAP
> > schema so that it is possible to e.g. have different shells and home
> > directories in different views but always the same UID/GID settings.
> No, I do not agree at all, the most important feature of views is not
> changing home directories, but being able to maintain a different uid
> because all the local files (which spread on some shared storage) for a
> group of servers have historically a different uid for the user than the
> rest of the infrastructure (NIS domains consolidation case).
> Simo Sorce * Red Hat, Inc * New York
More information about the Freeipa-devel