I have a storage appliance that needs local passwd/group files loaded onto it, which need to match the entries we get by using sssd's ldap_id_mapping feature. So I need some way to enumerate or synthesize passwd/group entries, for every user/group object in our domain, using LDIF dumps from AD that includes all users/groups, along with their respective objectSid attributes.
We know (from experience, and from discussion on this list) that enabling enumeration in sssd is problematic, so that's out. 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). From digging around in the sssd source code, I see that sssd has a SSS_NSS_GETIDBYSID API call that looks to be exactly what I need. But it's not clear to me whether that's a public or private API, and additionally, it looks like I'd be limited to C for my implementation, as I see no other language bindings for those functions. Has anyone already rolled (Python, Ruby, Perl, et. al.) bindings for sssd's API calls, specifically the ID-SID mapping calls? One potential option would be to just re-implement sssd's id mapping code in Python. I could "cheat" in our implementation, because I know that the only options that vary across our domains are (ldap_idmap_range_max, ldap_idmap_range_min, ldap_idmap_range_size). But re-implementation opens the door for a subtle error that would cause my mapping code to return different results from sssd in some corner cases, which I definitely don't want. So leveraging sssd's SSS_NSS_GETIDBYSID API call would be best… if that's possible. Another option would be to bypass the API and talk directly to the NSS responder via its listening socket, which is easy enough to do in other languages. But this would require me to speak the protocol exactly the way sssd expects, and any API changes would break my code. Thoughts? Suggestions? _______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
