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?
Clearly this and administration mistake, and not something we should try
Use different groups for HBAC and UID views, period.
> > 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
> 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
> 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
Freeipa-devel mailing list