Re: Trouble-shooting sssd’s ‘Automatic Kerberos Host Keytab Renewal’ with AD back-end….
by Patrick Goetz
So i think you just want:
kinit -R -k $HOSTNAME$
On 8/30/21 11:28 AM, Mote, Todd wrote:
> I wrote that from memory. What's needed is the shortname and a $, but thinking more about it now, that's needed at the end of the shortname not the beginning.
>
> -----Original Message-----
> From: Patrick Goetz <pgoetz(a)math.utexas.edu>
> Sent: Monday, August 30, 2021 11:25 AM
> To: sssd-users(a)lists.fedorahosted.org
> Subject: [SSSD-users]Re: Trouble-shooting sssd’s ‘Automatic Kerberos Host Keytab Renewal’ with AD back-end….
>
> Todd,
>
> On 8/27/21 9:41 AM, Mote, Todd wrote:
>> We ultimately decided to deploy a cron job with the install that ran periodically (less than the renewal period) to keep the keytab fresh (kinit -R -k $($hostname -s)). We haven't had computers falling off the domain since we implemented that.
>>
>
> Are you sure about this syntax? Adding a -s flag in $( ) containing a bash variable doesn't do anything.
>
> _______________________________________________
> sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave(a)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.fedorahoste...
> Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
>>> This message is from an external sender. Learn more about why this <<
>>> matters at https://links.utexas.edu/rtyclf. <<
> _______________________________________________
> sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-leave(a)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.fedorahoste...
> Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
>>> This message is from an external sender. Learn more about why this <<
>>> matters at https://links.utexas.edu/rtyclf. <<
2 years, 7 months
SOLVED: automounts in non-local AD domain....
by Spike White
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
2 years, 7 months