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…):

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

This is the list of Domain Local required groups

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