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