[cifs-protocol] [EXTERNAL] KERB-ERROR-DATA code 136 - TrackingID#2209120040006251

[Michael Bowen]

[DocHelp to bcc]

Hi Julien,

Thank you for contacting Microsoft Open Specification Support. We created case number 2209120040006251 for this inquiry. Please leave the case number in the subject line and cc supportmail at microsoft.com when responding to emails. One of our team members will follow up with you soon.

Mike Bowen
Escalation Engineer - Microsoft Open Specifications

-----Original Message-----
From: Julien Rische <jrische at redhat.com> 
Sent: Monday, September 12, 2022 7:01 AM
To: Interoperability Documentation Help <dochelp at microsoft.com>
Cc: cifs-protocol at lists.samba.org
Subject: [EXTERNAL] KERB-ERROR-DATA code 136

[Some people who received this message don't often get email from jrische at redhat.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]

Hello team,

We are experiencing Active Directory interoperability issues for the MIT Kerberos 1.20 release, which is introducing generation of PAC for all tickets by default. There are two scenarios:

* Cross-realm AD TGS request from an MIT Kerberos client (realm trust)[1]
* Cross-realm S4U2Self request for a FreeIPA service to impersonate an AD user
  (forest trust)[2]

In both cases, a TGS-REQ[3][4] against AD using the cross-realm TGT results in a generic error (MS-SFU 4.2 step 3[5] in S4U2Self case). We suspect these two failures may have the same underlying cause, because of the "e-data" attribute from the KRB_ERR_GENERIC message[6][7]:

SEQUENCE {
  SEQUENCE {
    [1] {
      INTEGER 136
      }
    [2] {
      OCTET STRING
        ...
      }
    }
  }

The octet string is different, but the integer is the same in both scenarios.
According to the MS-KILE specification, this piece of data should be a KERB-ERROR-DATA structure[8]. However the 136 integer do not match any of the documented "data-type" values.

This error is most likely related to the PAC, because in the realm trust case, the cross-realm TGS-REQ works in case PAC support is disable on the MIT KDC (i.e. the MIT TGT does not contain a PAC).

Could you please give us more details about KERB-ERROR-DATA code 136, and check if you see anything wrong in the PACs that are being used in these 2 scenarios?

--
Julien Rische
Software Engineer
Red Hat


[1] krb5_1_20_mit_ad_realm_trust.(pcap|keytab) files in attachment [2] krb5_1_20_ipa_ad_trust_s4u2self.(pcapng|keytab) files in attachment [3] krb5_1_20_mit_ad_realm_trust.pcap packet no. 7 [4] krb5_1_20_ipa_ad_trust_s4u2self.pcapng packet no. 11 [5] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fopenspecs%2Fwindows_protocols%2Fms-sfu%2Ff35b6902-6f5e-4cd0-be64-c50bbaaf54a5&data=05%7C01%7CMike.Bowen%40microsoft.com%7C6c7d4e5a876b4e3e653c08da94c736c5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637985880853223939%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=WkHZJvMIg4DfpzOOzy%2FG61k54%2FGqnpKJ10xWgu%2FMfjQ%3D&reserved=0
[6] e-data in krb5_1_20_mit_ad_realm_trust.pcap packet no. 8 or krb5_1_20_mit_ad_realm_trust_edata.blob in attachment [7] e-data in krb5_1_20_ipa_ad_trust_s4u2self.pcapng packet no. 12 or krb5_1_20_ipa_ad_trust_s4u2self_edata.blob in attachment [8] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fopenspecs%2Fwindows_protocols%2Fms-kile%2F25fabd02-560d-4c1f-8f42-b32e9d97996a&data=05%7C01%7CMike.Bowen%40microsoft.com%7C6c7d4e5a876b4e3e653c08da94c736c5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637985880853223939%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=pw7II8Yx7PAC9Pau1nyFYqBV6PnunDGTK71wgSs2i7c%3D&reserved=0