Did some more digging and found out following:
Service ticket used in S4U2Proxy need not be forwardable if resource based constrained delegation is used i.e. principalsAllowedToDelegateTo option is configured on Service B.

https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-sfu/dd1b47f9-580c-4c4e-8f34-4485b9728331
This is proved here: https://shenaniganslabs.io/2019/01/28/Wagging-the-Dog.html#serendipity




On Sat, Jul 24, 2021 at 2:08 AM Vipul Mehta <vipulmehta.1989@gmail.com>
wrote:

Hi,

To perform constrained delegation from Service A to Service B,
forwardable flag must be set in the S4U2Self service ticket returned by KDC to Service A.

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 ?
In my test, I have configured resource based constrained delegation in Service B (principalsAllowedToDelegateTo).

--
Regards,
Vipul

--
Regards,
Vipul

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

To perform constrained delegation from Service A to Service B, forwardable flag must be set in the S4U2Self service ticket returned by KDC to Service
A.

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 ?
In my test, I have configured resource based constrained delegation in
Service B (principalsAllowedToDelegateTo).

--
Regards,
Vipul

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

To: kerberos@mit.edu

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.

Service ticket used in S4U2Proxy need not be forwardable if resource
based constrained delegation is used i.e.
principalsAllowedToDelegateTo option is
configured on Service B.

Note that, as of 2019, the forwardable flag must be set on the evidence
ticket if the delegation is authorized in both directions (on the
intermediate service and the target service). We implemented this counterintuitive behavior in the MIT KDC for consistency.

There is some reason to think this might be changing. This article
(noted by Isaac):

https://support.microsoft.com/en-us/topic/managing-deployment-of-rbcd-protected-user-changes-for-cve-2020-16996-9a59a49f-20b9-a292-f205-da9da0ff24d3

talks about a protection measure that "unifies the logic for
Resource-Based Constrained Delegation (RBCD) with the original
constrained delegation." We have asked Microsoft for clarification.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Copy: vipulmehta.1989@gmail.com (Vipul Mehta)
Copy: kerberos@mit.edu (kerberos)

On Mon, Jul 26, 2021 at 10:17 PM Greg Hudson <ghudson@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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Copy: vipulmehta.1989@gmail.com (Vipul Mehta)
Copy: kerberos@mit.edu (kerberos)

On Tue, Jul 27, 2021 at 1:17 PM Isaac Boukris <iboukris@gmail.com> wrote:

On Mon, Jul 26, 2021 at 10:17 PM Greg Hudson <ghudson@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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Copy: vipulmehta.1989@gmail.com (Vipul Mehta)
Copy: kerberos@mit.edu (kerberos)

Note, for MIT I think we don't need the NonForwardableDelegation flag,
just need to behave as enabled and let the plugin's get_principal()
add 'TrustedToAuthForDelegation' if the list is empty. This could
simplify the KDC code as we don't need to check the PAC's
not-delegated flag, although some tests would need updating.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Copy: kerberos@mit.edu

Need a clarification:
MIT KDC will set the forwardable flag in S4U2Self ticket in following cases (provided account is not sensitive and not part of secure group):
1) ok_to_auth_as_delegate is true
or
2) ok_to_auth_as_delegate is false and Service TGT has forwardable flag set

Am I correct here ?

One more thing:
If msDS-AllowedToDelegateTo is non-empty and TrustedToAuthForDelegation is false then the forwardable flag must be set to false. Isn't this behavior different between MIT KDC and Windows KDC as MIT KDC does not check msDS-AllowedToDelegateTo list.

Just copy pasting microsoft doc statement:
"If the TrustedToAuthenticationForDelegation parameter on the Service 1 principal is set to:
TRUE: the KDC MUST set the FORWARDABLE ticket flag ([RFC4120] section 2.6)
in the S4U2self service ticket.
FALSE and ServicesAllowedToSendForwardedTicketsTo is nonempty: the KDC MUST
NOT set the FORWARDABLE ticket flag ([RFC4120] section 2.6) in the S4U2self service ticket.<18>
If the DelegationNotAllowed parameter on the principal is set, then the KDC SHOULD NOT set the FORWARDABLE ticket flag ([RFC4120], section 2.6) in the S4U2self service ticket.<19>"



