Query regarding S4U2Self protocol extension

[Isaac Boukris]

On Tue, Jul 27, 2021 at 1:17 PM Isaac Boukris <iboukris at gmail.com> wrote:
>
> On Mon, Jul 26, 2021 at 10:17 PM Greg Hudson <ghudson at mit.edu> wrote:
> >
> > On 7/23/21 4:38 PM, Vipul Mehta wrote:
> > > I did some testing with Windows KDC and it will set forwardable flag in
> > > S4U2Self service ticket in either of the following cases:
> > >
> > > 1) TrustedToAuthForDelegation is set to true in Service A account.
> > >
> > > 2) Service A TGT used in S4U2Self has forwardable flag set and
> > > msDS-AllowedToDelegateTo list is empty on Service A account.
> > > I am not able to understand why msDS-AllowedToDelegateTo needs to be empty
> > > in the 2nd case.
> > >
> > > Is the behavior of MIT KDC the same as Windows KDC ?
> >
> > We have an analog of the TrustedToAuthForDelegation flag, called
> > ok_to_auth_as_delegate.  We don't check for an empty
> > allowed-to-delegate-to list.
> ...
> > https://support.microsoft.com/en-us/topic/managing-deployment-of-rbcd-protected-user-changes-for-cve-2020-16996-9a59a49f-20b9-a292-f205-da9da0ff24d3
>
> Now that I read this again, and read again the "Additional
> considerations" section in that link, I think what might happened with
> this change is that now RBCD requires the forwardable flag but any
> service with an empty msDS-AllowedToDelegateTo to list, as Vipul
> remarked, gets treated as TrustedToAuthForDelegation and gets the flag
> (presumably, unless the client is in the protected-users group or has
> the not-delegated flag).
>
> I'll run some tests and check it with dochelp.

Yes, now any service is treated as TrustedToAuthForDelegation unless
it has a none-empty msDS-AllowedToDelegateTo list, on the other hand
with
NonForwardableDelegation set to enabled RBCD is no longer allowed with
non-forwardable tickets (this would be the default soon, or it is
already).

I guess that cross-realm would also be required to be forwardable,
which means the other realm is trusted for that, I'll try to test it.