Active Directory and PowerShell for Jobseekers: Learn how to create, manage, and secure user accounts (English Edition)

By Mariusz Wróbel

“Active Directory and PowerShell for Jobseekers” takes you by the hand, and equips you with essential skills sought after by employers in today's IT landscape.

This book walks you through every step of the Active Directory lifecycle, covering design, deployment, configuration, and management. Automation using PowerShell is emphasized, helping you learn how to automate processes with scripts. It begins with Active Directory management, creating a development environment in Azure. In the next stage you get a thorough overview of environment creation, configuration, monitoring, security settings and recovery. With examples presented through both manual steps and automated PowerShell scripts, this book allows readers to choose their preferred method for learning PowerShell automation. Additionally, it also introduces DevOps tools for cloud infrastructure, covering update management, monitoring, security, and automation resources.

By the end of this book, you'll be confident and prepared to tackle real-world Active Directory challenges. You will also be able to impress potential employers with your in-demand skills and launch your career as a sought-after IT security specialist.

• Language: English
• Publisher: BPB Online LLP
• Release date: Feb 9, 2024
• ISBN: 9789355515865

Book preview

C

HAPTER

1

Introduction

Inspiration

Working in different companies, industries, divisions and teams can teach us many different types of Active Directory architecture. In various organizations, there are multiple ways of implementing robust, lean and high performance Directory Service solution. Starting with later versions of Windows, PowerShell scripting gained popularity and provided a great advantage to manage the Active Directory infrastructure. It also provided users with a way to improve the service from several perspectives.

There were several publications around Active Directory, most of them explained different areas of the solution and details of the implementation. The part that we missed was always thinking of the bigger picture along with how to interpolate Active Directory, what can be archived with different AD capabilities, and what are the best practices from the security point of view. It is beneficial that AD becomes a part of the security services in some companies, which shifted the focus from the enablement service to a more restrictive point of view.

There was also caution about implementing automation. PowerShell remoting was used in popular types of attacks, and big organizations were planning to disable it completely from their IT estate. On the other hand, smaller companies that grow dynamically needed to have an even more automated approach for managing Windows and AD infrastructure.

Understanding all the aspects of Active Directory and having the mindset of the person who always wants to automate IT work is very important. We can switch our effort from manual operations and use energy for different parts of the service, like security enhancement, monitoring and automation.

The purpose of this book is to explain and demonstrate all major aspects of implementation, maintenance and automation of Active Directory service and the underlying server infrastructure. It is a summary of the knowledge I gained while working in different industries, implementing different aspects of Active Directory Services and infrastructure required to host the AD service.

Introduction

So, you would like to know more about Active Directory (AD) and how to manage it effectively using PowerShell? If yes, this is the right book for you! There is lot of literature that explains either AD or PowerShell. In this book we try to provide a comprehensive overview of all necessary knowledge that is required for any sysadmin, that would need to pick up the workload of Active Directory administration and automation of AD management using PowerShell.

Today, AD is mostly used by organizations of all sizes that are utilizing Microsoft operating systems and software products. As a result, the demand of experienced IT professionals who can support such technology is significant; choosing that career path is remarkably interesting and can be a particularly good start before becoming a sysadmin or specializing in access management and becoming an identity and access management expert.

In different companies, there could be various types of AD solutions. From small, single-domain implementations to multi-domain, multi-forest organizations, learning PowerShell automation is a huge benefit to any administrator in any company. It allows you to switch your thinking about how you are managing your Windows Server and AD infrastructure, allowing you to be more proactive, reduce management overhead, and focus on more critical issues that need to be solved.

Of course, PowerShell is not the answer to every problem that is to be solved when implementing AD. When scripting is not the best option, you should focus on customer needs rather than pushing for PowerShell. Understanding all the possibilities will allow you to choose the best solution.

You do not need to have any previous knowledge about AD or scripting before diving into this book. This will be a good first step to helping you become an AD sysadmin familiar with how to utilize PowerShell in daily work. Let us get started!

Structure

