Проверка состояния службы Active Directory с использованием среды PowerShell – techsyncer

Это часть II двухчастной серии о проверке состояния службы каталогов Active Directory. Хотя для понимания того, как создавался скрипт PowerShell, о котором вы узнаете в этой статье, не требуется чтения первой части, мы рекомендуем ознакомиться с Создание инструмента проверки состояния службы каталогов Active Directory [Подробно]: Часть I.

В первой части вы узнали, сколько различных тестов существует и почему они важны. Теперь давайте объединим их все вместе и создадим инструмент. В этой части вы преобразуете все проверки состояния службы каталогов Active Directory, объясненные в первой части, в тестовую структуру. Вы также узнаете, как выводить результаты различных проверок состояния AD в инструменты, такие как Pester и инструмент мониторинга под названием PRTG.

Чтобы следовать за примерами или увидеть готовую версию инструмента, о котором вы узнаете в этой статье, загрузите скрипт ADHealthCheck-NoResult.ps1 с GitHub.

Определение вывода

Наличие общего типа объекта и простого способа его генерации значительно облегчит преобразование результатов тестов в выбранный вами инструмент.

Для создания однородного вывода для всех потенциальных инструментов я выбрал использовать класс PowerShell. Хотя это не обязательно, я выбрал именно этот подход. Главное – обеспечить возврат всех проверок состояния AD одного и того же типа вывода.

A PowerShell class is a schema that defines how a PowerShell object should look and what it should do. Each line you see below represents a property the objects return will have. You can see below I’m planning on each AD health check to return ten properties.

Class AdhcResult {
    [string]$Source
    [string]$TestName
    [bool]$Pass
    $Was
    $ShouldBe
    [string]$Category
    [string]$SubCategory
    [string]$Message
    $Data
    [string[]]$Tags
}

Для ускорения создания этого класса я буду использовать вспомогательную функцию под названием New-AdhcResult. Эта функция создает класс и все необходимое для вашего участия. Эта функция будет выводить пользовательский объект типа [AdhcResult].

Запуск инструмента проверки состояния AD

Сначала загрузите и скопируйте сценарий проверки состояния AD на контроллер домена. Откройте его в PowerShell ISE и запустите. Этот этап инструмента не вернет никакой информации.

Этот сценарий выполнит проверку и сохранит результат каждой проверки в переменной $TestResults как несколько объектов [AdhcResult]. Вы будете использовать эти объекты позже для создания отчетов или вывода их в различные инструменты. Хранение результатов проверки состояния в переменной такого типа позволяет добавлять больше результатов, если вы решите создать еще один и использовать команду New-AdHcResult.

После завершения выполнения сценария у вас должен быть полный набор объектов проверки состояния AD, сохраненных в переменной $TestResults. Теперь вы можете запустить $TestResults из консоли и посмотреть сырые результаты.

Отображение результатов проверки состояния AD в инструментах

Поскольку все проверки находятся в общем типе объекта, вы можете лучше их проверить с помощью нескольких инструментов, таких как Pester и PRTG.

В этом разделе вы узнаете, как создать отчет HTML с помощью инструмента под названием extent и отобразить отчет в PRTG.

Создание файла XML nUnit с помощью Pester

Сначала вам нужно преобразовать объекты PowerShell в формат, понятный вашим инструментам. Большинство инструментов понимают XML или, более конкретно, XML формата nUnit. Это формат, который можно импортировать в различные инструменты для отображения результатов.

Поскольку вы работаете с PowerShell, вы будете использовать тестовый фреймворк Pester для чтения вывода из сценария проверки состояния AD и генерации файла XML nUnit

Начните с загрузки последней версии Pester. Вы можете загрузить Pester, выполнив Install-Module в повышенной консоли PowerShell. Нижеприведенная команда принудительно установит последнюю версию Pester. Поскольку издательский сертификат, которым подписан Pester, поставляется с Windows 10, нам нужно использовать параметр SkipPublisherCheck, чтобы установить его.

PS51> Install-Module Pester -Force -Verbose -SkipPublisherCheck

Как только Pester будет доступен, вы сможете запустить сценарий и динамически создать набор тестов Pester.

Примечание: Вы также можете создавать тесты Pester сами, даже не используя предоставленный мной сценарий PowerShell.

Нижеприведенный сценарий PowerShell будет использовать Pester для создания файла XML nUnit из вывода переменной $TestResults, определенной в сценарии ADHealthCheck-NoResult.ps1.

Сохраните этот файл как Pester.ps1 в той же папке, что и скрипт проверки состояния AD.

