The SSSD and sIDHistory

[Lawrence Kearney]

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.

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

[Sumit Bose]

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 -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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/[e-mail].o...

[mohammed irfan]

How to unsubscribe

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

[Lawrence Kearney]

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