On Tue, Jan 26, 2016 at 02:19:42PM -0500, James Ralston wrote:
We are using the ad provider for sssd, with the id mapping feature
We have a program that obtains a list of all Active Directory users and
groups via LDAP, and then calls getpwnam()/getgrnam() on those users
(We used to accomplish this enumeration simply by enabling enumeration
within sssd. But the performance issues this created for sssd,
combined with the threat of the removal of the enumeration feature,
made us search for a different solution.)
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
One thing we're considering is having our program synthesize the
passwd and group entries itself, rather than having sssd do it via
getpwnam()/getgrnam() calls. We'll still have to look up at least one
entry (to determine the slice starting point for the ID mapping), but
since we can obtain each object's RID from AD, once we know the
starting offset, we can calculate the uid/gid values. After that, all
we need to do is synthesize the rest of the fields from the object's
AD properties, the same as sssd.
Thoughts? Is there a way to accelerate iterative enumeration, or
should we just give up and replicate the logic sssd uses to generate
Did you try mounting the cache to tmpfs to get rid of the cache writes?
Add the following to /etc/fstab as a single line:
tmpfs /var/lib/sss/db/ tmpfs
size=300M,mode=0700,noauto,rootcontext=system_u:object_r:sssd_var_lib_t:s0 0 0
Then mount the directory and restart the sssd afterwards:
# mount /var/lib/sss/db/
# systemctl restart sssd
This cache wouldn't persist across reboots but would be quite fast.