Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8270137

Kerberos Credential Retrieval from Cache not Working in Cross-Realm Setup

    XMLWordPrintable

    Details

    • Subcomponent:
    • Resolved In Build:
      b11
    • CPU:
      generic
    • OS:
      generic
    • Verification:
      Not verified

      Backports

        Description

        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


          Attachments

            Issue Links

              Activity

                People

                Assignee:
                mbalao Martin Balao
                Reporter:
                webbuggrp Webbug Group
                Votes:
                0 Vote for this issue
                Watchers:
                7 Start watching this issue

                  Dates

                  Created:
                  Updated:
                  Resolved: