Re: best way to check if a host is in a net group - sssd-users - Fedora mailing-lists

23 Jan 2020

      I’d like to return to a discussion from a few months ago. I complained that I couldn’t find members of some netgroups. Here’s an example. I did “getent netgroup lcsrcf” and got no members. This is on Centos 8.1
It makes the right LDAP queries, and gets the right results.
Here’s the final section of the log:
Thu Jan 23 10:14:25 2020) [sssd[be[cs.rutgers.edu]]] [sdap_process_result] (0x2000): Trace: sh[0x5617e2787d10], connected[1], ops[0x5617e27f5d60], ldap[0x\
5617e27c7da0]
(Thu Jan 23 10:14:25 2020) [sssd[be[cs.rutgers.edu]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_RESULT]
(Thu Jan 23 10:14:25 2020) [sssd[be[cs.rutgers.edu]]] [sdap_get_generic_op_finished] (0x0400): Search result: Success(0), no errmsg set
(Thu Jan 23 10:14:25 2020) [sssd[be[cs.rutgers.edu]]] [sdap_get_generic_op_finished] (0x2000): Total count [0]
(Thu Jan 23 10:14:25 2020) [sssd[be[cs.rutgers.edu]]] [sdap_op_destructor] (0x2000): Operation 14 finished
(Thu Jan 23 10:14:25 2020) [sssd[be[cs.rutgers.edu]]] [ipa_netgr_members_process] (0x2000): Found 184 members in current search base
(Thu Jan 23 10:14:25 2020) [sssd[be[cs.rutgers.edu]]] [ipa_netgr_process_all] (0x2000): Extracting netgroup members of netgroup 0
(Thu Jan 23 10:14:25 2020) [sssd[be[cs.rutgers.edu]]] [ipa_netgr_process_all] (0x2000): Extracted 1 netgroup members
(Thu Jan 23 10:14:25 2020) [sssd[be[cs.rutgers.edu]]] [ipa_netgr_process_all] (0x4000): Extracting user members of netgroup 0
(Thu Jan 23 10:14:25 2020) [sssd[be[cs.rutgers.edu]]] [ipa_netgr_process_all] (0x2000): Extracted 0 user members
(Thu Jan 23 10:14:25 2020) [sssd[be[cs.rutgers.edu]]] [ipa_netgr_process_all] (0x4000): Extracting host members of netgroup 0
(Thu Jan 23 10:14:25 2020) [sssd[be[cs.rutgers.edu]]] [ipa_netgr_process_all] (0x2000): Extracted 0 host members
(Thu Jan 23 10:14:25 2020) [sssd[be[cs.rutgers.edu]]] [ipa_save_netgroup] (0x2000): Storing netgroup studentdb
(Thu Jan 23 10:14:25 2020) [sssd[be[cs.rutgers.edu]]] [ipa_save_netgroup] (0x1000): Adding original DN [ipaUniqueID=a5eacc30-c406-11e7-9045-000c29dbd083,cn\
=ng,cn=alt,dc=cs,dc=rutgers,dc=edu] to attributes of [studentdb].
Here’s what a check the works looks like:
Thu Jan 23 09:58:02 2020) [sssd[be[cs.rutgers.edu]]] [sysdb_set_entry_attr] (0x0200): Entry [name=dcsilab_random,cn=Netgroups,cn=cs.rutgers.edu,cn=sysdb] \
has set [cache] attrs.
(Thu Jan 23 09:58:02 2020) [sssd[be[cs.rutgers.edu]]] [ldb] (0x4000): commit ldb transaction (nesting: 0)
(Thu Jan 23 09:58:02 2020) [sssd[be[cs.rutgers.edu]]] [ipa_netgr_process_all] (0x2000): Extracting netgroup members of netgroup 5
(Thu Jan 23 09:58:02 2020) [sssd[be[cs.rutgers.edu]]] [ipa_netgr_process_all] (0x2000): Extracted 0 netgroup members
(Thu Jan 23 09:58:02 2020) [sssd[be[cs.rutgers.edu]]] [ipa_netgr_process_all] (0x4000): Extracting user members of netgroup 5
(Thu Jan 23 09:58:02 2020) [sssd[be[cs.rutgers.edu]]] [ipa_netgr_process_all] (0x2000): Extracted 0 user members
(Thu Jan 23 09:58:02 2020) [sssd[be[cs.rutgers.edu]]] [ipa_netgr_process_all] (0x4000): Extracting host members of netgroup 5
(Thu Jan 23 09:58:02 2020) [sssd[be[cs.rutgers.edu]]] [ipa_netgr_process_all] (0x2000): Extracted 6 host members
(Thu Jan 23 09:58:02 2020) [sssd[be[cs.rutgers.edu]]] [ipa_netgr_process_all] (0x2000): Putting together triples of netgroup 5
(Thu Jan 23 09:58:02 2020) [sssd[be[cs.rutgers.edu]]] [ipa_save_netgroup] (0x2000): Storing netgroup dcsilab_linuxclients__3
Note that the first search was for net group lcsrcf, yer it stores the value as studentdb. Is it getting confused? studentdb is an indirect member of lcsrcf.
...
On Nov 4, 2019, at 11:24 AM, Charles Hedrick hedrick@rutgers.edu wrote:
the query that generated that was
./test lcsrcf ilab1.cs.rutgers.edu
We have 242 net groups in a complex multi-level setup. It’s historical, and doesn’t make a lot of sense. Lots of redundancy and dead systems. I’m attaching an LDAP dump
<ng.out>
...
On Nov 4, 2019, at 11:18 AM, Charles Hedrick hedrick@rutgers.edu wrote:
<sssd_cs.rutgers.edu.log>
...
On Nov 1, 2019, at 9:03 AM, Sumit Bose sbose@redhat.com wrote:
On Thu, Oct 31, 2019 at 02:02:51PM +0000, Charles Hedrick wrote:
...
I need to support netgroup checks in a service, written in C. I’m asking the SSSD list because we’re using SSSD, which means that net group operations are routed to the SSSD provider.
I found that innetgr doesn’t work if there are nested net groups. The man page doesn’t suggest that this would happen, though various online discussions seem to suggest it. As far as I can tell, using the usual libc routines, I’d have to do a recursive enumeration of the netgroup. This seems pretty silly, since the host's memberOf attribute shows what net groups it’s a member of, whether direct or indirect. You could also enumerate using the compat tree, which lets a single LDAP query get all members of the netgroup.
Hi,
it would be good if you can share some logs which covered the failed
attempt. Iirc nested netgroups are handled by SSSD and glibc together.
I.e. SSSD will not resolve a nested netgroup automatically but just
returns the name and the glibc ask for the members of the nested group
if needed.
bye,
Sumit
...
For the moment I’m doing LDAP operations. My application already needs to do GSSAPI-authenticated LDAP operations, so I have an LDAP connection already. A netgroup check require two queries, which could reasonably be cached. Lookup the netgroup by name to find the unique ID. Look up the host and see if the unique ID matches any memberOf attributes.
But not all applications would be set up so this is easy. Is there a reasonable way to check netgroup membership using normal libc calls?

sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.o...