[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%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 _______________________________________________ cifs-protocol mailing list [email protected] https://lists.samba.org/mailman/listinfo/cifs-protocol