This chapter will cover the following topics:

Active Directory Overview

Several types of Active Directory services

AD domain and forest implementations

PowerShell overview

Getting started with PowerShell editors

Diverse ways of Active Directory management using PowerShell

Development environment overview

Objectives

This chapter will give you basic information on Active Directory and PowerShell. We will explain the basic Active Directory architectures and provide a basic overview of PowerShell History and versioning. We will get familiar with PowerShell Editor and define the requirements for AD test environment that will be managed using scripting and automation.

Active Directory overview

What is Active Directory? Well, there are many definitions of AD, but it is a directory service that can be implemented on the Windows Server Operating system. After completing the operating system configuration, you can enable the Active Directory Domain Services Role and start deploying AD.

There are multiple Active Directory services:

Active Directory Domain Services (ADDS): It is the base Active Directory service is required for an AD infrastructure. If Active Directory skill is required in the job description, it is about ADDS. Other services are optional, but the rest of Active Directory services require ADDS to be present.

Active Directory Certificate Services (ADCS): It is the Microsoft PKI services. PKI is the organization public key infrastructure that is based on digital certificates. When enabling that role, you can deploy private CA infrastructure that would rely on AD implementation in your organization and use the benefits of the Active Directory for certificate enrolment.

Active Directory Federation Services (ADFS): This makes it possible to federate the identities to applications as well, becoming the identity provider to other external identity providers. It extends the Active Directory Domain Services with modern authentication protocols like SAML and Oath and limits the requirement of passing the credentials on applications.

Active Directory Rights Management Services (ADRMS): It is the service that protects information and ensures that only allowed people can read and modify specific documents and files. With an application that is integrated with RMS, you can define access policies and decide what level of access is required when working with sensitive information.

Active Directory Lightweight Directory Services (ADLDS): It is the implementation of LDAP database services. While ADDS provides extended capabilities, LDS is limited to provide LDAP directory without additional services. It allows integration of applications that require LDAP directory without Active Directory overhead. Here, you can implement multiple LDS instances on one server to support multiple applications with separate directories, while ADDS can only support one domain on one server.

When it comes to Active Directory, everyone refers to Active Directory Domain Services. That service is utilized in most organizations, and it requires the most effort for implementation and administration. ADFS and ADCS are commonly used, but learning about those services is much easier. In this book, we will focus on learning how to implement and administer Active Directory Domain Services.

Active Directory domain and forest implementations

As Active Directory was designed to support varied sizes of organizations, there could be multiple architecture implementations for AD. Most common architectures could be the following:

Single forest, single domain

Single forest, multiple domains

Multiple forests, multiple domains

Single forest, single domain

This architecture is recommended by Microsoft for most small organizations. It contains only one domain that holds the entire AD forest. In this case, the single domain is the root domain, and name of the domains is the same as entire forest’s name, as shown in Figure 1.1:

Figure 1.1: Example of single domain Active Directory Forest

Single forest, multiple domains

This architecture is mostly used in medium to large organizations with no requirement to split the AD into multiple forests. It provides the benefit of central administration capabilities and simple authentication scenarios within a single forest. In most cases, different domains are for geographical separation; it is not recommended to separate due to special functional use cases like manufacturing, DMZ, and the like, as shown in Figure 1.2:

Figure 1.2: Example of multiple domain Active Directory Forest

Multiple forest Active Directory

Multiple forest AD architecture is typically found in large organizations that need separation of infrastructure and management between different internal teams and products. They utilize the concept of Admin Forest and DMZ forests that need separation, often acquire different companies, and decides to keep the AD infrastructure separated. Trusts between organizations are setup to support cross-forest authentications. The following example shows three forests connected with the main forest with one-way forest trusts. That type of design allows split sensitive administration to be performed from administrative forest and separate DMZ forest from main forest using same type of trust. We will look at the trusts in detail later on. Figure 1.3 is an illustrating example implementation:

Figure 1.3: Example of multiple forest Active Directory architecture

Development environment domain architecture

