Which Kerberos delegation model would you standardise on across many middle-tier services, and why does who holds the configuration decide it?
answer
- ask who writes the setting
- the list sits at one end or the other
- an empty default is the whole argument
- the back end bears the loss
- unconstrained forwarding enumerates nothing
basics
~20 sResource-based delegation, in most estates: the target service declares who may impersonate to it, so the party bearing the loss holds the setting and a new service starts reachable by nobody. Constrained delegation puts that list on the middle tier instead.
solid answer
~50 sCompare the three by **who writes the setting**, not by how they feel. Unconstrained forwarding puts no list anywhere: the middle tier receives a forwarded ticket-granting ticket and reaches whatever the ticket-granting service will serve. Constrained delegation puts a list of permitted target service principals **on the middle tier**, so it is written by whoever administers the front end — the back end's owner has no say and cannot read it. Resource-based delegation inverts that: the **target** declares which principals may impersonate to it, so the setting sits with the team that bears the loss, and a newly created service is reachable by nobody until its own owner acts. That default is why it is the safe standard. The real cost is discovery: unconstrained forwarding records nothing, so nobody knows which call paths exist to enumerate.
go deeper
Recall that letting a service act as the user comes in narrower forms than simply handing over the user's ticket-granting ticket, and that those forms differ in which account carries the permission.
Explain the mechanics of each model: what the ticket-granting service checks before issuing, and whether the permitted target list lives on the requesting service or on the target it wants to reach.
Demonstrate the operational reality — that unconstrained forwarding left no inventory, so a migration starts with observation at the back ends rather than with configuration at the front ends.
Decide on the axis of who writes the setting and who bears the loss, defend the empty-by-default property as the deciding argument, and put a date on any unconstrained forwarding that survives the decision.
## Three models, and the only axis that separates them cleanly All three let a middle tier act as the user against a back end. They differ in **where the permission is written and who can write it**, and that is the axis a lead should decide on, because it determines who notices when the answer is wrong. - **Unconstrained forwarding.** The client sets `GSS_C_DELEG_FLAG (1)`, its `forwardable(1)` ticket-granting ticket is forwarded, and the middle tier holds a credential good for any service principal the ticket-granting service will serve. There is **no list anywhere**. The only configuration is the permission for the middle tier to receive a forwarded credential at all. - **Constrained delegation.** The middle tier's own account carries a list of target service principals. The ticket-granting service refuses an S4U2Proxy request towards anything not on it. - **Resource-based delegation.** The **target** service carries the list, naming the principals permitted to impersonate to it. The decision moves to the far end of the call. ## Who holds what | | Unconstrained forwarding | Constrained delegation | Resource-based delegation | |---|---|---|---| | Where the permission is written | nowhere — reach is implicit | on the middle tier's account | on the target service's account | | Who can write it | whoever permits forwarding at all | whoever administers the front end | whoever owns the back end | | What a back-end owner can see | nothing | nothing | its own complete list | | Default for a new back-end service | already reachable | reachable as soon as anyone lists it | reachable by nobody | | Reach when the setting is wrong | every service in the realm | the listed targets | the one service that listed wrongly | | Adding a new front end | no change needed | edit the front end | edit the back end | ## Which one fails safe, and why that is the deciding argument A model fails safe when the **absence** of a decision produces the restrictive outcome. Work the three through: 1. Under unconstrained forwarding, a service that nobody has thought about is already reachable as the user, because reach was never enumerated. Absence of a decision is maximum exposure. 2. Under constrained delegation, a new back end is protected only until some front-end administrator adds it. Its owner is not consulted and cannot audit who has. Absence of a decision **by the owner** changes nothing, because the decision was never theirs. 3. Under resource-based delegation, a new back end starts with an empty list. Absence of a decision is zero exposure, and the party who must act is the party who loses if they act wrongly. Only the third aligns the setting with the consequence. That alignment — not the size of the list — is what makes it the sensible estate-wide standard. ## What each costs when it is wrong - **Unconstrained forwarding wrong** costs the realm, and costs it silently: because nothing is enumerated, there is no artefact to review and no diff to notice. - **Constrained delegation wrong** costs the listed targets, and the characteristic failure is **drift**. Lists are written once during an integration and never revisited, and the people who could spot a stale entry are the ones who cannot see it. - **Resource-based delegation wrong** costs one back end, but it moves a subtle protocol decision to teams who may not understand it. A back-end owner who lists a shared front end has effectively granted every caller of that front end. - **Any model plus protocol transition** adds a separate cost: the middle tier can mint user-named credentials with no user involved, so that permission should be argued about on its own rather than bundled with the delegation decision. ## Sequencing a move, since this is never a flag day The hard part is not the target model. It is that unconstrained forwarding **kept no record of what it permitted**, so you cannot write the lists until you know the call paths: 1. Inventory, from the back ends, which middle tiers actually arrive with user-named tickets today. The back end is the only place with observational evidence, which is itself an argument for the resource-based shape. 2. Populate the target lists while forwarding is still permitted, so nothing breaks. 3. Withdraw the permission to receive a forwarded credential, one middle tier at a time, watching for call paths the inventory missed. 4. Keep a standing review of the lists, owned by the back ends, because the model is only as good as the enumeration it forces. ## The judgment a lead actually owns Ask first whether the call needs the user's identity at the back end **at all**. A large share of delegation exists because someone wanted the back end's own access rules to apply, which is a good reason; the rest exists because the middle tier was easier to build that way, which is not. Every call path you remove is one you never have to enumerate, review, or explain. Standardise on resource-based delegation for the paths that survive, hold protocol transition as a separate and rarer grant, and treat any remaining unconstrained forwarding as an open item with a date on it rather than a configuration.
- Why does constrained delegation's target list sit awkwardly with service ownership?The list names back-end service principals but lives on the middle tier's own account, so it is written by whoever administers the front end. The back end's owner is not consulted, cannot read the list, and learns of a new impersonator only by observing tickets arrive.
- What makes migrating an estate off unconstrained forwarding slow?You must discover, for each middle tier, every back end it actually reaches — and the unconstrained model recorded nothing, because it never needed a list. Until that inventory exists, switching to a bounded model breaks call paths nobody documented.
- When is unconstrained forwarding still the defensible choice?Where the middle tier is genuinely a general-purpose agent acting for the user across services nobody can enumerate in advance, and where its own compromise would already be equivalent to the user's. That is rare, and the burden of proof sits with whoever proposes it.
- Does choosing a bounded model reduce what a compromised middle tier can do to its listed targets?No, and claiming otherwise oversells it. Within its permitted targets a compromised middle tier acts as any user it can name, with those users' rights. Bounding the target set limits blast radius across the estate; it does not protect the services inside the boundary.
saying these in an interview costs you the question
- Treats all three delegation models as one feature under different names.
- Says constrained delegation limits which users may be impersonated.
- Assumes a back-end owner can see which middle tiers list it as a target.
- Claims unconstrained forwarding is acceptable if the middle tier is patched.
- Believes one realm-wide setting can switch every service to a bounded model.
- Thinks a bounded target list protects the services inside the boundary.