SOLVED: find automount maps in non-local AD domain. All,
We solved this a couple of months ago; just took a while to get time to write it up. We have automounts in our AD domains and autofs finds them. By default, autofs always looks in the local domain for its automount maps. We have an AD forest with 3 trusted regional subdomains. Parent COMPANY.COM, with children: AMER.COMPANY.COM, APAC.COMPANY.COM and EMEA.COMPANY.COM. For boring historical reasons, we have all our automount maps in AMER child domain. That works great for Linux servers in AMER. But what about servers in APAC and EMEA? You could replicate your automounts in all 3 child domains, but this is tedious and error-prone. Instead, you have to modify their sssd.conf file to coerce them to look in AMER for the automount maps. So for servers in AMER, the sssd.conf file is pretty straightforward: … [sssd] …. domains = amer.company.com domain_resolution_order = amer.company.com, emea.company.com, apac.company.com, company.com … services = nss,pam,ifp,autofs …. [autofs] [domain/amer.company.com] id_provider = ad autofs_provider = ad ldap_autofs_search_base = ou=automount,ou=UNIX,dc=AMER,dc=COMPANY,dc=COM access_provider = simple auth_provider = ad ldap_sasl_authid = <fqdn>@AMER.COMPANY.COM … simple_allow_groups = … # look at https://docs.pagure.org/SSSD.sssd/design_pages/subdomain_configuration.html [domain/amer.company.com/company.com] ldap_search_base = dc=COMPANY,dc=COM [domain/amer.company.com/apac.company.com] ldap_search_base = dc=APAC,dc=COMPANY,dc=COM [domain/amer.company.com/emea.company.com] ldap_search_base = dc=EMEA,dc=COMPANY,dc=COM (Technically we don’t even need ldap_search_base for each child domain. Sssd will look it up from each AD domain’s rootDSE. But explaining to the average Linux SE what is an AD rootDSE and how to perform a rootDSE search to verify the search base? That’s complicated. It’s easier just to put ldap_search_base in for each child domain.) Ok, so then for an EMEA sssd.conf, we have to invent a new sssd domain purely for autofs. That new sssd domain is associated with the AMER child AD domain and the only provider it provides is the autofs_provider. [sssd] domains = emea.company.com, amer.autofs … domain_resolution_order = emea.company.com, amer.company.com, apac.company.com, company.com services = nss,pam,ifp,autofs … [autofs] [domain/emea.company.com] … id_provider = ad auth_provider = ad autofs_provider = none … ldap_sasl_authid = <fqdn>@EMEA.COMPANY.COM ldap_search_base = dc=EMEA,dc=COMPANY,dc=COM … simple_allow_groups = … # look at https://docs.pagure.org/SSSD.sssd/design_pages/subdomain_configuration.html [domain/emea.company.com/company.com] ldap_search_base = dc=COMPANY,dc=COM [domain/emea.company.com/apac.company.com] ldap_search_base = dc=APAC,dc=COMPANY,dc=COM [domain/emea.company.com/amer.company.com] ldap_search_base = dc=AMER,dc=COMPANY,dc=COM [domain/amer.autofs] id_provider = none dns_discovery_domain = amer.company.com autofs_provider = ldap ldap_sasl_mech = GSSAPI ldap_sasl_authid = <fqdn>@EMEA.COMPANY.COM krb5_server = ORKDC16EMEA02.emea.company.com, ATHDC16EMEA02.emea.company.com, ORKDC16EMEA01.emea.company.com The “secret sauce” is in this krb5_servers line for this autofs sssd domain. All the other lines in this autofs AD domain make sense; it’s not clear why this krb5_server line is required (but it is). Spike
_______________________________________________ sssd-users mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected] Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
