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@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
--
Thank you,
Dmitri Pal
Sr. Engineering Manager IdM portfolio
Red Hat, Inc.
_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
