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

Julien Rische jrische at redhat.com
Wed Sep 21 15:06:53 UTC 2022


Hi Jeff,

Thank you for identifying the issue with the realm trust scenario.
I uploaded the TTD and network traces, and the kerberos keys for the
S4U2Self failure with an IPA/AD forest trust setup in the new
workspace.

--
Julien Rische
Software Engineer
Red Hat

On Tue, Sep 20, 2022 at 7:06 PM Jeff McCashland (He/him)
<jeffm at microsoft.com> wrote:
>
> [Updated SR ID on Subject]
>
> Hi Julien,
>
> We have created SR 2209200040006923 to track this alternate scenario where all the requisite data structures are in the PAC. Please upload LSASS TTT traces as before, and upload using these new credentials:
>
> Log in as: 2209200040006923_julien at dtmxfer.onmicrosoft.com
> 1-Time: 3xx3+xW]
>
> Workspace link:
> https://support.microsoft.com/files?workspace=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiJ9.eyJ3c2lkIjoiMDM4NDM5ZTgtZjI1ZC00Y2FmLTkwMmEtNWIyNDRiNGEyZDMxIiwic3IiOiIyMjA5MjAwMDQwMDA2OTIzIiwiYXBwaWQiOiI0ZTc2ODkxZC04NDUwLTRlNWUtYmUzOC1lYTNiZDZlZjIxZTUiLCJzdiI6InYxIiwicnMiOiJFeHRlcm5hbCIsInd0aWQiOiJlYjNjOTdhZi1lMTdjLTRhZTctYjFlMy0yNGZlOTU3ZmNkMjMiLCJpc3MiOiJodHRwczovL2FwaS5kdG1uZWJ1bGEubWljcm9zb2Z0LmNvbSIsImF1ZCI6Imh0dHA6Ly9zbWMiLCJleHAiOjE2NzE0NjkzNDMsIm5iZiI6MTY2MzY5MzM0M30.aeANIe2nm_SnaTLrVFqBibVpBwOe3I3wmO2fLkXPKqplXqI25krK3M2oHDLCvHIM6LXJ7Z97CKWddAho_qUs7AXRWG8Ati7vzOqEW1jegi3t-nnUcNMDu_KErIES6oTLxinQOvRdpApr0WuJf_iJby4gK7EgC8L8JOvNy1X0zwArbJaLBOMjdw1aDJa__m3mw7aAMOy3FTYaR9uKGPC9ZllcAJprETOU24Ts0-HThX67q0ZXdSvxlLSiiUTNA6hBGQ4SFBFgNVtpo7ox5ZYEB1mwpy7X9zAYo3usSCfRKe0ju1LWKcke5CN8r5cjzUBZegCjaAcDpZQ5MKbQnZDd3g&wid=038439e8-f25d-4caf-902a-5b244b4a2d31
>
> 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 20, 2022 8:55 AM
> To: Alexander Bokovoy <ab at samba.org>
> Cc: Julien Rische <jrische at redhat.com>; cifs-protocol at lists.samba.org; Microsoft Support <supportmail at microsoft.com>
> Subject: RE: [cifs-protocol] [EXTERNAL] KERB-ERROR-DATA code 136 - TrackingID#2209120040006251
>
> Thank you Alexander, I did miss that the structure was present.
>
> Julien, please hold off on uploading the TTT traces for the moment. To help us keep straight on this end, I'm having a new SR made and will send new credentials for uploading the next set of 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: Alexander Bokovoy <ab at samba.org>
> Sent: Monday, September 19, 2022 10:32 PM
> To: Jeff McCashland (He/him) <jeffm at microsoft.com>
> Cc: Julien Rische <jrische at redhat.com>; cifs-protocol at lists.samba.org; Microsoft Support <supportmail at microsoft.com>
> Subject: Re: [cifs-protocol] [EXTERNAL] KERB-ERROR-DATA code 136 - TrackingID#2209120040006251
>
> Hi Jeff,
>
> On ma, 19 syys 2022, Jeff McCashland (He/him) wrote:
> > Hi Alexander,
> >
> > Unfortunately, the error information in the network trace, as you
> > notice, is not sufficient to determine the cause of failure, which is
> > why I collected the TTT trace. The TTT trace I received fails twice,
> > both times due to the missing LOGON_INFO structure (1). As I read the
> > [MS-PAC] documentation quoted below, structures 1, 6, 7, and A are all
> > required. Each element states "PAC structures MUST contain one buffer
> > of this type". You mentioned one of the originally attached traces
> > includes structures 1, 6, and 7, but I don't see A listed.
> >
> > Do you have any examples that appear to be the same failure, where all 4 required structures are present?
>
> type A is present in the list I provided in my previous email (Client Info Type (10) is the type A), sorry for not calling it out explicitly:
>
>  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)
>
> So all four required buffers are present but AD DCs reject S4U requests.
>
> Julien is going to generate a TTT trace for this use case. I'm sure we might have some incompatibility in FreeIPA implementation but we cannot find what is broken so far, due to this undocumented error response.
>
> One of my theories is that it might be related to the FAST channel wrapping ticket. FAST is the pre-auth type 136. Is AD DC expecting that the FAST channel ticket, if present, also must have a PAC with the required buffers? Where is this documented?
>
> So far, 'MS-KILE 3.3.5.7.4 Compound Identity' might be the closest one but it doesn't apply as the FAST TGS-REQ is armored with the TGT of a computer in a trusted forest, not from the AD itself. This part of MS-KILE spec probably needs a bit of clarification as well.
>
> Another theory is that MIT Kerberos might produce incorrect Client Info package -- it supposed to have username at userrealm formatted name according to 'MS-SFU 3.2.5.1.1 KDC Replies with Referral TGT':
>
> ---------------
> If the KDC supports the Privilege Attribute Certificate Data Structure [MS-PAC], and a PAC is provided, the referral TGT Name field in the PAC_CLIENT_INFO structure of the PAC contains username at userRealm. This format is the syntax of the single-string representation ([RFC1964] section 2.1.1) using the username and userRealm fields from the PA-FOR-USER pre-authentication data.
> ---------------
>
> We send this client info buffer:
>
> Type: Client Info Type (10)
>     Size: 50
>     Offset: 808
>     PAC_CLIENT_INFO_TYPE: 808cae3b8ac2d801280068006f00730074002f006d00610073007400650072002e006900...
>         ClientID: Sep  7, 2022 10:19:57.000000000 EEST
>         Name Length: 40
>         Name: host/master.ipa.test
>
> instead of 'host/master.ipa.test at IPA.TEST'.
>
> >
> > 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%7C54153b0d6a314e4c635b08da9ac975a2%7C72f988bf86f141af91ab2d7cd011d
> > b47%7C1%7C0%7C637992487471990696%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wL
> > jAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000%7C%7C%7C&
> > amp;sdata=Cf5nCrlWOp%2Fq2yefHW0CVasW4zl8B%2BuOtdFxlyuB6cY%3D&reser
> > ved=0 | Extension 1138300
> >
> > -----Original Message-----
> > From: Alexander Bokovoy <ab at samba.org>
> > Sent: Monday, September 19, 2022 4:24 AM
> > To: Jeff McCashland (He/him) <jeffm at microsoft.com>
> > Cc: Julien Rische <jrische at redhat.com>; cifs-protocol at lists.samba.org;
> > Microsoft Support <supportmail at microsoft.com>
> > Subject: Re: [cifs-protocol] [EXTERNAL] KERB-ERROR-DATA code 136 -
> > TrackingID#2209120040006251
> >
> > 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:
> > > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fsup
> > > po
> > > rt.microsoft.com%2Fglobalenglish&data=05%7C01%7Cjeffm%40microsoft.
> > > com%7C163a1dbf984c42d8412f08da9a3171be%7C72f988bf86f141af91ab2d7cd01
> > > 1d
> > > b47%7C1%7C0%7C637991834754844507%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4
> > > wL
> > > jAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7
> > > C&
> > > amp;sdata=gZnYaF1%2B2KWsTHCKlF%2BBP1OY3El9QKI33R86ckSOgr0%3D&res
> > > er
> > > ved=0 | 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:
> > > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fsup
> > > po
> > > rt.microsoft.com%2Fglobalenglish&data=05%7C01%7Cjeffm%40microsoft.
> > > com%7C163a1dbf984c42d8412f08da9a3171be%7C72f988bf86f141af91ab2d7cd01
> > > 1d
> > > b47%7C1%7C0%7C637991834754844507%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4
> > > wL
> > > jAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7
> > > C&
> > > amp;sdata=gZnYaF1%2B2KWsTHCKlF%2BBP1OY3El9QKI33R86ckSOgr0%3D&res
> > > er
> > > ved=0 | 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%2Fs
> > > > up
> > > > po
> > > > rt.microsoft.com%2Fglobalenglish&data=05%7C01%7Cjeffm%40microsoft.
> > > > com%7C9dc19bb9dec5477ad0bb08da96877b29%7C72f988bf86f141af91ab2d7cd
> > > > 01
> > > > 1d
> > > > b47%7C1%7C0%7C637987805901775050%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiM
> > > > C4
> > > > wL
> > > > jAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C
> > > > %7
> > > > C&
> > > > amp;sdata=JtHTcsXnoZTTyll5asTlG3spHubJ1U8OzSlM2VsIvp0%3D&reser
> > > > ve
> > > > d=
> > > > 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%
> > > > > 2F
> > > > > su
> > > > > pp
> > > > > ort.microsoft.com%2Ffiles%3Fworkspace%3DeyJ0eXAiOiJKV1QiLCJhbGci
> > > > > Oi
> > > > > JS
> > > > > Uz
> > > > > I1NiJ9.eyJ3c2lkIjoiNzQ2NmNlOTUtYjQwNi00NzM4LThjMDEtMTJjMTMzNjU4M
> > > > > zA
> > > > > 4I
> > > > > iw
> > > > > ic3IiOiIyMjA5MTIwMDQwMDA2MjUxIiwiYXBwaWQiOiI0ZTc2ODkxZC04NDUwLTR
> > > > > lN
> > > > > WU
> > > > > tY
> > > > > mUzOC1lYTNiZDZlZjIxZTUiLCJzdiI6InYxIiwicnMiOiJFeHRlcm5hbCIsInd0a
> > > > > WQ
> > > > > iO
> > > > > iI
> > > > > yNTE3ZDA2Yi0wNTY1LTQwZTYtYmUwZi0zNWEwNTY1ZTM2NDQiLCJpc3MiOiJodHR
> > > > > wc
> > > > > zo
> > > > > vL
> > > > > 2FwaS5kdG1uZWJ1bGEubWljcm9zb2Z0LmNvbSIsImF1ZCI6Imh0dHA6Ly9zbWMiL
> > > > > CJ
> > > > > le
> > > > > HA
> > > > > iOjE2NzA4NzY3NzcsIm5iZiI6MTY2MzEwMDc3N30.FMEx9xM5hrwYjID69wV0qJ1
> > > > > nD
> > > > > sE
> > > > > ff
> > > > > D9JLWTxZhf0GKPXGa9U8EZy5BbVtOLDQEdyAl4uEyGrDmH1-YlEB-byxDhA_TYjC
> > > > > Xv
> > > > > Fv
> > > > > y6
> > > > > z2Eu5G8GlfV6CKMEDc9JJUYIMAROLBoKHIEQxXBoehoru1Z8cHGtyHqwfJUmfnh_
> > > > > 33
> > > > > mf
> > > > > k6
> > > > > 84qdwrhiMSwxi94AxovZ4n2BVPVzopPi_s1EGiwse28zg8ccKthEAGH4qs3qVmAf
> > > > > _V
> > > > > 7y
> > > > > 8F
> > > > > 52dimwkfLvTSq1AvB3ZI0elDTDh8_rOR1FgW57v1sbVIl1art_hmqquWbJCxa-oW
> > > > > 9_
> > > > > iW
> > > > > kX
> > > > > 2n4OzZNmyhagfgF6XmMqdKl3LuV69u24Q%26wid%3D7466ce95-b406-4738-8c0
> > > > > 1-
> > > > > 12
> > > > > c1
> > > > > 33658308&data=05%7C01%7Cjeffm%40microsoft.com%7C5784d93aa785
> > > > > 43
> > > > > c3
> > > > > 53
> > > > > 5408da9637c306%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6379
> > > > > 87
> > > > > 46
> > > > > 34
> > > > > 98496191%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2l
> > > > > uM
> > > > > zI
> > > > > iL
> > > > > CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ywWLrzP3
> > > > > Yv
> > > > > cZ
> > > > > 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%2
> > > > > Fs
> > > > > up
> > > > > po
> > > > > rt.microsoft.com%2Fglobalenglish&data=05%7C01%7Cjeffm%40microsoft.
> > > > > com%7C5784d93aa78543c3535408da9637c306%7C72f988bf86f141af91ab2d7
> > > > > cd
> > > > > 01
> > > > > 1d
> > > > > b47%7C1%7C0%7C637987463498496191%7CUnknown%7CTWFpbGZsb3d8eyJWIjo
> > > > > iM
> > > > > C4
> > > > > wL
> > > > > jAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%
> > > > > 7C
> > > > > %7
> > > > > C&
> > > > > amp;sdata=HLnwmeRNNJTOW9L1zl6f82H59KU4IN9SAK%2F5bjeWZL8%3D&r
> > > > > es
> > > > > er
> > > > > 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%2
> > > > > Fs
> > > > > up
> > > > > po
> > > > > rt.microsoft.com%2Fglobalenglish&data=05%7C01%7Cjeffm%40microsoft.
> > > > > com%7C5784d93aa78543c3535408da9637c306%7C72f988bf86f141af91ab2d7
> > > > > cd
> > > > > 01
> > > > > 1d
> > > > > b47%7C1%7C0%7C637987463498496191%7CUnknown%7CTWFpbGZsb3d8eyJWIjo
> > > > > iM
> > > > > C4
> > > > > wL
> > > > > jAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%
> > > > > 7C
> > > > > %7
> > > > > C&
> > > > > amp;sdata=HLnwmeRNNJTOW9L1zl6f82H59KU4IN9SAK%2F5bjeWZL8%3D&r
> > > > > es
> > > > > er
> > > > > 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%
> > > > > 2F
> > > > > do
> > > > > cs
> > > > > .microsoft.com%2Fen-us%2Fopenspecs%2Fwindows_protocols%2Fms-sfu%
> > > > > 2F
> > > > > f3
> > > > > 5b
> > > > > 6902-6f5e-4cd0-be64-c50bbaaf54a5&data=05%7C01%7Cjeffm%40microsoft.
> > > > > com%7C5784d93aa78543c3535408da9637c306%7C72f988bf86f141af91ab2d7
> > > > > cd
> > > > > 01
> > > > > 1d
> > > > > b47%7C1%7C0%7C637987463498496191%7CUnknown%7CTWFpbGZsb3d8eyJWIjo
> > > > > iM
> > > > > C4
> > > > > wL
> > > > > jAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%
> > > > > 7C
> > > > > %7
> > > > > C&
> > > > > amp;sdata=uKOEQ%2FildzknOS5dUiy0qrcwJjTwzgML%2B6Zf1c8KaHs%3D&amp
> > > > > ;r
> > > > > es
> > > > > 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%
> > > > > 2F
> > > > > do
> > > > > cs
> > > > > .microsoft.com%2Fen-us%2Fopenspecs%2Fwindows_protocols%2Fms-kile
> > > > > %2
> > > > > F2
> > > > > 5f
> > > > > abd02-560d-4c1f-8f42-b32e9d97996a&data=05%7C01%7Cjeffm%40mic
> > > > > ro
> > > > > so
> > > > > ft
> > > > > .com%7C5784d93aa78543c3535408da9637c306%7C72f988bf86f141af91ab2d
> > > > > 7c
> > > > > d0
> > > > > 11
> > > > > db47%7C1%7C0%7C637987463498496191%7CUnknown%7CTWFpbGZsb3d8eyJWIj
> > > > > oi
> > > > > MC
> > > > > 4w
> > > > > LjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C
> > > > > %7
> > > > > C%
> > > > > 7C
> > > > > &sdata=NrPdAACaR3Srj4XL%2Bk7S7SzsZF%2BV8eRbMbcCSpR5uPI%3D&am
> > > > > p;
> > > > > re
> > > > > se
> > > > > rved=0
> > > > >
> > > >
> > >
> > >
> > > _______________________________________________
> > > cifs-protocol mailing list
> > > cifs-protocol at lists.samba.org
> > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fli
> > > st
> > > s.samba.org%2Fmailman%2Flistinfo%2Fcifs-protocol&data=05%7C01%7C
> > > je
> > > ffm%40microsoft.com%7C163a1dbf984c42d8412f08da9a3171be%7C72f988bf86f
> > > 14
> > > 1af91ab2d7cd011db47%7C1%7C0%7C637991834755000738%7CUnknown%7CTWFpbGZ
> > > sb
> > > 3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3
> > > D%
> > > 7C2000%7C%7C%7C&sdata=tokIPnq2Hup7m2%2Fer438hZ1boXeVGZS%2BxMb4Rb
> > > bB
> > > WXs%3D&reserved=0
> >
> > --
> > / Alexander Bokovoy
>
> --
> / Alexander Bokovoy
>




More information about the cifs-protocol mailing list