Thanks Bryan, Yes, that's my point! I still feel that the issue is with the NAS vendors. Adding the SSSD algorithm would be a small amount of effort and "just work" for most of us working with Linux systems. As I mentioned before it seems that multiple people say they've asked their NAS vendor to do this, yet the vendors aren't interested.
Having to add and manage additional fields in AD just to cater for a NAS seems like a huge cost. We don't need to do so for any other reason and yet have a fully interoperable environment today. Ed. On 10/5/22 12:51 am, Bryan Smith wrote: Define 'large'? In general many NAS, SAN and even Network vendors have issues with LDAP trees and attributes any way. So UID, GID and UPN (user@domain) and NT/Dom SID enumeration and mapping is a secondary issue. I.e., I spend a lot more time dealing with maintaining a 'light' 389/RHDS or AD-LDS tree just for those Storage/Network devices than anything else. This is the biggest issue with AD and a lot of attributed and added schema. There shouldn't be any issue with SSSD scaling to tens of thousands of records, and it's more of an issue of how the Storage/Network devices use or even search the LDAP attributes across a lot of records. -- Sent from my phone, apologies for any brevity as well as autocorrect Bryan J Smith - http://linkedin.com/in/bjsmith _______________________________________________ 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] Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
