Like Spike said, there are two separate but related things here. The Kerberos
portion and the AD account password portion.
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, but it is likely since the actual account name in AD has the $
and would likely return the 'not found in the database' error message without
it.
A valid Kerberos identity and ticket tells AD that this entity is who they say
they are. This allows all of the other domain related activities happen,
changing the account password, updating dynamic DNS, etc. those activities are
done through using Kerberos to validate that that context can do those things.
The AD account password rotation is separate from that and is, by default,
required to rotate every 30 days. (you can turn it off if you want to, in AD)
In the 1.x days of SSSD and the I think .7 days of adcli this wasn't handled
super great, Kerberos tickets would expire and then AD couldn't validate the
computer was who it said it was, so AD denied the right to change the account
password, and viola, computer falls off domain.
Kinit -k -R <shorthostname>$ as root back then kept the Kerberos ticket for the
computer account valid and didn't let it expire, there by allowing whatever
other process that was changing the computer account password to successfully
complete.
It sounds now though that some of these things may be incorporated into SSSD
2.x now. SSSD wakes up to check the computer account password, and it might
wake up to check the Kerberos ticket validity too with the right option,
negating the need for a separate cron job to do either now. I haven't kept up
with it enough to know off the top of my head though.
Todd
-----Original Message-----
From: Patrick Goetz <pgo...@math.utexas.edu>
Sent: Wednesday, September 8, 2021 11:05 AM
To: sssd-users@lists.fedorahosted.org
Subject: [SSSD-users]Re: Trouble-shooting sssd’s ‘Automatic Kerberos Host
Keytab Renewal’ with AD back-end….
Hi Spike -
Thanks for this clarification. Now I'm wondering what happens when you run
`kinit -k -R HOST$` which was our previous cron job solution to linux machines
losing their AD connections. Switching to
`msktutil --update --computer-name HOST`
Modulo my ongoing confusion about when you need to include the $ in the host
name and when you don't, this seems to have mostly resolved that issue. Since
msktutil --update is updating the password, one would think we shouldn't need
this, given the every 24-hour adcli thing, but prior to this all the Ubuntu
hosts would routinely drop out of AD every month, so it's still not clear what
is going on. Based on a previous examination of the log files, the password
was expiring, so maybe adcli can't run for some reason? Maybe the problem is
we're using an older version of sssd? Even on the Ubuntu 20.04 machines the
sssd version is 2.2.3.
All that said, the kinit man page is awfully confusing and could use a rewrite.
The -R flag explicitly mentions renewing a TGT, while the -k flag just talks
about renewing a ticket. Tickets and TGT's are not the same thing in Kerberos.
--------------------------------------
-R
requests renewal of the ticket-granting ticket. Note that
an expired ticket cannot be renewed, even if the ticket is still within
its renew‐ able life.
Note that renewable tickets that have expired as reported by
klist(1) may sometimes be renewed using this option, because the KDC
applies a grace period to account for client-KDC clock skew. See
krb5.conf(5) clockskew setting.
-k [-i | -t keytab_file]
requests a ticket, obtained from a key in the local host's
keytab. The location of the keytab may be specified with the -t
keytab_file option, or with the -i option to specify the use of the
default client keytab; otherwise the default keytab will be used. By
default, a host ticket for the local host is requested, but any principal
may be specified. On a KDC, the special keytab location KDB:
can be used to indicate that kinit should open the KDC database and
look up the key directly. This permits an administrator to obtain
tickets as any principal that supports authen‐ tication based on
the key.
--------------------------------------
On 9/7/21 1:40 PM, Spike White wrote:
> Patrick,
>
> kinit -k acquires a new fresh TGT ticket.
>
> kinit -R renews an existing TGT ticket (if it's not already expired).
> Even if renewed, "renew until" doesn't change (usually 7 days).
>
> None of these are updating any computer account password on AD.
> That's an AD-specific requirement, that machines update their machine
> account passwords every 40 days or be locked out.
>
> sssd wakes up every 24 hrs by default (controlled by
> ad_machine_account_password_renewal_opts). It checks to see if
> machine account password is older than
> ad_maximum_machine_account_password_age
> (default 30 days). If it's < 30 days, sssd do nothing. If 31 days or
> greater, it calls adcli update with various flags. to update the
> machine account password.
>
> Spike
>
> On Tue, Sep 7, 2021 at 9:53 AM Patrick Goetz <pgo...@math.utexas.edu
> <mailto:pgo...@math.utexas.edu>> wrote:
>
>
>
> On 9/6/21 4:49 AM, Sumit Bose wrote:
> > Am Thu, Sep 02, 2021 at 10:02:54AM -0500 schrieb Patrick Goetz:
> >>
> >> On 9/2/21 12:49 AM, Sumit Bose wrote:
> >>> The reason is that 'kinit -k' constructs the principal by calling
> >>> gethostname() or similar, adding the 'host/' prefix and the
> realm. But
> >>> by default this principal in AD is only a service principal can
> cannot
> >>> be used to request a TGT as kinit does. AD only allows user
> principals
> >>> for request a TGT and this is by default 'SHORT$@AD.REALM'. If the
> >>> userPrincipalName attribute is set, this principal given here
> is allowed
> >>> as well.
> >>>
> >>
> >> This raises a couple of questions. Because of AD's flat address
> space, we
> >> use a host naming convention in AD as a sort of low rent
> namespacing; so,
> >> for example, for this host the college is cns and the research
> group cryo,
> >> so the AD hostname is cns-cryo-ross1$
> >>
> >> However,
> >>
> >> # hostname
> >> rossmann.biosci.utexas.edu <http://rossmann.biosci.utexas.edu>
> >>
> >>
> >> which is easier for the users to remember for ssh purposes. We set
> >>
> >> ad_hostname = cns-cryo-ross1.austin.utexas.edu
> <http://cns-cryo-ross1.austin.utexas.edu>
> >>
> >> in /etc/sssd/sssd.conf.
> >>
> >> But I just checked, and kinit does not use ad_hostname, so I
> have to run it
> >> as
> >>
> >> kinit -k -R cns-cryo-ross1$
> >>
> >> The question is, then what does use the ad_hostname key/value pair?
> >>
> >> Next, the kinit example provided by Spike was `kinit -k` -- we
> always run
> >> `kinit -k -R`
> >>
> >> -R renews the TGT, which is what I thought is the thing set to
> expire in AD
> >> that needs to be periodically renewed. What's the purpose of
> running `kinit
> >> -k` without the -R?
> >
> > Hi,
> >
> > there are two different things.
> >
> > First, there are the host keys in the keytab which are equivalent
> to a
> > user password. Those keys are renewed by 'adcli update' if they are
> > older then 30 days, similar as you would renew you user password
> if the
> > AD DC tells you to do it.
> >
> > Second, with those keys you can request a Kerberos TGT
> >
> > kinit -k 'shortname$'
> >
>
> I thought, based on the kinit man page, that the -k flag is just an
> ordinary ticket request and that you need to add the -R flag to request
> a TGT. What you're saying is it also renews the TGT?
>
> OTOH I thought `kinit -k` was updating the computer account password on
> the domain controller, but that doesn't seem to be the case, in which
> case I'm not even sure what the purpose of an ordinary (non-TGT) ticket
> is if you're not requesting automatic login to some specifically
> requested service.
>
> Also, just to make sure I'm clear on this, the "renew until" doesn't
> change because this is based on the computer account password
> expiration, and further that sssd runs `adcli update` for you
> periodically? How often, by the way?
>
>
> > as you can do with your user password:
> >
> > kinit user@REALM
> > Password for user@REALM
> >
> > This TGT has a lifetime and it might have a renewal time as well:
> >
> > # klist
> > Ticket cache: KCM:0:69840
> > Default principal: administra...@child.ad.vm
> >
> > Valid starting Expires Service principal
> > 09/06/2021 09:39:28 09/06/2021 19:39:28
> krbtgt/child.ad...@child.ad.vm
> > renew until 09/07/2021 09:39:24
> >
> >
> > In the example above the TGT will expire at '09/06/2021 19:39:28' but
> > can be renewed until '09/07/2021 09:39:24'. This means that if
> you call
> >
> > kinit -R
> >
> > before '09/06/2021 19:39:28' you will get a fresh TGT without
> entering
> > your password. The new TGT will have a new lifetime but 'renew until'
> > will stay the same. After '09/07/2021 09:39:24' 'kinit -R' will
> not work
> > anymore and you have to enter your password again. It does not matter
> > here if the TGT was originally requested with a keytab with
> 'kinit -k'
> > or with plain 'kinit' and a password.
> >
> > However, since the keytab is present in the file system calling
> >
> > kinit -k 'shortname$'
> >
> > will always get a fresh TGT without manual intervention. So in
> case you
> > have a valid keytab this is even more flexible than 'kinit -R'
> >
> > HTH
> >
> > bye,
> > Sumit
> >
> >>
> >> _______________________________________________
> >> sssd-users mailing list -- sssd-users@lists.fedorahosted.org
> <mailto:sssd-users@lists.fedorahosted.org>
> >> To unsubscribe send an email to
> sssd-users-le...@lists.fedorahosted.org
> <mailto:sssd-users-le...@lists.fedorahosted.org>
> >> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> <https://docs.fedoraproject.org/en-US/project/code-of-conduct/>
> >> List Guidelines:
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> <https://fedoraproject.org/wiki/Mailing_list_guidelines>
> >> List Archives:
>
> https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
>
> <https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org>
> >> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
> <https://pagure.io/fedora-infrastructure>
> > _______________________________________________
> > sssd-users mailing list -- sssd-users@lists.fedorahosted.org
> <mailto:sssd-users@lists.fedorahosted.org>
> > To unsubscribe send an email to
> sssd-users-le...@lists.fedorahosted.org
> <mailto:sssd-users-le...@lists.fedorahosted.org>
> > Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> <https://docs.fedoraproject.org/en-US/project/code-of-conduct/>
> > List Guidelines:
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> <https://fedoraproject.org/wiki/Mailing_list_guidelines>
> > List Archives:
>
> https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
>
> <https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org>
> > Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
> <https://pagure.io/fedora-infrastructure>
> >>> This message is from an external sender. Learn more about why
> this <<
> >>> matters at https://links.utexas.edu/rtyclf
> <https://links.utexas.edu/rtyclf>. <<
> _______________________________________________
> sssd-users mailing list -- sssd-users@lists.fedorahosted.org
> <mailto:sssd-users@lists.fedorahosted.org>
> To unsubscribe send an email to
> sssd-users-le...@lists.fedorahosted.org
> <mailto:sssd-users-le...@lists.fedorahosted.org>
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> <https://docs.fedoraproject.org/en-US/project/code-of-conduct/>
> List Guidelines:
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> <https://fedoraproject.org/wiki/Mailing_list_guidelines>
> List Archives:
>
> https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
>
> <https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org>
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
> <https://pagure.io/fedora-infrastructure>
>
>
> _______________________________________________
> sssd-users mailing list -- sssd-users@lists.fedorahosted.org To
> unsubscribe send an email to sssd-users-le...@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.fedoraho
> sted.org 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@lists.fedorahosted.org To unsubscribe
send an email to sssd-users-le...@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.org
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@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@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.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
