8 hours ago8 hr Our help desk resets passwords and unlocks accounts all day long. When we take over a small or mid-sized domain, the most common over-privilege I find is the help desk (or the office manager who does it on the side) sitting in Domain Admins just so they can do that. AD has had granular delegation since Windows 2000, and it takes a few minutes to set up. Further down is a related trick I use from the RMM a lot: getting a machine, and scripts running as SYSTEM on it, to pick up a new group membership without rebooting someone's PC in the middle of their day. Delegating resets and unlocks You'll need Domain Admin once to set it up, users organised into OUs so you can scope it, and a security group for the people getting the rights, for example GRP-Helpdesk-PwReset. Always delegate to a group, never to individuals. When someone joins or leaves the help desk you change group membership, not ACLs. In Active Directory Users and Computers, right-click the OU containing the users (for example OU=Staff,DC=contoso,DC=local) and choose Delegate Control. Add GRP-Helpdesk-PwReset. Under common tasks, tick Reset user passwords and force password change at next logon. Finish the wizard. That common task doesn't include unlocking, which catches people out. Run the wizard again on the same OU, choose Create a custom task to delegate, then Only the following objects in the folder, tick User objects, and on the permissions page show Property-specific permissions and tick Read lockoutTime and Write lockoutTime. If you're setting this up across a lot of OUs or clients, I'd script it with dsacls instead: $ou = "OU=Staff,DC=contoso,DC=local" $grp = "CONTOSO\GRP-Helpdesk-PwReset" dsacls $ou /I:S /G "${grp}:CA;Reset Password;user" dsacls $ou /I:S /G "${grp}:RPWP;pwdLastSet;user" dsacls $ou /I:S /G "${grp}:RPWP;lockoutTime;user" /I:S applies the entry to child objects only, CA is a control access right (Reset Password), and RPWP is read and write property. The help desk can then use ADUC from RSAT, or PowerShell: Set-ADAccountPassword -Identity jdoe -Reset -NewPassword (Read-Host -AsSecureString "New password") Set-ADUser -Identity jdoe -ChangePasswordAtLogon $true Unlock-ADAccount -Identity jdoe Why it won't work on your admins Members of protected groups (Domain Admins, Account Operators and so on) have adminCount=1, and their permissions get reset hourly from the AdminSDHolder object. Your help desk delegation won't apply to them, by design. Honestly, that's what you want. The help desk shouldn't be able to reset a Domain Admin's password. New group membership for SYSTEM, no reboot Computer accounts get group memberships too, usually to grant access to a file share, a certificate template or a GPO's security filter. The catch is that a computer gets its Kerberos tickets when it boots and renews them for hours afterwards. Add it to a group and it won't "see" the membership until it gets a new ticket, which normally means a reboot. That's a hard sell when someone is halfway through their work on that machine. You can force it by purging the tickets for the SYSTEM logon session (LUID 0x3e7). The next time anything running as SYSTEM needs a ticket, the machine asks the DC for a fresh TGT, and that one carries the new group. First add the computer to the group. Note the trailing $ on the computer's account name. Add-ADGroupMember -Identity "GRP-Deploy-Share-Read" -Members "WS-0142$" Make sure the change has replicated to the DC the machine authenticates against (repadmin /syncall /APed if you're in a hurry). Then on the target machine, from an elevated prompt or your RMM, which usually runs as SYSTEM anyway: klist -li 0x3e7 purge gpupdate /force # if the group is used for GPO security filtering certutil -pulse # if the group grants enrollment on a certificate template Now the script running as SYSTEM can reach the share or service that's restricted to the group. Access the resource by its DNS name, not its IP address, so Kerberos actually gets used. If the membership was only for a one-off job, like copying installers from a restricted share or a single enrollment, take the computer back out when it's done and purge again so the access goes away now and not in ten hours: Remove-ADGroupMember -Identity "GRP-Deploy-Share-Read" -Members "WS-0142$" -Confirm:$false # then on WS-0142: klist -li 0x3e7 purge Put the removal in the same script or ticket as the add. We've found computers sitting in "temporary" groups months after the job, because nobody came back for them. Where the trick stops working Purging tickets refreshes what the machine presents to other servers over Kerberos. It doesn't rebuild the local token of processes already running as SYSTEM, so whoami /groups in an existing SYSTEM session won't change, and neither will local permission checks against the new group. Anything that depends on the local token still needs a reboot. Testing both halves Log on as a help desk member (not an admin) and reset a test user's password and unlock them. Try the same on a user outside the OU. It should be denied. After the purge, klist -li 0x3e7 shows a fresh TGT issued a moment ago, and the SYSTEM-context task can read the restricted resource. I mostly use the purge for remote one-off jobs where a reboot would interrupt someone, for testing GPO filtering or certificate autoenrollment without rebooting each time, and for temporary access during a deployment script. It isn't a substitute for proper standing access. If machines need a group permanently, put them in it and let them pick it up on their next reboot like normal.
Create an account or sign in to comment