On Tue, Jul 27, 2021 at 12:44 AM Greg Hudson <ghudson@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.

Service ticket used in S4U2Proxy need not be forwardable if resource
based constrained delegation is used i.e.
principalsAllowedToDelegateTo option is
configured on Service B.

Note that, as of 2019, the forwardable flag must be set on the evidence ticket if the delegation is authorized in both directions (on the intermediate service and the target service). We implemented this counterintuitive behavior in the MIT KDC for consistency.

There is some reason to think this might be changing. This article
(noted by Isaac):

https://support.microsoft.com/en-us/topic/managing-deployment-of-rbcd-protected-user-changes-for-cve-2020-16996-9a59a49f-20b9-a292-f205-da9da0ff24d3

talks about a protection measure that "unifies the logic for
Resource-Based Constrained Delegation (RBCD) with the original
constrained delegation." We have asked Microsoft for clarification.

--
Regards,
Vipul

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Copy: kerberos@mit.edu (kerberos)

On Tue, Jul 27, 2021 at 6:54 PM Vipul Mehta <vipulmehta.1989@gmail.com> wrote:

Need a clarification:
MIT KDC will set the forwardable flag in S4U2Self ticket in following cases (provided account is not sensitive and not part of secure group):
1) ok_to_auth_as_delegate is true
or
2) ok_to_auth_as_delegate is false and Service TGT has forwardable flag set

In case of 2) we'll also check that
'ServicesAllowedToSendForwardedTicketsTo' is empty like in the doc, I
was just suggesting implementation wise that we do it in the plugin
instead of the kdc itself, that is when the principal is retrieved the
plugin will add 'ok_to_auth_as_delegate' if the 'ServicesAllowedToSendForwardedTicketsTo' is empty.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Copy: kerberos@mit.edu (kerberos)

On Wed, Jul 28, 2021 at 11:10 AM Vipul Mehta <vipulmehta.1989@gmail.com> wrote:

I have windows server 2012 R2 with all the security updates installed and did some tests:

Resource Based Constrained Delegation configured for Service A in Service B account.

Case 1) Service A : trustedToAuthForDelegation = false and non-empty msds-AllowedToDelegateTo -> S42U2Self ticket didn't have a forwardable flag and subsequent S4U2Proxy failed.

That's expected because the default of 'NonForwardableDelegation' is
enabled I think, so RBCD requires forwardable flag now, if you set NonForwardableDelegation to disabled (that is to 1 ..), then RBCD
S4U2Proxy will continue to work as before the update.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Copy: kerberos@mit.edu (kerberos)

On Wed, Jul 28, 2021 at 1:46 PM Vipul Mehta <vipulmehta.1989@gmail.com> wrote:

Now we know that behavior is unified and S4U2Self ticket should be forwardable to avoid vulnerability, i think we can add a check in MIT Kerberos API itself such that before sending S4U2Proxy TGS-REQ to KDC, if ticket is not forwardable it will fail in

client itself.

I can see that JDK has this check: https://github.com/openjdk/jdk/blob/739769c8fc4b496f08a92225a12d07414537b6c0/src/java.security.jgss/share/classes/sun/security/krb5/internal/CredentialsUtil.java -> line 105

MIT used to have that as well before RBCD was added, although I don't
think this was ever necessary, as that check should be done in the
KDC. Also disabling NonForwardableDelegation can be a valid usage when
relying on SIDs and not using protected-group, as in the original RBCD
design:

https://github.com/MicrosoftDocs/windowsserverdocs/blob/master/WindowsServerDocs/security/kerberos/kerberos-constrained-delegation-overview.md

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Copy: kerberos@mit.edu (kerberos)

Now we know that behavior is unified and S4U2Self ticket should be
forwardable to avoid vulnerability, i think we can add a check in MIT
Kerberos API itself such that before sending S4U2Proxy TGS-REQ to KDC, if ticket is not forwardable it will fail in client itself.

I can see that JDK has this check: https://github.com/openjdk/jdk/blob/739769c8fc4b496f08a92225a12d07414537b6c0/src/java.security.jgss/share/classes/sun/security/krb5/internal/CredentialsUtil.java

