[SSSD] Unable to resolv netgroup with sssd

Stephen Gallagher sgallagh at redhat.com
Mon Jul 8 12:11:18 UTC 2013


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 07/08/2013 02:49 AM, Jakub Hrozek wrote:
> On Fri, Jul 05, 2013 at 03:54:57PM +0200, Mathieu Bouillaguet
> wrote:
>> Hello,
>> 
>> We are trying to get sssd to resolv netgroups. Our goal is to be
>> able to specify group of hosts in sudo rules. The sudo
>> configuration is held in the Active Directory DC. The only way to
>> do that in our environment seems to be by using host netgroups.
>> 
>> We use Red Hat 6.2, the sssd version is 1.5.1.-66.el6.
> 
> Hi Mathieu,
> 
> this is quite an old version, I think you should really upgrade.
> 
>> 
>> We have a working configuration with auth_provider=krb5,
>> id_provider=ldap and access_provider=ldap.
>> 
>> In nsswitch.conf passwd, group and shadow have "files sss" and
>> getent return the expected information.
>> 
>> For netgroup, I have also put "files sss" but I cannot resolv any
>> netgroup.
>> 
>> When I type : getent netgroup -s sss <NetGroup> I see the
>> following logs in sssd_nss.log :
>> 
>> (Fri Jul  5 15:48:04 2013) [sssd[nss]] [sbus_dispatch] (9): dbus
>> conn: 6560B0 (Fri Jul  5 15:48:04 2013) [sssd[nss]]
>> [sbus_dispatch] (9): Dispatching. (Fri Jul  5 15:48:04 2013)
>> [sssd[nss]] [sbus_message_handler] (9): Received SBUS method
>> [ping] (Fri Jul  5 15:48:04 2013) [sssd[nss]] [get_client_cred]
>> (9): Client creds: euid[0] egid[0] pid[18938]. (Fri Jul  5
>> 15:48:04 2013) [sssd[nss]] [accept_fd_handler] (4): Client 
>> connected! (Fri Jul  5 15:48:04 2013) [sssd[nss]]
>> [sss_cmd_get_version] (5): Received client version [1]. (Fri Jul
>> 5 15:48:04 2013) [sssd[nss]] [sss_cmd_get_version] (5): Offered 
>> version [1]. (Fri Jul  5 15:48:04 2013) [sssd[nss]]
>> [setnetgrent_send] (4): Requesting info for netgroup
>> [Linux.Global] from [<ALL>] (Fri Jul  5 15:48:04 2013)
>> [sssd[nss]] [sss_ncache_check_str] (8): Checking negative cache
>> for [NCE/NETGR/LOCAL/Linux.Global] (Fri Jul  5 15:48:04 2013)
>> [sssd[nss]] [lookup_netgr_step] (4): Requesting info for
>> [Linux.Global at LOCAL] (Fri Jul  5 15:48:04 2013) [sssd[nss]] [ldb]
>> (9): tevent: Added timed event "ltdb_callback": 0x65dc80 (Fri Jul
>> 5 15:48:04 2013) [sssd[nss]] [ldb] (9): tevent: Added timed
>> event "ltdb_timeout": 0x652170 (Fri Jul  5 15:48:04 2013)
>> [sssd[nss]] [ldb] (9): tevent: Destroying timer event 0x652170
>> "ltdb_timeout" (Fri Jul  5 15:48:04 2013) [sssd[nss]] [ldb] (9):
>> tevent: Ending timer event 0x65dc80 "ltdb_callback" (Fri Jul  5
>> 15:48:04 2013) [sssd[nss]] [lookup_netgr_step] (2): No matching 
>> domain found for [Linux.Global], fail! (Fri Jul  5 15:48:04 2013)
>> [sssd[nss]] [nss_cmd_setnetgrent] (0): Fatal error calling
>> setnetgrent_send (Fri Jul  5 15:48:04 2013) [sssd[nss]]
>> [client_recv] (5): Client disconnected! (Fri Jul  5 15:48:04
>> 2013) [sssd[nss]] [get_client_cred] (9): Client creds: euid[0]
>> egid[0] pid[18938]. (Fri Jul  5 15:48:04 2013) [sssd[nss]]
>> [accept_fd_handler] (4): Client connected! (Fri Jul  5 15:48:04
>> 2013) [sssd[nss]] [sss_cmd_get_version] (5): Received client
>> version [1]. (Fri Jul  5 15:48:04 2013) [sssd[nss]]
>> [sss_cmd_get_version] (5): Offered version [1]. (Fri Jul  5
>> 15:48:04 2013) [sssd[nss]] [client_recv] (5): Client 
>> disconnected! (Fri Jul  5 15:48:14 2013) [sssd[nss]]
>> [sbus_dispatch] (9): dbus conn: 6560B0 (Fri Jul  5 15:48:14 2013)
>> [sssd[nss]] [sbus_dispatch] (9): Dispatching. (Fri Jul  5
>> 15:48:14 2013) [sssd[nss]] [sbus_message_handler] (9): Received 
>> SBUS method [ping] (Fri Jul  5 15:48:24 2013) [sssd[nss]]
>> [sbus_dispatch] (9): dbus conn: 6560B0 (Fri Jul  5 15:48:24 2013)
>> [sssd[nss]] [sbus_dispatch] (9): Dispatching. (Fri Jul  5
>> 15:48:24 2013) [sssd[nss]] [sbus_message_handler] (9): Received 
>> SBUS method [ping]
>> 
>> Notably, I can see that it appears as if sssd cannot find the
>> right domain to query netgroups.
>> 
> 
> The error message actually means that the SSSD tried to search the 
> configured domain and didn't find the netgroup. But the logs you
> paste are only from the nss process which doesn't actually perform
> the searches.
> 
> Can you put debug_level=10 into the [domain] section in sssd.conf,
> restart the SSSD and check the /var/log/sssd/sssd_$domain.log ?


Actually, reading more closely, it tries to check the domain labeled
"LOCAL" and then fails in the NSS responder trying to call
setnetgrent_send(). Looking at the code for that version, it means
that the tevent_req returned NULL here, so it never got sent to the
data provider at all.

It looks like there was probably a bug with handling multiple domains
there (not sure if it still exists; I don't know if anyone ever tested
this).

Mathieu, would you mind sharing your (sanitized) sssd.conf with us?
Also, if you could please try upgrading to the RHEL 6.4 version of
SSSD on one of your machines to verify whether the bug has been fixed
there already, that would be very helpful. You *should* be able to
install the 6.4 SSSD on 6.2 just fine (though you will also need to
update libtdb, libtevent, libtalloc, libldb, selinux-policy, krb5-libs
and possibly openldap-libs as well).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlHarGYACgkQeiVVYja6o6NEIQCfWpvD2hF4va7ak6f01ziDKdpp
zEsAni5yFxzy4FKSmiXL3vzWyyQOm75H
=AVdC
-----END PGP SIGNATURE-----



More information about the sssd-devel mailing list