On Tue, Sep 19, 2017 at 4:08 PM, James Ralston <ralston(a)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?