[Freeipa-devel] [RFC] Migrating existing environments to Trust

[Dmitri Pal]

On 04/18/2014 02:03 PM, Sumit Bose wrote:
> On Fri, Apr 18, 2014 at 06:52:30PM +0200, Sumit Bose wrote:
>> On Fri, Apr 18, 2014 at 01:53:30AM -0400, Simo Sorce wrote:
>>> On Thu, 2014-04-17 at 23:58 -0400, Dmitri Pal wrote:
>>>>> yes, this can already be controlled by the idrange type. But you
>>>> have to
>>>>> choose either algorithmic or manual mapping you cannot have both in
>>>> a
>>>>> given domain. What you can do is to create a domain in the AD forest
>>>> for
>>>>> the old users and one for the new users. Now you can use manual
>>>> mapping
>>>>> for the old-users-domain and algorithmic mapping for the
>>>>> new-users-domain.
>>>> If this requires moving users between domains on AD side then this is
>>>> a
>>>> non starter.
>>>> The more I read it the more I think that decision is wrong and it is
>>>> bug.
>>>>
>>> What we can do is halfway, if an overlay view is activate for an AD
>>> domain then in IPA we have options to automatically generate IDs for any
>>> AD user (if the admin wants), these IDs get stored in the Ad overlaying
>>> view.
>>>
>>> >From the SSSD pov no algoritmic mapping is occurring as SSSD always
>>> looks for the IDs in IPA.
>>>
>>> Note that we have to do this anyway if you want to allow also legacy
>>> clients to see the same ids, so it seem to me the best/only possible
>>> way.
>> I agree, this sounds like safe and robust solution to the discussed
>> issues. I wonder if we shouldn't do this always for all users and groups
>> in the AD trusted AD forests? Since it looks like most real-world
>> deployments would need it anyways it might be easier to stop thinking
>> about the few cases where this is not needed. We will have lots of
>> additional objects in the database but on the plus side:
>>
>> - the compat-tree does not have to talk to SSSD and keep the users and
>>    groups in memory but can just read of object from the tree, maybe do
>>    some modification and deliver the result.
>> - the current extdom plugin won't be needed anymore because all it's
>>    operations can be done by SSSD with plain ldapsearch.
> Another benefit would be easier group management because since now AD
> users and group have an object in the IPA tree, they can be added to IPA
> groups directly without the need of an external group.
>
> A positive side-effect is that migrations from the win-sync solution
> would become much easier.

Yes this seems like the right direction to go.

>
> bye,
> Sumit
>
>> I'm not sure but it might also be the only way to resolve the user or
>> group name for a given UID or GID in a more complex environment.
>>> The only caveat is that it requires some development on the IPA side to
>>> do this object creation, but it is not a lot of code as we can reuse DNA
>>> for the actual ID allocation, we just need to create the entry in the
>>> view.
>> Or as an alternative SSSD running in ipa-server-mode can create the
>> missing objects? Since SSSD in ipa-server-mode is currently doing the ID
>> allocation it would be easily to keep compatibility with older versions.
>>
>> bye,
>> Sumit
>>
>>> Simo.
>>>
>>> -- 
>>> Simo Sorce * Red Hat, Inc * New York
>>>
>>> _______________________________________________
>>> 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
> _______________________________________________
> Freeipa-devel mailing list
> Freeipa-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-devel


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.