[cifs-protocol] [EXTERNAL] [MS-KILE] Authentication Policies and RODCs - TrackingID#2310190040000616

Jeff McCashland (He/him) jeffm at microsoft.com
Thu Oct 19 22:50:35 UTC 2023


Hi Joseph,

To debug this issue, I need to collect an LSASS TTT trace. I have created a file transfer workspace for exchanging files related to this issue (link below). 

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 2310190040000616_joseph at dtmxfer.onmicrosoft.com
1-Time: 9dx_7ndz

Workspace link: https://support.microsoft.com/files?workspace=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiJ9.eyJ3c2lkIjoiNWQ2YjE2MzgtYzU5Ni00N2ZhLTkxNDQtN2QzMzMzNmJmNTlhIiwic3IiOiIyMzEwMTkwMDQwMDAwNjE2IiwiYXBwaWQiOiI0ZTc2ODkxZC04NDUwLTRlNWUtYmUzOC1lYTNiZDZlZjIxZTUiLCJzdiI6InYxIiwicnMiOiJFeHRlcm5hbCIsInd0aWQiOiJmNDdhMTY0ZS1jYjFiLTQ2MGQtYjczZS03YWZmZDEwY2Q0YTAiLCJpc3MiOiJodHRwczovL2FwaS5kdG1uZWJ1bGEubWljcm9zb2Z0LmNvbSIsImF1ZCI6Imh0dHA6Ly9zbWMiLCJleHAiOjE3MDU1MzEzMzIsIm5iZiI6MTY5Nzc1NTMzMn0.U82nOV5WR7AK7pNvLhlCsTkcMPfZV9NouoJlJQYbNJeQQ3w5XBrCsAxLolvtXVt85zVs6YDkmF4gN2NxH2GW4DP46UsENY1-Qg4RQ3omGdfy4aqTOprhdzBdDegmq0IDCnz_dB862F_fzkiMtyuMoACCPGFpnufedw5X4a8IVSfdST9enEREWlH1TQHE7KsWKgvJ7aPydEdYoOUDatQ1annMYfhbGttsrXXZfbsSlc1-l5jhGPs9RtGqpgzycy3m9VftAbGjpz4em-_nFAADznArzn4dnIitRjH2zulc-fQRCraq6cgwKJ6BJrxh9BE_4Qq7xjXP4EsSMcB40wE8Kg&wid=5d6b1638-c596-47fa-9144-7d33336bf59a

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: Thursday, October 19, 2023 10:01 AM
To: Joseph Sutton <jsutton at samba.org>; cifs-protocol at lists.samba.org
Cc: Microsoft Support <supportmail at microsoft.com>
Subject: RE: [EXTERNAL] [MS-KILE] Authentication Policies and RODCs - TrackingID#2310190040000616

Hi Joseph,

I will research your issue and get back to you. 

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, October 18, 2023 6:52 PM
To: Joseph Sutton <jsutton at samba.org>; cifs-protocol at lists.samba.org
Cc: Microsoft Support <supportmail at microsoft.com>
Subject: RE: [EXTERNAL] [MS-KILE] Authentication Policies and RODCs - TrackingID#2310190040000616

[DocHelp to BCC, support on CC, SR ID on Subject]

Hi Joseph,

Thank you for your email. We have created SR 2310190040000616 to track this issue. One of our engineers will respond soon. 

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: Joseph Sutton <jsutton at samba.org>
Sent: Wednesday, October 18, 2023 6:44 PM
To: cifs-protocol at lists.samba.org; Interoperability Documentation Help <dochelp at microsoft.com>
Subject: [EXTERNAL] [MS-KILE] Authentication Policies and RODCs

[Some people who received this message don't often get email from jsutton at samba.org. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]

Hi dochelp,

[MS-KILE] 3.3.5.7, “TGS Exchange”, states that if during a TGS Exchange an Authentication Policy with ‘AllowedToAuthenticateTo’ is in effect, the user and device PACs must be used to perform an access check: if the access check succeeds, a service ticket is issued to the client; if it fails, the KDC returns KDC_ERR_POLICY.

However, I have found that Windows Server 2019, acting as a RWDC,
*always* returns KDC_ERR_POLICY if the client’s TGT presented to the KDC has been issued by an RODC.

If no ‘AllowedToAuthenticateTo’ policy is enforced, or the client’s TGT has been issued by a RWDC, the TGS‐REQ exchange is successful.

As far as I can tell, this behaviour — disallowing the combination of authentication policies and RODC‐issued tickets — is not documented anywhere. Is matching this behaviour important for the correct and secure operation of MS-KILE implementations? and if so, can it be clearly documented in [MS-KILE]?

Regards,
Joseph


More information about the cifs-protocol mailing list