Hi Jeff,

My bad, I tried to log in again and the file was there. I probably
messed up with the session cookie.

I uploaded these three files into the workspace:
* lsass01.run.zip: compressed output file from TTTracer.exe
* mit_kdc.pcap: Kerberos network trace captured on the MIT KDC
* credentials.keytab: Kerberos keys from MIT and AD

I used the first TTTrace.exe command you have sent. Please let me know
if I should use the second command you mentioned instead.

--
Julien Rische
Software Engineer
Red Hat

On Wed, Sep 14, 2022 at 5:30 PM Jeff McCashland (He/him)
<[email protected]> wrote:
>
> Hi Julien,
>
> Please ensure that you are logging onto the workspace using the provided 
> credentials, as it may automatically log you on with other credentials and 
> provide a different view. I have confirmed the .zip file is on the workspace 
> and available for you to download.
>
> Also, please try these alternate steps in place of step 1:
> a) On your Windows Server, open an elevated command prompt and enter the 
> command: tasklist /FI 'IMAGENAME eq lsass'
> b) Note the PID number in the output from the above command, and use it in 
> the next command:
> c) Execute: C:\TTD\TTTracer.exe -attach PID
>
> 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: Julien Rische <[email protected]>
> Sent: Wednesday, September 14, 2022 2:59 AM
> To: Jeff McCashland (He/him) <[email protected]>
> Cc: [email protected]; Microsoft Support 
> <[email protected]>
> Subject: Re: [EXTERNAL] KERB-ERROR-DATA code 136 - TrackingID#2209120040006251
>
> 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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsupp
> > ort.microsoft.com%2Ffiles%3Fworkspace%3DeyJ0eXAiOiJKV1QiLCJhbGciOiJSUz
> > I1NiJ9.eyJ3c2lkIjoiNzQ2NmNlOTUtYjQwNi00NzM4LThjMDEtMTJjMTMzNjU4MzA4Iiw
> > ic3IiOiIyMjA5MTIwMDQwMDA2MjUxIiwiYXBwaWQiOiI0ZTc2ODkxZC04NDUwLTRlNWUtY
> > mUzOC1lYTNiZDZlZjIxZTUiLCJzdiI6InYxIiwicnMiOiJFeHRlcm5hbCIsInd0aWQiOiI
> > yNTE3ZDA2Yi0wNTY1LTQwZTYtYmUwZi0zNWEwNTY1ZTM2NDQiLCJpc3MiOiJodHRwczovL
> > 2FwaS5kdG1uZWJ1bGEubWljcm9zb2Z0LmNvbSIsImF1ZCI6Imh0dHA6Ly9zbWMiLCJleHA
> > iOjE2NzA4NzY3NzcsIm5iZiI6MTY2MzEwMDc3N30.FMEx9xM5hrwYjID69wV0qJ1nDsEff
> > D9JLWTxZhf0GKPXGa9U8EZy5BbVtOLDQEdyAl4uEyGrDmH1-YlEB-byxDhA_TYjCXvFvy6
> > z2Eu5G8GlfV6CKMEDc9JJUYIMAROLBoKHIEQxXBoehoru1Z8cHGtyHqwfJUmfnh_33mfk6
> > 84qdwrhiMSwxi94AxovZ4n2BVPVzopPi_s1EGiwse28zg8ccKthEAGH4qs3qVmAf_V7y8F
> > 52dimwkfLvTSq1AvB3ZI0elDTDh8_rOR1FgW57v1sbVIl1art_hmqquWbJCxa-oW9_iWkX
> > 2n4OzZNmyhagfgF6XmMqdKl3LuV69u24Q%26wid%3D7466ce95-b406-4738-8c01-12c1
> > 33658308&amp;data=05%7C01%7Cjeffm%40microsoft.com%7C5784d93aa78543c353
> > 5408da9637c306%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6379874634
> > 98496191%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL
> > CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=ywWLrzP3YvcZ9e
> > XwuTqoPq5j1%2FaZisjhea%2F2Tv9nsD0%3D&amp;reserved=0
> >
> > 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:
> > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fsuppo
> > rt.microsoft.com%2Fglobalenglish&amp;data=05%7C01%7Cjeffm%40microsoft.
> > com%7C5784d93aa78543c3535408da9637c306%7C72f988bf86f141af91ab2d7cd011d
> > b47%7C1%7C0%7C637987463498496191%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wL
> > jAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&
> > amp;sdata=HLnwmeRNNJTOW9L1zl6f82H59KU4IN9SAK%2F5bjeWZL8%3D&amp;reserve
> > d=0 | 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:
> > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fsuppo
> > rt.microsoft.com%2Fglobalenglish&amp;data=05%7C01%7Cjeffm%40microsoft.
> > com%7C5784d93aa78543c3535408da9637c306%7C72f988bf86f141af91ab2d7cd011d
> > b47%7C1%7C0%7C637987463498496191%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wL
> > jAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&
> > amp;sdata=HLnwmeRNNJTOW9L1zl6f82H59KU4IN9SAK%2F5bjeWZL8%3D&amp;reserve
> > d=0 | 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%2Ff35b
> > 6902-6f5e-4cd0-be64-c50bbaaf54a5&amp;data=05%7C01%7Cjeffm%40microsoft.
> > com%7C5784d93aa78543c3535408da9637c306%7C72f988bf86f141af91ab2d7cd011d
> > b47%7C1%7C0%7C637987463498496191%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wL
> > jAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&
> > amp;sdata=uKOEQ%2FildzknOS5dUiy0qrcwJjTwzgML%2B6Zf1c8KaHs%3D&amp;reser
> > ved=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%2F25f
> > abd02-560d-4c1f-8f42-b32e9d97996a&amp;data=05%7C01%7Cjeffm%40microsoft
> > .com%7C5784d93aa78543c3535408da9637c306%7C72f988bf86f141af91ab2d7cd011
> > db47%7C1%7C0%7C637987463498496191%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4w
> > LjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C
> > &amp;sdata=NrPdAACaR3Srj4XL%2Bk7S7SzsZF%2BV8eRbMbcCSpR5uPI%3D&amp;rese
> > rved=0
> >
>


_______________________________________________
cifs-protocol mailing list
[email protected]
https://lists.samba.org/mailman/listinfo/cifs-protocol

Reply via email to