Background
I'm creating a service to allow support staff to enable their firecall accounts out of hours (i.e. if there's an issue in the night and we can't get hold of someone with admin rights, another member of the support team can enable their personal firecall account on AD, which has previously been setup with admin rights). This service also logs a reason for the change, alerts key people, and a bunch of other bits to ensure that this change of access is audited / so we can ensure these temporary admin rights are used in the proper way.
To do this I need the service account which my service runs under to have permissions to enable users on active directory. Ideally I'd like to lock this down so that the service account can only enable/disable users in a particular AD security group.
Question
How do you grant access to an account to enable/disable users who are members of a particular security group in AD?
Backup Question
If it's not possible to do this by security group, is there a suitable alternative? i.e. could it be done by OU, or would it be best to write a script to loop through all members of the security group and update the permissions on the objects (firecall accounts) themselves?
Thanks in advance.
Additional Tags
(I don't yet have access to create new tags here, so listing below to help with keyword searches until it can be tagged & this bit editted/removed) DSACLS, DSACLS.EXE, FIRECALL, ACCOUNT, SECURITY-GROUP
Permission to modify the properties of Active Directory (AD) objects is controlled by Access Control Lists (ACLs). ACLs are applied to objects explicitly (without inheritance) or implicitly by inheritance from the container (OU or Container object) the object is located within.
Delegating control of attributes to a user or group (you should almost always delegate permissions to groups, as an aside) is nothing more than changing permissions on container objects (most commonly) or individual non-container objects (like user accounts and computer accounts-- though, technically, they are container objects).
ACLs are not applied to objects based on the objects' security group membership, which is what you state you're looking for.
Your best bet is to arrange the user accounts you want to delegate control over into an OU and delegate control over that OU. If that's not feasible then you're stuck modifying the ACLs on each user account individually.
Most third party identity and access management software can handle this type of access control by completing the request on behalf of the user, usually using a domain admin credential (but it could always be locked down further).
Unfortunately, Windows itself can't do this: group membership in AD is really just being listed in the group's list of members (the
member
attribute of the group, used to generate thememberOf
constructed attribute), and has no structural meaning in the directory (recall that AD is largely just LDAP). By contrast, permissions in AD are defined structurally, so that you can give accounts specific permissions on subtrees (such as a domain, OU, or individual user) according to the hierarchy that groups do not define. The structure is based on domains and OUs, similarly to any other LDAP tree. If something doesn't appear in the user's DN (distinguished name), it can't be used to govern directory permissions.Delegation. You need to delegate write permission to userAccountControl attribute for the object.
This delegation can be applied to members of a security group.