On pe, 23 syys 2022, Jeff McCashland (He/him) wrote:
> 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.
Thanks. Perhaps this is an issue with Wireshark parsing.
From the second trace, packet 12:
Kerberos
Record Mark: 362 bytes
0... .... .... .... .... .... .... .... = Reserved: Not set
.000 0000 0000 0000 0000 0001 0110 1010 = Record Length: 362
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…
If I'd take the e-data content through dumpasn1, it says
$ dumpasn1 -a -hh bytes
<30 81 F4 30 81 F1 A1 04 02 02 00 88 A2 81 E8 04 81 E5 A0 81 E2 30 81 DF>
0 244: SEQUENCE {
<30 81 F1 A1 04 02 02 00 88 A2 81 E8 04 81 E5 A0 81 E2 30 81 DF A0 81 DC>
3 241: SEQUENCE {
<A1 04 02 02 00 88>
6 4: [1] {
<02 02 00 88>
8 2: INTEGER 136
: }
<A2 81 E8 04 81 E5 A0 81 E2 30 81 DF A0 81 DC 30 81 D9 A0 03 02 01 12 A2>
12 232: [2] {
<04 81 E5 A0 81 E2 30 81 DF A0 81 DC 30 81 D9 A0 03 02 01 12 A2 81 D1 04>
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
: 5D D1 FA 5F 98 2F C9 64 EC 8A 04 2A DB DC 19 AF
: D6 03 35 83 60 D3 D7 7F 44 07 94 9F 6F 28 2E 1A
: B3 BB CB 7E C6 E7 A4 11 53 90 DE E5 45 0D F1 6B
: F7 44 58 B9 04 3D 12 FF A0 81 84 D4 14 F2 9D 5A
: 03 68 67 94 3C 26 4A B3 89 41 A6 FC BB A9 3B E1
: C5 F9 18 1B BA 67 29 06 E8 4D D3 3E 26 8F 29 7D
: 6A 8F 95 87 E3
: }
: }
: }
0 warnings, 0 errors.
So this looks like a valid ASN.1 structure of a sequence inside a
sequence, e.g. like a TYPED-DATA from RFC4120 section 5.9.1. 'KRB_ERROR
Definition'.
The inner one looks like MS-KILE 2.2.2 KERB-ERROR-DATA:
KERB-ERROR-DATA ::= SEQUENCE {
data-type [1] INTEGER,
data-value [2] OCTET STRING OPTIONAL
}
That is why I asked about 'data-type' value INTEGER 136.
On the other hand, MS-KILE 2.2.2 says this structure may be returned by
an application server, not KDC. KDC would return KERB-EXT-ERROR (MS-KILE
2.2.1):
typedef struct KERB_EXT_ERROR {
unsigned long status;
unsigned long reserved;
unsigned long flags;
} KERB_EXT_ERROR;
but MS-KILE 2.2.1 does not specify which encoding would be used here,
while MS-KILE 2.2 says it should be ASN.1 DER.
So, if this e-data is KERB-EXT-ERROR, is it encoded with NDR? There are
244 bytes there, clearly more than three 'unsigned long' fields, even in
NDR.
>
> 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
--
/ Alexander Bokovoy
_______________________________________________
cifs-protocol mailing list
[email protected]
https://lists.samba.org/mailman/listinfo/cifs-protocol
