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

[Sumit Bose]

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.

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