line 105

On Wed, Jul 28, 2021 at 2:08 PM Isaac Boukris <iboukris@gmail.com> wrote:

On Wed, Jul 28, 2021 at 11:10 AM Vipul Mehta <vipulmehta.1989@gmail.com> wrote:

I have windows server 2012 R2 with all the security updates installed

and did some tests:

Resource Based Constrained Delegation configured for Service A in

Service B account.

Case 1) Service A : trustedToAuthForDelegation = false and non-empty

msds-AllowedToDelegateTo -> S42U2Self ticket didn't have a forwardable flag and subsequent S4U2Proxy failed.

That's expected because the default of 'NonForwardableDelegation' is
enabled I think, so RBCD requires forwardable flag now, if you set NonForwardableDelegation to disabled (that is to 1 ..), then RBCD
S4U2Proxy will continue to work as before the update.

--
Regards,
Vipul

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Copy: kerberos@mit.edu (kerberos)

I have windows server 2012 R2 with all the security updates installed and
did some tests:

Resource Based Constrained Delegation configured for Service A in Service B account.

Case 1) Service A : trustedToAuthForDelegation = false and non-empty msds-AllowedToDelegateTo -> S42U2Self ticket didn't have a forwardable flag
and subsequent S4U2Proxy failed.

Case 2) Service A : trustedToAuthForDelegation = false and empty msds-AllowedToDelegateTo -> S42U2Self ticket was forwardable and subsequent S4U2Proxy passed.

Because ticket signature check has been enabled in KDC in the security
update, now I cannot change the forwardable flag from false to true in S42U2Self ticket in case 1).

On Tue, Jul 27, 2021 at 9:58 PM Isaac Boukris <iboukris@gmail.com> wrote:

On Tue, Jul 27, 2021 at 6:54 PM Vipul Mehta <vipulmehta.1989@gmail.com> wrote:

Need a clarification:
MIT KDC will set the forwardable flag in S4U2Self ticket in following

cases

(provided account is not sensitive and not part of secure group):
1) ok_to_auth_as_delegate is true
or
2) ok_to_auth_as_delegate is false and Service TGT has forwardable flag

set

In case of 2) we'll also check that
'ServicesAllowedToSendForwardedTicketsTo' is empty like in the doc, I
was just suggesting implementation wise that we do it in the plugin
instead of the kdc itself, that is when the principal is retrieved the
plugin will add 'ok_to_auth_as_delegate' if the 'ServicesAllowedToSendForwardedTicketsTo' is empty.

--
Regards,
Vipul

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Copy: kerberos@mit.edu (kerberos)

Thank you.
This was a useful discussion for me.

On Wed, Jul 28, 2021 at 4:36 PM Isaac Boukris <iboukris@gmail.com> wrote:

On Wed, Jul 28, 2021 at 1:46 PM Vipul Mehta <vipulmehta.1989@gmail.com> wrote:

Now we know that behavior is unified and S4U2Self ticket should be

forwardable to avoid vulnerability, i think we can add a check in MIT Kerberos API itself such that before sending S4U2Proxy TGS-REQ to KDC, if ticket is not forwardable it will fail in client itself.

I can see that JDK has this check:

https://github.com/openjdk/jdk/blob/739769c8fc4b496f08a92225a12d07414537b6c0/src/java.security.jgss/share/classes/sun/security/krb5/internal/CredentialsUtil.java

line 105

MIT used to have that as well before RBCD was added, although I don't
think this was ever necessary, as that check should be done in the
KDC. Also disabling NonForwardableDelegation can be a valid usage when relying on SIDs and not using protected-group, as in the original RBCD design:

https://github.com/MicrosoftDocs/windowsserverdocs/blob/master/WindowsServerDocs/security/kerberos/kerberos-constrained-delegation-overview.md

--
Regards,
Vipul

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

I have one more query on this based on following statement in microsoft document:

"If a non forwardable S4U2self-generated user's service ticket for a nonsensitive user is used, then the SFU client SHOULD<11> locate a DS_BEHAVIOR_WIN2012 DC ([MS-KILE] section 3.2.5.3) to send the request."

