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:
> http://support.microsoft.com/globalenglish | 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:
> http://support.microsoft.com/globalenglish | 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%2Fsuppo
> > rt.microsoft.com%2Fglobalenglish&data=05%7C01%7Cjeffm%40microsoft.
> > com%7C9dc19bb9dec5477ad0bb08da96877b29%7C72f988bf86f141af91ab2d7cd011d
> > b47%7C1%7C0%7C637987805901775050%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wL
> > jAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&
> > amp;sdata=JtHTcsXnoZTTyll5asTlG3spHubJ1U8OzSlM2VsIvp0%3D&reserved=
> > 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%2F%2Fsu
> > > pp
> > > ort.microsoft.com%2Ffiles%3Fworkspace%3DeyJ0eXAiOiJKV1QiLCJhbGciOiJS
> > > Uz
> > > I1NiJ9.eyJ3c2lkIjoiNzQ2NmNlOTUtYjQwNi00NzM4LThjMDEtMTJjMTMzNjU4MzA4I
> > > iw
> > > ic3IiOiIyMjA5MTIwMDQwMDA2MjUxIiwiYXBwaWQiOiI0ZTc2ODkxZC04NDUwLTRlNWU
> > > tY
> > > mUzOC1lYTNiZDZlZjIxZTUiLCJzdiI6InYxIiwicnMiOiJFeHRlcm5hbCIsInd0aWQiO
> > > iI
> > > yNTE3ZDA2Yi0wNTY1LTQwZTYtYmUwZi0zNWEwNTY1ZTM2NDQiLCJpc3MiOiJodHRwczo
> > > vL
> > > 2FwaS5kdG1uZWJ1bGEubWljcm9zb2Z0LmNvbSIsImF1ZCI6Imh0dHA6Ly9zbWMiLCJle
> > > HA
> > > iOjE2NzA4NzY3NzcsIm5iZiI6MTY2MzEwMDc3N30.FMEx9xM5hrwYjID69wV0qJ1nDsE
> > > ff
> > > D9JLWTxZhf0GKPXGa9U8EZy5BbVtOLDQEdyAl4uEyGrDmH1-YlEB-byxDhA_TYjCXvFv
> > > y6
> > > z2Eu5G8GlfV6CKMEDc9JJUYIMAROLBoKHIEQxXBoehoru1Z8cHGtyHqwfJUmfnh_33mf
> > > k6
> > > 84qdwrhiMSwxi94AxovZ4n2BVPVzopPi_s1EGiwse28zg8ccKthEAGH4qs3qVmAf_V7y
> > > 8F
> > > 52dimwkfLvTSq1AvB3ZI0elDTDh8_rOR1FgW57v1sbVIl1art_hmqquWbJCxa-oW9_iW
> > > kX
> > > 2n4OzZNmyhagfgF6XmMqdKl3LuV69u24Q%26wid%3D7466ce95-b406-4738-8c01-12
> > > c1
> > > 33658308&data=05%7C01%7Cjeffm%40microsoft.com%7C5784d93aa78543c3
> > > 53
> > > 5408da9637c306%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63798746
> > > 34
> > > 98496191%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzI
> > > iL
> > > CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ywWLrzP3YvcZ
> > > 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%2Fsup
> > > po
> > > rt.microsoft.com%2Fglobalenglish&data=05%7C01%7Cjeffm%40microsoft.
> > > com%7C5784d93aa78543c3535408da9637c306%7C72f988bf86f141af91ab2d7cd01
> > > 1d
> > > b47%7C1%7C0%7C637987463498496191%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4
> > > wL
> > > jAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7
> > > C&
> > > amp;sdata=HLnwmeRNNJTOW9L1zl6f82H59KU4IN9SAK%2F5bjeWZL8%3D&reser
> > > ve
> > > d=0 | Extension 1138300
> > >
> > > -----Original Message-----
> > > From: Jeff McCashland (He/him)
> > > Sent: Tuesday, September 13, 2022 12:15 PM
> > > To: Julien Rische <[email protected]>
> > > Cc: [email protected]; Microsoft Support
> > > <[email protected]>
> > > Subject: RE: [EXTERNAL] KERB-ERROR-DATA code 136 -
> > > TrackingID#2209120040006251
> > >
> > > [Michael to BCC]
> > >
> > > Hi Julien,
> > >
> > > I will reply again in an hour or two with instructions to collect and
> > > upload traces for the scenario. This will be the best way to determine
> > > the actual root cause of the error. Let's start with the first scenario,
> > > then if that answer does not resolve the second scenario, we'll create a
> > > new SR case and collect additional traces.
> > >
> > > Best regards,
> > > Jeff McCashland (He/him) | Senior Escalation Engineer | Microsoft
> > > Protocol Open Specifications Team
> > > Phone: +1 (425) 703-8300 x38300 | Hours: 9am-5pm | Time zone:
> > > (UTC-08:00) Pacific Time (US and Canada) Local country phone number
> > > found here:
> > > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fsup
> > > po
> > > rt.microsoft.com%2Fglobalenglish&data=05%7C01%7Cjeffm%40microsoft.
> > > com%7C5784d93aa78543c3535408da9637c306%7C72f988bf86f141af91ab2d7cd01
> > > 1d
> > > b47%7C1%7C0%7C637987463498496191%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4
> > > wL
> > > jAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7
> > > C&
> > > amp;sdata=HLnwmeRNNJTOW9L1zl6f82H59KU4IN9SAK%2F5bjeWZL8%3D&reser
> > > 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%2F%2Fdo
> > > cs
> > > .microsoft.com%2Fen-us%2Fopenspecs%2Fwindows_protocols%2Fms-sfu%2Ff3
> > > 5b
> > > 6902-6f5e-4cd0-be64-c50bbaaf54a5&data=05%7C01%7Cjeffm%40microsoft.
> > > com%7C5784d93aa78543c3535408da9637c306%7C72f988bf86f141af91ab2d7cd01
> > > 1d
> > > b47%7C1%7C0%7C637987463498496191%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4
> > > wL
> > > jAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7
> > > C&
> > > amp;sdata=uKOEQ%2FildzknOS5dUiy0qrcwJjTwzgML%2B6Zf1c8KaHs%3D&res
> > > 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%2Fdo
> > > cs
> > > .microsoft.com%2Fen-us%2Fopenspecs%2Fwindows_protocols%2Fms-kile%2F2
> > > 5f
> > > abd02-560d-4c1f-8f42-b32e9d97996a&data=05%7C01%7Cjeffm%40microso
> > > ft
> > > .com%7C5784d93aa78543c3535408da9637c306%7C72f988bf86f141af91ab2d7cd0
> > > 11
> > > db47%7C1%7C0%7C637987463498496191%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC
> > > 4w
> > > LjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%
> > > 7C
> > > &sdata=NrPdAACaR3Srj4XL%2Bk7S7SzsZF%2BV8eRbMbcCSpR5uPI%3D&re
> > > se
> > > rved=0
> > >
> >
>
>
> _______________________________________________
> cifs-protocol mailing list
> [email protected]
> https://lists.samba.org/mailman/listinfo/cifs-protocol
--
/ Alexander Bokovoy
_______________________________________________
cifs-protocol mailing list
[email protected]
https://lists.samba.org/mailman/listinfo/cifs-protocol
