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 <pgoetz(a)math.utexas.edu>
Sent: Wednesday, September 8, 2021 11:05 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….
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 <pgoetz(a)math.utexas.edu
<mailto:pgoetz@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$(a)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: Administrator(a)CHILD.AD.VM
>
> Valid starting Expires Service principal
> 09/06/2021 09:39:28 09/06/2021 19:39:28
krbtgt/CHILD.AD.VM(a)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(a)lists.fedorahosted.org
<mailto:sssd-users@lists.fedorahosted.org>
>> To unsubscribe send an email to
sssd-users-leave(a)lists.fedorahosted.org
<mailto:sssd-users-leave@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.fedorahoste...
<
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
<
https://pagure.io/fedora-infrastructure>
> _______________________________________________
> sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
<mailto:sssd-users@lists.fedorahosted.org>
> To unsubscribe send an email to
sssd-users-leave(a)lists.fedorahosted.org
<mailto:sssd-users-leave@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.fedorahoste...
<
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
<
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(a)lists.fedorahosted.org
<mailto:sssd-users@lists.fedorahosted.org>
To unsubscribe send an email to
sssd-users-leave(a)lists.fedorahosted.org
<mailto:sssd-users-leave@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.fedorahoste...
<
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
<
https://pagure.io/fedora-infrastructure>
_______________________________________________
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.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(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. <<