and will refuse to renew existing service tickets and TGTs. Windows clients*How does this patch affect third-party Kerberos clients?*
When the registry key is set to 1, patched domain controllers will issue service tickets and Ticket-Granting Tickets (TGT)s that are not renewable
Luke Hebert <lhebert@cloudera.com> writes:
Hi,
Disabling service
ticket and tgt renewability is not great and it obviously breaks long
running processes that rely on renewability of these items.
and will refuse to renew existing service tickets and TGTs. Windows clients >> are not impacted by this since they never renew service tickets or TGTs.*How does this patch affect third-party Kerberos clients?*
When the registry key is set to 1, patched domain controllers will issue >> service tickets and Ticket-Granting Tickets (TGT)s that are not renewable
Third-party Kerberos clients may fail to renew service tickets or TGTs
acquired from unpatched DCs. If all DCs are patched with the registry set
to 1, third-party clients will no longer receive renewable tickets.
You're correct that Microsoft has not released details on this issue.
They have indicated that some failures are a known issue, and claim to
be working on a fix: https://docs.microsoft.com/en-us/windows/release-information/status-windows-10-20h2#1522msgdesc
Hi,
We've just started encountering problems at customer sites with Kerberos enabled clients as a result of how Microsoft appears to be approaching CVE-2020-17049 <https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-17049>. The
details on this CVE are slim on Mitre and there is a small amount of additional information on the microsoft portal. I thought I'd ask the list what their thoughts are on what is being done here. Disabling service
ticket and tgt renewability is not great and it obviously breaks long
running processes that rely on renewability of these items. I'm sure we
could move to an alternate approach where we do not renew these items but rather obtain a new one but the changes are likely non-trivial across many different projects.
https://msrc.microsoft.com/update-guide/vulnerability/CVE-2020-17049
*How does this patch affect third-party Kerberos clients?*
service tickets and Ticket-Granting Tickets (TGT)s that are not renewableWhen the registry key is set to 1, patched domain controllers will issue
and will refuse to renew existing service tickets and TGTs. Windows clients are not impacted by this since they never renew service tickets or TGTs. Third-party Kerberos clients may fail to renew service tickets or TGTs acquired from unpatched DCs. If all DCs are patched with the registry set
to 1, third-party clients will no longer receive renewable tickets.
Hi,
We've just started encountering problems at customer sites with Kerberos enabled clients as a result of how Microsoft appears to be approaching CVE-2020-17049 <https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-17049>. The
details on this CVE are slim on Mitre and there is a small amount of additional information on the microsoft portal. I thought I'd ask the list what their thoughts are on what is being done here. Disabling service
ticket and tgt renewability is not great and it obviously breaks long
running processes that rely on renewability of these items. I'm sure we
could move to an alternate approach where we do not renew these items but rather obtain a new one but the changes are likely non-trivial across many different projects.
https://msrc.microsoft.com/update-guide/vulnerability/CVE-2020-17049
*How does this patch affect third-party Kerberos clients?*
and will refuse to renew existing service tickets and TGTs. Windows clients are not impacted by this since they never renew service tickets or TGTs. Third-party Kerberos clients may fail to renew service tickets or TGTs acquired from unpatched DCs. If all DCs are patched with the registry setWhen the registry key is set to 1, patched domain controllers will issue service tickets and Ticket-Granting Tickets (TGT)s that are not renewable
to 1, third-party clients will no longer receive renewable tickets.
*--Luke Hebert* |
cloudera.com <https://www.cloudera.com> ________________________________________________
Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
On 11/17/20 12:53 PM, Jeffrey Altman wrote:
Just to set the record straight, Kerberos service tickets have never
been renewable unless they were obtained as initial tickets. Only
TGTs are renewable. This is true for MIT and Heimdal as well as
Active Directory.
Both initial and non-initial non-TGTs are renewable with MIT krb5:
$ make testrealm
$ kadmin.local modprinc -maxrenewlife 1d host/small-gods
$ kadmin.local modprinc -maxrenewlife 1d user
$ kadmin.local modprinc -maxrenewlife 1d krbtgt/KRBTEST.COM
$ kinit -S host/small-gods -l 10m -r 20m
Password for user@KRBTEST.COM:
$ kinit -R -S host/small-gods
$ kinit -l 10m -r 20m user
Password for user@KRBTEST.COM:
$ kvno host/small-gods
host/small-gods@KRBTEST.COM: kvno = 1
$ kinit -R -S host/small-gods
$
There is even a messaging service at MIT that makes use of renewable
service tickets.
Prior to release 1.9 the MIT krb5 KDC supported renewing service
tickets, but the client library did not: https://krbdev.mit.edu/rt/Ticket/Display.html?id=6699 .
It used to be the case that "kinit -r" would fail if the requested
principal was "disallow-renewable". I don't remember if it was because
the KDC refused to issue any ticket when renewable was requested or if
it was the client library rejecting the ticket because it didn't satisfy
the request.
That was KDC-side. For MIT krb5, the KDC behavior changed in release
1.12 to just issue a non-renewable ticket in this case.
On 11/17/20 12:53 PM, Jeffrey Altman wrote:
Just to set the record straight, Kerberos service tickets have never
been renewable unless they were obtained as initial tickets. Only
TGTs are renewable. This is true for MIT and Heimdal as well as
Active Directory.
Both initial and non-initial non-TGTs are renewable with MIT krb5:
$ make testrealm
$ kadmin.local modprinc -maxrenewlife 1d host/small-gods
$ kadmin.local modprinc -maxrenewlife 1d user
$ kadmin.local modprinc -maxrenewlife 1d krbtgt/KRBTEST.COM
$ kinit -S host/small-gods -l 10m -r 20m
Password for user@KRBTEST.COM:
$ kinit -R -S host/small-gods
$ kinit -l 10m -r 20m user
Password for user@KRBTEST.COM:
$ kvno host/small-gods
host/small-gods@KRBTEST.COM: kvno = 1
$ kinit -R -S host/small-gods
$
There is even a messaging service at MIT that makes use of renewable
service tickets.
Prior to release 1.9 the MIT krb5 KDC supported renewing service
tickets, but the client library did not: https://krbdev.mit.edu/rt/Ticket/Display.html?id=6699 .
It used to be the case that "kinit -r" would fail if the requested
principal was "disallow-renewable". I don't remember if it was because
the KDC refused to issue any ticket when renewable was requested or if
it was the client library rejecting the ticket because it didn't satisfy
the request.
That was KDC-side. For MIT krb5, the KDC behavior changed in release
1.12 to just issue a non-renewable ticket in this case.
Just to set the record straight, Kerberos service tickets have never
been renewable unless they were obtained as initial tickets. Only
TGTs are renewable. This is true for MIT and Heimdal as well as
Active Directory.
It used to be the case that "kinit -r" would fail if the requested
principal was "disallow-renewable". I don't remember if it was because
the KDC refused to issue any ticket when renewable was requested or if
it was the client library rejecting the ticket because it didn't satisfy
the request.
We've just started encountering problems at customer sites with
Kerberos enabled clients as a result of how Microsoft appears to be approaching CVE-2020-17049 <https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-17049>. The
details on this CVE are slim on Mitre and there is a small amount of additional information on the microsoft portal. I thought I'd ask
the list what their thoughts are on what is being done here.
Disabling service ticket and tgt renewability is not great and it
obviously breaks long running processes that rely on renewability of
these items.
From packet tracing, the TGS-REQ packet contains the following options:
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 296 |
Nodes: | 16 (2 / 14) |
Uptime: | 36:29:51 |
Calls: | 6,648 |
Calls today: | 3 |
Files: | 12,193 |
Messages: | 5,329,035 |