ADDITIONAL SYSTEM INFORMATION :
We tried both:
openjdk version "1.8.0_292"
OpenJDK Runtime Environment (AdoptOpenJDK)(build 1.8.0_292-b10)
OpenJDK 64-Bit Server VM (AdoptOpenJDK)(build 25.292-b10, mixed mode)

and

openjdk version "11.0.11" 2021-04-20
OpenJDK Runtime Environment AdoptOpenJDK-11.0.11+9 (build 11.0.11+9)
OpenJDK 64-Bit Server VM AdoptOpenJDK-11.0.11+9 (build 11.0.11+9, mixed mode)

We encounter the same problem in both versions.


What is your operating system and platform?
Windows Server 2016 Datacenter

A DESCRIPTION OF THE PROBLEM :
We have the problem that with Kerberos constrained delegation in a cross-realm setup, the first request succeeds, while subsequent requests fail. We found that this is due to the usage of tickets retrieved from the referrals cache. We pasted a patch to the workaround field that fixes the problem for us by not retrieving tickets from the cache for Proxy requests. We successfully tested the patch in JDK 1.8.0_292.

Duplicate of:
https://github.com/adoptium/adoptium-support/issues/318

Related implementation:
https://bugs.openjdk.java.net/browse/JDK-8005819

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Setup:
Our setup is a double-hop consisting of:
client@REALM1
middleware@REALM1
backend@REALM2

The client requests our middleware where the problem occurs. The middleware is allowed to perform resource-based constrained delegation and requests the backend in the name of the client using S4U2PROXY.

The problem occurs when the backend is in another realm than the middleware. If both are in the same realm, everything works fine.

Steps to reproduce:
1. The client requests the middleware. The middleware receives a ticket for constrained delegation to the backend and requests it on behalf of the client. This step succeeds and the backend returns a proper response to the middleware.
2. The client requests the middleware for a second time. Now the middleware retrieves its credentials from the referrals cache, but does not get a valid Kerberos ticket.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Subsequent requests to the backend shall succeed like the first request does.
ACTUAL -
Instead it reports these error messages:


            KRBError:
            sTime is Tue Jun 01 14:03:37 CEST 2021 1622549017000
            suSec is 204909
            error code is 28
            error Message is null
            sname is HTTP/backend@REALM2
            msgType is 30

and

            KRBError:
            sTime is Tue Jun 01 14:03:37 CEST 2021 1622549017000
            suSec is 201727
            error code is 13
            error Message is KDC cannot accommodate requested option
            sname is HTTP/backend@REALM1
            eData provided.
            msgType is 30

When we look into the first error message with Wireshark, we found the error to be:
KRB5KRB_AP_PATH_NOT_ACCEPTED

When remote-debugging into the code of CredentialsUtil.java we see that on the first request Credentials of type Proxy are not stored but the ones with None are. A comment in the code explicitly states that Credentials for Proxy should not be cached. However, in the second search request, the Credentials for Proxy are retrieved from the Cache. We think this contradicts the warning in the comment, as this is basically a caching of Proxy credentials. Our patch that does not retrieve credentials from the cache for Proxy requests aligns with that comment.

CUSTOMER SUBMITTED WORKAROUND :
Index: jdk/src/share/classes/sun/security/krb5/internal/CredentialsUtil.java
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===================================================================
diff --git a/jdk/src/share/classes/sun/security/krb5/internal/CredentialsUtil.java b/jdk/src/share/classes/sun/security/krb5/internal/CredentialsUtil.java
--- a/jdk/src/share/classes/sun/security/krb5/internal/CredentialsUtil.java	(revision 64cc2bc73816f3e0a91776805482fee37fa37bbe)
+++ b/jdk/src/share/classes/sun/security/krb5/internal/CredentialsUtil.java	(revision 64d47cc41dd481115f45da407318a9516f68bb28)
@@ -362,6 +362,7 @@
         PrincipalName clientAlias = asCreds.getClientAlias();
         while (referrals.size() <= Config.MAX_REFERRALS) {
             ReferralsCache.ReferralCacheEntry ref =
+                    s4u2Type != S4U2Type.NONE ? null :
                     ReferralsCache.get(cname, sname, refSname.getRealmString());
             String toRealm = null;
             if (ref == null) {


FREQUENCY : always