We will use the multiple-domain, single-forest architecture as it will allow us to go through most AD implementation, configuration, and management scenarios with PowerShell. For our needs, we will implement the structure as close as possible, as illustrated in the Figure 1.4:

Figure 1.4: Development environment architecture

Act]ive Directory domain and forest functional levels

To utilize capabilities deployed on specific Windows Server versions, domain and forest functional level need to be raised to specific versions as well. If the current domain and forest level is not the latest, the features introduced in AD cannot be utilized fully.

Unfortunately, since Windows Server 2016, there were no significant changes in AD features that would require raising functional level, and it is the latest one available. Windows Server 2016 functional level is supported on the following:

Windows Server 2022

Windows Server 2019

Windows Server 2016

Development environment will utilize the latest available Domain and Forest functional level.

Active Directory Domain Controller

Active Directory Domain Controller is a Windows Server that has been promoted to hold Active Directory data. When there is no domain, and we are not joining an existing forest, Domain Controller will first create a domain and forest configuration. If the domain already exists, a new server will replicate the information from the existing Domain Controller, creating a replica of the same domain. That process is called DC Promotion.

Sometimes, old Domain Controllers are no longer required. To remove a Domain Controller from a domain, you need to follow the Domain Controller demotion process. The server will become a standard member of the domain and will be a candidate for complete decommissioning. If it is the last DC in the domain after demotion, the domain will be removed.

Active Directory FSMO roles

Active Directory replicates data between domain controllers, so single master roles were used to ensure consistency of the replicated data earlier. Unfortunately, when single master role failed, some of the operations could not be performed.

Then, the concept of Flexible Single Master Operations (FSMO) roles was introduced. Flexible Single Master Operations ensured that after the failure of one Domain Controller that is serving the role, the administrator was able to move or the size role to a different server without service downtime. Table 1.1 shows which FSMO roles are required in domain and forest:

Table 1.1: FSMO roles scope

When promoting first domain controller in a domain and forest, it holds all FSMO roles, but eventually splitting them between different servers is required to maintain best performance and service flexibility. FSMO roles will be covered in further detail in the upcoming chapters.

PowerShell overview

What is PowerShell (PS), and how can it be utilized for managing Active Directory? PowerShell is an automation platform that is built into Windows and can also be used on Linux and Mac. There is a PowerShell command-line interface, scripting language and PowerShell Configuration Management. Using all of those, you can deploy, configure, and administrate Active Directory in a very simplified, agile, and repeatable way.

Most operations in AD can be performed using PowerShell, so it is recommended for any sysadmin to be on top of every aspect of Active Directory management in all types of organizations. PowerShell, like CMD, is built in and present on every device running Windows Client or Server, starting with Windows 7 SP1 and Windows Server 2008 R2 SP1. You can also install it separately on previous versions, but it is always better to upgrade your OS to have it officially supported by Microsoft.

PowerShell versions history

One of the most important aspects of working with PowerShell is the knowledge about which version of PS is installed on the managed device to be utilized. When managing older OS versions, the PS version would be older as well, especially because for upgrading to PowerShell newer version, update of Windows Management Framework using installer is required. If the supported environment has a more recent OS, it would help to utilize much more built in commands that would cover much more administration tasks. Table 1.2 shows which PS version is used on specific Windows Server operating system:

Table 1.2: PowerShell versions in Windows Server

In this book, we will use PowerShell version 5.1 as it is present on Windows Server 2022 by default. One of the good practices for Active Directory is to keep the operating system as lean as possible with a minimum number of agents and additional software; PowerShell 5.1 is fit for the purpose at the moment.

PowerShell command-line interface

The easiest way to get familiar with PowerShell is to start using PowerShell as your primary command-line interface when managing Windows Client and Server devices. PowerShell can be started by clicking Windows PowerShell in the start menu or running powershell.exe from the command-line interface or using Run. Executing the following command:

get-command

This will output all available commands in your PowerShell session, as illustrated in Figure 1.5:

Figure 1.5: PowerShell console

