[Freeipa-devel] [RFC] Migrating existing environments to Trust
dpal at redhat.com
Sat Apr 19 16:42:51 UTC 2014
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
>>>>> given domain. What you can do is to create a domain in the AD forest
>>>>> the old users and one for the new users. Now you can use manual
>>>>> for the old-users-domain and algorithmic mapping for the
>>>> If this requires moving users between domains on AD side then this is
>>>> non starter.
>>>> The more I read it the more I think that decision is wrong and it is
>>> 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
>>> >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
>> 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.
>> 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
>> 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.
>>> Simo Sorce * Red Hat, Inc * New York
>>> Freeipa-devel mailing list
>>> Freeipa-devel at redhat.com
>> Freeipa-devel mailing list
>> Freeipa-devel at redhat.com
> Freeipa-devel mailing list
> Freeipa-devel at redhat.com
Sr. Engineering Manager IdM portfolio
Red Hat, Inc.
More information about the Freeipa-devel