Sumit,
Thank you that helps immensely.

The goal of the referenced configuration is for new "direct integration" deployments in large AD environments for which we want to accommodate both growth and UID-GID alignment across systems that support the "ldap_idmap_helper_table_size" directive and those that don't.

-- lawrence

On Wed, Aug 29, 2018 at 5:01 AM Sumit Bose <sbose@redhat.com> wrote:
On Tue, Aug 28, 2018 at 03:55:37PM -0400, Lawrence Kearney wrote:
> I have a question concerning values for the the "ldap_idmap_range_size"
> directive. I'm aware that v1.13.4 or better of the daemon supports multiple
> slices for the same domain. My question goes to earlier versions of the
> daemon  that do not, "and" the v1.13.4 or better versions of the daemon
> that do.
>
> In environments that have high RID values (>750,000), what disadvantages
> are there to setting the value of the "ldap_idmap_range_size" directive to
> values above 1,000,000 to accommodate extraordinary large RID values. My
> common sense says the computational tax would be too high for a host to be
> sustainable, but I wanted to ask.

No it is ok to use larger value there is no additional tax. See the 'ID
MAPPING' section of the sssd-ad man page for details about how the
mapping is done.

>
> So, in environments where I might want to have slice capacity > 200,000,
> what are the concerns, best practices, and briefly, why?

You have to be aware that the UIDs and GIDs assigned to a user or a
group will change if you change ldap_idmap_range_size. If you already
used the default value for some time you have to migrate existing file
system permissions to the new values. Given that you should choose the
new value for ldap_idmap_range_size large enough so that chances are low
it has to be increased again.

If you increase the size of a range the number of ranges will decrease.
Since ranges are selected for each domain with the help of a hashed
value the chance of a collision (a range assigned to two different
domains) will increase. But so far I'm not aware of a reported
collision so this is more a theoretical concern.

HTH

bye,
Sumit
>
>
> Many thanks
>
>
> -- Lawrence Kearney

> _______________________________________________
> sssd-users mailing list -- sssd-users@lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
_______________________________________________
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org


--