PowerShell Integrated Scripting Environment

PowerShell Integrated Scripting Environment (ISE) is a scripting editor for writing more complex PowerShell functions and scripts.

It provides graphical interface for multiline code development, syntax coloring, and selective execution. The biggest advantage of ISE is integration with the currently used Windows Operating Systems but Microsoft deprecated starting Windows PowerShell 6.0 Core. ISE is not included in Windows Server 2022, and it is not currently in active development. You can start by navigating to the Start menu and running the ISE command in the PowerShell command-line, as shown in Figure 1.6:

Figure 1.6: PowerShell ISE

If you would like to know what the version of PowerShell on the machine is, just execute the following:

$PSVersionTable

All the details regarding the versioning will be presented.

Visual Studio Code

Microsoft is currently promoting writing any type of PowerShell scripts in Visual Studio Code with the PowerShell plugin. One of the biggest disadvantages of that solution is that it is not available by default, and you need to either install the VSCode software on your laptop or download the portable version. Fortunately, installing extensions to VSCode does not require administrator permissions in most cases. After the deployment is completed, you need to install the PowerShell Extension to get the most useful features supporting the PowerShell scripts development. Figure 1.7 illustrates the VSCode workplace with PowerShell extension installed:

Figure 1.7: Visual Studio Code with PowerShell extension

Windows Terminal

Windows Terminal is not exclusively for using PowerShell but provides a nice experience for every Windows administrator. The tool is developed by Microsoft, and you can start PowerShell or the command-line console in separate tabs and start multiple PowerShell sessions to remote devices. It also supports Azure Cloud Shell, which can be connected to directly from the Terminal window. It needs to be installed separately from Microsoft Store with some workarounds, but it is not officially supported on Windows Servers. A sample Windows Terminal view is shown in Figure 1.8:

Figure 1.8: Windows terminal

Notepad++

This is one of the editing tools preferred by many sysadmins; it is extremely useful when writing PowerShell scripts. It provides excellent features for multiple programming languages and is one of the simplest code editors, as illustrated in Figure 1.9:

Figure 1.9: Notepad++

Notepad

Sometimes there will be no other choice. Logging in to the Windows Server Core without rich graphical interface would require reviewing and editing in Notepad. If it is a few lines of code, that is feasible. But it is not something that would help in writing advanced scripts and large PowerShell modules. An example module edition in Notepad is shown in Figure 1.10:

Figure 1.10: Notepad

How to start with PowerShell?

The easiest way to switch the mindset of Windows Server administration using PowerShell is to try to review all the administrative tasks that need to be performed during your daily operations and think whether they can be automated using PowerShell. It will help us save time and focus on service improvements rather than maintenance. This challenge will not be completed in one day; it will take a long time, and eventually, some of the tasks will remain manual. But thinking about it every time while performing administrative tasks is a clever way of pushing toward the right way of managing the Active Directory and IT infrastructure in general.

What helps is to continuously work with the command-line interface when executing the PS commands for administration then learning to write PowerShell scripts in ISE or Visual Studio Code. The last solution will be the most useful because of built-in integration for version control systems like git repositories, GitHub, and Azure DevOps.

AD management options with PowerShell

Finally! So, what are our options when managing AD using PowerShell. Active Directory works on top of Window Server infrastructure. So, all modules and built-in commands that are available for managing on the servers will be useful for Managing Active Directory Domain Controllers. The options are as follows:

Built-in PowerShell commands for Windows Server management

Active Directory module that provides commands to manage users, groups and other AD objects and settings; it mostly uses ADWS for communication with AD

ADSI adapter that can be called from PowerShell and uses the LDAP protocol for communication with AD

.NET class objects

Other custom non-Microsoft supplied modules, like Quest

Built-in PowerShell commands

When starting a PowerShell session, many modules and commands will be available by default. You can check those available commands by executing the following command:

(get-command).count

The results are shown in Figure 1.11:

Figure 1.11: Windows PowerShell built-in commands

