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

Alexander Bokovoy ab at samba.org
Mon Sep 19 11:23:53 UTC 2022 

Hi Jeff,

On pe, 16 syys 2022, Jeff McCashland (He/him) via cifs-protocol wrote:
> Hi Julien,
> 
> Based on my debugging and research, the issue appears to be that the
> PAC does not include PAC_LOGON_INFO (type 1). 
> 
> The PAC appears to only include PAC_INFO_BUFFER types 6, 7, and A.

We see the same problem for the IPA trace from the original Julien's
attachment [2]: krb5_1_20_ipa_ad_trust_s4u2self.(pcapng|keytab) files

Packet 9 of the trace contains TGS-REQ with a PAC with seven buffers,
including types 1, 6, and 7:

ad-data: 070000000000000001000000e001000078000000000000000c000000a200000058020000…
    Verified Server checksum 16 keytype 18 using keytab principal krbtgt/WIN2022.TEST at IPA.TEST (id=keytab.13 same=0) (db7c3ac9...)
    Verified KDC checksum 20 keytype 20 using keytab principal krbtgt/IPA.TEST at IPA.TEST (id=keytab.1 same=0) (bb2dfa43...)
    Num Entries: 7
    Version: 0
    Type: Logon Info (1)
    Type: UPN DNS Info (12)
    Type: Unknown (17)
    Type: Unknown (18)
    Type: Client Info Type (10)
    Type: Server Checksum (6)
    Type: Privsvr Checksum (7)

Yet, we get the same Kerberos error:

krb-error
    pvno: 5
    msg-type: krb-error (30)
    stime: 2022-09-07 07:20:01 (UTC)
    susec: 583266
    error-code: eRR-GENERIC (60)
    realm: WIN2022.TEST
    sname
        name-type: kRB5-NT-ENTERPRISE-PRINCIPAL (10)
        sname-string: 1 item
            SNameString: host/master.ipa.test at IPA.TEST
    e-data: 3081f43081f1a10402020088a281e80481e5a081e23081dfa081dc3081d9a003020112a2…

The e-data contains the same style sequence with KERB-ERROR-DATA code 136:

  0 244: SEQUENCE {
  3 241:   SEQUENCE {
  6   4:     [1] {
  8   2:       INTEGER 136
       :       }
 12 232:     [2] {
 15 229:       OCTET STRING
       :         A0 81 E2 30 81 DF A0 81 DC 30 81 D9 A0 03 02 01
       :         12 A2 81 D1 04 81 CE 65 E8 3C 7A 86 1A C6 04 DC
       :         8B C7 FB E7 2A 18 0B 18 06 C0 15 3C 4D 09 9C 66
       :         06 69 4F 40 1C 8C 39 29 B6 1C BE 4C DB 0D 5C 98
       :         2B A8 34 04 6C 67 FB 5D 92 A6 73 CF 7F 84 00 84
       :         F0 33 9B 35 96 96 2E FD 94 D3 4E BC 4F 03 C6 56
       :         48 45 CA E2 FE 75 B0 3C 21 FE 1B 02 77 70 F3 5F
       :         6A 48 16 D1 91 85 94 FF B9 93 2F F1 4C 99 05 80
       :                 [ Another 101 bytes skipped ]
       :       }
       :     }
       :   }



