On Fri, Feb 2, 2018 at 1:07 AM, Sumit Bose <sb...@redhat.com> wrote: > On Thu, Feb 01, 2018 at 01:03:24PM -0800, Richard Sharpe wrote: >> Hi folks, >> >> We have a customer who seems to do what RHEL does with respects users >> and groups. >> >> That is: >> >> 1. User A has a SID of S-1-5-21-x-y-z-1234 >> 2. They also have a primary group SID of S-1-5-21-x-y-x-1235 (usually >> adjacent). >> 3. They are also using RFC2703bis and they have the UID property set >> to 21234 and the GID property set to 21234. >> >> Now, when the Samba idmap_sss.c calls sss_nss_getsidbyid looking for >> the SID associated with the GID it often gets back the SID associated >> with the UID, probably because we just asked for the SID associated >> with the UID. >> >> Is there a different function I can call to get both/all? I looked at >> the code for sss_nss_getsidbyid and it just calls sss_nss_getyyybyxxx >> and that function seems to only hand back the first SID returned. > > I'm sorry, I have to admit that this kind of setup didn't came to my > mind when writing those calls. But yes, users and group are coming from > different name spaces on the POSIX side and should be handled > separately. > > Currently you can only do workarounds. E.g. if the group name differs > from the user name you call getpwuid() and getgrgid() first and then > sss_nss_getsidbyname(). But this would only work if the use names based > on the samAccountName attribute from AD because iirc AD enforces > uniqueness here. If they use a different attribute for the group names > this might not work. > > As an alternative, but even more complicated you can make the SID > available via D-Bus/InfoPipe and then lookup user and group by ID. > > So it looks like sss_nss_getsidbyuid() and sss_nss_getsidbygid() should > be added to the interface. Would you mind to open a ticket about this on > https://pagure.io/SSSD/sssd/new_issue or do you prefer me doing this?
I can file a ticket. >> >> Also, as an aside, it seems like a bad decision to place fixed CERTs >> in the repos because if you need to rebuild the package after the CERT >> expires you are SOL. > > Yes, makeshift solutions have a long life. I already have a ticket to > generate fresh certificates for each test run > https://pagure.io/SSSD/sssd/issue/3436. But only two tests should be hit > by the issue. So, in the worst case they can be disabled: > > +diff --git a/Makefile.am b/Makefile.am > +index > 5635a8c8fd681c4a17d003487e9ea440ab431407..c230d5e69320206778637ee3d30bedf9fe2e000a > 100644 > +--- a/Makefile.am > ++++ b/Makefile.am > +@@ -273,11 +273,9 @@ if HAVE_CMOCKA > + responder_cache_req-tests \ > + test_sbus_opath \ > + test_fo_srv \ > +- pam-srv-tests \ > + test_ipa_subdom_util \ > + test_tools_colondb \ > + test_krb5_wait_queue \ > +- test_cert_utils \ > + test_ldap_id_cleanup \ > + test_data_provider_be \ > + test_dp_request_table \ > > > HTH > > bye, > Sumit > >> >> -- >> Regards, >> Richard Sharpe >> (何以解憂？唯有杜康。--曹操) >> _______________________________________________ >> sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org >> To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org > _______________________________________________ > sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org > To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org -- Regards, Richard Sharpe (何以解憂？唯有杜康。--曹操) _______________________________________________ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
