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

[Isaac Boukris]

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