A county discovers constrained Kerberos delegation configured on several service accounts. How should the assessment treat that finding?
Select an answer to reveal the explanation.
Short Explanation
"Constrained" sounds like a seatbelt, but the belt only helps if it is clipped to the right posts. Allowed services and targets still decide how far impersonation can travel. Review the map — do not trust the label alone.
Full Explanation
Constrained Kerberos delegation limits which services an account may impersonate users toward, but the constraint is only as safe as the allowed services and targets. A county that discovers constrained delegation on several service accounts must review those SPN/target maps because mis-scoped sensitive services can still enable dangerous impersonation paths against citizen-facing or internal systems. Naming does not equal safety; configuration review is mandatory.
Treating constrained delegation as inherently safe because of the label leaves residual abuse paths unexamined. Ignoring constrained objects while hunting only unconstrained settings under-reports risk that still matters for civic AD resilience. Delegation settings alone also do not prove Domain Admin has already been achieved—they are privilege and impersonation design findings that need path analysis.
Exam caveat: unconstrained, constrained, and resource-based constrained delegation are different mechanisms with different review questions—do not collapse them into one “delegation bad/good” binary. CPTS AD work rewards precise reading of allowed services and who can abuse them.
Operational check: enumerate accounts with constrained delegation, list allowed services/targets, flag any path toward Tier-0 or high-value civic apps, and recommend tightening or removing unnecessary delegation with change-ticket evidence of the reviewed map.