Building Admin Area (Tier0)

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