Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

We are using taskpads to delegete tasks(such as reset password) to remote admins; the delegation is done at the OU level ; but unfortunately OU contains some special accounts/groups(such as application accounts and admin groups which is by design) ; we dont want remote admins messing with them. Is there any way to make those groups and user account inaccesible to remote admins eventhough they are delegated at OU level?

->It would be better if we can me them invisible to the remote admins but i dont think its plausible. ->Those accounts/groups cant be moved out of the concerned OU

Please give your sugesstions, let me know if any questions or clarifications.

share|improve this question
up vote 2 down vote accepted

If you're delegating the minimum permissions necessary to manage user accounts (reset password, read attributes, write attributes, and unlock accounts on user accounts only), then they won't be able to do anything with the groups, so it's a non-issue. The fact that they're in the same OU doesn't matter if you've delegated the permissions properly.

Trying to do something like make users unable to read groups is possible, but it's really not the right answer to this problem and will likely cause problems down the road, as the default behavior us for all users to be able to read all group membership. Breaking this can have unintended consequences, especially with third party apps or things that are LDAP away, but maybe not AD aware.

share|improve this answer
Delegating the permissions to manage user accounts still would allow the delegated users to mess with the mentioned "special accounts". There is no way around withdrawing write permissions on those. Also, there is no harm in removing the "Write" permission on group objects for non-system and non-admin users. As for the "Read" permission there indeed could be adverse effects, but the extent is very dependent on the use case. – the-wabbit Jan 24 '13 at 8:55
You're right, I missed where there were accounts that he didn't want changed. I must have skimmed that section. Also, if delegated properly, the users shouldn't have write to the groups anyway. – MDMarra Jan 24 '13 at 11:54

You can withdraw the "Read" and/or "Write" permissions from the ACLs of the group and account objects in question after disabling inheritance so OU ACLs would not propagate to these objects - see the documentation for details on ACLs and inheritance.

To make these objects invisible for users without read permission, you would have to enable List Object Mode on your directory and set the List Object ACE for the container objects in question. Again see the docs for details.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.