[cifs-protocol] [EXTERNAL] [MS-SFU] Clarify the new NonForwardableDelegation flag - TrackingID#2107090040004014
Jeff McCashland
jeffm at microsoft.com
Tue Jul 27 20:15:19 UTC 2021
Hi Isaac,
Thank you for the additional observations and information. I will continue working with our CVE team to get verification and clarification.
Best regards,
Jeff McCashland | 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
We value your feedback. My manager is Natesha Morrison (namorri), +1 (704) 430-4292
-----Original Message-----
From: Isaac Boukris <iboukris at gmail.com>
Sent: Tuesday, July 27, 2021 7:16 AM
To: Jeff McCashland <jeffm at microsoft.com>
Cc: cifs-protocol at lists.samba.org; Greg Hudson <ghudson at mit.edu>; Jeff McCashland <jeffm at microsoftsupport.com>
Subject: Re: [EXTERNAL] [MS-SFU] Clarify the new NonForwardableDelegation flag - TrackingID#2107090040004014
On Tue, Jul 27, 2021 at 3:43 PM Isaac Boukris <iboukris at gmail.com> wrote:
>
> I've run a couple of tests, it looks like the behavior did change
> significantly, as now any service with an empty
> msDS-AllowedToDelegateTo list is treated as TrustedToAuthForDelegation
> and gets forwardable tickets with S4U2Self, on the other hand when the
> new NonForwardableDelegation is enabled (set to 0..), then the
> evidence ticket is required to be forwardable even in RBCD.
>
> Please confirm and update the documentation accordingly, especially
> for the cross-realm RBCD case which I suppose would also require
> forwardable tickets and the other realm is trusted for that.
Looking at the updated doc again, I can see that the S4U2Self change is already documented in MS-SFU 3.2.5.1.2, but not the S4U2Proxy part in 3.2.5.2.3, assuming we only need to document the NonForwardableDelegation enabled behavior (which I understand will be the default), then I guess we can remove the 'UserAccountControl'
check and simply say that: if the service ticket in the additional-tickets field is not set to forwardable then the KDC MUST return KRB-ERR-BADOPTION ..
Thanks
More information about the cifs-protocol
mailing list