0

When you're using unconstrained delegation, a service A is allowed to authenticate as the user B to any other service. This happens because the user B sends its TGS along with its TGT to the service A, and service A can then request other TGS on behalf of user B. On a first look this would seem less safe than constrained delegation, because service A can authenticate against any other service. But this has a previous requirement. User B needs to authenticate first to service A. If service A somehow gets compromised, it cannot impersonate any user until that user first connects to it, and forwards its TGT.

When using constrained delegation, this doesn't happen, because service A has access to S2U4self. This allows him to request a TGS to itself on behalf of user B. This TGS can then be used to ask for subsequent TGS to other services because it has the forward flag enabled (-f) using S2U4proxy. Granted, it will only be able to impersonate the user against services whitelisted in the attribute msDS-AllowedToDelegateTo (since its constrained delegation), but this seems like a good trade off against being able to delegate any user without the need of that user first connecting to it.

Is my understanding of these features correct? Can unconstrained delegation actually be safer than constrained delegation?

Thanks!

Improve this question

1 Answer 1

Reset to default
0

In short: no, unconstrained delegation is not more secure than constrained delegation (that does not necessarily prove the inverse either, but that's a different conversation).

You're conflating S4U2Proxy protocol transition with constrained delegation. Protocol transition is a mode of S4U2Proxy that lets a service request a ticket on behalf of any user without any evidence ticket. If you enable this feature then you've effectively delegated the role of domain controller to your application. This is not recommended for the majority of scenarios and is functionally orthogonal to constrained delegation. It also requires domain admin to enable by default.

Constrained delegation will not let you request a ticket on behalf of another user without that evidence ticket first. There's also an additional mode called Resource-based Constrained Delegation which flips the logic by letting the target service indicate who is allowed to delegate to themselves. If you compromise this service a user must still send an evidence ticket, and even then you can only request a delegated ticket to the approved list both the service and target have agreed on.

Improve this answer
5
  • "Constrained delegation will not let you request a ticket on behalf of another user without that evidence ticket first. " I've read in multiple resources that you can. As long as you have access to an account configured for Constrained Delegation, you can impersonate any user listed under msDS-AllowedToDelegateTo without any kind of ticket first. As explained here: harmj0y.net/blog/activedirectory/s4u2pwnage Look under "Scenario 1 : User Account Configured For Constrained Delegation + A Known Plaintext"
    – user134167
    Mar 30, 2020 at 18:28
  • You can see another explotation in github.com/GhostPack/Rubeus#asktgs with real examples.
    – user134167
    Mar 30, 2020 at 18:31
  • If you peek behind the curtains you'll see their attack is actually using protocol transition, which is exactly what I described above. twitter.com/gentilkiwi/status/806643377278173185/photo/1
    – Steve
    Mar 30, 2020 at 18:51
  • Sorry, I don't mean to be thick, but isn't protocol transition a type of constrained delegation? You said in your answer that "Constrained delegation will not let you request a ticket on behalf of another user without that evidence ticket first". If I understand correctly what you said, you have some type of constrained delegations that will, like protocol transition, and some kinds that wont, like resource based? Did i get it right?
    – user134167
    Mar 31, 2020 at 17:20
  • 1
    It's not clear in the UI and the documentation is vague, but the product team does not qualify protocol transition as constrained delegation. It is officially "Protocol Transition" which is functionally a subset of the [MS-SFU] protocol.
    – Steve
    Mar 31, 2020 at 18:11

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .