[Freeipa-devel] [RFC] Migrating existing environments to Trust
sbose at redhat.com
Fri Apr 18 18:03:39 UTC 2014
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.
> 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.
> > 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
More information about the Freeipa-devel