<div dir="ltr"><div><div>The sssd .conf is in attached in my first message in this thread.<br><br></div>I will try to upgrade sssd to the version from RH 6.4 and see how it works.<br><br></div>Mathieu<br></div><div class="gmail_extra">
<br><br><div class="gmail_quote">2013/7/8 Stephen Gallagher <span dir="ltr">&lt;<a href="mailto:sgallagh@redhat.com" target="_blank">sgallagh@redhat.com</a>&gt;</span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA1<br>
<div><div class="h5"><br>
On 07/08/2013 02:49 AM, Jakub Hrozek wrote:<br>
&gt; On Fri, Jul 05, 2013 at 03:54:57PM +0200, Mathieu Bouillaguet<br>
&gt; wrote:<br>
&gt;&gt; Hello,<br>
&gt;&gt;<br>
&gt;&gt; We are trying to get sssd to resolv netgroups. Our goal is to be<br>
&gt;&gt; able to specify group of hosts in sudo rules. The sudo<br>
&gt;&gt; configuration is held in the Active Directory DC. The only way to<br>
&gt;&gt; do that in our environment seems to be by using host netgroups.<br>
&gt;&gt;<br>
&gt;&gt; We use Red Hat 6.2, the sssd version is 1.5.1.-66.el6.<br>
&gt;<br>
&gt; Hi Mathieu,<br>
&gt;<br>
&gt; this is quite an old version, I think you should really upgrade.<br>
&gt;<br>
&gt;&gt;<br>
&gt;&gt; We have a working configuration with auth_provider=krb5,<br>
&gt;&gt; id_provider=ldap and access_provider=ldap.<br>
&gt;&gt;<br>
&gt;&gt; In nsswitch.conf passwd, group and shadow have &quot;files sss&quot; and<br>
&gt;&gt; getent return the expected information.<br>
&gt;&gt;<br>
&gt;&gt; For netgroup, I have also put &quot;files sss&quot; but I cannot resolv any<br>
&gt;&gt; netgroup.<br>
&gt;&gt;<br>
&gt;&gt; When I type : getent netgroup -s sss &lt;NetGroup&gt; I see the<br>
&gt;&gt; following logs in sssd_nss.log :<br>
&gt;&gt;<br>
&gt;&gt; (Fri Jul  5 15:48:04 2013) [sssd[nss]] [sbus_dispatch] (9): dbus<br>
&gt;&gt; conn: 6560B0 (Fri Jul  5 15:48:04 2013) [sssd[nss]]<br>
&gt;&gt; [sbus_dispatch] (9): Dispatching. (Fri Jul  5 15:48:04 2013)<br>
&gt;&gt; [sssd[nss]] [sbus_message_handler] (9): Received SBUS method<br>
&gt;&gt; [ping] (Fri Jul  5 15:48:04 2013) [sssd[nss]] [get_client_cred]<br>
&gt;&gt; (9): Client creds: euid[0] egid[0] pid[18938]. (Fri Jul  5<br>
&gt;&gt; 15:48:04 2013) [sssd[nss]] [accept_fd_handler] (4): Client<br>
&gt;&gt; connected! (Fri Jul  5 15:48:04 2013) [sssd[nss]]<br>
&gt;&gt; [sss_cmd_get_version] (5): Received client version [1]. (Fri Jul<br>
&gt;&gt; 5 15:48:04 2013) [sssd[nss]] [sss_cmd_get_version] (5): Offered<br>
&gt;&gt; version [1]. (Fri Jul  5 15:48:04 2013) [sssd[nss]]<br>
&gt;&gt; [setnetgrent_send] (4): Requesting info for netgroup<br>
&gt;&gt; [Linux.Global] from [&lt;ALL&gt;] (Fri Jul  5 15:48:04 2013)<br>
&gt;&gt; [sssd[nss]] [sss_ncache_check_str] (8): Checking negative cache<br>
&gt;&gt; for [NCE/NETGR/LOCAL/Linux.Global] (Fri Jul  5 15:48:04 2013)<br>
&gt;&gt; [sssd[nss]] [lookup_netgr_step] (4): Requesting info for<br>
&gt;&gt; [Linux.Global@LOCAL] (Fri Jul  5 15:48:04 2013) [sssd[nss]] [ldb]<br>
&gt;&gt; (9): tevent: Added timed event &quot;ltdb_callback&quot;: 0x65dc80 (Fri Jul<br>
&gt;&gt; 5 15:48:04 2013) [sssd[nss]] [ldb] (9): tevent: Added timed<br>
&gt;&gt; event &quot;ltdb_timeout&quot;: 0x652170 (Fri Jul  5 15:48:04 2013)<br>
&gt;&gt; [sssd[nss]] [ldb] (9): tevent: Destroying timer event 0x652170<br>
&gt;&gt; &quot;ltdb_timeout&quot; (Fri Jul  5 15:48:04 2013) [sssd[nss]] [ldb] (9):<br>
&gt;&gt; tevent: Ending timer event 0x65dc80 &quot;ltdb_callback&quot; (Fri Jul  5<br>
&gt;&gt; 15:48:04 2013) [sssd[nss]] [lookup_netgr_step] (2): No matching<br>
&gt;&gt; domain found for [Linux.Global], fail! (Fri Jul  5 15:48:04 2013)<br>
&gt;&gt; [sssd[nss]] [nss_cmd_setnetgrent] (0): Fatal error calling<br>
&gt;&gt; setnetgrent_send (Fri Jul  5 15:48:04 2013) [sssd[nss]]<br>
&gt;&gt; [client_recv] (5): Client disconnected! (Fri Jul  5 15:48:04<br>
&gt;&gt; 2013) [sssd[nss]] [get_client_cred] (9): Client creds: euid[0]<br>
&gt;&gt; egid[0] pid[18938]. (Fri Jul  5 15:48:04 2013) [sssd[nss]]<br>
&gt;&gt; [accept_fd_handler] (4): Client connected! (Fri Jul  5 15:48:04<br>
&gt;&gt; 2013) [sssd[nss]] [sss_cmd_get_version] (5): Received client<br>
&gt;&gt; version [1]. (Fri Jul  5 15:48:04 2013) [sssd[nss]]<br>
&gt;&gt; [sss_cmd_get_version] (5): Offered version [1]. (Fri Jul  5<br>
&gt;&gt; 15:48:04 2013) [sssd[nss]] [client_recv] (5): Client<br>
&gt;&gt; disconnected! (Fri Jul  5 15:48:14 2013) [sssd[nss]]<br>
&gt;&gt; [sbus_dispatch] (9): dbus conn: 6560B0 (Fri Jul  5 15:48:14 2013)<br>
&gt;&gt; [sssd[nss]] [sbus_dispatch] (9): Dispatching. (Fri Jul  5<br>
&gt;&gt; 15:48:14 2013) [sssd[nss]] [sbus_message_handler] (9): Received<br>
&gt;&gt; SBUS method [ping] (Fri Jul  5 15:48:24 2013) [sssd[nss]]<br>
&gt;&gt; [sbus_dispatch] (9): dbus conn: 6560B0 (Fri Jul  5 15:48:24 2013)<br>
&gt;&gt; [sssd[nss]] [sbus_dispatch] (9): Dispatching. (Fri Jul  5<br>
&gt;&gt; 15:48:24 2013) [sssd[nss]] [sbus_message_handler] (9): Received<br>
&gt;&gt; SBUS method [ping]<br>
&gt;&gt;<br>
&gt;&gt; Notably, I can see that it appears as if sssd cannot find the<br>
&gt;&gt; right domain to query netgroups.<br>
&gt;&gt;<br>
&gt;<br>
&gt; The error message actually means that the SSSD tried to search the<br>
&gt; configured domain and didn&#39;t find the netgroup. But the logs you<br>
&gt; paste are only from the nss process which doesn&#39;t actually perform<br>
&gt; the searches.<br>
&gt;<br>
&gt; Can you put debug_level=10 into the [domain] section in sssd.conf,<br>
&gt; restart the SSSD and check the /var/log/sssd/sssd_$domain.log ?<br>
<br>
<br>
</div></div>Actually, reading more closely, it tries to check the domain labeled<br>
&quot;LOCAL&quot; and then fails in the NSS responder trying to call<br>
setnetgrent_send(). Looking at the code for that version, it means<br>
that the tevent_req returned NULL here, so it never got sent to the<br>
data provider at all.<br>
<br>
It looks like there was probably a bug with handling multiple domains<br>
there (not sure if it still exists; I don&#39;t know if anyone ever tested<br>
this).<br>
<br>
Mathieu, would you mind sharing your (sanitized) sssd.conf with us?<br>
Also, if you could please try upgrading to the RHEL 6.4 version of<br>
SSSD on one of your machines to verify whether the bug has been fixed<br>
there already, that would be very helpful. You *should* be able to<br>
install the 6.4 SSSD on 6.2 just fine (though you will also need to<br>
update libtdb, libtevent, libtalloc, libldb, selinux-policy, krb5-libs<br>
and possibly openldap-libs as well).<br>
-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG v1.4.13 (GNU/Linux)<br>
Comment: Using GnuPG with Thunderbird - <a href="http://www.enigmail.net/" target="_blank">http://www.enigmail.net/</a><br>
<br>
iEYEARECAAYFAlHarGYACgkQeiVVYja6o6NEIQCfWpvD2hF4va7ak6f01ziDKdpp<br>
zEsAni5yFxzy4FKSmiXL3vzWyyQOm75H<br>
=AVdC<br>
-----END PGP SIGNATURE-----<br>
<div class="HOEnZb"><div class="h5">_______________________________________________<br>
sssd-devel mailing list<br>
<a href="mailto:sssd-devel@lists.fedorahosted.org">sssd-devel@lists.fedorahosted.org</a><br>
<a href="https://lists.fedorahosted.org/mailman/listinfo/sssd-devel" target="_blank">https://lists.fedorahosted.org/mailman/listinfo/sssd-devel</a><br>
</div></div></blockquote></div><br></div>