Take the 2-minute tour ×


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.


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

share|improve this question

migrated from security.stackexchange.com Oct 18 '12 at 17:32

This question came from our site for Information security professionals.

ps. I just found an example of how to do it by OU (i.e. one of my backup options): vbzine.wordpress.com/2011/05/14/… –  JohnLBevan Oct 18 '12 at 17:07

3 Answers 3

up vote 5 down vote accepted

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.

share|improve this answer

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 the memberOf 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.

share|improve this answer

Delegation. You need to delegate write permission to userAccountControl attribute for the object.

This delegation can be applied to members of a security group.

share|improve this answer
Sorta. I don't think you're reading the OP closely. He wants to delegate control to modify userAccountControl to objects based on the objects' membership in a security group. That's not gonna fly. –  Evan Anderson Oct 19 '12 at 3:12
Oh. Yeah, that wont work that way. –  Ablue Oct 19 '12 at 4:17
Additionally... you typically wouldn't delegate the entire userAccountControl attribute when the operation on it is itself delegatable, which I seem to recall unlock being. –  Falcon Momot Oct 19 '12 at 5:14
I think you are right. –  Ablue Oct 19 '12 at 6:12

Your Answer


