{"id":149,"date":"2007-09-17T23:25:37","date_gmt":"2007-09-17T21:25:37","guid":{"rendered":"http:\/\/www.corelan.be:8800\/index.php\/2007\/09\/17\/delegating-ad-admin-tasks-to-non-admin-accounts\/"},"modified":"2007-09-17T23:25:37","modified_gmt":"2007-09-17T21:25:37","slug":"delegating-ad-admin-tasks-to-non-admin-accounts","status":"publish","type":"post","link":"https:\/\/www.corelan.be\/index.php\/2007\/09\/17\/delegating-ad-admin-tasks-to-non-admin-accounts\/","title":{"rendered":"Delegating AD Admin tasks to non-Admin accounts"},"content":{"rendered":"
\n

Designing a distributed\/international Active Directory is certainly the most important piece of a successful AD implementation. One of the issues that should be dealt with is whether you want to allow other people to be Enterprise\/Domain Admin or not. If you ask me : it's not a good idea. You should restrict those rights to just a handful well-trained people and set up logging and auditing on those accounts and groups. Those admins can create the forest and domains, set up the top level OU structure and then delegate access on those OU's. This will preserve the confidentiality, integrity and availability of your AD. You basically limit the number of people who can blow up AD; and if someone else screws up, the worst they can do is screw up their own OU tree. Very nice – but a good security policy should not limit people in any way or prevent them from doing their job. So the real challenge is to allow local admins to do their job properly, without having to provide them with too much privileges. <\/p>\n

This post describes a couple of common tasks that can be delegated to local people, without having to grant those admins access to the "keys to the kingdom". <\/p>\n

First of all, let's make a couple of assumptions : <\/p>\n

    \n
  1. DC's should be dedicated. Interactive (local) logon to DC's must be avoided <\/li>\n
  2. Making people local admin on a DC or member of "Server Operators" must be avoided at all times. While this would solve most of the issues, it will grant them too much rights at the same time <\/li>\n
  3. Local admins are part of a group. We'll use the group name to grant necessary permissions. <\/li>\n
  4. I'll assume that we are not talking about basic delegation : stuff that can be granted using a delegation wizard on OU level, or by using basic NTFS permissions. You should be able to set up those permissions yourself. <\/li>\n<\/ol>\n

    So, in addition to the basic stuff, here are a couple of tasks that could trigger a request to get access to. <\/p>\n