Building the Admin Area (Tier0) is a challenge on its own. This area is not only the OU subtree, but many other containers, which will have the “accessing” groups stored here.
There are several steps to build this tier:
- Organizational Units
- Move objects
- Default Administrators Accounts
- Creating Groups
- Fine Grained Password Policy
- Group Nesting
- Modify AdminSdHolder
- Default Container Redirection
- Initial setup of Servers Area (Tier1)
- Initial setup of Sites Area (Tier2)
- Start with Delegations
Organizational Units needed to build Admin Area (Tier0)
We will start with the “Admin” Organizational Unit. When creating an OU, this one does have inherit permissions from the parent, which might become a issue when dealing with high privileged accounts. For example, if there is a rouge delegation at the domain level, which can reset AD User password, this one will be applied to this new Admin OU, which is a security risk.
We start by creating our OU:
This will create the OU, with all pre-defined ACL’s (including Orphan SIDs) and inheritance. And as we already mention, is not what we want. So now that we have this OU, we have to block inheritance, copy ACLs and “Clan it up”; this is done by removing inheritance, and copying the inherited ACLs; then we do remove all of those ACEs that we do not need, as is the case of “Pre-Windows 2000”, “Account Operators” and “Print Operators”. We also be removing any orphan SID (this SID on the ACE which cannot be resolved to a name, most likely because the object was deleted) and any other delegation that might interfere with the setup we are doing here. We will end up with something similar to this:
In order to automate the build of Admin Area (Tier0), EguibarIT PowerShell Module provides some CMDlets that can help:
New-DelegateAdOU
This is a wrapper functions that 1) Checks for OU existence, and create it if doe not exist 2) Calls “Start-AdCleanOU” to remove unwanted ACEs 3) Call “Remove-SpecificACLandEnableInheritance” to manage inheritance and specific ACEs
Start-AdCleanOU
This is another wrapper function that provides functionality to clean any other OU. It relies on EguibarIT.Delegation PowerShell Module CMDlets.
Creating the sub-OU structure
The following step is to create remaining OUs. By using these functions, we can optimize the creation of ANY OU that we might need, and as described before, building the Admin Area (Tier0). So the following sub-OU have to be created (but not limited to…):
| Sub-OU | Objects | Justification |
| Users | User Identities | Any user object which has administrative rights within the domain. The rights can be inherited, as the Administrator account, by group membership of privileged groups as Domain Admins or Account operators, or any other group used to delegate rights. This OU will have its own set of configurations for the users (GPO) and it will have a Fine Grained Password Policy. |
| Groups | Global/Universal Groups | This container will differentiate the organizational groups from the ones belonging to the Rights OU. These groups (as per definition) should only contain as members, users and other groups, and shall not be granted any right. Only Privileged, Semi-Privileged and Service Accounts can belong to these kinds of groups. This OU will have its own set of configurations for the computers (GPO). |
| Housekeeping | Users & Computers | Staled user objects and computer objects. An automated procedure will search for staled objects and move those to this container in order to delete when thresholds are met. |
| Infrastructure Services | Computers | Any server belonging to Tier0 and providing services exclusively to this area/tier. This could be the virtualization servers, patching servers, deployment servers, monitoring servers, etc. |
| Privileged Groups | Global/Universal Groups | Delegation model Privileged groups. |
| Privileged Access Workstations | Computers | Highly secured computers (known as PAW) used to administer the domain. RDP to manage Domain Controllers is not a desired practice, and doing so from a “standard” PC must be avoided by any means. Instead these designated management computers will fulfill this request. |
| PAW Tier0 | Computers | Privileged Access Workstation restricted exclusively for Administration Area / Tier0 |
| PAW Tier1 | Computers | Privileged Access Workstation restricted exclusively for Servers Area / Tier1 |
| PAW Tier2 | Computers | Privileged Access Workstation restricted exclusively for Sites Area / Tier2 |
| Rights | Domain Local Groups | Any ACL granting access within the domain has to be assigned to these groups. This container will only have groups which are delegated rights. Although this container could be merged with the Groups one, is a good idea to have clearly identified the standard groups (As the ones in the groups container, which its SACLs are not modified nor assigned to any other system object) from the groups which DO have additional access rights. |
| Service Accounts | User/Service Identities | By design, a service account should be guarded and kept extremely secured. Whenever possible, a ServiceAccount object should be created instead. If a ServiceAccount object cannot be created, additional security measures should be implemented. This OU will have its own set of configurations for the users (GPO) and it will have a Fine Grained Password Policy. |
| Service-Accounts Tier 0 | User/Service Identities | Service Accounts and/or Managed Service Accounts used exclusively for Administration Area / Tier0 |
| Service-Accounts Tier 1 | User/Service Identities | Service Accounts and/or Managed Service Accounts used exclusively for Servers Area / Tier1 |
| Service-Accounts Tier 2 | User/Service Identities | Service Accounts and/or Managed Service Accounts used exclusively for Sites Area / Tier2 |
We will end up having something similar to this:
Move objects to newly created Admin Area (Tier0)
After our “brand new” container was created, and that is secured, is time to move objects into it. There are many objects that cannot be moved (we are talking about many built-in domain local groups), but for those which can be moved.
We need to have all important objects (Privileged and Semi-Privileged) under our control, thus the reason to have Admin Area.
Default Administrators Accounts
Although an Administrator default account can be tracked down by its well-known sid (SID ending with 500) is a good idea to rename it, and possibly disable it. I know there are many different discussions with regards of this, some of them in favor, and some of those against ir… but we are not going to enter this discussion here. Additionally, we will create a new Administrator Like account, which will have a normal SID instead. After initial setup, the well-known Administrator account should not be used; instead the Admin-Like account will be used. Both accounts should be heavily monitored, and of course, jealously guarded.
Creating Groups
Now that we have the corresponding containers, we will start creating the corresponding groups (Global & Domain Local). Starting table contains the required Global Groups
| Security Principal | Description |
|---|---|
| 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 |
This is the list of Domain Local required groups
| Security Principal | Description |
|---|---|
| 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 |
Same as we did for OUs, there is a wrapper function for creating groups.
New-AdDelegatedGroup
Native New-AdGroup throws an error exception when the group already exists. This error is handled as a “correct” within this function due the fact that group might already exist and operation should continue, having the existing group modified. The function also can take care of removing unneeded groups, as Account Operators; or set the “Protect from accidental deletion” flag.
This wrapper function uses some CMDLets from EguibarIT.Delegation PowerShell Module
Used Functions:
Name | Module
————————-|————————–
Get-CurrentErrorToDisplay | EguibarIT
Remove-AccountOperator | EguibarIT.Delegation
Remove-Everyone | EguibarIT.Delegation
Remove-AuthUser | EguibarIT.Delegation
Remove-PreWin2000 | EguibarIT.Delegation
Fine Grained Password Policy
The Default Domain Policy is not enough to secure Privileged & Semi-Privileged accounts. Instead create a Fine Grained Password policy and assign it to privileged admin accounts and groups. Same will be for Service Accounts
Group Nesting
There is a lot to do when nesting groups. Instead, the following image will describe quite good the following PowerShell nesting code.
Same as other cases already mentioned, there is a wrapper function for group nesting. This is the same as Add-AdGroupMember but with error handling, managing duplicates an “already member” and logging.
Modify AdminSdHolder
Delegation Model defines 2 “Privileged” groups which can modify privileged users and privileged groups respectively. In other word, a “Privileged User Manager (PUM)” group that its members cam change Domain Administrators (DA) without being members of the group. Same way, “Privileged Group Management (PGM) can change “Domain Admins”, “Enterprise Admins”, etc. without being a DA. EguibarIT.Delegation PowerShell Module provides 2 CMDLets for these purposes.
Default Container Redirection
Default location for computers and users in AD is a simple folder; in other words, no specific GPO can be linked to these containers… something not good. This configuration section will create 2 OUs (Quarantine-Users & Quarantine-PCs), set the corresponding LOKDOWN GPO’s and have redirected the default location for each. Final result is that whenever a computer is domain joined without pre-staging the computer object (or without providing LDAP path destination while joining), it will end up in these new container; similar will happen to users.
Initial setup of Servers Area (Tier1)
Create Servers (or other previously defined name) OU subtree. If any sub-OU already exists, just proceed to clean it up (The CMDlet Start-AdCleanOU from module EguibarIT can be used for this propose). As we are creating OUs, we will follow the same approach as we did on Organizational Units needed to build Admin Area (Tier0). This area/tier will only contain computer objects representing servers; any other related object should go into Sites Area (Tier2) or Admin Area (Tier0).
Create the required management groups (SG_SvrAdmin, SL_SvrServerRiht, SG_Operations & SL_SvrOpsRight) as defined on the Delegation Model.
Initial setup of Sites Area (Tier2)
Create Sites (or other previously defined name) OU subtree. If any sub-OU already exists, just proceed to clean it up (The CMDlet Start-AdCleanOU from module EguibarIT can be used for this propose). As we are creating OUs, we will follow the same approach as we did on Organizational Units needed to build Admin Area (Tier0). This area/tier will contain all remaining objects, meaning anything apart from Tier0 used for administration of the environment, and servers; any other related object should go into Servers Area (Tier1) or Admin Area (Tier0).
As each and every site will be created individually, based on requirements, there is no need to create such administrative groups in advance.
Start with Delegations
Now that we have the right taxonomy & containers, and that we have the corresponding groups, we are ready to start delegating permissions and rights to these groups. We are halve the way on building our Admin Area (Tier0). Go to Delegating Admin Area (Tier0) page