On Tue, Jan 26, 2016 at 05:50:06PM -0500, James Ralston wrote:
On Tue, Jan 26, 2016 at 3:03 PM, Jakub Hrozek
> On Tue, Jan 26, 2016 at 02:19:42PM -0500, James Ralston wrote:
>> Here's the problem: unless the user/group objects already happen to be
>> in sssd's cache, enumerating the passwd/group entries in this way is
>> very slow: 3-5 entries per second, at best. For a larger AD domain,
>> the program can take 10-15 minutes to perform this iterative
>> enumeration, which is much longer than we'd prefer.
>> Can anyone think of a way to make this iterative enumeration go
> Did you try mounting the cache to tmpfs to get rid of the cache writes?
That's… a very clever idea.
From testing using tmpfs to back /var/lib/sss/db, the speed of lookups
increases by about an order of magnitude: about 44 lookups per second,
instead of 4-5 lookups per second. We have around 5,000 AD objects,
so the ~100 second wait would be tolerable.
A related question: is there any possibility of adding an option
to the ad backend to disable the filtering of distribution
groups (group type flag 0x8)?
I'm glad it helped. FWIW, we're considering adding a nosync option to
the cache as well at some point, which should have the same performance
effect as using tmpfs except the cache would be persistent (otoh, if
sssd was killed during the transaction, the cache might got
corrupt..which is why always sync by default)
It's a long story, but what we are trying to do here is to take
regular snapshots of our AD users and groups, and sssd's
getpwnam()/getgrnam() mapping is the perfect way to do it. I think I
understand why distribution groups are filtered by default (they're
not security-enabled in AD, and can't be used in Windows ACLs), but in
this one particular case, we really do want to be able to enumerate
every single group.
can you try setting:
ldap_group_type = nosuchattr
That should trick sssd into not seeing the group type at all and would
avoid filtering I guess (not tested).