sssd-users September 2021

sssd-users@lists.fedorahosted.org

9 participants
13 discussions

Re: Trouble-shooting sssd’s ‘Automatic Kerberos Host Keytab Renewal’ with AD back-end….
by James Ralston 09 Sep '21

09 Sep '21

On 2021-09-08 at 14:18-0400 Todd Mote <moter(a)austin.utexas.edu> wrote: > The $ at the end of the host name is for AD. <short hostname>$ is > the actual name of the account in AD. The Kerberos utilities are > just asking the KDC to renew tickets for accounts. Computer > accounts in AD happen to have a $ appended to them under the covers. > They are obfuscated from most human views. Msktutil may be > appending the $ under its covers, you'd have to examine the source > to know From the msktutil man page: --computer-name <name> Specifies that the new account should use <name> for the computer account name and the SAM Account Name. Note that a '$' will be automatically appended to the SAM Account Name. Defaults to the machine's hostname, excluding the realm, with dots replaced with dashes. That is: if the realm is EXAMPLE.COM, and the hostname is FOO.EXAMPLE.COM, the default computer name is FOO. If the hostname is FOO.BAR.EXAMPLE.COM, the default computer name is FOO-BAR. --account-name <name> An alias for --computer-name that can be used when operating on service accounts. Note that a '$' will not be automatically appended to the SAM Account Name when using service accounts. We love msktutil (including its magnificent man page); it is our preferred mechanism for joining hosts to AD.

1 0

Re: Trouble-shooting sssd’s ‘Automatic Kerberos Host Keytab Renewal’ with AD back-end….
by Patrick Goetz 08 Sep '21

08 Sep '21

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.fedorahosted.… > 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.fedorahosted.… > 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. <<

5 16

SOLVED: automounts in non-local AD domain....
by Spike White 06 Sep '21

06 Sep '21

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 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

sssd-users September 2021