top of page
Search

Deploy Domain Controllers with PowerShell and JSON (Part 2) - OU Structure and Delegation

Updated: Apr 23

Welcome Back

Welcome back to the continuation of our series on deploying Domain Controllers using PowerShell and JSON. If you've been following along with Part 1, you should now have a newly configured Domain Controller with a delegated Organizational Unit (OU) structure in place.


If you missed Part 1 of the series, you can access the necessary files by following the provided link or reference, (here).


This blog will provide an in-depth explanation of the delegation model that has been delivered by PowerShell. It will also delve into the intricacies of the Organizational Unit (OU) structure, the arrangement of nested Groups and the various Roles assigned.


Aim of the Game

The objective is to establish an Organizational Unit (OU) structure that aligns with a clear and consistent delegation model. This approach incorporates well-defined naming standards to enhance comprehensibility and facilitate ease of navigation and management within the structure.


AD Group Best Practice

Group management will follow Microsoft's best practice of assigning Domain Local groups against the object, eg an OU or GPO. The Domain Local group is then added as a 'Member of' a Domain Global group. The user is added to Domain Global as a 'Member'.


The naming convention I've persisted with over the years, again from Microsoft, is naming delegation groups 'Action Tasks', a task being an individual permission set. And 'Roles', a role being a collection of Tasks or individual permissions.

AG is Action Task Global Group

AL is Action Task Domain Local Group

RG is a Role Global Group

RL is a Role Domain Local Group


Again, something that I've persisted with over the years is that Groups and OUs are named based on their Distinguished Name (DN).


Let's break down an example of a group name:

AG_RG_Member Servers_SCCM_Servers_ResGrpAdmin


AG\AL\RG\RL - Action Task Global, AL for AT Domain Local, R for Role

RG\OU\GPO - Restricted Group, OU or GPO - Type of object delegation

Member Servers - The Top-Tier OU name

SCCM - The Application or Service eg SCCM or Certificates

Servers - It's for Computer objects

ResGrpAdmin - ResGrpAdmin is a Restricted Group providing Admin privileges.

ResGrpUser is a Restricted Group providing User privileges.

CompMgmt, create\delete and modify Computer objects.

UserMgmt, create\delete and modify User objects.

GroupMgmt, create\delete and modify Group objects.

GPOModify, edit GPO settings.

SvcMgmt, create\delete and modify user objects.

FullCtrl, full control over OU's and any child objects.


JSON OU Configuration

Traditionally there are only 3 tiers, the lower the tier the less trustworthy:

Zero = Domain Controllers and CA's

One = Member Servers

Two = Clients and Users


Given that this script can potentially generate numerous levels or hierarchies, it seemed more suitable to avoid the term "tier" and instead opted to label the top-level OU's as "Organizations" for a more meaningful representation.


The JSON configuration provided creates an OU structure based on a default OU structure for many businesses, where Orgainisation1 is for Member Servers and Orgainisation2 is for Clients and Users.


In addition, Organisation0 provides Admin Resources OU for the management of all delegation, role and admin account provision.


Organisation0 - Admin Resources

Organisation0, creates a top-level management OU named Admin Resources' This OU serves as the central hub for all delegation and management groups across subsequent Organizations.


Each Organization benefits from having its own dedicated management OU within the Admin Resources OU. Organisation specific delegation groups, roles, and admin accounts are created. This approach allows for potential future delegation.

Admin Accounts Member Servers

Admin Tasks Member Servers

Admin Roles Member Servers


"OU":

