Configuring Admin Area (Tier0)

At this stage, we have all (or most) of our Tier0 objects ready; and most (if not all) delegations are in place representing all roles defined i our Delegation Model. Now is time to configure our Admin Area (Tier0). All those configurations are to maintain Tier0 integrity over time, while having a central configuration. This will make our infrastructure more manageable and secure over the coming years.

• Create & Configure GPOs
• Import GPO templates
• Set GPO Restrictions

Create & Configure GPOs

After over 2 decades of having GPOs, we still having many diverse strategies on how many GPOs do we need. This have raised the number of GPOs too much; the lack of a strong strategy.

As the definition says: a GPO is a set of configurations which can be centrally applied. Applied to whom? Simple, just to Users and/or computers. So here we define the first rule:

Any GPO created must be defined to be either for Users or for Computers, but not for both.

A very common bad practice is that every time a new setting is need, a new GPO is created. In order to avoid these bad practices, we have to define how are we going to manage these GPOs, and when is “valid” to create a new one. Create the GPOs as Monolithic GPO. Meaning of this is that 90% or 95% of the configurations will be done using the same GPO object, and only the remaining configurations which are not compatible with the monolithic GPO will be configured on another GPO. New GPO will ONLY be created when the existing (monolithic) GPO is not compatible with the new setting.

• Monolithic GPO refers to a consolidated GPO which will have ALL settings configured.
• Monolithic GPO will be either COMPUTER or USER, but not both.
• Monolithic GPO strategy is to have the fewest number of GPO within the hierarchy:
• 2 GPOs at domain level (1 user and 1 computer | GENERAL)
• 2 GPOs at sites (1 user and 1 computer | GLOBAL)
• 3 GPOs at site level (1 user, 1 Desktop and 1 Laptop)
• Exceptions might exist, previous analysis and authorization by corresponding AD Architect board.

For more information please read more on “Monolithic GPO”.

After reviewing our GPO strategy, and most important, the “monolithic GPO” concept, we can start creating all required GPOs for Configuring Admin Area (Tier0). The New-DelegateAdGpo wrapper function will check for existence of a GPO, creating it in case it does not exists; it will grant the previously defined GPO Admin Rights group to edit, modify, delete & security; disable the corresponding section of the GPO (If user settings, disable computer & viceversa); link the GPO to its corresponding Ldap path; and in case a backup template needs to be imported, the process it accordingly.

Import GPO templates

The wrapper function New-DelegateAdGpo can restore the GPO during creation time, but this can also be accomplished in case GPO already exist. Remember that when importing a GPO, all previous existing settings will get removed, and only the settings from the backup will remain. Those mentioned backup templates can be found on several places, like Microsoft Security Compliance Toolkit, Microsoft Security Baselines Blog or Center for Internet Security (CIS)

This is exactly the case for already existing “Default Domain” & “Default Domain Controllers” GPOs.

Set GPO Restrictions

This section is the key for the Tier Model to be compliant. By setting up the Rights each tier has, we can ensure that Semi-Privileged and Privileged accounts are able to logon ONLY to the tier they belong to.

The Set-GpoPrivilegeRights will help us to implement such restrictions while Configuring Admin Area (Tier0), having the parameter to configure NetworkLogon, DenyNetworkLogon, InteractiveLogon, DenyInteractiveLogon, RemoteInteractiveLogon, DenyRemoteInteractiveLogon, BatchLogon, DenyBatchLogon, ServiceLogon and DenyServiceLogon.

Domain Restrictions

Domain Controllers Restrictions