We are using the ad provider for sssd, with the id mapping feature enabled.
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 and groups.
(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 faster?
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 passwd/group entries?
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 enabled.
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 and groups.
(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 faster?
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 passwd/group entries?
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.
sssd-users@lists.fedorahosted.org