> 
> 2.4 PAC_INFO_BUFFER
> ulType (4 bytes): A 32-bit unsigned integer in little-endian format
> that describes the type of data present in the buffer contained at
> Offset. 
> 
> 0x00000001 Logon information (section 2.5). PAC structures MUST contain one buffer of this type. Additional logon information buffers MUST be ignored.
> 0x00000006 Server checksum (section 2.8). PAC structures MUST contain one buffer of this type. Additional logon server checksum buffers MUST be ignored.
> 0x00000007 KDC (privilege server) checksum (section 2.8). PAC structures MUST contain one buffer of this type. Additional KDC checksum buffers MUST be ignored.
> 0x0000000A Client name and ticket information (section 2.7). PAC structures MUST contain one buffer of this type. Additional client and ticket information buffers MUST be ignored.
> 
> Let me know if that resolves one or both issues. 
> 
> 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: Wednesday, September 14, 2022 1:33 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
> 
> Hi Julien,
> 
> I have received the files you uploaded. It is not necessary to run the alternate commands if the first one worked. Please retain the tools and information in case we need to collect additional traces. 
> 
> I will analyze these traces and let you know what I find. 
> 
> 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 <jrische at redhat.com>
> Sent: Wednesday, September 14, 2022 12:30 PM
> To: Jeff McCashland (He/him) <jeffm at microsoft.com>
> Cc: cifs-protocol at lists.samba.org; Microsoft Support <supportmail at microsoft.com>
> Subject: Re: [EXTERNAL] KERB-ERROR-DATA code 136 - TrackingID#2209120040006251
> 
> 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) <jeffm at microsoft.com> 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:
> > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fsuppo
> > rt.microsoft.com%2Fglobalenglish&data=05%7C01%7Cjeffm%40microsoft.
> > com%7C9dc19bb9dec5477ad0bb08da96877b29%7C72f988bf86f141af91ab2d7cd011d
> > b47%7C1%7C0%7C637987805901775050%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wL
> > jAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&
> > amp;sdata=JtHTcsXnoZTTyll5asTlG3spHubJ1U8OzSlM2VsIvp0%3D&reserved=
> > 0 | Extension 1138300
> >
> > -----Original Message-----
> > From: Julien Rische <jrische at redhat.com>
> > Sent: Wednesday, September 14, 2022 2:59 AM
> > To: Jeff McCashland (He/him) <jeffm at microsoft.com>
> > Cc: cifs-protocol at lists.samba.org; Microsoft Support 
> > <supportmail at microsoft.com>
> > 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) <jeffm at microsoft.com> 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: 2209120040006251_julien at dtmxfer.onmicrosoft.com
> > > 1-Time: ;@[r@(E9
> > >
> > > Link:
> > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsu
> > > pp
> > > ort.microsoft.com%2Ffiles%3Fworkspace%3DeyJ0eXAiOiJKV1QiLCJhbGciOiJS
> > > Uz
> > > I1NiJ9.eyJ3c2lkIjoiNzQ2NmNlOTUtYjQwNi00NzM4LThjMDEtMTJjMTMzNjU4MzA4I
> > > iw
> > > ic3IiOiIyMjA5MTIwMDQwMDA2MjUxIiwiYXBwaWQiOiI0ZTc2ODkxZC04NDUwLTRlNWU
> > > tY
> > > mUzOC1lYTNiZDZlZjIxZTUiLCJzdiI6InYxIiwicnMiOiJFeHRlcm5hbCIsInd0aWQiO
> > > iI
> > > yNTE3ZDA2Yi0wNTY1LTQwZTYtYmUwZi0zNWEwNTY1ZTM2NDQiLCJpc3MiOiJodHRwczo
> > > vL
> > > 2FwaS5kdG1uZWJ1bGEubWljcm9zb2Z0LmNvbSIsImF1ZCI6Imh0dHA6Ly9zbWMiLCJle
> > > HA
> > > iOjE2NzA4NzY3NzcsIm5iZiI6MTY2MzEwMDc3N30.FMEx9xM5hrwYjID69wV0qJ1nDsE
> > > ff
> > > D9JLWTxZhf0GKPXGa9U8EZy5BbVtOLDQEdyAl4uEyGrDmH1-YlEB-byxDhA_TYjCXvFv
> > > y6
> > > z2Eu5G8GlfV6CKMEDc9JJUYIMAROLBoKHIEQxXBoehoru1Z8cHGtyHqwfJUmfnh_33mf
> > > k6
> > > 84qdwrhiMSwxi94AxovZ4n2BVPVzopPi_s1EGiwse28zg8ccKthEAGH4qs3qVmAf_V7y
> > > 8F
> > > 52dimwkfLvTSq1AvB3ZI0elDTDh8_rOR1FgW57v1sbVIl1art_hmqquWbJCxa-oW9_iW
> > > kX
> > > 2n4OzZNmyhagfgF6XmMqdKl3LuV69u24Q%26wid%3D7466ce95-b406-4738-8c01-12
> > > c1
> > > 33658308&data=05%7C01%7Cjeffm%40microsoft.com%7C5784d93aa78543c3
> > > 53
> > > 5408da9637c306%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63798746
> > > 34
> > > 98496191%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzI
> > > iL
> > > CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ywWLrzP3YvcZ
> > > 9e
> > > XwuTqoPq5j1%2FaZisjhea%2F2Tv9nsD0%3D&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%2Fsup
> > > po
> > > rt.microsoft.com%2Fglobalenglish&data=05%7C01%7Cjeffm%40microsoft.
> > > com%7C5784d93aa78543c3535408da9637c306%7C72f988bf86f141af91ab2d7cd01
> > > 1d
> > > b47%7C1%7C0%7C637987463498496191%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4
> > > wL
> > > jAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7
> > > C&
> > > amp;sdata=HLnwmeRNNJTOW9L1zl6f82H59KU4IN9SAK%2F5bjeWZL8%3D&reser
> > > ve
> > > d=0 | 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:
> > > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fsup
> > > po
> > > rt.microsoft.com%2Fglobalenglish&data=05%7C01%7Cjeffm%40microsoft.
> > > com%7C5784d93aa78543c3535408da9637c306%7C72f988bf86f141af91ab2d7cd01
> > > 1d
> > > b47%7C1%7C0%7C637987463498496191%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4
> > > wL
> > > jAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7
> > > C&
> > > amp;sdata=HLnwmeRNNJTOW9L1zl6f82H59KU4IN9SAK%2F5bjeWZL8%3D&reser
> > > ve
> > > d=0 | 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%2Fdo
> > > cs
> > > .microsoft.com%2Fen-us%2Fopenspecs%2Fwindows_protocols%2Fms-sfu%2Ff3
> > > 5b
> > > 6902-6f5e-4cd0-be64-c50bbaaf54a5&data=05%7C01%7Cjeffm%40microsoft.
> > > com%7C5784d93aa78543c3535408da9637c306%7C72f988bf86f141af91ab2d7cd01
> > > 1d
> > > b47%7C1%7C0%7C637987463498496191%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4
> > > wL
> > > jAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7
> > > C&
> > > amp;sdata=uKOEQ%2FildzknOS5dUiy0qrcwJjTwzgML%2B6Zf1c8KaHs%3D&res
> > > er
> > > 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%2Fdo
> > > cs
> > > .microsoft.com%2Fen-us%2Fopenspecs%2Fwindows_protocols%2Fms-kile%2F2
> > > 5f
> > > abd02-560d-4c1f-8f42-b32e9d97996a&data=05%7C01%7Cjeffm%40microso
> > > ft
> > > .com%7C5784d93aa78543c3535408da9637c306%7C72f988bf86f141af91ab2d7cd0
> > > 11
> > > db47%7C1%7C0%7C637987463498496191%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC
> > > 4w
> > > LjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%
> > > 7C
> > > &sdata=NrPdAACaR3Srj4XL%2Bk7S7SzsZF%2BV8eRbMbcCSpR5uPI%3D&re
> > > se
> > > rved=0
> > >
> >
> 
> 
> _______________________________________________
> cifs-protocol mailing list
> cifs-protocol at lists.samba.org
> https://lists.samba.org/mailman/listinfo/cifs-protocol

-- 
/ Alexander Bokovoy

More information about the cifs-protocol mailing list