The Delegation Model – Admin Area or Tier0 will host all objects required by the delegation model to operate as mentioned in this design. This is the container holding all the objects needed for domain administration, regardless of the Area/Tier where they belong to. This includes:
- Built-In Administrator
- the privileged groups (as Domain Admins or Enterprise Admins)
- all users/groups used to delegate rights and administrative tasks
- all service accounts, etc.
This area, meaning OU sub-tree, is effectively Tier0.
All the domain administration and delegation, while having a well-defined and organized structure, will live in this area, managed and maintained by the infrastructure owners. We will achieve this by sub-dividing the objects into functional containers. This area should be as restrictive as possible while maintaining the operational level.
This OU (Delegation Model – Admin Area or Tier0) consolidates and secures all privileged identities while delegating tasks and rights to each of the objects of the domain.
As a good start, the 1st level OU (called in this document Admin OU, being the equivalent of Tier0) has to be secure. We do this by modifying the SACL’s (Security Access Control List) of the OU. Modifying the default inheritance is a must, and the legacy compatibility groups removed. Additionally, the standard operational groups must be removed as well. We need to create other groups for the specific and secured operation of this area.
Once we create and secure the “root”, we must define additional sub-containers for the proper management of the environment. These containers should include Users, Groups, Service Accounts, Management Computers and the redirected User and Computer containers. When deciding the number of sub-containers, we have to keep it as simple as possible, while committing our goals. If our goal is fulfill with a single OU, then adding additional containers will barely help, but will make our operational costs higher and will jeopardize our security.
Once the root OU exists and secured, we can create all the required sub-OUs. Having enabled inheritance from the custom OU mentioned. Auditing must be enable and implemented for every object within this area. Only Infra Admins have the right to create and delete OUs within the domain.
After the creation of the Sub-OUs, we must create extra groups within is corresponding container. Some of these groups will have the delegated ability to manage objects in this area.
When deciding the number of sub-containers, we have to keep it as simple as possible, while committing our goals. If our goal can be fulfilled with a single OU, then adding additional container will barely help, but will make our operational costs higher and will jeopardize our security.
The root OU of this area will not inherit the default security of the domain. Instead it will be copied and remove Account Operators &Print Operators from the Access Control Lists. Then all the required sub-OU will be created, now having enabled inheritance from the custom OU just mentioned. Auditing must be enabled and implemented for every object within this area. Only Infra Admins have the right to create and delete OUs within the domain.
After the creation of the Sub-OUs, additional groups must be created within is corresponding container. Some of these groups will have the delegated ability to manage objects in this area.
Global Groups of the Delegation Model
|SG_InfraAdmins||Full rights on all Active Directory infrastructure|
|SG_ADAdmins||Partial rights on all Active Directory infrastructure|
|SG_T0SA||Service Account for Tier 0 / Admin Area|
|SG_T1SA||Service Account for Tier 1 / Servers Area|
|SG_T2SA||Service Account for Tier 2 / Sites Area|
|SG_Tier0Admins||Administrators group for Tier 0 / Admin Area|
|SG_Tier1Admins||Administrators group for Tier 1 / Servers Area|
|SG_Tier2Admins||Administrators group for Tier 2 / Sites Area|
|SG_DfsAdmin||Full Rights to administer DFS|
|SG_GpoAdmin||Full Rights to administer GPO|
|SG_PkiAdmin||Full Rights to administer CA|
|SG_PkiTemplateAdmin||Full Rights to administer CA Templates|
|SG_AllGalAdmins||Delegated Limited general rights on all sites|
|SG_AllSiteAdmins||Limited general rights on all sites|
|SG_Operation||Limited rights on all Servers|
|SG_ServiceDesk||Password rights and AllGALAdmin rights on all sites|
|SG_ServerAdmin||Full administrative rights on servers|
|SG_GlobalGroupAdmin||Full Group administrative rights on all sites|
|SG_GlobalUserAdmin||Full user administrative rights on all sites|
|SG_GlobalPcAdmin||Full computer administrative rights on all sites|
Domain Local Groups of the Delegation Model
|SL_InfraRights||Delegated full rights to all AD infrastructure|
|SL_AdRights||Delegated partial rights to all AD infrastructure|
|SL_PUM||Rights for Privileged User management|
|SL_PGM||Right for Privileged Group management|
|SL_PISM||Right for Privileged Infrastructure management|
|SL_PAWM||Right for Privileged Access Workstation management|
|SL_DirReplRights||Right for Privileged Directory Replication Rights|
|SL_PkiRights||Right for Privileged Public Key Infrastructure management|
|SL_PkiTemplateRights||Right for Privileged Public Key Infrastructure Template management|
|SL_DfsRights||Right for Privileged DFS management|
|SL_GpoAdminRights||Right for Privileged GPO management|
|SL_UM||Rights for User Management|
|SL_GM||Rights for Group Management|
|SL_PSAM||Rights for Service Account Management|
|SL_InfrastructureServers||>Rights for ALL Infrastructure Servers|
|SL_PAWs||Rights for ALL PAWs|
|SL_SvrAdmRight||Rights for server management|
|SL_SvrOpsRight||Rights for server operation management|
|SL_GlobalAppAccUserRight||Rights for Global Aplication Access Users|
|SL_GlobalGroupRight||Rights for Global Group Management|