Gotcha! That reasoning makes sense. I know that "autofs" is a special case. Even though there's an "automount" entry in /etc/nsswitch.conf file, I've read that automountd does not technically use libnsswitch.so -- instead it "peeks" inside /etc/nsswitch.conf file for the settings of that "automount" entry. And automountd takes the appropriate action itself.
So automount is not a "an nsswitch map provided by libc", thus you have a separate autofs_provider. Spike On Mon, Feb 18, 2019 at 3:02 PM Spike White <[email protected]> wrote: > This LDAP domain has no user or group information. Only automount maps > and netgroups. > > I'm defining search_base only for autofs and netgroup: > > ldap_autofs_search_base = ou=automount,ou=admin,dc=itzgeek,dc=local > ldap_netgroup_search_base = ou=netgroup,ou=admin,dc=itzgeek,dc=local > > > I am not explicitly setting ldap_search_base. If not explicitly set, the > sssd-ldap man page gives a lot of LDAP server-ese as to what value it takes > on: > > Default [for ldap_search_base]: If not set, the value of the > defaultNamingContext or namingContexts attribute from the RootDSE of the > LDAP server > is used. If defaultNamingContext does not exist or has an empty > value namingContexts is used. The namingContexts attribute > must have a single value with the DN of the search base of the > LDAP server to make this work. Multiple values are are not > supported. > > (I don't understand that above paragraph from the man page.) > > However, I do see in the LDAP_child.log that it does attempt a user > authentication. We're using short login names, so I'm guessing it consults > each child domain for authentication. I haven't checked the logs to see if > it is consulted during the access phase. > > Anyway, since there are no users or groups in this LDAP child domain, I > should set: > auth_provider = none > account_provider = none > > for this domain, so that it doesn't even consult this child domain for > user login -- correct? > > Spike > > > > On Mon, Feb 18, 2019 at 11:37 AM Lukas Slebodnik <[email protected]> > wrote: > >> On (18/02/19 10:53), Spike White wrote: >> >All, >> > >> >Spoiler alert: my configuration is working; I just want verification I >> >did it right. >> > >> >BACKGROUND: >> > >> >I have an LDAP domain that was delivering autofs maps exclusively. Other >> >(AD) domains were delivering users, groups, authentication and access. >> > >> >Since this back-end LDAP domain didn’t participate in any user >> >authentication or access, I configured that backup LDAP domain in >> sssd.conf >> >with only an autofs_provder: >> > >> >[domain/LDAP] >> > >> >debug_level = 9 >> > >> >id_provider = none >> > >> >autofs_provider = ldap >> > >> >ldap_uri= ldap://austgcore17.example.com >> > >> >ldap_schema = rfc2307bis >> > >> >ldap_default_bind_dn = cn=ldapadm,dc=itzgeek,dc=local >> > >> >ldap_default_authtok = ldppassword >> > >> >ldap_autofs_search_base = ou=automount,ou=admin,dc=itzgeek,dc=local >> > >> >ldap_autofs_map_object_class = automountMap >> > >> >ldap_autofs_map_name = automountMapName >> > >> >ldap_autofs_entry_object_class = automount >> > >> >ldap_autofs_entry_key = automountKey >> > >> >ldap_autofs_entry_value = automountInformation >> > >> >ldap_netgroup_search_base = ou=netgroup,ou=admin,dc=itzgeek,dc=local >> > >> > >> > >> >Works great! Get all expected automount maps. >> > >> >CURRENT (ADDED NETGROUPS): >> > >> >Now I have added NIS netgroups to this backend LDAP server. Thus, it now >> >successfully delivers automount maps + netgroups. >> > >> >I still don’t want this LDAP backend domain to even attempt >> authentication >> >and access – that’s in my other (AD) domains. >> > >> >So you’d think all I’d have to do is change this: >> > >> >[domain/LDAP] >> > >> >… >> > >> >id_provider = none >> > >> >autofs_provider = ldap >> > >> > >> > >> >to this: >> > >> >[domain/LDAP] >> > >> >… >> > >> >id_provider = none >> > >> >autofs_provider = ldap >> > >> >netgroup_provider = ldap >> > >> > >> > >> >But – point in fact – there is no “netgroup_provider” setting for >> sssd.conf >> >file. Netgroup takes whatever the value is of ‘id_provider’. >> > >> > >> > >> >So I turned on id_provider, then explicitly turned off all providers I >> >don’t want. Is this correct? >> > >> > >> > >> >[domain/LDAP] >> > >> >debug_level = 9 >> > >> >#id_provider = none >> > >> >id_provider = ldap >> > >> >auth_provider = none >> > >> >account_provider = none >> > >> >chpass_provider = none >> > >> >sudo_provider = none >> > >> >subdomains_provider = none >> > >> >autofs_provider = ldap >> > >> > >> > >> >Also, any particular reason there’s not a netgroup_provider? >> > >> >> Because netgroups are part of id_provider >> The same as users, groups and service. (There is neither user_provider nor >> group_provider ...) >> >> If you want to provide just netgroups then you might set sssd options >> ldap_user_search_base and ldap_group_search_base( >> ldap_service_search_base) >> to the part of LDAP tree which does not contain any users/groups. >> >> >> >BTW, retrieving netgroups via sssd does not seem explicitly and >> concretely >> >documented. That is, I had to consult multiple sources to get the RFC >> >2307bis setup, another to get the sssd.conf settings. (I’m not >> faulting >> >anyone; netgroups are rarely used anymore.) >> > >> > >> Netgroups are retrieved by default if you have standard nisSchema[0] in >> your LDAP >> server. >> >> [domain/$DOMAIN] >> ldap_search_base = $BASE_DN >> id_provider = ldap >> ldap_uri = ldap://$SERVER >> ldap_tls_cacert = /etc/openldap/certs/cacert.asc >> >> >> LS >> >> [1] https://docs.oracle.com/cd/E36784_01/html/E38254/appendixa-3.html >> _______________________________________________ >> sssd-users mailing list -- [email protected] >> To unsubscribe send an email to [email protected] >> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html >> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines >> List Archives: >> https://lists.fedorahosted.org/archives/list/[email protected] >> >
_______________________________________________ sssd-users mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/[email protected]
