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

Sreekanth Nadendla srenaden at microsoft.com
Wed Feb 19 21:51:55 UTC 2020


Hello Isaac, there are no plans to change the product behavior.


Regards,
Sreekanth Nadendla
Microsoft Windows Open Specifications

-----Original Message-----
From: Isaac Boukris <iboukris at gmail.com> 
Sent: Friday, February 14, 2020 5:05 PM
To: Sreekanth Nadendla <srenaden at microsoft.com>
Cc: cifs-protocol at lists.samba.org; Greg Hudson <ghudson at mit.edu>; support <support at mail.support.microsoft.com>
Subject: Re: [EXTERNAL] Re: [120012821001594] [MS-SFU]Errata from 2019/12/09 - if RBCD bit is set should KDC match in ServicesAllowedToReceiveForwardedTicketsFrom

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?

https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fwindows-server%2Fsecurity%2Fkerberos%2Fkerberos-constrained-delegation-overview&data=02%7C01%7Csrenaden%40microsoft.com%7C7f3ff823eb624f43073708d7b19a0599%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637173147389279127&sdata=YwrM2bqHZV0zIrOT5%2Fa%2FCcDk%2Bn8bL12FH2432gqQfHU%3D&reserved=0

Quote:

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.

Unquote.

Thanks!


More information about the cifs-protocol mailing list