A city helpdesk group can reset passwords on privileged user accounts. What risk should be highlighted?
Select an answer to reveal the explanation.
Short Explanation
Whoever can reset the vault combination effectively owns the vault. Helpdesk rights over Domain Admin-class users turn a social or helpdesk foothold into privilege. Ticket numbers do not shrink that blast radius.
Full Explanation
Password reset rights on privileged users are a high-risk control gap. If a city helpdesk group can reset passwords on privileged accounts, helpdesk-equivalent operators (or anyone who compromises them) can take over those identities and inherit their Active Directory power—an account-takeover path into systems that run municipal services. Ticketing hygiene alone does not neutralize the technical right.
Numbered tickets do not make privileged resets low risk if standing rights are overly broad. It is false that only Domain Admins can ever reset passwords—delegated reset rights are common and must be scoped carefully. Reset rights matter for interactive admins as well as service accounts.
Exam caveat: privileged account lifecycle should use tightly controlled PAM/JIT workflows, not broad helpdesk reset on Tier-0 users. CPTS control-path analysis treats “who can reset whom” like “who can write group membership.”
Operational check: enumerate password-reset permissions on privileged civic accounts, remove standing helpdesk rights where inappropriate, require break-glass procedures with logging, and alert on resets of Tier-0 identities. Treat privileged password reset as a break-glass civic control with dual control where feasible, not as routine helpdesk convenience.