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

Jeff McCashland (He/him) jeffm at microsoft.com
Tue Sep 13 19:15:10 UTC 2022

[Michael to BCC]

Hi Julien,

I will reply again in an hour or two with instructions to collect and upload traces for the scenario. This will be the best way to determine the actual root cause of the error. Let's start with the first scenario, then if that answer does not resolve the second scenario, we'll create a new SR case and collect additional traces. 

Best regards,
Jeff McCashland (He/him) | Senior Escalation Engineer | Microsoft Protocol Open Specifications Team 
Phone: +1 (425) 703-8300 x38300 | Hours: 9am-5pm | Time zone: (UTC-08:00) Pacific Time (US and Canada)
Local country phone number found here: http://support.microsoft.com/globalenglish | Extension 1138300

-----Original Message-----
From: Michael Bowen <Mike.Bowen at microsoft.com> 
Sent: Monday, September 12, 2022 9:42 AM
To: Julien Rische <jrische at redhat.com>
Cc: cifs-protocol at lists.samba.org; Microsoft Support <supportmail at microsoft.com>
Subject: RE: [EXTERNAL] KERB-ERROR-DATA code 136 - TrackingID#2209120040006251

[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]:

    [1] {
      INTEGER 136
    [2] {

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%7Cjeffm%40microsoft.com%7C58223f7690194088b40708da94ddb97b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637985977273082246%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=A6MfMlTjKbmO780bqQOI%2F2VTZSnxcFUDaJ0LmmuiP6E%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%7Cjeffm%40microsoft.com%7C58223f7690194088b40708da94ddb97b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637985977273082246%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=lhu20TZGsOMLsvq06cQ%2BnSYE7Gokbp9r85mQCzZXls4%3D&reserved=0

More information about the cifs-protocol mailing list