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