[SSSD] Unable to resolv netgroup with sssd

Jakub Hrozek jhrozek at redhat.com
Mon Jul 8 06:49:08 UTC 2013


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 ?



More information about the sssd-devel mailing list