Skip to main content

Overview: Operations

Introduction​

So, the introduction got you interested and you want to know more? About what you need to prepare, how to get started and how working with Active Directory through the ADMF looks like?

Well, you've come to the right place!

While we will go through all of it in more details, here's the quick cheat sheet to give an impression of what is ahead of you.

Security​

The ADMF is a toolkit implemented in MIT-licensed Open Source PowerShell modules. All code is written under a single author, no dependencies outside of his control are used. But there is a lot of code involved.

To use this solution, using this code is a prerequisite, if your organization refuses to use Open Source PowerShell code from a person from the internet, that is a cold stop. We go further into security concerns - and approaches to get approval to use the code in the dedicated Security page.

All code can be used from a central machine and connect to - and manage - multiple forests. Remote connections use (and require) the following protocols:

  • Active Directory Web Services (ADWS): As used by the official Microsoft ActiveDirectory PowerShell commands.
  • Leightweight Directory Access Protocol (LDAP): For direct Active Directory requests.
  • Windows Remote Management (WinRM): For local identity resolution and file actions.

Infrastructure​

The overall setup requires only few components:

  • Source Control Service/Server
  • Internal PowerShell Repository (Nuget or FileShare based)
  • Windows Host that executes PowerShell
  • A git client and text editor on the computer where the configurations are edited/developed
  • Optional: Automation Agent for Source Control Service/Server

Source Control Service/Server

A git host to properly version control your Active Directory configuration, but ideally also to host your custom code and copies of the ADMF code. From an ADMF perspective, it matters not, whether you use a cloud-based hosted service such as Azure DevOps Services, or operate your own on-premises server (Azure DevOps Server, Gitlab, ...).

When planning for this component, keep in mind that the configuration files hosted on this service will be used as the template according to which your entire Active Directory's security configuration will be modelled.

Internal PowerShell Repository

The reference process described later will have you distribute configuration sets as Modules and Module versions. To ensure proper deployment, ease of use and reliability, use of a PowerShell repository is strongly recommended.

These can be hosted either in a File Share or in a Nuget server. Azure DevOps Services & Azure DevOps Server both offer Nuget services under their "Artifacts" component. File Share-based repositories are simpler but scale less well - for dedicated ADMF operations they are however perfectly fine. If you wish to use the same repository for other use however, you may reach performance issues, at which point switching to Nuget based services is recommended.

Windows Host that executes PowerShell

All actual ADMF operations involve executing the associated PowerShell modules, which must be done from a Windows Computer. Whether that is a Domain Controller or an Admin workstation / Jumphost matters not. That computer cannot restrict the execution of the toolkit - whether that means you need to excempt it from PowerShell hardening, or allowlist all code involved depends on your environment. From that computer you need ADWS, LDAP & WinRM connectivity to the administrated domains.

Considering that Domain Admin level operations are executed from this computer, it must be treated as having the highest security sensitivity.

Git client & Text Editor

On the computer you edit the configuration sets from - usually the same computer that executes them - you need a git client and a text editor. The git client - an application, we recommend using the default, original tool - can be simply installed and that is it. For the text editor, we recommend Visual Studio Code (any screenshots & demo videos will use it), but any editor will technically do. Language support for json and PowerShell files is recommended.

This computer need not be a Windows Computer, but executing the ADMF does require it, any examples and videos will assume it is a Windows computer. The computer must have access to the source control service/server.

Automation Agent for Source Control Service/Server

A computer can be connected to the Source Control Service/System to help automate tasks. This is optional, but having one allows automating a few of the steps in operating ADMF code & configuration sets. Operating System is not important, but it must be able to reach the Source Control Service/System and the PowerShell Repository.

The Operational Process​

Once the infrastructure is set up - more guidance on that in sub-chapters of this guidance - the basic workflow is like this:

Your configuration, how your Active Directory should look like - your ADMF Contexts - are stored in one (or multiple, for advanced scenarios) PowerShell Module.

For each new "release" - or version - of your configuration set, you do:

  • Iterate the configuration in your editor, then test it against a test environment. This can be the production environment, so long as you do not actually invoke the changes.
  • Once satisfied with the results, update your configuration on the Source Control System
  • Release a new version of the module with your ADMF Contexts from Source Control and publish it to your PowerShell Repository.
  • Install that version onto the Windows Host you want to execute ADMF from.
  • Use that latest version and apply/invoke the changes into your Active Directory environment.