[SSSD] Unable to resolv netgroup with sssd

Mathieu Bouillaguet mathieu.bouillaguet at gmail.com
Mon Jul 8 12:30:25 UTC 2013


The sssd .conf is in attached in my first message in this thread.

I will try to upgrade sssd to the version from RH 6.4 and see how it works.

Mathieu


2013/7/8 Stephen Gallagher <sgallagh at redhat.com>

> -----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-----
> _______________________________________________
> sssd-devel mailing list
> sssd-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fedorahosted.org/pipermail/sssd-devel/attachments/20130708/48641ff8/attachment.html>


More information about the sssd-devel mailing list