Sumit,
Thank you for the response and the confirmation. Do you think it be
possible to have the daemon reference the sIDHistory attribute for a
specific domain SID and "if" it finds it use it for the id-mapping
algorithm? This way the previous UID/GID values would be generated for
users migrated to new domains as an example. I'm sure there would be other
useful results or am I oversimplifying a complex request?
Either way I think it would be a useful feature if development is viable.
Thanks as always!
-- lawrence
On Tue, May 19, 2020 at 11:47 AM mohammed irfan <
mohammed.irfan2331(a)gmail.com> wrote:
How to unsubscribe
On Tue, 19 May 2020, 18:24 Sumit Bose, <sbose(a)redhat.com> wrote:
> On Tue, May 12, 2020 at 06:58:13AM -0400, Lawrence Kearney wrote:
> > Hello! A question, is it possible now, or would there be value in
> > developing the ability, for the daemon to use the siDHistory attribute
> when
> > id-mapping is used for users and groups that are migrated to new
> domains?
> >
> > If I assume correctly, normally there would not be a need for this
> because
> > in direct integration mode id-mapping is constrained by the domain, so
> the
> > object SID is the object SID. However, if you are migrating users to a
> new
> > domain(s) (as the result of organisational changes or upgrades for
> example)
> > it would be very useful if a specific value in the sIDHistory attribute
> > could be referenced for id-mapping so POSIX file systems or other data
> > relationships tied to UID/GID enumerations if they exist were not
> > negatively impacted.
> >
> > And again, if I understand correctly indirect integration modes do not
> > solve this potential issue if the target users reside in domains
> trusted by
> > the IPA domain.
>
> Hi,
>
> you are right, currently the sIDHistory isn't used in direct or indirect
> integration.
>
> I have to admit that I didn't had a close look at the details of
> siDHistory. I know e.g. that the old SIDs are available in the PAC. So
> in theory it might be possible to generate group memberships based on
> the so that you are still a member of the old groups. But it might be
> difficult with the UID because there can be only one.
>
> bye,
> Sumit
>
> >
> > Suggestions or feedback if I misunderstand, and if I do understand
> > correctly is there a possibility of developing a solution for this use
> case?
> >
> > Many thanks as always,
> >
> >
> > -- lawrence
>
> > _______________________________________________
> > sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
> > To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
> > Fedora Code of Conduct:
>
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
>
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahoste...
> _______________________________________________
> sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
> Fedora Code of Conduct:
>
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
>
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahoste...
>
_______________________________________________
sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahoste...