[cifs-protocol] [EXTERNAL] KERB-ERROR-DATA code 136 - TrackingID#2209120040006251

Jeff McCashland (He/him) jeffm at microsoft.com
Tue Sep 13 20:37:01 UTC 2022


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: 2209120040006251_julien at dtmxfer.onmicrosoft.com
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 <jrische at redhat.com>
Cc: cifs-protocol at lists.samba.org; Microsoft Support <supportmail at microsoft.com>
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 <Mike.Bowen at microsoft.com>
Sent: Monday, September 12, 2022 9:42 AM
To: Julien Rische <jrische at redhat.com>
Cc: cifs-protocol at lists.samba.org; Microsoft Support <supportmail at microsoft.com>
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 supportmail at microsoft.com 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 <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 ]

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



More information about the cifs-protocol mailing list