[cifs-protocol] [EXTERNAL] Re: [120012821001594] [MS-SFU]Errata from 2019/12/09 - if RBCD bit is set should KDC match in ServicesAllowedToReceiveForwardedTicketsFrom

Isaac Boukris iboukris at gmail.com
Fri Feb 14 22:05:24 UTC 2020

Hi Sreekanth

On Fri, Feb 14, 2020 at 10:33 PM Sreekanth Nadendla
<srenaden at microsoft.com> wrote:
> Hello Isaac, our product group confirms that in the RBCD case, the KDC will consider an evidence ticket that is not forwardable if the UserAccountControl bits from the validation information in the PAC doesn’t contain the sensitive account bit. This is the current behavior which isn't intended.
> The document is correct as is and no need to match on ServicesAllowedToReceiveForwardedTicketsFrom as you've suggested below.

Does it mean that Windows behavior is expected to change? Perhaps I'm
missing something, but requiring the evidence ticket to be forwardable
in RBCD would be a significant change, as it would require the
Trusted-to-Authenticate-for-Delegation bit to be set on impersonator
when S4U2Self is used, which was the reason for not requiring it, as
documented below.

Will Trusted-to-Authenticate-for-Delegation be required in S4U2Self
for RBCD to work now, as without this flag the evidence ticket won't
be forwardable. Or how is it going to work?



Security Implications of Resource-based Constrained Delegation

Resource-based constrained delegation puts control of delegation in
the hands of the administrator owning the resource being accessed. It
depends on attributes of the resource service rather than the service
being trusted to delegate. As a result, resource-based constrained
delegation cannot use the Trusted-to-Authenticate-for-Delegation bit
that previously controlled protocol transition. The KDC always allows
protocol transition when performing resource-based constrained
delegation as though the bit were set.

Because the KDC does not limit protocol transition, two new well-known
SIDs were introduced to give this control to the resource
administrator. These SIDs identify whether protocol transition has
occurred, and can be used with standard access control lists to grant
or limit access as needed.



More information about the cifs-protocol mailing list