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 < [email protected]> wrote: > How to unsubscribe > > On Tue, 19 May 2020, 18:24 Sumit Bose, <[email protected]> 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 -- [email protected] >> > To unsubscribe send an email to [email protected] >> > 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/[email protected] >> _______________________________________________ >> sssd-users mailing list -- [email protected] >> To unsubscribe send an email to [email protected] >> 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/[email protected] >> > _______________________________________________ > sssd-users mailing list -- [email protected] > To unsubscribe send an email to [email protected] > 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/[email protected] >
_______________________________________________ sssd-users mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected]
