Hi Alexander, I took a closer look at the TTT traces uploaded by Julien. I'm not finding KERB-ERROR-DATA structures with an extended error code of 136. I'm not sure what that would be, as it is not an NTSTATUS code.
The NTSTATUS codes returned in the KERB-EXT-ERROR structures: >From the first trace: 0xc000000d -1073741811 >STATUS_INVALID_PARAMETER An invalid parameter was passed to a service >or function. >From the second trace: 0xc000009a -1073741670 >STATUS_INSUFFICIENT_RESOURCES Insufficient system resources exist to >complete the API. 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: Friday, September 23, 2022 10:08 AM To: Alexander Bokovoy <[email protected]> Cc: Julien Rische <[email protected]>; Microsoft Support <[email protected]>; [email protected] Subject: RE: [cifs-protocol] [EXTERNAL] KERB-ERROR-DATA code 136 - TrackingID#2209200040006923 Hi Alexander, I will submit a ticket for consideration by our Kerberos team. 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 <[email protected]> Sent: Thursday, September 22, 2022 10:08 PM To: Jeff McCashland (He/him) <[email protected]> Cc: Julien Rische <[email protected]>; Microsoft Support <[email protected]>; [email protected] Subject: Re: [cifs-protocol] [EXTERNAL] KERB-ERROR-DATA code 136 - TrackingID#2209200040006923 On ke, 21 syys 2022, Jeff McCashland (He/him) wrote: > Hi Alexander, > > Yes, that is the correct section, and I believe you are interpreting the > table correctly. Thank you. I did a short experiment by forcing signature algorithm to HMAC_SHA1_96_AES256 for all PrivSvr buffer signatures in FreeIPA and AD DCs seem to be happy now. I encountered another issue but that is within FreeIPA as we are too tight with SID requester checks now that AD DC response comes through. Could you please document krb5 error response 136 somehow? It is definitely not something that is covered in MS-KILE. > > 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%7C097ac315fdc94ca2731208da9d21888f%7C72f988bf86f141af91ab2d7cd011d > b47%7C1%7C0%7C637995064963196059%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wL > jAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000%7C%7C%7C& > amp;sdata=9FxKvszLf%2FOOIUDkxfAwjBkvkhbgAoE6YEUXtewbcDc%3D&reserve > d=0 | Extension 1138300 > > -----Original Message----- > From: Alexander Bokovoy <[email protected]> > Sent: Wednesday, September 21, 2022 12:44 PM > To: Jeff McCashland (He/him) <[email protected]> > Cc: Julien Rische <[email protected]>; Microsoft Support > <[email protected]>; [email protected] > Subject: Re: [cifs-protocol] [EXTERNAL] KERB-ERROR-DATA code 136 - > TrackingID#2209200040006923 > > 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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flear > n.microsoft.com%2Fen-us%2Fopenspecs%2Fwindows_protocols%2Fms-pac%2F312 > 2bf00-ea87-4c3f-92a0-91c0a99f5eec&data=05%7C01%7Cjeffm%40microsoft > .com%7C097ac315fdc94ca2731208da9d21888f%7C72f988bf86f141af91ab2d7cd011 > db47%7C1%7C0%7C637995064963196059%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4w > LjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000%7C%7C%7C > &sdata=W5IYBkkFeh%2BeGMmThhBga3dZ9jn6x7wV5lAfdRx52h4%3D&reserv > ed=0 > > ----------------------------------------------------------------------------------------------------------------- > 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: > > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fsup > > po > > rt.microsoft.com%2Fglobalenglish&data=05%7C01%7Cjeffm%40microsoft. > > com%7C6179d9c558374313cbcb08da9c09a49d%7C72f988bf86f141af91ab2d7cd01 > > 1d > > b47%7C1%7C0%7C637993862889279864%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4 > > wL > > jAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000%7C%7C%7 > > C& > > amp;sdata=r6zdeZeDYwsnGBz4wzpm94OE2Z5qZiE0AXV%2BChMHDRA%3D&reser > > ve > > d=0 | 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: > > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fsup > > po > > rt.microsoft.com%2Fglobalenglish&data=05%7C01%7Cjeffm%40microsoft. > > com%7C6179d9c558374313cbcb08da9c09a49d%7C72f988bf86f141af91ab2d7cd01 > > 1d > > b47%7C1%7C0%7C637993862889279864%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4 > > wL > > jAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000%7C%7C%7 > > C& > > amp;sdata=r6zdeZeDYwsnGBz4wzpm94OE2Z5qZiE0AXV%2BChMHDRA%3D&reser > > ve > > d=0 | 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%2F > > > su > > > pp > > > ort.microsoft.com%2Ffiles%3Fworkspace%3DeyJ0eXAiOiJKV1QiLCJhbGciOi > > > JS > > > Uz > > > I1NiJ9.eyJ3c2lkIjoiMDM4NDM5ZTgtZjI1ZC00Y2FmLTkwMmEtNWIyNDRiNGEyZDM > > > xI > > > iw > > > ic3IiOiIyMjA5MjAwMDQwMDA2OTIzIiwiYXBwaWQiOiI0ZTc2ODkxZC04NDUwLTRlN > > > WU > > > tY > > > mUzOC1lYTNiZDZlZjIxZTUiLCJzdiI6InYxIiwicnMiOiJFeHRlcm5hbCIsInd0aWQ > > > iO > > > iJ > > > lYjNjOTdhZi1lMTdjLTRhZTctYjFlMy0yNGZlOTU3ZmNkMjMiLCJpc3MiOiJodHRwc > > > zo > > > vL > > > 2FwaS5kdG1uZWJ1bGEubWljcm9zb2Z0LmNvbSIsImF1ZCI6Imh0dHA6Ly9zbWMiLCJ > > > le > > > HA > > > iOjE2NzE0NjkzNDMsIm5iZiI6MTY2MzY5MzM0M30.aeANIe2nm_SnaTLrVFqBibVpB > > > wO > > > e3 > > > I3wmO2fLkXPKqplXqI25krK3M2oHDLCvHIM6LXJ7Z97CKWddAho_qUs7AXRWG8Ati7 > > > vz > > > Oq > > > EW1jegi3t-nnUcNMDu_KErIES6oTLxinQOvRdpApr0WuJf_iJby4gK7EgC8L8JOvNy > > > 1X > > > 0z > > > wArbJaLBOMjdw1aDJa__m3mw7aAMOy3FTYaR9uKGPC9ZllcAJprETOU24Ts0-HThX6 > > > 7q > > > 0Z > > > XdSvxlLSiiUTNA6hBGQ4SFBFgNVtpo7ox5ZYEB1mwpy7X9zAYo3usSCfRKe0ju1LWK > > > ck > > > e5 > > > CN8r5cjzUBZegCjaAcDpZQ5MKbQnZDd3g%26wid%3D038439e8-f25d-4caf-902a- > > > 5b > > > 24 > > > 4b4a2d31&data=05%7C01%7Cjeffm%40microsoft.com%7Caa204126498d42 > > > 2e > > > 71 > > > c408da9be2f408%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637993 > > > 69 > > > 63 > > > 24465845%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luM > > > zI > > > iL > > > CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=sEezQUzzaz > > > zB > > > 5T > > > 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%2Fs > > > up > > > po > > > rt.microsoft.com%2Fglobalenglish&data=05%7C01%7Cjeffm%40microsoft. > > > com%7Caa204126498d422e71c408da9be2f408%7C72f988bf86f141af91ab2d7cd > > > 01 > > > 1d > > > b47%7C1%7C0%7C637993696324465845%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiM > > > C4 > > > wL > > > jAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C > > > %7 > > > C& > > > amp;sdata=FOQtQGmGGlM745kzBB8Z3kBLHHjOr3Ntp5y86WsrcGY%3D&reser > > > ve > > > d= > > > 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%2Fs > > > up > > > po > > > rt.microsoft.com%2Fglobalenglish&data=05%7C01%7Cjeffm%40microsoft. > > > com%7Caa204126498d422e71c408da9be2f408%7C72f988bf86f141af91ab2d7cd > > > 01 > > > 1d > > > b47%7C1%7C0%7C637993696324465845%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiM > > > C4 > > > wL > > > jAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C > > > %7 > > > C& > > > amp;sdata=FOQtQGmGGlM745kzBB8Z3kBLHHjOr3Ntp5y86WsrcGY%3D&reser > > > ve > > > d= > > > 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%2 > > > > Fs > > > > up > > > > po > > > > rt.microsoft.com%2Fglobalenglish&data=05%7C01%7Cjeffm%40microsoft. > > > > com%7C54153b0d6a314e4c635b08da9ac975a2%7C72f988bf86f141af91ab2d7 > > > > cd > > > > 01 > > > > 1d > > > > b47%7C1%7C0%7C637992487471990696%7CUnknown%7CTWFpbGZsb3d8eyJWIjo > > > > iM > > > > C4 > > > > wL > > > > jAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000%7C% > > > > 7C > > > > %7 > > > > C& > > > > amp;sdata=Cf5nCrlWOp%2Fq2yefHW0CVasW4zl8B%2BuOtdFxlyuB6cY%3D& > > > > ;r > > > > es > > > > 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 > > > > > %2 > > > > > Fs > > > > > up > > > > > po > > > > > rt.microsoft.com%2Fglobalenglish&data=05%7C01%7Cjeffm%40microsoft. > > > > > com%7C163a1dbf984c42d8412f08da9a3171be%7C72f988bf86f141af91ab2 > > > > > d7 > > > > > cd > > > > > 01 > > > > > 1d > > > > > b47%7C1%7C0%7C637991834754844507%7CUnknown%7CTWFpbGZsb3d8eyJWI > > > > > jo > > > > > iM > > > > > C4 > > > > > wL > > > > > jAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7 > > > > > C% > > > > > 7C > > > > > %7 > > > > > C& > > > > > amp;sdata=gZnYaF1%2B2KWsTHCKlF%2BBP1OY3El9QKI33R86ckSOgr0%3D&a > > > > > mp > > > > > ;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 > > > > > %2 > > > > > Fs > > > > > up > > > > > po > > > > > rt.microsoft.com%2Fglobalenglish&data=05%7C01%7Cjeffm%40microsoft. > > > > > com%7C163a1dbf984c42d8412f08da9a3171be%7C72f988bf86f141af91ab2 > > > > > d7 > > > > > cd > > > > > 01 > > > > > 1d > > > > > b47%7C1%7C0%7C637991834754844507%7CUnknown%7CTWFpbGZsb3d8eyJWI > > > > > jo > > > > > iM > > > > > C4 > > > > > wL > > > > > jAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7 > > > > > C% > > > > > 7C > > > > > %7 > > > > > C& > > > > > amp;sdata=gZnYaF1%2B2KWsTHCKlF%2BBP1OY3El9QKI33R86ckSOgr0%3D&a > > > > > mp > > > > > ;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%7C72f988bf86f141af91a > > > > > > b2 > > > > > > d7 > > > > > > cd > > > > > > 01 > > > > > > 1d > > > > > > b47%7C1%7C0%7C637987805901775050%7CUnknown%7CTWFpbGZsb3d8eyJ > > > > > > WI > > > > > > jo > > > > > > iM > > > > > > C4 > > > > > > wL > > > > > > jAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000 > > > > > > %7 > > > > > > C% > > > > > > 7C > > > > > > %7 > > > > > > C& > > > > > > amp;sdata=JtHTcsXnoZTTyll5asTlG3spHubJ1U8OzSlM2VsIvp0%3D& > > > > > > ;r > > > > > > es > > > > > > 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%3DeyJ0eXAiOiJKV1QiLC > > > > > > > Jh > > > > > > > bG > > > > > > > ci > > > > > > > Oi > > > > > > > JS > > > > > > > Uz > > > > > > > I1NiJ9.eyJ3c2lkIjoiNzQ2NmNlOTUtYjQwNi00NzM4LThjMDEtMTJjMTM > > > > > > > zN > > > > > > > jU > > > > > > > 4M > > > > > > > zA > > > > > > > 4I > > > > > > > iw > > > > > > > ic3IiOiIyMjA5MTIwMDQwMDA2MjUxIiwiYXBwaWQiOiI0ZTc2ODkxZC04N > > > > > > > DU > > > > > > > wL > > > > > > > TR > > > > > > > lN > > > > > > > WU > > > > > > > tY > > > > > > > mUzOC1lYTNiZDZlZjIxZTUiLCJzdiI6InYxIiwicnMiOiJFeHRlcm5hbCI > > > > > > > sI > > > > > > > nd > > > > > > > 0a > > > > > > > WQ > > > > > > > iO > > > > > > > iI > > > > > > > yNTE3ZDA2Yi0wNTY1LTQwZTYtYmUwZi0zNWEwNTY1ZTM2NDQiLCJpc3MiO > > > > > > > iJ > > > > > > > od > > > > > > > HR > > > > > > > wc > > > > > > > zo > > > > > > > vL > > > > > > > 2FwaS5kdG1uZWJ1bGEubWljcm9zb2Z0LmNvbSIsImF1ZCI6Imh0dHA6Ly9 > > > > > > > zb > > > > > > > WM > > > > > > > iL > > > > > > > CJ > > > > > > > le > > > > > > > HA > > > > > > > iOjE2NzA4NzY3NzcsIm5iZiI6MTY2MzEwMDc3N30.FMEx9xM5hrwYjID69 > > > > > > > wV > > > > > > > 0q > > > > > > > J1 > > > > > > > nD > > > > > > > sE > > > > > > > ff > > > > > > > D9JLWTxZhf0GKPXGa9U8EZy5BbVtOLDQEdyAl4uEyGrDmH1-YlEB-byxDh > > > > > > > A_ > > > > > > > TY > > > > > > > jC > > > > > > > Xv > > > > > > > Fv > > > > > > > y6 > > > > > > > z2Eu5G8GlfV6CKMEDc9JJUYIMAROLBoKHIEQxXBoehoru1Z8cHGtyHqwfJ > > > > > > > Um > > > > > > > fn > > > > > > > h_ > > > > > > > 33 > > > > > > > mf > > > > > > > k6 > > > > > > > 84qdwrhiMSwxi94AxovZ4n2BVPVzopPi_s1EGiwse28zg8ccKthEAGH4qs > > > > > > > 3q > > > > > > > Vm > > > > > > > Af > > > > > > > _V > > > > > > > 7y > > > > > > > 8F > > > > > > > 52dimwkfLvTSq1AvB3ZI0elDTDh8_rOR1FgW57v1sbVIl1art_hmqquWbJ > > > > > > > Cx > > > > > > > a- > > > > > > > oW > > > > > > > 9_ > > > > > > > iW > > > > > > > kX > > > > > > > 2n4OzZNmyhagfgF6XmMqdKl3LuV69u24Q%26wid%3D7466ce95-b406-47 > > > > > > > 38 > > > > > > > -8 > > > > > > > c0 > > > > > > > 1- > > > > > > > 12 > > > > > > > c1 > > > > > > > 33658308&data=05%7C01%7Cjeffm%40microsoft.com%7C5784d9 > > > > > > > 3a > > > > > > > a7 > > > > > > > 85 > > > > > > > 43 > > > > > > > c3 > > > > > > > 53 > > > > > > > 5408da9637c306%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0% > > > > > > > 7C > > > > > > > 63 > > > > > > > 79 > > > > > > > 87 > > > > > > > 46 > > > > > > > 34 > > > > > > > 98496191%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQI > > > > > > > jo > > > > > > > iV > > > > > > > 2l > > > > > > > uM > > > > > > > zI > > > > > > > iL > > > > > > > CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=yw > > > > > > > WL > > > > > > > rz > > > > > > > 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%3 > > > > > > > A% > > > > > > > 2F > > > > > > > %2 > > > > > > > Fs > > > > > > > up > > > > > > > po > > > > > > > rt.microsoft.com%2Fglobalenglish&data=05%7C01%7Cjeffm%40microsoft. > > > > > > > com%7C5784d93aa78543c3535408da9637c306%7C72f988bf86f141af9 > > > > > > > 1a > > > > > > > b2 > > > > > > > d7 > > > > > > > cd > > > > > > > 01 > > > > > > > 1d > > > > > > > b47%7C1%7C0%7C637987463498496191%7CUnknown%7CTWFpbGZsb3d8e > > > > > > > yJ > > > > > > > WI > > > > > > > jo > > > > > > > iM > > > > > > > C4 > > > > > > > wL > > > > > > > jAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C30 > > > > > > > 00 > > > > > > > %7 > > > > > > > C% > > > > > > > 7C > > > > > > > %7 > > > > > > > C& > > > > > > > amp;sdata=HLnwmeRNNJTOW9L1zl6f82H59KU4IN9SAK%2F5bjeWZL8%3D > > > > > > > &a > > > > > > > mp > > > > > > > ;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%3 > > > > > > > A% > > > > > > > 2F > > > > > > > %2 > > > > > > > Fs > > > > > > > up > > > > > > > po > > > > > > > rt.microsoft.com%2Fglobalenglish&data=05%7C01%7Cjeffm%40microsoft. > > > > > > > com%7C5784d93aa78543c3535408da9637c306%7C72f988bf86f141af9 > > > > > > > 1a > > > > > > > b2 > > > > > > > d7 > > > > > > > cd > > > > > > > 01 > > > > > > > 1d > > > > > > > b47%7C1%7C0%7C637987463498496191%7CUnknown%7CTWFpbGZsb3d8e > > > > > > > yJ > > > > > > > WI > > > > > > > jo > > > > > > > iM > > > > > > > C4 > > > > > > > wL > > > > > > > jAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C30 > > > > > > > 00 > > > > > > > %7 > > > > > > > C% > > > > > > > 7C > > > > > > > %7 > > > > > > > C& > > > > > > > amp;sdata=HLnwmeRNNJTOW9L1zl6f82H59KU4IN9SAK%2F5bjeWZL8%3D > > > > > > > &a > > > > > > > mp > > > > > > > ;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%2Fm > > > > > > > s- > > > > > > > sf > > > > > > > u% > > > > > > > 2F > > > > > > > f3 > > > > > > > 5b > > > > > > > 6902-6f5e-4cd0-be64-c50bbaaf54a5&data=05%7C01%7Cjeffm%40microsoft. > > > > > > > com%7C5784d93aa78543c3535408da9637c306%7C72f988bf86f141af9 > > > > > > > 1a > > > > > > > b2 > > > > > > > d7 > > > > > > > cd > > > > > > > 01 > > > > > > > 1d > > > > > > > b47%7C1%7C0%7C637987463498496191%7CUnknown%7CTWFpbGZsb3d8e > > > > > > > yJ > > > > > > > WI > > > > > > > jo > > > > > > > iM > > > > > > > C4 > > > > > > > wL > > > > > > > jAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C30 > > > > > > > 00 > > > > > > > %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%2Fm > > > > > > > s- > > > > > > > ki > > > > > > > le > > > > > > > %2 > > > > > > > F2 > > > > > > > 5f > > > > > > > abd02-560d-4c1f-8f42-b32e9d97996a&data=05%7C01%7Cjeffm > > > > > > > %4 > > > > > > > 0m > > > > > > > ic > > > > > > > ro > > > > > > > so > > > > > > > ft > > > > > > > .com%7C5784d93aa78543c3535408da9637c306%7C72f988bf86f141af > > > > > > > 91 > > > > > > > ab > > > > > > > 2d > > > > > > > 7c > > > > > > > d0 > > > > > > > 11 > > > > > > > db47%7C1%7C0%7C637987463498496191%7CUnknown%7CTWFpbGZsb3d8 > > > > > > > ey > > > > > > > JW > > > > > > > Ij > > > > > > > oi > > > > > > > MC > > > > > > > 4w > > > > > > > LjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3 > > > > > > > 00 > > > > > > > 0% > > > > > > > 7C > > > > > > > %7 > > > > > > > C% > > > > > > > 7C > > > > > > > &sdata=NrPdAACaR3Srj4XL%2Bk7S7SzsZF%2BV8eRbMbcCSpR5uPI > > > > > > > %3 > > > > > > > D& > > > > > > > am > > > > > > > p; > > > > > > > re > > > > > > > se > > > > > > > rved=0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > cifs-protocol mailing list > > > > > [email protected] > > > > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2 > > > > > F% > > > > > 2F > > > > > li > > > > > st > > > > > s.samba.org%2Fmailman%2Flistinfo%2Fcifs-protocol&data=05%7 > > > > > C0 > > > > > 1% > > > > > 7C > > > > > je > > > > > ffm%40microsoft.com%7C163a1dbf984c42d8412f08da9a3171be%7C72f98 > > > > > 8b > > > > > f8 > > > > > 6f > > > > > 14 > > > > > 1af91ab2d7cd011db47%7C1%7C0%7C637991834755000738%7CUnknown%7CT > > > > > WF > > > > > pb > > > > > GZ > > > > > sb > > > > > 3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI > > > > > 6M > > > > > n0 > > > > > %3 > > > > > D% > > > > > 7C2000%7C%7C%7C&sdata=tokIPnq2Hup7m2%2Fer438hZ1boXeVGZS%2B > > > > > xM > > > > > b4 > > > > > Rb > > > > > bB > > > > > WXs%3D&reserved=0 > > > > > > > > -- > > > > / Alexander Bokovoy > > > > > > -- > > > / Alexander Bokovoy > > > > > > > -- > / Alexander Bokovoy -- / Alexander Bokovoy _______________________________________________ cifs-protocol mailing list [email protected] https://lists.samba.org/mailman/listinfo/cifs-protocol
