2

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.

Improve this question

2 Answers 2

Reset to default
2

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.

Improve this answer
2
  • 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, 2013 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, 2013 at 11:54
1

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.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .