On ke, 21 syys 2022, Jeff McCashland (He/him) wrote: > Hi Julien, > > The root cause of the failure in today's TTT trace is that the size of > the PrivSvr checksum in the type 7 structure is too large. The size > provided was 0x1c, while the expected maximum size is 0x14.
Thank you, Jeff. Do I understand correct that we are dealing with the following table from 'MS-PAC 2.8.2 KDC Signature': https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-pac/3122bf00-ea87-4c3f-92a0-91c0a99f5eec ----------------------------------------------------------------------------------------------------------------- If the KDC: | Then the cryptographic system is: ----------------------------------------------------------------------------------------------------------------- Supports RC4-HMAC | KERB_CHECKSUM_HMAC_MD5 ----------------------------------------------------------------------------------------------------------------- Does not support RC4-HMAC and supports AES256 | HMAC_SHA1_96_AES256<17> ----------------------------------------------------------------------------------------------------------------- Does not support RC4-HMAC or AES256-CTS-HMAC-SHA1-96, and supports | HMAC_SHA1_96_AES128<18> AES128-CTS-HMAC-SHA1-96 | ----------------------------------------------------------------------------------------------------------------- Does not support RC4-HMAC, AES128-CTS-HMAC-SHA1-96 or | None. The checksum operation will fail. AES256-CTS-HMAC-SHA1-96 | ----------------------------------------------------------------------------------------------------------------- In the traces we have PrivSvr checksum using enctype 20, eTYPE-AES256-CTS-HMAC-SHA384-192 (20) which is not supported by Windows systems and thus causing an issue. > > 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 21, 2022 9:43 AM > To: Julien Rische <[email protected]> > Cc: Alexander Bokovoy <[email protected]>; Microsoft Support > <[email protected]>; [email protected] > Subject: RE: [cifs-protocol] [EXTERNAL] KERB-ERROR-DATA code 136 - > TrackingID#2209200040006923 > > Hi Julien, > > I have received the files you uploaded. I will analyze the 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 <[email protected]> > Sent: Wednesday, September 21, 2022 8:07 AM > To: Jeff McCashland (He/him) <[email protected]> > Cc: Alexander Bokovoy <[email protected]>; Microsoft Support > <[email protected]>; [email protected] > Subject: Re: [cifs-protocol] [EXTERNAL] KERB-ERROR-DATA code 136 - > TrackingID#2209200040006923 > > 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) > <[email protected]> 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: [email protected] > > 1-Time: 3xx3+xW] > > > > Workspace link: > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsupp > > ort.microsoft.com%2Ffiles%3Fworkspace%3DeyJ0eXAiOiJKV1QiLCJhbGciOiJSUz > > I1NiJ9.eyJ3c2lkIjoiMDM4NDM5ZTgtZjI1ZC00Y2FmLTkwMmEtNWIyNDRiNGEyZDMxIiw > > ic3IiOiIyMjA5MjAwMDQwMDA2OTIzIiwiYXBwaWQiOiI0ZTc2ODkxZC04NDUwLTRlNWUtY > > mUzOC1lYTNiZDZlZjIxZTUiLCJzdiI6InYxIiwicnMiOiJFeHRlcm5hbCIsInd0aWQiOiJ > > lYjNjOTdhZi1lMTdjLTRhZTctYjFlMy0yNGZlOTU3ZmNkMjMiLCJpc3MiOiJodHRwczovL > > 2FwaS5kdG1uZWJ1bGEubWljcm9zb2Z0LmNvbSIsImF1ZCI6Imh0dHA6Ly9zbWMiLCJleHA > > iOjE2NzE0NjkzNDMsIm5iZiI6MTY2MzY5MzM0M30.aeANIe2nm_SnaTLrVFqBibVpBwOe3 > > I3wmO2fLkXPKqplXqI25krK3M2oHDLCvHIM6LXJ7Z97CKWddAho_qUs7AXRWG8Ati7vzOq > > EW1jegi3t-nnUcNMDu_KErIES6oTLxinQOvRdpApr0WuJf_iJby4gK7EgC8L8JOvNy1X0z > > wArbJaLBOMjdw1aDJa__m3mw7aAMOy3FTYaR9uKGPC9ZllcAJprETOU24Ts0-HThX67q0Z > > XdSvxlLSiiUTNA6hBGQ4SFBFgNVtpo7ox5ZYEB1mwpy7X9zAYo3usSCfRKe0ju1LWKcke5 > > CN8r5cjzUBZegCjaAcDpZQ5MKbQnZDd3g%26wid%3D038439e8-f25d-4caf-902a-5b24 > > 4b4a2d31&data=05%7C01%7Cjeffm%40microsoft.com%7Caa204126498d422e71 > > c408da9be2f408%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6379936963 > > 24465845%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL > > CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=sEezQUzzazzB5T > > B2ZnXFpXn5jQ7RjTCSdajt3E%2FIUM8%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%2Fsuppo > > rt.microsoft.com%2Fglobalenglish&data=05%7C01%7Cjeffm%40microsoft. > > com%7Caa204126498d422e71c408da9be2f408%7C72f988bf86f141af91ab2d7cd011d > > b47%7C1%7C0%7C637993696324465845%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wL > > jAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C& > > amp;sdata=FOQtQGmGGlM745kzBB8Z3kBLHHjOr3Ntp5y86WsrcGY%3D&reserved= > > 0 | Extension 1138300 > > > > -----Original Message----- > > From: Jeff McCashland (He/him) > > Sent: Tuesday, September 20, 2022 8:55 AM > > To: Alexander Bokovoy <[email protected]> > > Cc: Julien Rische <[email protected]>; [email protected]; > > Microsoft Support <[email protected]> > > 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: > > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fsuppo > > rt.microsoft.com%2Fglobalenglish&data=05%7C01%7Cjeffm%40microsoft. > > com%7Caa204126498d422e71c408da9be2f408%7C72f988bf86f141af91ab2d7cd011d > > b47%7C1%7C0%7C637993696324465845%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wL > > jAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C& > > amp;sdata=FOQtQGmGGlM745kzBB8Z3kBLHHjOr3Ntp5y86WsrcGY%3D&reserved= > > 0 | Extension 1138300 > > > > -----Original Message----- > > From: Alexander Bokovoy <[email protected]> > > Sent: Monday, September 19, 2022 10:32 PM > > To: Jeff McCashland (He/him) <[email protected]> > > Cc: Julien Rische <[email protected]>; [email protected]; > > Microsoft Support <[email protected]> > > 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/[email protected] (id=keytab.13 same=0) (db7c3ac9...) > > Verified KDC checksum 20 keytype 20 using keytab principal > > krbtgt/[email protected] (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@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@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/[email protected]'. > > > > > > > > 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%7C54153b0d6a314e4c635b08da9ac975a2%7C72f988bf86f141af91ab2d7cd01 > > > 1d > > > b47%7C1%7C0%7C637992487471990696%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4 > > > wL > > > jAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000%7C%7C%7 > > > C& > > > amp;sdata=Cf5nCrlWOp%2Fq2yefHW0CVasW4zl8B%2BuOtdFxlyuB6cY%3D&res > > > er > > > ved=0 | Extension 1138300 > > > > > > -----Original Message----- > > > From: Alexander Bokovoy <[email protected]> > > > Sent: Monday, September 19, 2022 4:24 AM > > > To: Jeff McCashland (He/him) <[email protected]> > > > Cc: Julien Rische <[email protected]>; > > > [email protected]; Microsoft Support > > > <[email protected]> > > > 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/[email protected] (id=keytab.13 same=0) (db7c3ac9...) > > > Verified KDC checksum 20 keytype 20 using keytab principal > > > krbtgt/[email protected] (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/[email protected] > > > 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%2Fs > > > > up > > > > po > > > > rt.microsoft.com%2Fglobalenglish&data=05%7C01%7Cjeffm%40microsoft. > > > > com%7C163a1dbf984c42d8412f08da9a3171be%7C72f988bf86f141af91ab2d7cd > > > > 01 > > > > 1d > > > > b47%7C1%7C0%7C637991834754844507%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiM > > > > C4 > > > > wL > > > > jAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C > > > > %7 > > > > C& > > > > amp;sdata=gZnYaF1%2B2KWsTHCKlF%2BBP1OY3El9QKI33R86ckSOgr0%3D&r > > > > es > > > > er > > > > ved=0 | Extension 1138300 > > > > > > > > -----Original Message----- > > > > From: Jeff McCashland (He/him) > > > > Sent: Wednesday, September 14, 2022 1:33 PM > > > > To: Julien Rische <[email protected]> > > > > Cc: [email protected]; Microsoft Support > > > > <[email protected]> > > > > 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%2Fs > > > > up > > > > po > > > > rt.microsoft.com%2Fglobalenglish&data=05%7C01%7Cjeffm%40microsoft. > > > > com%7C163a1dbf984c42d8412f08da9a3171be%7C72f988bf86f141af91ab2d7cd > > > > 01 > > > > 1d > > > > b47%7C1%7C0%7C637991834754844507%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiM > > > > C4 > > > > wL > > > > jAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C > > > > %7 > > > > C& > > > > amp;sdata=gZnYaF1%2B2KWsTHCKlF%2BBP1OY3El9QKI33R86ckSOgr0%3D&r > > > > es > > > > er > > > > ved=0 | Extension 1138300 > > > > > > > > -----Original Message----- > > > > From: Julien Rische <[email protected]> > > > > Sent: Wednesday, September 14, 2022 12:30 PM > > > > To: Jeff McCashland (He/him) <[email protected]> > > > > Cc: [email protected]; Microsoft Support > > > > <[email protected]> > > > > 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) > > > > <[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: > > > > > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2 > > > > > Fs > > > > > up > > > > > po > > > > > rt.microsoft.com%2Fglobalenglish&data=05%7C01%7Cjeffm%40microsoft. > > > > > com%7C9dc19bb9dec5477ad0bb08da96877b29%7C72f988bf86f141af91ab2d7 > > > > > cd > > > > > 01 > > > > > 1d > > > > > b47%7C1%7C0%7C637987805901775050%7CUnknown%7CTWFpbGZsb3d8eyJWIjo > > > > > iM > > > > > C4 > > > > > wL > > > > > jAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C% > > > > > 7C > > > > > %7 > > > > > C& > > > > > amp;sdata=JtHTcsXnoZTTyll5asTlG3spHubJ1U8OzSlM2VsIvp0%3D&res > > > > > er > > > > > ve > > > > > d= > > > > > 0 | 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%2 > > > > > > F% > > > > > > 2F > > > > > > su > > > > > > pp > > > > > > ort.microsoft.com%2Ffiles%3Fworkspace%3DeyJ0eXAiOiJKV1QiLCJhbG > > > > > > ci > > > > > > Oi > > > > > > JS > > > > > > Uz > > > > > > I1NiJ9.eyJ3c2lkIjoiNzQ2NmNlOTUtYjQwNi00NzM4LThjMDEtMTJjMTMzNjU > > > > > > 4M > > > > > > zA > > > > > > 4I > > > > > > iw > > > > > > ic3IiOiIyMjA5MTIwMDQwMDA2MjUxIiwiYXBwaWQiOiI0ZTc2ODkxZC04NDUwL > > > > > > TR > > > > > > lN > > > > > > WU > > > > > > tY > > > > > > mUzOC1lYTNiZDZlZjIxZTUiLCJzdiI6InYxIiwicnMiOiJFeHRlcm5hbCIsInd > > > > > > 0a > > > > > > WQ > > > > > > iO > > > > > > iI > > > > > > yNTE3ZDA2Yi0wNTY1LTQwZTYtYmUwZi0zNWEwNTY1ZTM2NDQiLCJpc3MiOiJod > > > > > > HR > > > > > > wc > > > > > > zo > > > > > > vL > > > > > > 2FwaS5kdG1uZWJ1bGEubWljcm9zb2Z0LmNvbSIsImF1ZCI6Imh0dHA6Ly9zbWM > > > > > > iL > > > > > > CJ > > > > > > le > > > > > > HA > > > > > > iOjE2NzA4NzY3NzcsIm5iZiI6MTY2MzEwMDc3N30.FMEx9xM5hrwYjID69wV0q > > > > > > J1 > > > > > > nD > > > > > > sE > > > > > > ff > > > > > > D9JLWTxZhf0GKPXGa9U8EZy5BbVtOLDQEdyAl4uEyGrDmH1-YlEB-byxDhA_TY > > > > > > jC > > > > > > Xv > > > > > > Fv > > > > > > y6 > > > > > > z2Eu5G8GlfV6CKMEDc9JJUYIMAROLBoKHIEQxXBoehoru1Z8cHGtyHqwfJUmfn > > > > > > h_ > > > > > > 33 > > > > > > mf > > > > > > k6 > > > > > > 84qdwrhiMSwxi94AxovZ4n2BVPVzopPi_s1EGiwse28zg8ccKthEAGH4qs3qVm > > > > > > Af > > > > > > _V > > > > > > 7y > > > > > > 8F > > > > > > 52dimwkfLvTSq1AvB3ZI0elDTDh8_rOR1FgW57v1sbVIl1art_hmqquWbJCxa- > > > > > > oW > > > > > > 9_ > > > > > > iW > > > > > > kX > > > > > > 2n4OzZNmyhagfgF6XmMqdKl3LuV69u24Q%26wid%3D7466ce95-b406-4738-8 > > > > > > c0 > > > > > > 1- > > > > > > 12 > > > > > > c1 > > > > > > 33658308&data=05%7C01%7Cjeffm%40microsoft.com%7C5784d93aa7 > > > > > > 85 > > > > > > 43 > > > > > > c3 > > > > > > 53 > > > > > > 5408da9637c306%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63 > > > > > > 79 > > > > > > 87 > > > > > > 46 > > > > > > 34 > > > > > > 98496191%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV > > > > > > 2l > > > > > > uM > > > > > > zI > > > > > > iL > > > > > > CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ywWLrz > > > > > > P3 > > > > > > 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%7C72f988bf86f141af91ab2 > > > > > > d7 > > > > > > cd > > > > > > 01 > > > > > > 1d > > > > > > b47%7C1%7C0%7C637987463498496191%7CUnknown%7CTWFpbGZsb3d8eyJWI > > > > > > jo > > > > > > iM > > > > > > C4 > > > > > > wL > > > > > > jAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7 > > > > > > C% > > > > > > 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 <[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 > > > > > > %2 > > > > > > Fs > > > > > > up > > > > > > po > > > > > > rt.microsoft.com%2Fglobalenglish&data=05%7C01%7Cjeffm%40microsoft. > > > > > > com%7C5784d93aa78543c3535408da9637c306%7C72f988bf86f141af91ab2 > > > > > > d7 > > > > > > cd > > > > > > 01 > > > > > > 1d > > > > > > b47%7C1%7C0%7C637987463498496191%7CUnknown%7CTWFpbGZsb3d8eyJWI > > > > > > jo > > > > > > iM > > > > > > C4 > > > > > > wL > > > > > > jAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7 > > > > > > C% > > > > > > 7C > > > > > > %7 > > > > > > C& > > > > > > amp;sdata=HLnwmeRNNJTOW9L1zl6f82H59KU4IN9SAK%2F5bjeWZL8%3D& > > > > > > ;r > > > > > > es > > > > > > er > > > > > > ve > > > > > > 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%2 > > > > > > F% > > > > > > 2F > > > > > > do > > > > > > cs > > > > > > .microsoft.com%2Fen-us%2Fopenspecs%2Fwindows_protocols%2Fms-sf > > > > > > u% > > > > > > 2F > > > > > > f3 > > > > > > 5b > > > > > > 6902-6f5e-4cd0-be64-c50bbaaf54a5&data=05%7C01%7Cjeffm%40microsoft. > > > > > > com%7C5784d93aa78543c3535408da9637c306%7C72f988bf86f141af91ab2 > > > > > > d7 > > > > > > cd > > > > > > 01 > > > > > > 1d > > > > > > b47%7C1%7C0%7C637987463498496191%7CUnknown%7CTWFpbGZsb3d8eyJWI > > > > > > jo > > > > > > iM > > > > > > C4 > > > > > > wL > > > > > > jAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7 > > > > > > C% > > > > > > 7C > > > > > > %7 > > > > > > C& > > > > > > amp;sdata=uKOEQ%2FildzknOS5dUiy0qrcwJjTwzgML%2B6Zf1c8KaHs%3D&a > > > > > > mp > > > > > > ;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%2 > > > > > > F% > > > > > > 2F > > > > > > do > > > > > > cs > > > > > > .microsoft.com%2Fen-us%2Fopenspecs%2Fwindows_protocols%2Fms-ki > > > > > > le > > > > > > %2 > > > > > > F2 > > > > > > 5f > > > > > > abd02-560d-4c1f-8f42-b32e9d97996a&data=05%7C01%7Cjeffm%40m > > > > > > ic > > > > > > ro > > > > > > so > > > > > > ft > > > > > > .com%7C5784d93aa78543c3535408da9637c306%7C72f988bf86f141af91ab > > > > > > 2d > > > > > > 7c > > > > > > d0 > > > > > > 11 > > > > > > db47%7C1%7C0%7C637987463498496191%7CUnknown%7CTWFpbGZsb3d8eyJW > > > > > > Ij > > > > > > 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 > > > > [email protected] > > > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2F > > > > li > > > > st > > > > s.samba.org%2Fmailman%2Flistinfo%2Fcifs-protocol&data=05%7C01% > > > > 7C > > > > je > > > > ffm%40microsoft.com%7C163a1dbf984c42d8412f08da9a3171be%7C72f988bf8 > > > > 6f > > > > 14 > > > > 1af91ab2d7cd011db47%7C1%7C0%7C637991834755000738%7CUnknown%7CTWFpb > > > > GZ > > > > sb > > > > 3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0 > > > > %3 > > > > D% > > > > 7C2000%7C%7C%7C&sdata=tokIPnq2Hup7m2%2Fer438hZ1boXeVGZS%2BxMb4 > > > > Rb > > > > bB > > > > WXs%3D&reserved=0 > > > > > > -- > > > / Alexander Bokovoy > > > > -- > > / Alexander Bokovoy > > > -- / Alexander Bokovoy _______________________________________________ cifs-protocol mailing list [email protected] https://lists.samba.org/mailman/listinfo/cifs-protocol
