On Tue, Sep 19, 2017 at 4:08 PM, James Ralston <rals...@pobox.com> wrote: > I could just issue individual getpwnam()/getgrnam() calls for every > user/group object, and let sssd synthesize the entries. But this > would require careful tuning of sssd's cache configuration options > to avoid significant delays, and even then, this would pound our AD > domain controllers with thousands and thousands of lookup requests > every time we regenerate the synthesized passwd/group files (which > will probably be hourly).
It just occurred to me that I can cheat. For any given user or group, I know that sssd calculates the id from the SID by hashing the non-RID component of the SID to yield a base offset, and then adding the value of the RID. The hashing of the SID component to yield the base offset is the tricky part, because there are many configuration options that can influence how that happens. But I can derive the base offset that sssd is using by issuing a getgrnam() call for "Domain Users", taking the gid, and subtracting the Domain Users's RID (which I can derive from the SID, but is always 513). And once I have the base offset that sssd is using, I don't need to issue any more getpwnam()/getgrnam() calls, because I can calculate the uid/gid for any object by adding the object's RID (which I can extract from the SID) to the base offset. Can anyone see any problems or drawbacks to this approach? _______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
