[cifs-protocol] [EXTERNAL] [MS-SFU] Clarify the new NonForwardableDelegation flag - TrackingID#2107090040004014

Jeff McCashland jeffm at microsoft.com
Tue Jul 27 20:31:33 UTC 2021


Hi Isaac,

You are correct about the NonForwardableDelegation enabled behavior: 
If the evidence ticket is not forwardable, the KDC immediately returns KDC_ERR_BADOPTION with the status code STATUS_ACCOUNT_RESTRICTION.

Best regards,
Jeff McCashland | Senior Escalation Engineer | Microsoft Protocol Open Specifications Team 

-----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