[cifs-protocol] [EXTERNAL] KERB-ERROR-DATA code 136 - TrackingID#2209120040006251
Mike.Bowen at microsoft.com
Mon Sep 12 16:42:01 UTC 2022
[DocHelp to bcc]
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.
Escalation Engineer - Microsoft Open Specifications
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 ]
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)
* Cross-realm S4U2Self request for a FreeIPA service to impersonate an AD user
In both cases, a TGS-REQ against AD using the cross-realm TGT results in a generic error (MS-SFU 4.2 step 3 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:
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. 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?
 krb5_1_20_mit_ad_realm_trust.(pcap|keytab) files in attachment  krb5_1_20_ipa_ad_trust_s4u2self.(pcapng|keytab) files in attachment  krb5_1_20_mit_ad_realm_trust.pcap packet no. 7  krb5_1_20_ipa_ad_trust_s4u2self.pcapng packet no. 11  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
 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  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  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
More information about the cifs-protocol