There is a pattern I run into in almost every mid-sized company I look at: first-level support either has far too few rights to do its job, or far too many. Both are a problem, just in different ways. Too few rights means every small thing, a password reset, an account unlock, a group membership for a new hire, has to be escalated to the second tier. Too many rights means the help desk sits on full admin accounts in Active Directory because that is just how it grew over the years, and suddenly ten people have sweeping permissions at the exact frontline where most phishing and social engineering attempts land first.
In one project I actually counted how many tickets per month were pure password resets and account unlocks. At a mid-sized company with roughly 300 employees, that was over 60 percent of all first-level tickets. The rest was split between software requests, hardware issues, and group memberships. Once you see how much time and how many escalations to the second tier come purely from these simple, repetitive tasks, it becomes obvious why this is worth fixing.
Why standard AD delegation does not go far enough
Microsoft’s native answer to this is delegating permissions in Active Directory, using the Delegation of Control Wizard to let certain groups reset passwords or unlock accounts without granting Domain Admin rights. That works technically, no argument there. But in practice I keep running into two recurring issues.
First, delegation in AD is granular at the OU level, but not really granular at the level of a traceable, logged self-service process. When a help desk agent resets a password through the native AD console, there is a security event log, but not a business-readable record with a ticket reference, a reason, and a history an auditor can actually read. Second, and this is the bigger point in my view, native AD delegation only covers on-premises Active Directory. As soon as a company also has Entra ID accounts that are not covered by hybrid sync, or accounts in both worlds need to be managed through different processes, the unified delegation model falls apart.
How I approached this at au2mator
The first time I worked on a self-service portal for help desk agents, the starting point was exactly this observation: support staff need a limited set of clearly defined actions, not admin rights in general. Reset a password, unlock an account, reset an MFA method, add someone to a specific distribution list, those are maybe ten to fifteen actions that cover ninety percent of daily demand.
In au2mator, this runs through a web portal where exactly these actions are built as self-contained, individual building blocks. A help desk agent signs in with their own normal account, which itself has no elevated AD or Entra rights whatsoever. They search for the affected user, pick the action, enter a ticket number and a short reason, and the action gets executed through a runbook process using a separate, dedicated service account in the background. The agent never has direct access to a privileged account, they only trigger a predefined, controlled action.
The effect is twofold. On one side, the help desk gets immediate self-service access to exactly the tasks that previously had to be escalated, without anyone needing personal admin rights. On the other side, a clean, searchable history is created automatically: who performed which action, for which user, with which reason, and when. That is exactly the kind of evidence an ISO 27001 audit or an internal review asks for, and it is not something a classic admin-rights delegation model provides on its own.
How this changes escalation numbers
At one customer that rolled this model out, the number of tickets escalated to the second tier for exactly these standard tasks dropped by roughly 70 percent within a few weeks. That is not a surprising number once you consider that previously, every account unlock outside the limited AD delegation rights of the first tier got passed on automatically. What I found more interesting was a side effect: response time for employees who genuinely needed fast help, say a locked account on a Monday morning, dropped from an average of forty minutes to under five minutes, because the first tier could resolve the request directly instead of putting it into a queue for the second tier.
What I actually recommend to companies
The most pragmatic starting point I recommend is not building a full self-service portal for every conceivable AD action right away. Instead, I would start with the three to five ticket categories that actually make up the bulk of the volume, usually password resets, account unlocks, and simple group memberships. Delegating just these few actions to the first tier cleanly, in a controlled way, with logging attached, typically delivers the biggest effect for the least effort before you tackle more complex scenarios.
I write regularly about IT automation, Azure, and whatever comes up while building au2mator. If you have questions about your own environment, feel free to reach out.
