[Freeipa-devel] [RFC] Migrating existing environments to Trust
dpal at redhat.com
Thu Apr 17 22:03:48 UTC 2014
On 04/17/2014 11:50 AM, 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:
>>>>>> #* Shall we allow different UIDs/GIDs in different views?
>>>> 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
> Clearly this and administration mistake, and not something we should try
> to address.
> 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
> 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.
>> 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).
Yes, this is the main use case we are trying to solve: having different
UID/GID exposed to different groups of hosts.
It should work for simple ldap clients too. This is similar to Zones in
some third party solutions.
This is actually most asked feature based on the conversations I had
I will comment on the rest questions later.
Sr. Engineering Manager IdM portfolio
Red Hat, Inc.
More information about the Freeipa-devel