{

"Organisation0":

{

"Name":"Admin Resources",

"Path":"Root",

"Type":"Admin",

"Protect":"false",

"AdministrativeOU":"Administrative Resources",

"AdministrativeResources":

[

"AD Roles,Group",

"AD Tasks,Group",

"Admin Accounts,User"

]

},


Organisation1 - Member Servers

Organisation1 represents the typical Member Server OU and it's of the Type Server. The type Server designates a behavioural difference for assigning policy.


AppResources designates application service OU's that will be created eg Exchange.


Service Resources is used for creating OU's based on a set of standard administrative functions for example Servers and the delegation and object type of Computers.

"Organisation1":

{

"Name":"Member Servers",

"Path":"Root",

"Type":"Server",

"Protect":"false",

"AdministrativeOU":"Service Infrastructure",

"AdministrativeResources":

[

"AD Roles,Group",

"AD Tasks,Group",

"Admin Accounts,User"

],

"AppResources":"Certificates,MOSS,SCCM,SCOM,File Server,Exchange",

"ServiceResources":

[

"Servers,Computer",

"Application Groups,Group",

"Service Accounts,SvcAccts",

"URA,Group"

]

},


Organisation2 - Client Services

Organisation2 represents the typical User Services OU and it's of the Type 'Clients'.


"Organisation2":

{

"Name":"User Services",

"Path":"Root",

"Type":"Clients",

"Protect":"false",

"AdministrativeOU":"Service Infrastructure",

"AdministrativeResources":

[

"AD Roles,Group",

"AD Tasks,Group",

"Admin Accounts,User"

],

"AppResources":"Clients",

"ServiceResources":

[

"Workstations,Computer",

"Groups,Group",

"Accounts,User",

"URA,Group"

]

}

}


Hundreds and thousands

It's possible to add further top-level OU's by duplicating an Organisation, then updating the Organisation(*) and Name values as they need to be unique.


It's possible to add hundreds or even thousands of Organisations, with this possibility in mind, the management and delegation structure reflects this within the design.


Levels of OU Delegation

As we delve deeper into the structure of each organization, we encounter a hierarchy consisting of three levels of delegation, using Member Servers as an example:

Organisation = Member Servers (Level 1)

Application Service = Certificates (Level 2)

Resources = Computer, Groups, Users and Service Accounts (Level 3)


OU delegation controls the level of access to manage objects eg create a Computer or Group object.

Level 1

Level 1 is the organisation level in this case it's the Member Server OU. It's delegated with AL_OU_Member Servers_FullCtrl. The group provides full control over the OU, sub-OU's and all objects within.


The arrow serves as an indicator, denoting the point at which the group's application takes effect within the structure.


Level 2

Level 2 is the Service Application level, in this case, Certificate services. AL_OU_Member Servers_Certificates_FullCtrl is applied a level below Member Servers and provides full control over itself and any subsequent objects.


Level 3

At Level 3, the delegation involves the management of Service Applications resources, which includes items such as Server objects and service accounts.


The 4 default OU's allow the delegation and management of their respective resource types, for example, the Application Groups OU permits the creation and deletion of Group objects via AL_OU_Member Servers_Certifcates_Applications Groups_GroupMgmt.

Application Groups - Application specific Groups

Servers - Server or Computer objects

Service Accounts - Service Accounts for running the application services

URA - User Rights Assignments for services that require LogonAsAService etc


Restricted Groups and User Rights Assignment (URA) Levels

In this delegated model, Restricted Groups facilitate access by allowing administrative access whilst User Rights Assignments (URA) allow admins or users to log on over Remote Desktop Protocol (RDP).


There are two primary levels of organization. The first level encompasses the entire organization, including all subsequent Organizational Units (OUs). The second level consists of a dedicated Servers OU for each specific Service Application.


Level 1 of Restricted Groups

The GPO GPO_Member Server_RestrictedGroups is linked to the Member Servers OU and has the following groups assigned:


URA:

Allow log on through Terminal Services:

AL_RG_Member Servers_ResGrpAdmin

AL_RG_Member Servers_ResGrpUser


Restricted Group:

Administrators:

AL_RG_Member Servers_ResGrpAdmin


Remote Desktop Users:

AL_RG_Member Servers_ResGrpUser


This is how it looks when applied in GPO.

