Hello Jeff, Thank you for your response. I logged into the file transfer workspace, but it is empty. I don't see any "PartnerTTDRecorder_x86_x64.zip" file inside.
I see a "tttracer.exe" executable file is already provided on the system, but there is no window popping up when I run the command you have sent me. So I guess it is not the same one. I am using Windows Server 2019 Standard. Could you add the TTDRecorder file in the workspace please? Thank you in advance, -- Julien Rische Software Engineer Red Hat On Tue, Sep 13, 2022 at 10:37 PM Jeff McCashland (He/him) <[email protected]> wrote: > > Hi Julien, > > I have created a File Transfer workspace for exchanging files (link and > credentials below) related to this issue: "Cross-realm AD TGS request from an > MIT Kerberos client (realm trust)[1]". To troubleshoot this issue, I would > like to collect LSASS TTT traces and a concurrent network packet capture. > > The LSASS traces can be quite large, but are highly compressible, so please > add them to a .zip archive before uploading (file transfer workspace > credentials are below). Please log into the workspace and find > PartnerTTDRecorder_x86_x64.zip available for download. The x64 tool can be > staged onto the Windows server in any location (instructions below assume > C:\TTD). > > To collect the needed traces: > 1. From a PowerShell prompt, execute: > C:\TTD\tttracer.exe -Attach ([int](Get-Process -NAME lsass | > Format-Wide -Property ID).formatEntryInfo.formatPropertyField.propertyValue) > 2. Wait for a little window to pop up in top left corner of your > screen, titled "lsass01.run" > 3. start a network trace using netsh or WireShark, etc. > 4. Repro the attempted operation > 5. Stop the network trace and save it > 6. CAREFULLY: uncheck the checkbox next to "Tracing" in the small > "lsass01.run" window. Do not close or exit the small window or you will need > to reboot. > 7. The TTTracer.exe process will generate a trace file, then print > out the name and location of the file. > Compress the *.run file into a .zip archive before uploading with the > matching network trace. It is a good idea to reboot the machine at the next > opportunity to restart the lsass process. > > Workspace credentials: > Log in as: [email protected] > 1-Time: ;@[r@(E9 > > Link: > https://support.microsoft.com/files?workspace=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiJ9.eyJ3c2lkIjoiNzQ2NmNlOTUtYjQwNi00NzM4LThjMDEtMTJjMTMzNjU4MzA4Iiwic3IiOiIyMjA5MTIwMDQwMDA2MjUxIiwiYXBwaWQiOiI0ZTc2ODkxZC04NDUwLTRlNWUtYmUzOC1lYTNiZDZlZjIxZTUiLCJzdiI6InYxIiwicnMiOiJFeHRlcm5hbCIsInd0aWQiOiIyNTE3ZDA2Yi0wNTY1LTQwZTYtYmUwZi0zNWEwNTY1ZTM2NDQiLCJpc3MiOiJodHRwczovL2FwaS5kdG1uZWJ1bGEubWljcm9zb2Z0LmNvbSIsImF1ZCI6Imh0dHA6Ly9zbWMiLCJleHAiOjE2NzA4NzY3NzcsIm5iZiI6MTY2MzEwMDc3N30.FMEx9xM5hrwYjID69wV0qJ1nDsEffD9JLWTxZhf0GKPXGa9U8EZy5BbVtOLDQEdyAl4uEyGrDmH1-YlEB-byxDhA_TYjCXvFvy6z2Eu5G8GlfV6CKMEDc9JJUYIMAROLBoKHIEQxXBoehoru1Z8cHGtyHqwfJUmfnh_33mfk684qdwrhiMSwxi94AxovZ4n2BVPVzopPi_s1EGiwse28zg8ccKthEAGH4qs3qVmAf_V7y8F52dimwkfLvTSq1AvB3ZI0elDTDh8_rOR1FgW57v1sbVIl1art_hmqquWbJCxa-oW9_iWkX2n4OzZNmyhagfgF6XmMqdKl3LuV69u24Q&wid=7466ce95-b406-4738-8c01-12c133658308 > > 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: Jeff McCashland (He/him) > Sent: Tuesday, September 13, 2022 12:15 PM > To: Julien Rische <[email protected]> > Cc: [email protected]; Microsoft Support > <[email protected]> > Subject: RE: [EXTERNAL] KERB-ERROR-DATA code 136 - TrackingID#2209120040006251 > > [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