# dot source in the ADHealthCheck file
. $PSScriptRoot\ADHealthCheck-NoResult.ps1
$Grouped = $TestResults | Group-Object Category

Foreach($Category in $Grouped) {
    Describe -Name $Category.Name -Tags ($Category.Group.Tags | Select -Unique) {
        Foreach($Result in $Category.Group){
            Context "$($Result.Source) - $($Result.TestName)" {
                It -Name "Should've passed" {
                    $Result.Pass | Should -Be -ExpectedValue $True -Because $Result.data
                }
            }
        }
    }
}

Наконец, выполните Invoke-Pester ниже, чтобы вызвать файл Pester.ps1 и сохранить результаты в формате NUnitXml.

PS51 > Invoke-Pester -Script @{Path = '.\Pester.ps1'} -OutputFile .\NunitReport.xml -OutputFormat NUnitXml

Создание HTML-отчета с помощью инструмента Extent

После того как у вас есть файл XML NUnit, вы можете использовать его для передачи в инструмент, который может преобразовать его в HTML. Один из таких инструментов называется extent. Extent – удобный инструмент для создания HTML-отчетов из файлов XML NUnit.

Сначала скачайте extent в ту же директорию, что и файл NunitReport.xml, созданный ранее. Затем выполните следующие команды в сеансе PowerShell. Эти команды создадут каталог для хранения HTML-файлов, а затем выполните extent.exe для выполнения преобразования.

# Создать каталог отчета
PS51> mkdir .\HTMLReports

# Создать отчет
PS51> .\extent.exe -i .\NunitReport.xml -o .\HTMLReports\

По завершении вы найдете два HTML-файла в каталоге HTMLReports. Эти файлы будут выглядеть как на скриншотах ниже, когда вы откроете их в веб-браузере.

Внедрение результатов проверки состояния AD в PRTG

PRTG – популярный инструмент мониторинга, разработанный компанией Paessler, который вы можете использовать для мониторинга вашей инфраструктуры и услуг. В этом разделе вы узнаете, как отправить результаты проверки состояния в PRTG после выполнения скрипта проверки состояния.

Отправка результатов в PRTG требует больше работы, чем получение информации инструментом, но в конечном итоге вы увидите, что настройка стоит потраченного времени.

Предварительные требования

Чтобы успешно настроить PRTG как инструмент мониторинга для скрипта проверки состояния AD, созданного в этой статье, убедитесь, что у вас есть:

Установленный и настроенный PRTG
Все контроллеры домена настроены в PRTG
Скрипт PowerShell Send-AdhcResultToPrtg.ps1 загружен с GitHub
URL и порт вашего датчика PRTG

Если у вас выполнены все предварительные требования, вы можете следовать ниже приведенным пошаговым инструкциям о том, как я рекомендую отправлять результаты проверки состояния AD в PRTG.

Создайте устройство в PRTG с именем Domain или любым другим именем, которое вам нравится.
Создайте датчик Advanced HTTP push sensor с IdentityToken directory-adhealthcheck. Обратите внимание, что это чувствительно к регистру!
Для каждого устройства контроллера домена в PRTG создайте один Advanced HTTP push sensor. Для каждого IdentityToken добавьте к каждому датчику -adhealthcheck, например dc01-adhealthcheck.
Добавьте содержимое сценария PowerShell Send-AdhcResultToPrtg.ps1 в конец сценария PowerShell ADHealthCheck-NoResult.ps1, который мы рассматривали.
Измените переменную $PRTGUrl на URL и порт вашего датчика PRTG.
Выполните сценарий.

После завершения выполнения сценария проверки состояния AD он должен теперь отправлять статус на ваши датчики PRTG, как показано ниже.

Планирование сценария проверки состояния Active Directory

Мониторинг состояния AD является непрерывным процессом. Вы должны выполнять тесты все время, а не случайно. Давайте запланируем запуск сценария проверки состояния Active Directory с частыми интервалами.

Самый простой способ автоматизировать эти проверки – добавить сценарий в планировщик задач и запустить его от имени учетной записи пользователя AD или управляемой службы группы.

Использование управляемой службы группы (gMSA) является более безопасным способом выполнения запланированных задач автономно, поскольку пароль можно получить только из указанных учетных записей компьютеров из AD. Но некоторые организации могут не иметь такой возможности.

Создание учетной записи пользователя AD

Давайте сначала разберемся, что требуется для настройки учетной записи пользователя AD для запуска запланированной задачи.

Если вы собираетесь запускать запланированное задание от имени учетной записи пользователя, то, пожалуйста, не запускайте его от своей учетной записи! Всегда создавайте отдельную учетную запись пользователя для этого.

