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

Jeff McCashland (He/him) jeffm at microsoft.com
Mon Sep 26 23:22:21 UTC 2022


Hi Alexander,

I will investigate the parsing and work to clarify the response. 

Best regards,
Jeff McCashland (He/him) | Senior Escalation Engineer | Microsoft Protocol Open Specifications Team 
Phone: +1 (425) 703-8300 x38300 | Hours: 9am-5pm | Time zone: (UTC-08:00) Pacific Time (US and Canada)
Local country phone number found here: http://support.microsoft.com/globalenglish | Extension 1138300

-----Original Message-----
From: Alexander Bokovoy <ab at samba.org> 
Sent: Saturday, September 24, 2022 1:57 AM
To: Jeff McCashland (He/him) <jeffm at microsoft.com>
Cc: Julien Rische <jrische at redhat.com>; Microsoft Support <supportmail at microsoft.com>; cifs-protocol at lists.samba.org
Subject: Re: [cifs-protocol] [EXTERNAL] KERB-ERROR-DATA code 136 - TrackingID#2209200040006923

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/master.ipa.test at IPA.TEST
        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: https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fsupport.microsoft.com%2Fglobalenglish&data=05%7C01%7Cjeffm%40microsoft.com%7Cbc4e6c7da2364ab3999608da9e0aaf16%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637996066391656944%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000%7C%7C%7C&sdata=tlvS4zWjqgUviLSDQ3P093%2FdtTm9Y92VzhVKfiDo2yU%3D&reserved=0 | Extension 1138300