Within this delegation model, the ability to manage Group Policy Object (GPO) settings is also delegated to ensure comprehensive control and management of the environment. via AL_GPO_Member Servers_GPOModify Group.


Level 2 of Restricted Groups

The GPO GPO_Member Server_Certificates_Servers_RestrictedGroups is linked to the sub-OU Servers under Certificates and has the following groups assigned, that of the Organisation and of the Service Application:


URA:

Allow log on through Terminal Services:

AL_RG_Member Servers_ResGrpAdmin

AL_RG_Member Servers_ResGrpUser

AL_RG_Member Servers_Certifcates_ResGrpAdmin

AL_RG_Member Servers_Certificates_ResGrpUser


Restricted Group:

Administrators:

AL_RG_Member Servers_ResGrpAdmin

AL_RG_Member Servers_Certifcates_ResGrpAdmin


Remote Desktop Users:

AL_RG_Member Servers_ResGrpUser

AL_RG_Member Servers_Certificates_ResGrpUser


This is how it looks when applied in GPO.

As above Group Policy Object (GPO) settings are also delegated via AL_GPO_Member Servers_Certificates_Servers_GPOModify


Bringing it all together with Roles

In this demonstration, an account named 'CertAdmin01' has been specifically created to oversee the management of resources within the Certificates OU.

The account is added to the role group RG_OU_Member Servers Certificates_AdminRole.

Opening the RG_ group and then selecting the 'Members Of' tab displays the nested RL_ group. Drilling down into the RL_ group displays the individual delegated task groups.


Delegated Admin

To test the certificate Admin (CertAdmin01) deploy an additional server, adding to the domain and ensuring the computer object is in the Certificate Servers OU.


Login as CertAdmin01 to the new member server and install the GPO Management and AD Tools.


Browse to Member Server and then Certificates OU and complete the following tests:


Right-click on Applications Group > New > Group

Right-click on Servers > New > Computer

Right-click on Service Accounts > New > User

Right-click on URA > New > Group.

Open Group Policy Management and Edit GPO_Member Servers_Certificates_Servers_RestrictedGroup.

Open Compmgmt.msc and confirm that the Administrators group contains the 2 _ResGrpAdmin groups and the local Administrator.

AL_RG_Member Servers_Certificates_Servers_ResGrpAdmin

AL_RG_Member Servers_ResGrpAdmin

Confirm that CertAdmin01 is unable to create or manage any object outside the delegated OU's.


Nearly there.....SCM Policies and ADMX Files

As part of the delivery and configuration of the OU structure, Microsoft's Security Compliance Manager (SCM) GPOs and a collection of Administrative (ADMX) templates are included.


SCM GPOs:

Microsoft's SCM offers a set of pre-configured GPOs that are designed to enhance the security and compliance of Windows systems. These GPOs contain security settings, audit policies, and other configurations that align with industry best practices and Microsoft's security recommendations.


ADMX Templates:

ADMX files, also known as Administrative Template files, extend functionality within Group Policy Management enabling settings for Microsoft and 3rd party applications. Within a Domain, ADMX files are copied to the PolicyDefinition directory within Sysvol.


Zipped...

Both SCM and ADMX files are zipped and will automatically be uncompressed during the OU deployment. However, if you would like to add your own policies and ADMX files you can.


SCM Policy Placement

The SCM policies are delivered in their default configuration, without any modifications or merging. The policies are placed directly into the designated target directory, imported and linked to their respective OU. For example, the Member Server directory content will be linked to any OU that is of type 'Server'.


The SCM imported policies are prefixed with 'MSFT,' indicating that they are Microsoft-provided policies. There are a substantial number of these policies linked from the root of the domain down to client and server-specific policies.


As far as delegation the SCM policies remain under the jurisdiction of the Domain Admin with control to effect change delegated to the _'RestrictedGroup' policies.

Thank you for taking the time to read this blog. I hope you found the information valuable and that it has been helpful. Your support is greatly appreciated!





























21 views0 comments
bottom of page