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

[Sreekanth Nadendla]

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.

-----Original Message-----
From: Isaac Boukris <iboukris at gmail.com> 
Sent: Friday, January 31, 2020 1:35 AM
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: [EXTERNAL] Re: [120012821001594] [MS-SFU]Errata from 2019/12/09 - if RBCD bit is set should KDC match in ServicesAllowedToReceiveForwardedTicketsFrom

Hi Sreekanth

On Thu, Jan 30, 2020 at 10:48 PM Sreekanth Nadendla <srenaden at microsoft.com> wrote:
>
> Product group confirms that this is the case in which the evidence ticket is not forwardable, i.e. the user is marked as sensitive and may not be delegated.  In that case, it doesn’t matter whether the delegation would otherwise be allowed.

Thanks for getting back to me on this, I have read again the corrected document and I still find it ambiguous as it stand. If a ticket is not forwardable it means that it *may* be sensitive user, it does not mean that it *is* a sensitive user. In this case the DelegationNotAllowed in the PAC must be checked as it more clearly reflected in the now deleted section.

I have verified it again and even with non-forwardable evidence ticket, if the RBCD bit is set in pa-pac-options, I can get a ticket if RBCD was configured to allow it.

I did find some strange behavior however, if I allow the resource via
*both* delegation types (i.e. legacy constrained-delegation and RBCD), then the 2nd ticket I use *must* be forwardable just as before. This is strange because now if I just remove the legacy constrained-delegation permission rule, and leave only the RBCD permission rule, then I can get a ticket again using a non-forwardable 2nd ticket as evidence.

In light of the errata about the order of precedence of legacy vs RBCD, I guess the meaning is that if we matched on legacy constrained-delegation, then the evidence ticket *must* be forwardable just like before (regardless if the user is sensitive), however if the we didn't match on legacy and the RBCD bit is set in pa-pac-options, we should try to match on ServicesAllowedToReceiveForwardedTicketsFrom, like Windowd KDC does.

Thanks,
Isaac