Depending on the context of that execution, we can get a different number of commands, which is shown in Figure 1.11. That could mean we are running it on a server with pre-loaded modules, having some modules imported in our user profile or simply running it on different version of PowerShell.

Running Active Directory on Windows Server requires the maintenance of all necessary server components in the right way and with proper configuration; that would include storage, networking, security events, performance, and resource management. For example, executing the following command will display the details of all PowerShell processes:

get-process | where {$_.ProcessName -like *PowerShell*}

The results are shown in Figure 1.12:

Figure 1.12: Listing PowerShell processes

If we would like to see details about volumes on the machine, you can execute the command that is part of storage volumes:

    get-volume

The results are illustrated in Figure 1.13:

Figure 1.13: Displaying volumes details using PowerShell

Active Directory PowerShell module

Most of the PowerShell Active Directory management is performed using the Active Directory module. This module contains all the necessary functions to manage AD objects and server configuration from PowerShell and scripts perspective. It has some limitations as it mostly uses Active Directory Web Services (ADWS) for interacting with AD, so performance-wise, it is slower than connecting with ADSI and LDAP directly. Also, it does not handle running this model in multithread applications. On the other hand, if you are not developing custom solution or service for AD management like this will suite all administrative needs. You can use it on the Active Directory domain controller or machine with Remote Server Administration Tools (RSAT) installed.

On Windows 10/11 client device, execute the following:

Get-WindowsCapability -Name Rsat.Active* -Online | Add-WindowsCapability -Online

The results are illustrated in Figure 1.14:

Figure 1.14: Installing RSAT Tools

Remember to elevate PowerShell as an administrator, otherwise you may get permission errors.

On Windows Server, you would need to execute different commands:

Get-WindowsFeature | Where-Object {$_.Name -like RSAT-AD-Tools} | Install-WindowsFeature

This is illustrated in Figure 1.15:

Figure 1.15: Installing RSAT Tools on Windows Server Operating System

This is because RSAT tools are available for very Windows Server without installing optional features from packages or online repositories.

Then, you will be able to import a module into your session:

import-module ActiveDirectory

The output of above command is shown in Figure 1.16:

Figure 1.16: Active Directory module overview

If you would like to import a module in the environment where no Active Directory Web Services are available, you will be shown warnings that connectivity with ADWS was not established, and you will not be able to manage Active Directory. Creation of development environment is necessary to learn all of AD management by practicing and automating tasks.

Development environment overview

As mentioned, earlier, Active Directory works as Windows Server Role. So, to deploy AD, there is a requirement to deploy at least a couple of servers that run as virtual machines. Those VMs can be deployed locally using Hyper-V on Windows or other hypervisor products like VirtualBox or VMware workstation. Each solution will have advantages and disadvantages.

Physical environment

Yes, it is the old school way of deploying Active Directory. Implementing the environment this way would be a fascinating exercise, but it would bring much more overhead than benefits. When we create a development environment, we expect rapid changes, quick deployments, and potential configuration rollbacks, so running it on physical servers will not be the best solution. Because we would like to learn about Active Directory, it is probably too much overhead. Some companies may still use physical server infrastructure and knowing potential problems when running Active Directory Domain Controller is good advantage as well, but it is less and less required.

Hyper-V environment

Hyper-V Environment could provide all the necessary capabilities to run the development environment. There is no additional cost except hardware with resources that would allow us to run set of VMs. It can be established even on laptop with some good specifications, but in extreme workloads, there may not be enough resources for what we would like to achieve, especially from memory requirements perspective.

Advantage of that solution except of reduced cost is that it can be natively managed using PowerShell. So, by implementing the Hyper-V solution, the administrator will learn some more useful commands and improve their scripting skills.

A few downsides of the solution are that it is little difficult to share it between members of the team, as the company network will probably not allow you to introduce unmanaged systems. Additionally, it cannot be used in test and production environments in the company when it is not using on-prem virtualization.

Cloud environment

Development environment can be easily implemented in the cloud. Choosing your cloud provider for development can be