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 <[email protected]> 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 -- [email protected] > > To unsubscribe send an email to [email protected] > > 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/[email protected] > _______________________________________________ > sssd-users mailing list -- [email protected] > To unsubscribe send an email to [email protected] > 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/[email protected] > -- Lawrence Kearney e: [email protected] t: +001 706.951.6257 w: www.lawrencekearney.com l: www.linkedin.com/in/lawrencekearney
_______________________________________________ sssd-users mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected]
