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\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
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.
Organisation2 - Client Services
Organisation2 represents the typical User Services OU and it's of the Type 'Clients'.
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 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 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.
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:
Allow log on through Terminal Services:
Remote Desktop Users:
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:
Allow log on through Terminal Services:
Remote Desktop Users:
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.
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.
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.
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 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.
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!