https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-sfu/ddb2cafd-1f01-4834-b52a-d4a5b34cd960
<https://urldefense.com/v3/__https:/docs.microsoft.com/en-us/openspecs/windows_protocols/ms-sfu/ddb2cafd-1f01-4834-b52a-d4a5b34cd960__;!!KpaPruflFCEp!xs7LC6xF-p5noCT18UnibXxKXcrNUf6GDk_BArh2V7T3TRWFgGLo5IL9RlB1cVwEOw$>

Is this implemented in the MIT Kerberos client ?


On Thu, Jul 29, 2021 at 2:20 PM Vipul Mehta <vipulmehta.1989@gmail.com>
wrote:

Thank you.
This was a useful discussion for me.

On Wed, Jul 28, 2021 at 4:36 PM Isaac Boukris <iboukris@gmail.com> wrote:

On Wed, Jul 28, 2021 at 1:46 PM Vipul Mehta <vipulmehta.1989@gmail.com>
wrote:

Now we know that behavior is unified and S4U2Self ticket should be

forwardable to avoid vulnerability, i think we can add a check in MIT
Kerberos API itself such that before sending S4U2Proxy TGS-REQ to KDC, if
ticket is not forwardable it will fail in client itself.

I can see that JDK has this check:

https://github.com/openjdk/jdk/blob/739769c8fc4b496f08a92225a12d07414537b6c0/src/java.security.jgss/share/classes/sun/security/krb5/internal/CredentialsUtil.java

line 105

MIT used to have that as well before RBCD was added, although I don't
think this was ever necessary, as that check should be done in the
KDC. Also disabling NonForwardableDelegation can be a valid usage when
relying on SIDs and not using protected-group, as in the original RBCD
design:


https://github.com/MicrosoftDocs/windowsserverdocs/blob/master/WindowsServerDocs/security/kerberos/kerberos-constrained-delegation-overview.md

--
Regards,
Vipul

--
Regards,
Vipul

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Copy: kerberos@mit.edu (kerberos)

Hi Vipul,

On Wed, Aug 25, 2021 at 6:12 AM Vipul Mehta <vipulmehta.1989@gmail.com> wrote:

I have one more query on this based on following statement in microsoft document:

"If a non forwardable S4U2self-generated user's service ticket for a nonsensitive user is used, then the SFU client SHOULD<11> locate a DS_BEHAVIOR_WIN2012 DC ([MS-KILE] section 3.2.5.3) to send the request."

https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-sfu/ddb2cafd-1f01-4834-b52a-d4a5b34cd960

Is this implemented in the MIT Kerberos client ?

No it isn't, we just assume all the KDCs support RBCD.

I think this has become less relevant now that RBCD requires the
forwardable flag as well [1]. I guess this doc should be updated too.

[1] https://lists.samba.org/archive/cifs-protocol/2021-July/003608.html

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Copy: kerberos@mit.edu (kerberos)

Thanks.
This information will be provided to openjdk dev as they were asking about
MIT krb5 behavior -> https://bugs.openjdk.java.net/browse/JDK-8272162

On Wed, Aug 25, 2021 at 1:00 PM Isaac Boukris <iboukris@gmail.com> wrote:

Hi Vipul,

On Wed, Aug 25, 2021 at 6:12 AM Vipul Mehta <vipulmehta.1989@gmail.com> wrote:

I have one more query on this based on following statement in microsoft

document:

"If a non forwardable S4U2self-generated user's service ticket for a

nonsensitive user is used, then the SFU client SHOULD<11> locate a DS_BEHAVIOR_WIN2012 DC ([MS-KILE] section 3.2.5.3) to send the request."

https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-sfu/ddb2cafd-1f01-4834-b52a-d4a5b34cd960

Is this implemented in the MIT Kerberos client ?

No it isn't, we just assume all the KDCs support RBCD.

I think this has become less relevant now that RBCD requires the
forwardable flag as well [1]. I guess this doc should be updated too.

[1] https://lists.samba.org/archive/cifs-protocol/2021-July/003608.html

--
Regards,
Vipul

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)