JDK-8227437 : S4U2proxy cannot continue because server's TGT cannot be found
  • Type: Bug
  • Component: security-libs
  • Sub-Component: org.ietf.jgss:krb5
  • Affected Version: 11,13
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2019-07-09
  • Updated: 2021-01-14
  • Resolved: 2019-07-18
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 11 JDK 13 JDK 14 JDK 8 Other
11.0.6Fixed 13 b31Fixed 14Fixed 8u270Fixed openjdk8u242Fixed
Related Reports
Relates :  
JDK-8227381 - GSS login fails with PREAUTH_FAILED
Relates :  
JDK-8215032 - Support Kerberos cross-realm referrals (RFC 6806)
Relates :  
JDK-8256659 - Incorrect parsing of krb5 username
Description
With JDK-8215032, if the intermediate server name is an alias, its TGT would have a different client name. When the server is about to perform a S4U2proxy request, it needs to find its TGT first. However, since the TGT have a different name SubjectComber::find will not find it and thus S4U2proxy fails..
Comments
Fix request (11u) 11u is affected by this bug after the backport of 8215032. This is a critical bug fix that we need in 11u. Patch does not apply cleanly so I'll go through a review process. Proposed webrev: http://cr.openjdk.java.net/~mbalao/webrevs/8227437/8227437.jdk11u.webrev.00/ Review request: http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-November/002099.html
19-11-2019
This patch has a regression test for the corresponding fix.
26-07-2019
URL: https://hg.openjdk.java.net/jdk/jdk13/rev/643978a35f6e User: weijun Date: 2019-07-18 00:54:18 +0000
18-07-2019
A similar bug happens when there is a server side referral. The service ticket has a different name, so when a second security context is initiated, the cached service ticket in Subject cannot be located and a new TGS-REQ must be sent. Although the ticket can be acquired again successfully, this is waste of time and resource.
10-07-2019