As mentioned in a previous post, I work in an environment with a large AD tree with in excess of 30000 groups and multiple subdomains.
We authenticate against the primary domain and are using ldap_id_mapping after having migrated from using posix attributes (the admin overhead was becoming prohibitive) Recently we were experimenting with using the ldap_idmap_default_domain_sid as a measure to ensure that the allocated uids and gids were protected against arbitrary change as new domains were encountered in the environment. We had not specified it previously and it did not have any deleterious effect until we attempted to purge a group that was affecting an update of the database (see previous message on Re: apparent error with ad_enum_cross_dom_members). sss_cache -E wouldn't purge this group so I deleted the databases and config in /var/lib/sss/db and restarted sssd with the effect that sssd started using a different range - not good. Unfortunately this only increased my paranoia. At this point I'm not sure as to how to proceed to ensure that the current range is maintained as inclusion of ldap_idmap_default_domain_sid will start the use of a new range. I also experimented with increasing the ldap_idmap_range_size from the default of 200000 to test whether the issue was due to encountering rids beyond the default range but this also triggered sssd to use a new range. Basically I'm getting into territory beyond the scope of my experience and seek advice on either biting the bullet and accepting a change in the range and specifying the default sid and dealing with the change on client systems, or getting advice on how to configure sssd to lock on the range its currently using without changing it. Relevant config in sssd.conf : id_provider = ad auth_provider = ad access_provider = ad subdomains_provider = none enumerate = true ignore_group_members = true cache_credentials = true ldap_id_mapping = true ldap_schema = ad # ldap_idmap_default_domain_sid = S-1-5-21-3009471437-2678356326-1117381816 ldap_idmap_default_domain = our domain.com # ldap_idmap_range_size = 500000 Thanks in advance Craig Silva _________ Craig Silva | Specialist Engineer - Unix Services - Servers, Storage and IDAM Cenitex | Level 15, 80 Collins Street, Melbourne 3000 ph: 03-8688-1297 mob: 0429 365 609 | www.cenitex.vic.gov.au<http://www.cenitex.vic.gov.au/> This office is located on the land of the Traditional Owners of the Kulin Nation. [cenitex logo]<http://www.cenitex.vic.gov.au/> [cid:image004.jpg@01D36DDE.27450B80] <https://www.facebook.com/CenITex.vic.gov.au/> [cid:image006.jpg@01D36DDE.27450B80] <https://twitter.com/cenitex> [cid:image010.jpg@01D36DDE.27450B80] <https://www.linkedin.com/company/314749/> Accountability, Collaboration, Respect, Initiative and Courage ---------------------------------------------------------------------- Notice: This email and any attachments may contain information that is personal, confidential, legally privileged and/or copyright. No part of it should be reproduced, adapted or communicated without the prior written consent of the copyright owner. It is the responsibility of the recipient to check for and remove viruses. If you have received this email in error, please notify the sender by return email, delete it from your system and destroy any copies. You are not authorised to use, communicate or rely on the information contained in this email. Please consider the environment before printing this email.
_______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@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.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/6SW7VAIUUK6QZI6TNI37ZCCPJOOHJCWE/