Чтобы сэкономить время, вот PowerShell-скрипт ниже. Это пример скрипта, который вы можете использовать для создания учетной записи пользователя Active Directory, входящей в группу Domain Admins. Затем вы можете использовать эту учетную запись для запуска запланированного задания.

# Измените это на OU ваших учетных записей службы
$OU = "OU=Service Accounts,DC=contoso,DC=com"
# Измените это на пароль, который вы хотите использовать для учетной записи
$Password = "JägareTvå"
$SecureString = $Password | ConvertTo-SecureString -AsPlainText -Force
New-ADUser -Enabled $True -Path $OU -Name svcADHealthCheck -AccountPassword $SecureString
# Ограничьте учетную запись только для контроллеров домена
$DomainControllers = (Get-ADDomainController -Filter *).Name

Set-ADAccount -Identity svcADHealthCheck -LogonWorkstations ($DomainControllers -Join ",")

# Сделаем ее администратором домена (Извините)
Add-ADGroupMember -Identity "Domain Admins" -Members svcADHealthCheck

Создание управляемой групповой службы

Использование gMSA для запуска проверки состояния здоровья немного сложнее, если вы еще не используете gMSA в своей среде, но это гораздо безопаснее.

Создание корневого ключа KDS

Чтобы создать учетную запись gMSA для выполнения сценария проверки состояния AD, сначала добавьте корневой ключ KDS, если у вас его еще нет. Вы можете проверить наличие корневого ключа KDS, выполнив команду PowerShell Get-KDSRootKey на контроллере домена.

Если у вас нет корневого ключа KDS, вы можете создать его, запустив Add-KDSRootKey -EffectiveImmediately от имени учетной записи пользователя, входящей в группу Domain Admins AD на контроллере домена 2012R2 или более поздней версии.

Ключ должен реплицироваться на другие контроллеры домена для полного вступления в силу. Дополнительную информацию о этом процессе можно найти в документации Microsoft.

Создание учетной записи gMSA

После создания корневого ключа KDS вы готовы создать учетную запись gMSA с помощью PowerShell. Ниже приведен пример скрипта для создания учетной записи gMSA, разрешенной только для аутентификации с контроллера домена в группе Domain Admins.

# Измените на ваш домен
$Domain = "contoso.com"

$AccountName = "svcadhealthcheck"

# Создайте GMSA с именем svcadhealthcheck (или на самом деле svcadhealthcheck$) и разрешите только контроллерам домена получать пароль
New-ADServiceAccount $AccountName -DNSHostName "$AccountName.$Domain" –PrincipalsAllowedToRetrieveManagedPassword "Domain Controllers"

# Добавьте GMSA в Domain Admins
# Обратите внимание, что мы добавляем учетную запись по ее настоящему SamAccountName 'svcadhealthcheck$'
Add-ADGroupMember -Identity "Domain Admins" -Members "$AccountName`$"

Установка и тестирование gMSA

Теперь gMSA создана, последний шаг – установить и протестировать её на всех контроллерах домена. Один из способов сделать это – использовать команду PowerShell Invoke-Command. Ниже вы можете увидеть сценарий PowerShell, который установит gMSA на всех контроллерах домена и убедится, что она работает правильно.

# Этот сценарий будет выполняться на всех контроллерах домена
Invoke-Command -ComputerName (Get-ADDomainController -Filter *).Name -ScriptBlock {
    $Account = Get-ADServiceAccount -Filter { Name -eq 'svcadhealthcheck'}
    Install-ADServiceAccount $Account

    # Проверяет, что GMSA работает на компьютере
    # Возвращает $True, если тесты проходят успешно
    $Test = Test-ADServiceAccount -Identity $Account.Name
    if($Test){
        Write-Output "GMSA test OK on $env:computername"
    }
    else {
        Write-Output "GMSA test FAILED on $env:computername"
    }

}

Даем gMSA разрешение на запуск как пакетная задача

После установки gMSA вам нужно дать ей разрешение на запуск как пакетной задачи на контроллерах домена. Учетная запись нуждается в этом праве, так как она будет работать автономно на заднем плане в запланированной задаче.

Вы можете установить это разрешение через существующую GPO или создав новую GPO и связав её с OU Контроллеры домена. Если у вас еще нет GPO для использования, ниже приведены некоторые шаги, которые вы можете предпринять, чтобы создать его.