> 
> -----Original Message-----
> From: Jeff McCashland (He/him) 
> Sent: Friday, September 23, 2022 10:08 AM
> To: Alexander Bokovoy <ab at samba.org>
> Cc: Julien Rische <jrische at redhat.com>; Microsoft Support <supportmail at microsoft.com>; cifs-protocol at lists.samba.org
> 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: https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fsupport.microsoft.com%2Fglobalenglish&data=05%7C01%7Cjeffm%40microsoft.com%7Cbc4e6c7da2364ab3999608da9e0aaf16%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637996066391656944%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000%7C%7C%7C&sdata=tlvS4zWjqgUviLSDQ3P093%2FdtTm9Y92VzhVKfiDo2yU%3D&reserved=0 | Extension 1138300
> 
> -----Original Message-----
> From: Alexander Bokovoy <ab at samba.org>
> Sent: Thursday, September 22, 2022 10:08 PM
> To: Jeff McCashland (He/him) <jeffm at microsoft.com>
> Cc: Julien Rische <jrische at redhat.com>; Microsoft Support <supportmail at microsoft.com>; cifs-protocol at lists.samba.org
> 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 <ab at samba.org>
> > Sent: Wednesday, September 21, 2022 12:44 PM
> > To: Jeff McCashland (He/him) <jeffm at microsoft.com>
> > Cc: Julien Rische <jrische at redhat.com>; Microsoft Support 
> > <supportmail at microsoft.com>; cifs-protocol at lists.samba.org
> > 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 <jrische at redhat.com>
> > > Cc: Alexander Bokovoy <ab at samba.org>; Microsoft Support 
> > > <supportmail at microsoft.com>; cifs-protocol at lists.samba.org
> > > 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 <jrische at redhat.com>
> > > Sent: Wednesday, September 21, 2022 8:07 AM
> > > To: Jeff McCashland (He/him) <jeffm at microsoft.com>
> > > Cc: Alexander Bokovoy <ab at samba.org>; Microsoft Support 
> > > <supportmail at microsoft.com>; cifs-protocol at lists.samba.org
> > > 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) <jeffm at microsoft.com> wrote:
> > > >
> > > > [Updated SR ID on Subject]
> > > >
> > > > Hi Julien,
> > > >
> > > > We have created SR 2209200040006923 to track this alternate scenario where all the requisite data structures are in the PAC. Please upload LSASS TTT traces as before, and upload using these new credentials:
> > > >
> > > > Log in as: 2209200040006923_julien at dtmxfer.onmicrosoft.com
> > > > 1-Time: 3xx3+xW]
> > > >
> > > > Workspace link:
> > > > https://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 <ab at samba.org>
> > > > Cc: Julien Rische <jrische at redhat.com>; 
> > > > cifs-protocol at lists.samba.org; Microsoft Support 
> > > > <supportmail at microsoft.com>
> > > > Subject: RE: [cifs-protocol] [EXTERNAL] KERB-ERROR-DATA code 136 -
> > > > TrackingID#2209120040006251
> > > >
> > > > Thank you Alexander, I did miss that the structure was present.
> > > >
> > > > Julien, please hold off on uploading the TTT traces for the moment. To help us keep straight on this end, I'm having a new SR made and will send new credentials for uploading the next set of traces.
> > > >
> > > > Best regards,
> > > > Jeff McCashland (He/him) | Senior Escalation Engineer | Microsoft 
> > > > Protocol Open Specifications Team
> > > > Phone: +1 (425) 703-8300 x38300 | Hours: 9am-5pm | Time zone: 
> > > > (UTC-08:00) Pacific Time (US and Canada) Local country phone 
> > > > number found here:
> > > > 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 <ab at samba.org>
> > > > Sent: Monday, September 19, 2022 10:32 PM
> > > > To: Jeff McCashland (He/him) <jeffm at microsoft.com>
> > > > Cc: Julien Rische <jrische at redhat.com>; 
> > > > cifs-protocol at lists.samba.org; Microsoft Support 
> > > > <supportmail at microsoft.com>
> > > > Subject: Re: [cifs-protocol] [EXTERNAL] KERB-ERROR-DATA code 136 -
> > > > TrackingID#2209120040006251
> > > >
> > > > Hi Jeff,
> > > >
> > > > On ma, 19 syys 2022, Jeff McCashland (He/him) wrote:
> > > > > Hi Alexander,
> > > > >
> > > > > Unfortunately, the error information in the network trace, as 
> > > > > you notice, is not sufficient to determine the cause of failure, 
> > > > > which is why I collected the TTT trace. The TTT trace I received 
> > > > > fails twice, both times due to the missing LOGON_INFO structure 
> > > > > (1). As I read the [MS-PAC] documentation quoted below, 
> > > > > structures 1, 6, 7, and A are all required. Each element states 
> > > > > "PAC structures MUST contain one buffer of this type". You 
> > > > > mentioned one of the originally attached traces includes structures 1, 6, and 7, but I don't see A listed.
> > > > >
> > > > > Do you have any examples that appear to be the same failure, where all 4 required structures are present?
> > > >
> > > > type A is present in the list I provided in my previous email (Client Info Type (10) is the type A), sorry for not calling it out explicitly:
> > > >
> > > >  ad-data: 070000000000000001000000e001000078000000000000000c000000a200000058020000...
> > > >      Verified Server checksum 16 keytype 18 using keytab principal krbtgt/WIN2022.TEST at IPA.TEST (id=keytab.13 same=0) (db7c3ac9...)
> > > >      Verified KDC checksum 20 keytype 20 using keytab principal krbtgt/IPA.TEST at IPA.TEST (id=keytab.1 same=0) (bb2dfa43...)
> > > >      Num Entries: 7
> > > >      Version: 0
> > > >      Type: Logon Info (1)
> > > >      Type: UPN DNS Info (12)
> > > >      Type: Unknown (17)
> > > >      Type: Unknown (18)
> > > >      Type: Client Info Type (10)
> > > >      Type: Server Checksum (6)
> > > >      Type: Privsvr Checksum (7)
> > > >
> > > > So all four required buffers are present but AD DCs reject S4U requests.
> > > >
> > > > Julien is going to generate a TTT trace for this use case. I'm sure we might have some incompatibility in FreeIPA implementation but we cannot find what is broken so far, due to this undocumented error response.
> > > >
> > > > One of my theories is that it might be related to the FAST channel wrapping ticket. FAST is the pre-auth type 136. Is AD DC expecting that the FAST channel ticket, if present, also must have a PAC with the required buffers? Where is this documented?
> > > >
> > > > So far, 'MS-KILE 3.3.5.7.4 Compound Identity' might be the closest one but it doesn't apply as the FAST TGS-REQ is armored with the TGT of a computer in a trusted forest, not from the AD itself. This part of MS-KILE spec probably needs a bit of clarification as well.
> > > >
> > > > Another theory is that MIT Kerberos might produce incorrect Client Info package -- it supposed to have username at userrealm formatted name according to 'MS-SFU 3.2.5.1.1 KDC Replies with Referral TGT':
> > > >
> > > > ---------------
> > > > If the KDC supports the Privilege Attribute Certificate Data Structure [MS-PAC], and a PAC is provided, the referral TGT Name field in the PAC_CLIENT_INFO structure of the PAC contains username at userRealm. This format is the syntax of the single-string representation ([RFC1964] section 2.1.1) using the username and userRealm fields from the PA-FOR-USER pre-authentication data.
> > > > ---------------
> > > >
> > > > We send this client info buffer:
> > > >
> > > > Type: Client Info Type (10)
> > > >     Size: 50
> > > >     Offset: 808
> > > >     PAC_CLIENT_INFO_TYPE: 808cae3b8ac2d801280068006f00730074002f006d00610073007400650072002e006900...
> > > >         ClientID: Sep  7, 2022 10:19:57.000000000 EEST
> > > >         Name Length: 40
> > > >         Name: host/master.ipa.test
> > > >
> > > > instead of 'host/master.ipa.test at IPA.TEST'.
> > > >
> > > > >
> > > > > Best regards,
> > > > > Jeff McCashland (He/him) | Senior Escalation Engineer | 
> > > > > Microsoft Protocol Open Specifications Team
> > > > > Phone: +1 (425) 703-8300 x38300 | Hours: 9am-5pm | Time zone:
> > > > > (UTC-08:00) Pacific Time (US and Canada) Local country phone 
> > > > > number found here:
> > > > > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%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&amp
> > > > > ;r
> > > > > es
> > > > > er
> > > > > ved=0 | Extension 1138300
> > > > >
> > > > > -----Original Message-----
> > > > > From: Alexander Bokovoy <ab at samba.org>
> > > > > Sent: Monday, September 19, 2022 4:24 AM
> > > > > To: Jeff McCashland (He/him) <jeffm at microsoft.com>
> > > > > Cc: Julien Rische <jrische at redhat.com>; 
> > > > > cifs-protocol at lists.samba.org; Microsoft Support 
> > > > > <supportmail at microsoft.com>
> > > > > Subject: Re: [cifs-protocol] [EXTERNAL] KERB-ERROR-DATA code 136
> > > > > -
> > > > > TrackingID#2209120040006251
> > > > >
> > > > > Hi Jeff,
> > > > >
> > > > > On pe, 16 syys 2022, Jeff McCashland (He/him) via cifs-protocol wrote:
> > > > > > Hi Julien,
> > > > > >
> > > > > > Based on my debugging and research, the issue appears to be 
> > > > > > that the PAC does not include PAC_LOGON_INFO (type 1).
> > > > > >
> > > > > > The PAC appears to only include PAC_INFO_BUFFER types 6, 7, and A.
> > > > >
> > > > > We see the same problem for the IPA trace from the original 
> > > > > Julien's attachment [2]:
> > > > > krb5_1_20_ipa_ad_trust_s4u2self.(pcapng|keytab)
> > > > > files
> > > > >
> > > > > Packet 9 of the trace contains TGS-REQ with a PAC with seven buffers, including types 1, 6, and 7:
> > > > >
> > > > > ad-data: 070000000000000001000000e001000078000000000000000c000000a200000058020000...
> > > > >     Verified Server checksum 16 keytype 18 using keytab principal krbtgt/WIN2022.TEST at IPA.TEST (id=keytab.13 same=0) (db7c3ac9...)
> > > > >     Verified KDC checksum 20 keytype 20 using keytab principal krbtgt/IPA.TEST at IPA.TEST (id=keytab.1 same=0) (bb2dfa43...)
> > > > >     Num Entries: 7
> > > > >     Version: 0
> > > > >     Type: Logon Info (1)
> > > > >     Type: UPN DNS Info (12)
> > > > >     Type: Unknown (17)
> > > > >     Type: Unknown (18)
> > > > >     Type: Client Info Type (10)
> > > > >     Type: Server Checksum (6)
> > > > >     Type: Privsvr Checksum (7)
> > > > >
> > > > > Yet, we get the same Kerberos error:
> > > > >
> > > > > krb-error
> > > > >     pvno: 5
> > > > >     msg-type: krb-error (30)
> > > > >     stime: 2022-09-07 07:20:01 (UTC)
> > > > >     susec: 583266
> > > > >     error-code: eRR-GENERIC (60)
> > > > >     realm: WIN2022.TEST
> > > > >     sname
> > > > >         name-type: kRB5-NT-ENTERPRISE-PRINCIPAL (10)
> > > > >         sname-string: 1 item
> > > > >             SNameString: host/master.ipa.test at IPA.TEST
> > > > >     e-data: 3081f43081f1a10402020088a281e80481e5a081e23081dfa081dc3081d9a003020112a2...
> > > > >
> > > > > The e-data contains the same style sequence with KERB-ERROR-DATA code 136:
> > > > >
> > > > >   0 244: SEQUENCE {
> > > > >   3 241:   SEQUENCE {
> > > > >   6   4:     [1] {
> > > > >   8   2:       INTEGER 136
> > > > >        :       }
> > > > >  12 232:     [2] {
> > > > >  15 229:       OCTET STRING
> > > > >        :         A0 81 E2 30 81 DF A0 81 DC 30 81 D9 A0 03 02 01
> > > > >        :         12 A2 81 D1 04 81 CE 65 E8 3C 7A 86 1A C6 04 DC
> > > > >        :         8B C7 FB E7 2A 18 0B 18 06 C0 15 3C 4D 09 9C 66
> > > > >        :         06 69 4F 40 1C 8C 39 29 B6 1C BE 4C DB 0D 5C 98
> > > > >        :         2B A8 34 04 6C 67 FB 5D 92 A6 73 CF 7F 84 00 84
> > > > >        :         F0 33 9B 35 96 96 2E FD 94 D3 4E BC 4F 03 C6 56
> > > > >        :         48 45 CA E2 FE 75 B0 3C 21 FE 1B 02 77 70 F3 5F
> > > > >        :         6A 48 16 D1 91 85 94 FF B9 93 2F F1 4C 99 05 80
> > > > >        :                 [ Another 101 bytes skipped ]
> > > > >        :       }
> > > > >        :     }
> > > > >        :   }
> > > > >
> > > > >
> > > > >
> > > > > >
> > > > > > 2.4 PAC_INFO_BUFFER
> > > > > > ulType (4 bytes): A 32-bit unsigned integer in little-endian 
> > > > > > format that describes the type of data present in the buffer 
> > > > > > contained at Offset.
> > > > > >
> > > > > > 0x00000001 Logon information (section 2.5). PAC structures MUST contain one buffer of this type. Additional logon information buffers MUST be ignored.
> > > > > > 0x00000006 Server checksum (section 2.8). PAC structures MUST contain one buffer of this type. Additional logon server checksum buffers MUST be ignored.
> > > > > > 0x00000007 KDC (privilege server) checksum (section 2.8). PAC structures MUST contain one buffer of this type. Additional KDC checksum buffers MUST be ignored.
> > > > > > 0x0000000A Client name and ticket information (section 2.7). PAC structures MUST contain one buffer of this type. Additional client and ticket information buffers MUST be ignored.
> > > > > >
> > > > > > Let me know if that resolves one or both issues.
> > > > > >
> > > > > > Best regards,
> > > > > > Jeff McCashland (He/him) | Senior Escalation Engineer | 
> > > > > > Microsoft Protocol Open Specifications Team
> > > > > > Phone: +1 (425) 703-8300 x38300 | Hours: 9am-5pm | Time zone:
> > > > > > (UTC-08:00) Pacific Time (US and Canada) Local country phone 
> > > > > > number found here:
> > > > > > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F
> > > > > > %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 <jrische at redhat.com>
> > > > > > Cc: cifs-protocol at lists.samba.org; Microsoft Support 
> > > > > > <supportmail at microsoft.com>
> > > > > > Subject: RE: [EXTERNAL] KERB-ERROR-DATA code 136 -
> > > > > > TrackingID#2209120040006251
> > > > > >
> > > > > > Hi Julien,
> > > > > >
> > > > > > I have received the files you uploaded. It is not necessary to run the alternate commands if the first one worked. Please retain the tools and information in case we need to collect additional traces.
> > > > > >
> > > > > > I will analyze these traces and let you know what I find.
> > > > > >
> > > > > > Best regards,
> > > > > > Jeff McCashland (He/him) | Senior Escalation Engineer | 
> > > > > > Microsoft Protocol Open Specifications Team
> > > > > > Phone: +1 (425) 703-8300 x38300 | Hours: 9am-5pm | Time zone:
> > > > > > (UTC-08:00) Pacific Time (US and Canada) Local country phone 
> > > > > > number found here:
> > > > > > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F
> > > > > > %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 <jrische at redhat.com>
> > > > > > Sent: Wednesday, September 14, 2022 12:30 PM
> > > > > > To: Jeff McCashland (He/him) <jeffm at microsoft.com>
> > > > > > Cc: cifs-protocol at lists.samba.org; Microsoft Support 
> > > > > > <supportmail at microsoft.com>
> > > > > > Subject: Re: [EXTERNAL] KERB-ERROR-DATA code 136 -
> > > > > > TrackingID#2209120040006251
> > > > > >
> > > > > > Hi Jeff,
> > > > > >
> > > > > > My bad, I tried to log in again and the file was there. I probably messed up with the session cookie.
> > > > > >
> > > > > > I uploaded these three files into the workspace:
> > > > > > * lsass01.run.zip: compressed output file from TTTracer.exe
> > > > > > * mit_kdc.pcap: Kerberos network trace captured on the MIT KDC
> > > > > > * credentials.keytab: Kerberos keys from MIT and AD
> > > > > >
> > > > > > I used the first TTTrace.exe command you have sent. Please let me know if I should use the second command you mentioned instead.
> > > > > >
> > > > > > --
> > > > > > Julien Rische
> > > > > > Software Engineer
> > > > > > Red Hat
> > > > > >
> > > > > > On Wed, Sep 14, 2022 at 5:30 PM Jeff McCashland (He/him) <jeffm at microsoft.com> wrote:
> > > > > > >
> > > > > > > Hi Julien,
> > > > > > >
> > > > > > > Please ensure that you are logging onto the workspace using the provided credentials, as it may automatically log you on with other credentials and provide a different view. I have confirmed the .zip file is on the workspace and available for you to download.
> > > > > > >
> > > > > > > Also, please try these alternate steps in place of step 1:
> > > > > > > a) On your Windows Server, open an elevated command prompt and enter the command: tasklist /FI 'IMAGENAME eq lsass'
> > > > > > > b) Note the PID number in the output from the above command, and use it in the next command:
> > > > > > > c) Execute: C:\TTD\TTTracer.exe -attach PID
> > > > > > >
> > > > > > > Best regards,
> > > > > > > Jeff McCashland (He/him) | Senior Escalation Engineer | 
> > > > > > > Microsoft Protocol Open Specifications Team
> > > > > > > Phone: +1 (425) 703-8300 x38300 | Hours: 9am-5pm | Time zone:
> > > > > > > (UTC-08:00) Pacific Time (US and Canada) Local country phone 
> > > > > > > number found here:
> > > > > > > https://nam06.safelinks.protection.outlook.com/?url=http%3A%
> > > > > > > 2F
> > > > > > > %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&amp
> > > > > > > ;r
> > > > > > > es
> > > > > > > er
> > > > > > > ve
> > > > > > > d=
> > > > > > > 0 | Extension 1138300
> > > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Julien Rische <jrische at redhat.com>
> > > > > > > Sent: Wednesday, September 14, 2022 2:59 AM
> > > > > > > To: Jeff McCashland (He/him) <jeffm at microsoft.com>
> > > > > > > Cc: cifs-protocol at lists.samba.org; Microsoft Support 
> > > > > > > <supportmail at microsoft.com>
> > > > > > > Subject: Re: [EXTERNAL] KERB-ERROR-DATA code 136 -
> > > > > > > TrackingID#2209120040006251
> > > > > > >
> > > > > > > Hello Jeff,
> > > > > > >
> > > > > > > Thank you for your response. I logged into the file transfer workspace, but it is empty. I don't see any "PartnerTTDRecorder_x86_x64.zip" file inside.
> > > > > > >
> > > > > > > I see a "tttracer.exe" executable file is already provided on the system, but there is no window popping up when I run the command you have sent me. So I guess it is not the same one. I am using Windows Server 2019 Standard.
> > > > > > >
> > > > > > > Could you add the TTDRecorder file in the workspace please?
> > > > > > >
> > > > > > > Thank you in advance,
> > > > > > >
> > > > > > > --
> > > > > > > Julien Rische
> > > > > > > Software Engineer
> > > > > > > Red Hat
> > > > > > >
> > > > > > > On Tue, Sep 13, 2022 at 10:37 PM Jeff McCashland (He/him) <jeffm at microsoft.com> wrote:
> > > > > > > >
> > > > > > > > Hi Julien,
> > > > > > > >
> > > > > > > > I have created a File Transfer workspace for exchanging files (link and credentials below) related to this issue: "Cross-realm AD TGS request from an MIT Kerberos client (realm trust)[1]". To troubleshoot this issue, I would like to collect LSASS TTT traces and a concurrent network packet capture.
> > > > > > > >
> > > > > > > > The LSASS traces can be quite large, but are highly compressible, so please add them to a .zip archive before uploading (file transfer workspace credentials are below). Please log into the workspace and find PartnerTTDRecorder_x86_x64.zip available for download. The x64 tool can be staged onto the Windows server in any location (instructions below assume C:\TTD).
> > > > > > > >
> > > > > > > > To collect the needed traces:
> > > > > > > >         1. From a PowerShell prompt, execute:
> > > > > > > >                 C:\TTD\tttracer.exe -Attach ([int](Get-Process -NAME lsass | Format-Wide -Property ID).formatEntryInfo.formatPropertyField.propertyValue)
> > > > > > > >         2. Wait for a little window to pop up in top left corner of your screen, titled "lsass01.run"
> > > > > > > >         3. start a network trace using netsh or WireShark, etc.
> > > > > > > >         4. Repro the attempted operation
> > > > > > > >         5. Stop the network trace and save it
> > > > > > > >         6. CAREFULLY: uncheck the checkbox next to "Tracing" in the small "lsass01.run" window. Do not close or exit the small window or you will need to reboot.
> > > > > > > >         7. The TTTracer.exe process will generate a trace file, then print out the name and location of the file.
> > > > > > > > Compress the *.run file into a .zip archive before uploading with the matching network trace. It is a good idea to reboot the machine at the next opportunity to restart the lsass process.
> > > > > > > >
> > > > > > > > Workspace credentials:
> > > > > > > > Log in as: 2209120040006251_julien at dtmxfer.onmicrosoft.com
> > > > > > > > 1-Time: ;@[r@(E9
> > > > > > > >
> > > > > > > > Link:
> > > > > > > > https://nam06.safelinks.protection.outlook.com/?url=https%
> > > > > > > > 3A
> > > > > > > > %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 <jrische at redhat.com>
> > > > > > > > Cc: cifs-protocol at lists.samba.org; Microsoft Support 
> > > > > > > > <supportmail at microsoft.com>
> > > > > > > > Subject: RE: [EXTERNAL] KERB-ERROR-DATA code 136 -
> > > > > > > > TrackingID#2209120040006251
> > > > > > > >
> > > > > > > > [Michael to BCC]
> > > > > > > >
> > > > > > > > Hi Julien,
> > > > > > > >
> > > > > > > > I will reply again in an hour or two with instructions to collect and upload traces for the scenario. This will be the best way to determine the actual root cause of the error. Let's start with the first scenario, then if that answer does not resolve the second scenario, we'll create a new SR case and collect additional traces.
> > > > > > > >
> > > > > > > > Best regards,
> > > > > > > > Jeff McCashland (He/him) | Senior Escalation Engineer | 
> > > > > > > > Microsoft Protocol Open Specifications Team
> > > > > > > > Phone: +1 (425) 703-8300 x38300 | Hours: 9am-5pm | Time zone:
> > > > > > > > (UTC-08:00) Pacific Time (US and Canada) Local country 
> > > > > > > > phone number found here:
> > > > > > > > https://nam06.safelinks.protection.outlook.com/?url=http%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 <Mike.Bowen at microsoft.com>
> > > > > > > > Sent: Monday, September 12, 2022 9:42 AM
> > > > > > > > To: Julien Rische <jrische at redhat.com>
> > > > > > > > Cc: cifs-protocol at lists.samba.org; Microsoft Support 
> > > > > > > > <supportmail at microsoft.com>
> > > > > > > > Subject: RE: [EXTERNAL] KERB-ERROR-DATA code 136 -
> > > > > > > > TrackingID#2209120040006251
> > > > > > > >
> > > > > > > > [DocHelp to bcc]
> > > > > > > >
> > > > > > > > Hi Julien,
> > > > > > > >
> > > > > > > > Thank you for contacting Microsoft Open Specification Support. We created case number 2209120040006251 for this inquiry. Please leave the case number in the subject line and cc supportmail at microsoft.com when responding to emails. One of our team members will follow up with you soon.
> > > > > > > >
> > > > > > > > Mike Bowen
> > > > > > > > Escalation Engineer - Microsoft Open Specifications
> > > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: Julien Rische <jrische at redhat.com>
> > > > > > > > Sent: Monday, September 12, 2022 7:01 AM
> > > > > > > > To: Interoperability Documentation Help 
> > > > > > > > <dochelp at microsoft.com>
> > > > > > > > Cc: cifs-protocol at lists.samba.org
> > > > > > > > Subject: [EXTERNAL] KERB-ERROR-DATA code 136
> > > > > > > >
> > > > > > > > [Some people who received this message don't often get 
> > > > > > > > email from jrische at redhat.com. Learn why this is important 
> > > > > > > > at https://aka.ms/LearnAboutSenderIdentification ]
> > > > > > > >
> > > > > > > > Hello team,
> > > > > > > >
> > > > > > > > We are experiencing Active Directory interoperability issues for the MIT Kerberos 1.20 release, which is introducing generation of PAC for all tickets by default. There are two scenarios:
> > > > > > > >
> > > > > > > > * Cross-realm AD TGS request from an MIT Kerberos client 
> > > > > > > > (realm trust)[1]
> > > > > > > > * Cross-realm S4U2Self request for a FreeIPA service to impersonate an AD user
> > > > > > > >   (forest trust)[2]
> > > > > > > >
> > > > > > > > In both cases, a TGS-REQ[3][4] against AD using the cross-realm TGT results in a generic error (MS-SFU 4.2 step 3[5] in S4U2Self case). We suspect these two failures may have the same underlying cause, because of the "e-data" attribute from the KRB_ERR_GENERIC message[6][7]:
> > > > > > > >
> > > > > > > > SEQUENCE {
> > > > > > > >   SEQUENCE {
> > > > > > > >     [1] {
> > > > > > > >       INTEGER 136
> > > > > > > >       }
> > > > > > > >     [2] {
> > > > > > > >       OCTET STRING
> > > > > > > >         ...
> > > > > > > >       }
> > > > > > > >     }
> > > > > > > >   }
> > > > > > > >
> > > > > > > > The octet string is different, but the integer is the same in both scenarios.
> > > > > > > > According to the MS-KILE specification, this piece of data should be a KERB-ERROR-DATA structure[8]. However the 136 integer do not match any of the documented "data-type" values.
> > > > > > > >
> > > > > > > > This error is most likely related to the PAC, because in the realm trust case, the cross-realm TGS-REQ works in case PAC support is disable on the MIT KDC (i.e. the MIT TGT does not contain a PAC).
> > > > > > > >
> > > > > > > > Could you please give us more details about KERB-ERROR-DATA code 136, and check if you see anything wrong in the PACs that are being used in these 2 scenarios?
> > > > > > > >
> > > > > > > > --
> > > > > > > > Julien Rische
> > > > > > > > Software Engineer
> > > > > > > > Red Hat
> > > > > > > >
> > > > > > > >
> > > > > > > > [1] krb5_1_20_mit_ad_realm_trust.(pcap|keytab) files in 
> > > > > > > > attachment [2]
> > > > > > > > krb5_1_20_ipa_ad_trust_s4u2self.(pcapng|keytab) files in 
> > > > > > > > attachment [3] krb5_1_20_mit_ad_realm_trust.pcap packet no.
> > > > > > > > 7 [4] krb5_1_20_ipa_ad_trust_s4u2self.pcapng packet no. 11 
> > > > > > > > [5] 
> > > > > > > > https://nam06.safelinks.protection.outlook.com/?url=https%
> > > > > > > > 3A
> > > > > > > > %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
> > > > > > cifs-protocol at lists.samba.org
> > > > > > 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



More information about the cifs-protocol mailing list