[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 <[email protected]> Sent: Monday, September 12, 2022 9:42 AM To: Julien Rische <[email protected]> Cc: [email protected]; Microsoft Support <[email protected]> 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 [email protected] 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 <[email protected]> Sent: Monday, September 12, 2022 7:01 AM To: Interoperability Documentation Help <[email protected]> Cc: [email protected] Subject: [EXTERNAL] KERB-ERROR-DATA code 136 [Some people who received this message don't often get email from [email protected]. 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%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 _______________________________________________ cifs-protocol mailing list [email protected] https://lists.samba.org/mailman/listinfo/cifs-protocol
