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

Alexander Bokovoy ab at samba.org
Tue Sep 20 05:32:04 UTC 2022


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: http://support.microsoft.com/globalenglish | 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%2Fsuppo
> > rt.microsoft.com%2Fglobalenglish&data=05%7C01%7Cjeffm%40microsoft.
> > com%7C163a1dbf984c42d8412f08da9a3171be%7C72f988bf86f141af91ab2d7cd011d
> > b47%7C1%7C0%7C637991834754844507%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wL
> > jAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&
> > amp;sdata=gZnYaF1%2B2KWsTHCKlF%2BBP1OY3El9QKI33R86ckSOgr0%3D&reser
> > 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%2Fsuppo
> > rt.microsoft.com%2Fglobalenglish&data=05%7C01%7Cjeffm%40microsoft.
> > com%7C163a1dbf984c42d8412f08da9a3171be%7C72f988bf86f141af91ab2d7cd011d
> > b47%7C1%7C0%7C637991834754844507%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wL
> > jAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&
> > amp;sdata=gZnYaF1%2B2KWsTHCKlF%2BBP1OY3El9QKI33R86ckSOgr0%3D&reser
> > 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%2Fsup
> > > po 
> > > rt.microsoft.com%2Fglobalenglish&data=05%7C01%7Cjeffm%40microsoft.
> > > com%7C9dc19bb9dec5477ad0bb08da96877b29%7C72f988bf86f141af91ab2d7cd01
> > > 1d 
> > > b47%7C1%7C0%7C637987805901775050%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4
> > > wL 
> > > jAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7
> > > C& 
> > > amp;sdata=JtHTcsXnoZTTyll5asTlG3spHubJ1U8OzSlM2VsIvp0%3D&reserve
> > > d=
> > > 0 | Extension 1138300
> > >
> > > -----Original Message-----
> > > From: Julien Rische <jrische at redhat.com>
> > > Sent: Wednesday, September 14, 2022 2:59 AM
> > > To: Jeff McCashland (He/him) <jeffm at microsoft.com>
> > > Cc: cifs-protocol at lists.samba.org; Microsoft Support 
> > > <supportmail at microsoft.com>
> > > Subject: Re: [EXTERNAL] KERB-ERROR-DATA code 136 -
> > > TrackingID#2209120040006251
> > >
> > > Hello Jeff,
> > >
> > > Thank you for your response. I logged into the file transfer workspace, but it is empty. I don't see any "PartnerTTDRecorder_x86_x64.zip" file inside.
> > >
> > > I see a "tttracer.exe" executable file is already provided on the system, but there is no window popping up when I run the command you have sent me. So I guess it is not the same one. I am using Windows Server 2019 Standard.
> > >
> > > Could you add the TTDRecorder file in the workspace please?
> > >
> > > Thank you in advance,
> > >
> > > --
> > > Julien Rische
> > > Software Engineer
> > > Red Hat
> > >
> > > On Tue, Sep 13, 2022 at 10:37 PM Jeff McCashland (He/him) <jeffm at microsoft.com> wrote:
> > > >
> > > > Hi Julien,
> > > >
> > > > I have created a File Transfer workspace for exchanging files (link and credentials below) related to this issue: "Cross-realm AD TGS request from an MIT Kerberos client (realm trust)[1]". To troubleshoot this issue, I would like to collect LSASS TTT traces and a concurrent network packet capture.
> > > >
> > > > The LSASS traces can be quite large, but are highly compressible, so please add them to a .zip archive before uploading (file transfer workspace credentials are below). Please log into the workspace and find PartnerTTDRecorder_x86_x64.zip available for download. The x64 tool can be staged onto the Windows server in any location (instructions below assume C:\TTD).
> > > >
> > > > To collect the needed traces:
> > > >         1. From a PowerShell prompt, execute:
> > > >                 C:\TTD\tttracer.exe -Attach ([int](Get-Process -NAME lsass | Format-Wide -Property ID).formatEntryInfo.formatPropertyField.propertyValue)
> > > >         2. Wait for a little window to pop up in top left corner of your screen, titled "lsass01.run"
> > > >         3. start a network trace using netsh or WireShark, etc.
> > > >         4. Repro the attempted operation
> > > >         5. Stop the network trace and save it
> > > >         6. CAREFULLY: uncheck the checkbox next to "Tracing" in the small "lsass01.run" window. Do not close or exit the small window or you will need to reboot.
> > > >         7. The TTTracer.exe process will generate a trace file, then print out the name and location of the file.
> > > > Compress the *.run file into a .zip archive before uploading with the matching network trace. It is a good idea to reboot the machine at the next opportunity to restart the lsass process.
> > > >
> > > > Workspace credentials:
> > > > Log in as: 2209120040006251_julien at dtmxfer.onmicrosoft.com
> > > > 1-Time: ;@[r@(E9
> > > >
> > > > Link:
> > > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> > > > su
> > > > pp
> > > > ort.microsoft.com%2Ffiles%3Fworkspace%3DeyJ0eXAiOiJKV1QiLCJhbGciOi
> > > > JS
> > > > Uz
> > > > I1NiJ9.eyJ3c2lkIjoiNzQ2NmNlOTUtYjQwNi00NzM4LThjMDEtMTJjMTMzNjU4MzA
> > > > 4I
> > > > iw
> > > > ic3IiOiIyMjA5MTIwMDQwMDA2MjUxIiwiYXBwaWQiOiI0ZTc2ODkxZC04NDUwLTRlN
> > > > WU
> > > > tY
> > > > mUzOC1lYTNiZDZlZjIxZTUiLCJzdiI6InYxIiwicnMiOiJFeHRlcm5hbCIsInd0aWQ
> > > > iO
> > > > iI
> > > > yNTE3ZDA2Yi0wNTY1LTQwZTYtYmUwZi0zNWEwNTY1ZTM2NDQiLCJpc3MiOiJodHRwc
> > > > zo
> > > > vL
> > > > 2FwaS5kdG1uZWJ1bGEubWljcm9zb2Z0LmNvbSIsImF1ZCI6Imh0dHA6Ly9zbWMiLCJ
> > > > le
> > > > HA
> > > > iOjE2NzA4NzY3NzcsIm5iZiI6MTY2MzEwMDc3N30.FMEx9xM5hrwYjID69wV0qJ1nD
> > > > sE
> > > > ff
> > > > D9JLWTxZhf0GKPXGa9U8EZy5BbVtOLDQEdyAl4uEyGrDmH1-YlEB-byxDhA_TYjCXv
> > > > Fv
> > > > y6
> > > > z2Eu5G8GlfV6CKMEDc9JJUYIMAROLBoKHIEQxXBoehoru1Z8cHGtyHqwfJUmfnh_33
> > > > mf
> > > > k6
> > > > 84qdwrhiMSwxi94AxovZ4n2BVPVzopPi_s1EGiwse28zg8ccKthEAGH4qs3qVmAf_V
> > > > 7y
> > > > 8F
> > > > 52dimwkfLvTSq1AvB3ZI0elDTDh8_rOR1FgW57v1sbVIl1art_hmqquWbJCxa-oW9_
> > > > iW
> > > > kX
> > > > 2n4OzZNmyhagfgF6XmMqdKl3LuV69u24Q%26wid%3D7466ce95-b406-4738-8c01-
> > > > 12
> > > > c1
> > > > 33658308&data=05%7C01%7Cjeffm%40microsoft.com%7C5784d93aa78543
> > > > c3
> > > > 53
> > > > 5408da9637c306%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637987
> > > > 46
> > > > 34
> > > > 98496191%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luM
> > > > zI
> > > > iL
> > > > CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ywWLrzP3Yv
> > > > cZ
> > > > 9e
> > > > XwuTqoPq5j1%2FaZisjhea%2F2Tv9nsD0%3D&reserved=0
> > > >
> > > > Best regards,
> > > > Jeff McCashland (He/him) | Senior Escalation Engineer | Microsoft 
> > > > Protocol Open Specifications Team
> > > > Phone: +1 (425) 703-8300 x38300 | Hours: 9am-5pm | Time zone:
> > > > (UTC-08:00) Pacific Time (US and Canada) Local country phone 
> > > > number found here:
> > > > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fs
> > > > up
> > > > po
> > > > rt.microsoft.com%2Fglobalenglish&data=05%7C01%7Cjeffm%40microsoft.
> > > > com%7C5784d93aa78543c3535408da9637c306%7C72f988bf86f141af91ab2d7cd
> > > > 01
> > > > 1d
> > > > b47%7C1%7C0%7C637987463498496191%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiM
> > > > C4
> > > > wL
> > > > jAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C
> > > > %7
> > > > C&
> > > > amp;sdata=HLnwmeRNNJTOW9L1zl6f82H59KU4IN9SAK%2F5bjeWZL8%3D&res
> > > > er
> > > > ve
> > > > d=0 | Extension 1138300
> > > >
> > > > -----Original Message-----
> > > > From: Jeff McCashland (He/him)
> > > > Sent: Tuesday, September 13, 2022 12:15 PM
> > > > To: Julien Rische <jrische at redhat.com>
> > > > Cc: cifs-protocol at lists.samba.org; Microsoft Support 
> > > > <supportmail at microsoft.com>
> > > > Subject: RE: [EXTERNAL] KERB-ERROR-DATA code 136 -
> > > > TrackingID#2209120040006251
> > > >
> > > > [Michael to BCC]
> > > >
> > > > Hi Julien,
> > > >
> > > > I will reply again in an hour or two with instructions to collect and upload traces for the scenario. This will be the best way to determine the actual root cause of the error. Let's start with the first scenario, then if that answer does not resolve the second scenario, we'll create a new SR case and collect additional traces.
> > > >
> > > > Best regards,
> > > > Jeff McCashland (He/him) | Senior Escalation Engineer | Microsoft 
> > > > Protocol Open Specifications Team
> > > > Phone: +1 (425) 703-8300 x38300 | Hours: 9am-5pm | Time zone:
> > > > (UTC-08:00) Pacific Time (US and Canada) Local country phone 
> > > > number found here:
> > > > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fs
> > > > up
> > > > po
> > > > rt.microsoft.com%2Fglobalenglish&data=05%7C01%7Cjeffm%40microsoft.
> > > > com%7C5784d93aa78543c3535408da9637c306%7C72f988bf86f141af91ab2d7cd
> > > > 01
> > > > 1d
> > > > b47%7C1%7C0%7C637987463498496191%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiM
> > > > C4
> > > > wL
> > > > jAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C
> > > > %7
> > > > C&
> > > > amp;sdata=HLnwmeRNNJTOW9L1zl6f82H59KU4IN9SAK%2F5bjeWZL8%3D&res
> > > > er
> > > > ve
> > > > d=0 | Extension 1138300
> > > >
> > > > -----Original Message-----
> > > > From: Michael Bowen <Mike.Bowen at microsoft.com>
> > > > Sent: Monday, September 12, 2022 9:42 AM
> > > > To: Julien Rische <jrische at redhat.com>
> > > > Cc: cifs-protocol at lists.samba.org; Microsoft Support 
> > > > <supportmail at microsoft.com>
> > > > Subject: RE: [EXTERNAL] KERB-ERROR-DATA code 136 -
> > > > TrackingID#2209120040006251
> > > >
> > > > [DocHelp to bcc]
> > > >
> > > > Hi Julien,
> > > >
> > > > Thank you for contacting Microsoft Open Specification Support. We created case number 2209120040006251 for this inquiry. Please leave the case number in the subject line and cc supportmail at microsoft.com when responding to emails. One of our team members will follow up with you soon.
> > > >
> > > > Mike Bowen
> > > > Escalation Engineer - Microsoft Open Specifications
> > > >
> > > > -----Original Message-----
> > > > From: Julien Rische <jrische at redhat.com>
> > > > Sent: Monday, September 12, 2022 7:01 AM
> > > > To: Interoperability Documentation Help <dochelp at microsoft.com>
> > > > Cc: cifs-protocol at lists.samba.org
> > > > Subject: [EXTERNAL] KERB-ERROR-DATA code 136
> > > >
> > > > [Some people who received this message don't often get email from 
> > > > jrische at redhat.com. Learn why this is important at 
> > > > https://aka.ms/LearnAboutSenderIdentification ]
> > > >
> > > > Hello team,
> > > >
> > > > We are experiencing Active Directory interoperability issues for the MIT Kerberos 1.20 release, which is introducing generation of PAC for all tickets by default. There are two scenarios:
> > > >
> > > > * Cross-realm AD TGS request from an MIT Kerberos client (realm 
> > > > trust)[1]
> > > > * Cross-realm S4U2Self request for a FreeIPA service to impersonate an AD user
> > > >   (forest trust)[2]
> > > >
> > > > In both cases, a TGS-REQ[3][4] against AD using the cross-realm TGT results in a generic error (MS-SFU 4.2 step 3[5] in S4U2Self case). We suspect these two failures may have the same underlying cause, because of the "e-data" attribute from the KRB_ERR_GENERIC message[6][7]:
> > > >
> > > > SEQUENCE {
> > > >   SEQUENCE {
> > > >     [1] {
> > > >       INTEGER 136
> > > >       }
> > > >     [2] {
> > > >       OCTET STRING
> > > >         ...
> > > >       }
> > > >     }
> > > >   }
> > > >
> > > > The octet string is different, but the integer is the same in both scenarios.
> > > > According to the MS-KILE specification, this piece of data should be a KERB-ERROR-DATA structure[8]. However the 136 integer do not match any of the documented "data-type" values.
> > > >
> > > > This error is most likely related to the PAC, because in the realm trust case, the cross-realm TGS-REQ works in case PAC support is disable on the MIT KDC (i.e. the MIT TGT does not contain a PAC).
> > > >
> > > > Could you please give us more details about KERB-ERROR-DATA code 136, and check if you see anything wrong in the PACs that are being used in these 2 scenarios?
> > > >
> > > > --
> > > > Julien Rische
> > > > Software Engineer
> > > > Red Hat
> > > >
> > > >
> > > > [1] krb5_1_20_mit_ad_realm_trust.(pcap|keytab) files in attachment 
> > > > [2]
> > > > krb5_1_20_ipa_ad_trust_s4u2self.(pcapng|keytab) files in 
> > > > attachment [3] krb5_1_20_mit_ad_realm_trust.pcap packet no. 7 [4] 
> > > > krb5_1_20_ipa_ad_trust_s4u2self.pcapng packet no. 11 [5] 
> > > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> > > > do
> > > > cs
> > > > .microsoft.com%2Fen-us%2Fopenspecs%2Fwindows_protocols%2Fms-sfu%2F
> > > > f3
> > > > 5b
> > > > 6902-6f5e-4cd0-be64-c50bbaaf54a5&data=05%7C01%7Cjeffm%40microsoft.
> > > > com%7C5784d93aa78543c3535408da9637c306%7C72f988bf86f141af91ab2d7cd
> > > > 01
> > > > 1d
> > > > b47%7C1%7C0%7C637987463498496191%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiM
> > > > C4
> > > > wL
> > > > jAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C
> > > > %7
> > > > C&
> > > > amp;sdata=uKOEQ%2FildzknOS5dUiy0qrcwJjTwzgML%2B6Zf1c8KaHs%3D&r
> > > > es
> > > > er
> > > > ved=0 [6] e-data in krb5_1_20_mit_ad_realm_trust.pcap packet no. 8 
> > > > or krb5_1_20_mit_ad_realm_trust_edata.blob in attachment [7] 
> > > > e-data in krb5_1_20_ipa_ad_trust_s4u2self.pcapng packet no. 12 or 
> > > > krb5_1_20_ipa_ad_trust_s4u2self_edata.blob in attachment [8] 
> > > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> > > > do
> > > > cs
> > > > .microsoft.com%2Fen-us%2Fopenspecs%2Fwindows_protocols%2Fms-kile%2
> > > > F2
> > > > 5f
> > > > abd02-560d-4c1f-8f42-b32e9d97996a&data=05%7C01%7Cjeffm%40micro
> > > > so
> > > > ft
> > > > .com%7C5784d93aa78543c3535408da9637c306%7C72f988bf86f141af91ab2d7c
> > > > d0
> > > > 11
> > > > db47%7C1%7C0%7C637987463498496191%7CUnknown%7CTWFpbGZsb3d8eyJWIjoi
> > > > MC
> > > > 4w
> > > > LjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7
> > > > C%
> > > > 7C
> > > > &sdata=NrPdAACaR3Srj4XL%2Bk7S7SzsZF%2BV8eRbMbcCSpR5uPI%3D&
> > > > re
> > > > se
> > > > rved=0
> > > >
> > >
> > 
> > 
> > _______________________________________________
> > cifs-protocol mailing list
> > cifs-protocol at lists.samba.org
> > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist
> > s.samba.org%2Fmailman%2Flistinfo%2Fcifs-protocol&data=05%7C01%7Cje
> > ffm%40microsoft.com%7C163a1dbf984c42d8412f08da9a3171be%7C72f988bf86f14
> > 1af91ab2d7cd011db47%7C1%7C0%7C637991834755000738%7CUnknown%7CTWFpbGZsb
> > 3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%
> > 7C2000%7C%7C%7C&sdata=tokIPnq2Hup7m2%2Fer438hZ1boXeVGZS%2BxMb4RbbB
> > WXs%3D&reserved=0
> 
> --
> / Alexander Bokovoy

-- 
/ Alexander Bokovoy



More information about the cifs-protocol mailing list