Запустите Редактор политики группы на одном из контроллеров домена.
Щелкните правой кнопкой мыши на OU Контроллеры домена и выберите Создать GPO в этом домене и связать его здесь.
Назовите его DC – Вход в систему как пакет или другим именем, которое вам нравится
Щелкните правой кнопкой мыши на GPO и выберите Изменить.
Перейдите к Конфигурация компьютера -> Настройки Windows -> Настройки безопасности -> Назначение прав пользователей.
Щелкните левой кнопкой мыши на Войти как пакетная задача и щелкните Свойства.
Кликните Добавить пользователя или группу.
Кликните на Типы объектов, выберите только Учетные записи служб и нажмите OK.
Поиск Учетной записи службы svcADHealthCheck, созданной ранее, выберите ее и нажмите OK.

Теперь вы должны увидеть gMSA в списке объектов AD, как показано ниже.

gMSA given rights to logon as a batch job

Создание запланированной задачи

Теперь, когда у вас есть учетная запись, созданная для запуска запланированных задач, вы можете создать саму запланированную задачу на выбранном вами сервере, присоединенном к домену.

Вы можете создать запланированную задачу через GUI, но это слишком много кликов! Вместо этого я рекомендую создать ее с помощью PowerShell. Почему? Потому что вы можете просто скопировать код, который вы видите ниже, и закончить с этим.

Ниже вы найдете два сценария; оба сценария похожи, но один предполагает учетную запись пользователя AD, а другой – gMSA. Обязательно используйте соответствующий сценарий в зависимости от того, какую учетную запись вы используете.

# Замените на путь к вашему скрипту
$ScriptPath = "C:\Scripts\ADHealthCheck.ps1"
# Замените на имя пользователя учетной записи, которую вы создали для запуска задачи
$UserName = "svdADHealthCheck"

# Замените на пароль, который вы установили для указанной учетной записи
$Password = "JägareTvå!"
# Создайте действие, которое запускает скрипт
$Action = New-ScheduledTaskAction -Execute "powershell.exe" -Argument "-ExecutionPolicy bypass -File '$ScriptPath'"
# Создайте триггер, который запускает задачу
$Trigger = New-ScheduledTaskTrigger -Once -At "12:00" -RepetitionInterval (New-TimeSpan -Hours 12)
# Создайте настройки для запланированной задачи
$Settings = New-ScheduledTaskSettingsSet -AllowStartIfOnBatteries -DontStopIfGoingOnBatteries -StartWhenAvailable -RunOnlyIfNetworkAvailable -DontStopOnIdleEnd
# Создайте запланированную задачу, используя splat для улучшения читаемости
$Splat = @{
    User = "$env:USERDOMAIN\$UserName"
    Password = $Password
    TaskName = "ADHealthCheck"
    Action = $Action
    Trigger = $Trigger
    RunLevel = "Highest"
    Settings = $Settings
}
Register-ScheduledTask @Splat

# Замените на путь к вашему скрипту
$ScriptPath = "C:\Scripts\ADHealthCheck.ps1"
# Замените на имя пользователя учетной записи, которую вы создали для запуска задачи
$UserName = "svdADHealthCheck$"
# Создайте действие, которое запускает скрипт
$Action = New-ScheduledTaskAction -Execute "powershell.exe" -Argument "-ExecutionPolicy bypass -File '$ScriptPath'"
# Создайте триггер, который запускает задачу
$Trigger = New-ScheduledTaskTrigger -Once -At "12:00" -RepetitionInterval (New-TimeSpan -Hours 12)
# Создайте настройки для запланированной задачи
$Settings = New-ScheduledTaskSettingsSet -AllowStartIfOnBatteries -DontStopIfGoingOnBatteries -StartWhenAvailable -RunOnlyIfNetworkAvailable -DontStopOnIdleEnd

# Создайте принципал, который определяет GMSA
$Principal = New-ScheduledTaskPrincipal -UserID "$env:USERDOMAIN\$UserName" -LogonType Password -RunLevel Highest
# Создайте запланированную задачу, используя splat для улучшения читаемости
$Splat = @{
    Principal = $Principal
    TaskName = "ADHealthCheck"
    Action = $Action
    Trigger = $Trigger
    RunLevel = "Highest"
    Settings = $Settings
}
Register-ScheduledTask @Splat

Вы готовы! В этот момент запланированная задача будет выполняться с указанным интервалом в одном из вышеуказанных скриптов.

Summary

Фух! Если вы следовали внимательно с самого начала Части I, то должны уже знать, что здоровье AD – это глубокая тема. В этой одной теме так много всего, что даже двух длинных блог-постов не хватит, чтобы охватить все.

Но к настоящему времени у вас должно быть достаточно знаний и готового к использованию сценария PowerShell, чтобы подключать другие проверки здоровья Active Directory по мере их появления.