构建 Active Directory 运行状况检查工具 [深入]：第二部分

这是有关 Active Directory 运行状况检查的两部分系列的第二部分。虽然不是必读内容，但如果您想了解如何构建您将在本文中了解的 PowerShell 脚本，我们鼓励您查看构建 Active Directory 运行状况检查工具 [深入]：第 I 部分.

在第一部分中，您了解了有多少种不同的多重测试以及它们为何如此重要。现在让我们将它们整合在一起并构建一个工具。在这一部分中，您将把第一部分中解释的所有 Active Directory 运行状况检查转换为测试框架。您还将学习如何将各种 AD 运行状况检查的结果输出到 Pester 等工具和名为 PRTG 的监控工具。

要继续操作或查看您将在本文中了解的工具的完成版本，请从 GitHub 下载 ADHealthCheck-NoResult.ps1 脚本。

定义输出

拥有通用的对象类型和简单的生成方法将使将测试结果转换为您选择的工具变得更加容易。

为了为所有潜在工具创建统一的输出，我选择使用 PowerShell 类。虽然不是必需的，但这是我选择在这里采用的方法。要点是确保所有 AD 健康检查返回相同类型的输出。

PowerShell 类是一个架构，它定义 PowerShell 对象的外观和功能。您在下面看到的每一行都代表对象返回将具有的属性。您可以在下面看到我计划在每次 AD 健康检查中返回十个属性。

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 命令，则可以添加更多结果。

脚本运行完毕后，您现在应该在 $TestResults 变量中存储了一组完整的 AD 运行状况检查对象。您现在可以从控制台运行 $TestResults 并查看原始结果。

在工具中显示AD健康检查结果

由于所有检查都采用通用对象类型，因此您可以通过 Pester 和 PRTG 等工具更好地检查它们。

在本节中，您将学习如何使用名为“extent”的工具创建 HTML 报告并在 PRTG 中显示该报告。

使用 Pester 创建 nUnit XML 文件

您首先需要将 PowerShell 对象转换为您的工具可以理解的格式。大多数工具都理解 XML，或更具体地说，nUnit XML。您可以将此格式导入到各种工具中以显示结果。

由于您使用的是 PowerShell，因此您将使用 Pester 测试框架读取 AD 运行状况检查脚本的输出并生成 nUnit XML 文件

首先下载最新版本的 Pester。您可以通过在提升的 PowerShell 控制台中运行 Install-Module 来下载 Pester。以下命令将强制安装最新的 Pester 版本。由于 Windows 10 附带了 Pester 签名的发布者证书，因此我们需要使用 SkipPublisherCheck 参数来安装它。

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

一旦 Pester 可用，您就可以运行脚本并动态创建一组 Pester 测试。

注意：您还可以自己创建 Pester 测试，甚至无需使用我提供的 PowerShell 脚本。

以下 PowerShell 脚本将使用 Pester 从 ADHealthCheck-NoResult.ps1 脚本中定义的 $TestResults 变量的输出生成 nUnit XML 文件。

将此文件另存为 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 报告

获得 NUnit XML 文件后，您现在可以使用该文件传递给可将其转换为 HTML 的工具。这些工具之一称为范围。 Extent 是一个方便的工具，用于从 Nunit XML 文件创建 HTML 报告。

首先，将范围下载到与之前创建的 NunitReport.xml 文件相同的目录。然后在 PowerShell 会话中执行以下命令。这些命令将创建存储 HTML 文件的目录，然后执行 extent.exe 进行转换。

# Create report directory
PS51> mkdir .\HTMLReports

# Create the report
PS51> .\extent.exe -i .\NunitReport.xml -o .\HTMLReports\

完成后，您将在 HTMLReports 目录中找到两个 HTML 文件。这些文件将类似于下面的屏幕截图，您可以使用网络浏览器打开它们。

将 AD 健康检查结果提取到 PRTG 中

PRTG 是 Paessler 开发的一款流行的监控工具，您可以使用它来监控您的基础设施和服务。在本节中，您将了解如何在运行状况检查脚本运行后将运行状况检查结果推送到 PRTG。

将结果推送到 PRTG 确实比使用工具提取信息需要更多的工作，但您最终会发现设置是非常值得花费时间的。

先决条件

要成功将 PRTG 设置为本文中构建的 AD 运行状况检查脚本的监视工具，请确保您拥有：

• PRTG安装并配置
• PRTG 中设置的所有域控制器
• 从 GitHub 下载的 Send-AdHCResultToPrtg.ps1 PowerShell 脚本
• 您的 PRTG 传感器的 URL 和端口

如果您已完成每个先决条件，则可以按照以下分步说明操作，了解我建议如何将这些 AD 运行状况检查结果推送到 PRTG。

1. 在 PRTG 中创建一个名为“域”或任何您喜欢的名称的设备。
2. 创建一个 高级 HTTP 推送传感器，其 IdentityToken 为 directory-adhealthcheck。请注意，这是区分大小写的！
3. 对于 PRTG 中的每个域控制器设备，创建一个高级 HTTP 推送传感器。对于每个 IdentityToken，为每个传感器附加 -adhealthcheck，例如 dc01-adhealthcheck。
4. 将 Send-AdHCResultToPrtg.ps1 PowerShell 脚本的内容添加到我们介绍过的 ADHealthCheck-NoResult.ps1 PowerShell 脚本的末尾。
5. 将变量 $PRTGUrl 更改为 PRTG 传感器的 URL 和端口。
6. 执行脚本。

完成后，一旦 AD 运行状况检查脚本完成，它现在应该将状态推送到您的 PRTG 传感器，如下所示。

安排 Active Directory 运行状况检查脚本

监测 AD 健康状况是一个持续的过程。您应该始终运行测试而不是临时实例。让我们安排 Active Directory 运行状况检查脚本定期运行。

自动执行这些检查的最简单途径是将脚本添加到任务计划程序并让它在 AD 用户帐户或组管理服务帐户下运行。

使用组托管服务帐户 (gMSA) 是自主执行计划任务的更安全方法，因为只有指定的计算机帐户可以从 AD 获取密码。但有些组织可能没有这种奢侈。

创建 AD 用户帐户

让我们首先详细说明如何设置 AD 用户帐户来运行计划任务。

如果您要以用户帐户运行计划任务，请务必不要以您自己的帐户运行它！始终为此目的创建一个单独的用户帐户。

为了节省时间，您将在下面看到一个 PowerShell 脚本。这是一个示例脚本，您可以使用它来创建属于域管理员组的 AD 用户帐户。然后，您可以使用此帐户来运行计划任务。

# Change this to the OU of your service accounts
$OU = "OU=Service Accounts,DC=contoso,DC=com"
# Change this to the password that you want to use for the account
$Password = "JägareTvå"
$SecureString = $Password | ConvertTo-SecureString -AsPlainText -Force
New-ADUser -Enabled $True -Path $OU -Name svcADHealthCheck -AccountPassword $SecureString
# Restrict account to only Domain Controllers
$DomainControllers = (Get-ADDomainController -Filter *).Name

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

# Making it Domain Admin (Sorry)
Add-ADGroupMember -Identity "Domain Admins" -Members svcADHealthCheck

创建组管理的服务帐户

如果您尚未在环境中使用 gMSA，则使用 gMSA 运行运行状况检查会有点棘手，但它更安全。

创建 KDS 根密钥

要创建 gMSA 帐户来运行 AD 运行状况检查脚本，请首先添加 KDS 根密钥（如果您还没有）。您可以通过在域控制器上运行 PowerShell 命令 Get-KDSRootKey 来检查您是否拥有 KDS 根密钥。

如果您没有 KDS 根密钥，可以通过在 2012R2 或更高版本的域控制器上的 Domain Admins AD 组的用户帐户下运行 Add-KDSRootKey -EffectiveImmediately 来创建一个。

密钥需要复制到其他域控制器才能完全生效。有关此过程的更多信息可以在 Microsoft 文档中找到。

创建 gMSA

创建 KDS 根密钥后，您就可以使用 PowerShell 创建 gMSA 帐户。您可以在下面看到一个示例脚本，用于创建仅允许从域管理员组中的域控制器进行身份验证的 gMSA 帐户。

# Change to your domain
$Domain = "contoso.com"

$AccountName = "svcadhealthcheck"

# Create a GMSA called svcadhealthcheck (or in reality svcadhealthcheck$) and allow only Domain Controllers to fetch the password
New-ADServiceAccount $AccountName -DNSHostName "$AccountName.$Domain" -PrincipalsAllowedToRetrieveManagedPassword "Domain Controllers"

# Add the GMSA to Domain Admins
# Note that we're adding the the account by it's true SamAccountName 'svcadhealthcheck$'
Add-ADGroupMember -Identity "Domain Admins" -Members "$AccountName`$"

安装和测试 gMSA

现在 gMSA 已创建，最后一步是在所有域控制器上安装并测试它。一种方法是使用 Invoke-Command PowerShell 命令。下面您可以看到一个 PowerShell 脚本，它将在所有 DC 上安装 gMSA 并确保其正常工作。

# This will run on all Domain Controllers
Invoke-Command -ComputerName (Get-ADDomainController -Filter *).Name -ScriptBlock {
    $Account = Get-ADServiceAccount -Filter { Name -eq 'svcadhealthcheck'}
    Install-ADServiceAccount $Account

    # Tests that the GMSA works on the computer
    # Returns $True if tests are OK
    $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 后，您现在需要授予其在 DC 上作为批处理作业运行的权限。该帐户需要此权限，因为它将在计划任务的后台自主运行。

您可以通过现有 GPO 或创建新 GPO 并将其链接到域控制器 OU 来设置此权限。如果您还没有可供使用的 GPO，可以按照以下步骤创建 GPO。

1. 在 DC 上启动组策略编辑器。
2. 右键单击“域控制器”OU，然后选择“在此域中创建 GPO 并将其链接到此处”。
3. 将其命名为DC - 以批处理方式登录或您喜欢的其他名称
4. 右键单击 GPO，然后单击“编辑”。
5. 转至计算机配置 -> Windows 设置 -> 安全设置 -> 用户权限分配。
6. 左键单击作为批处理作业登录，然后单击属性。
7. 单击“添加用户或组”。
8. 单击“对象类型”，仅选择“服务帐户”，然后单击“确定”。
9. 搜索之前创建的 svcADHealthCheck 服务帐户，选择它并单击“确定”。

您现在应该在 AD 对象列表下看到 gMSA，如下所示。

创建计划任务

现在您已经创建了一个帐户来运行计划任务，您现在可以在您选择的加入域的服务器上创建计划任务本身。

您可以通过 GUI 创建计划任务，但点击次数太多了！相反，我建议使用 PowerShell 创建它。为什么？因为您只需复制下面看到的代码即可完成。

下面你会发现两个脚本；这两个脚本很相似，但一个假设是 AD 用户帐户，另一个假设是 gMSA。请务必根据您使用的帐户使用适当的脚本。

# Replace with the path to your script
$ScriptPath = "C:\Scripts\ADHealthCheck.ps1"
# Replace with the username of the account that you created to run the task
$UserName = "svdADHealthCheck"

# Replace with the password that you set for above account
$Password = "JägareTvå!"
# Create the action that launches the script
$Action = New-ScheduledTaskAction -Execute "powershell.exe" -Argument "-ExecutionPolicy bypass -File '$ScriptPath'"
# Create the trigger that starts the task
$Trigger = New-ScheduledTaskTrigger -Once -At "12:00" -RepetitionInterval (New-TimeSpan -Hours 12)
# Create settings for the scheduled task
$Settings = New-ScheduledTaskSettingsSet -AllowStartIfOnBatteries -DontStopIfGoingOnBatteries -StartWhenAvailable -RunOnlyIfNetworkAvailable -DontStopOnIdleEnd
# Create the scheduled task using a splat for readability
$Splat = @{
    User = "$env:USERDOMAIN$UserName"
    Password = $Password
    TaskName = "ADHealthCheck"
    Action = $Action
    Trigger = $Trigger
    RunLevel = "Highest"
    Settings = $Settings
}
Register-ScheduledTask @Splat

# Replace with the path to your script
$ScriptPath = "C:\Scripts\ADHealthCheck.ps1"
# Replace with the username of the account that you created to run the task
$UserName = "svdADHealthCheck$"
# Create the action that launches the script
$Action = New-ScheduledTaskAction -Execute "powershell.exe" -Argument "-ExecutionPolicy bypass -File '$ScriptPath'"
# Create the trigger that starts the task
$Trigger = New-ScheduledTaskTrigger -Once -At "12:00" -RepetitionInterval (New-TimeSpan -Hours 12)
# Create settings for the scheduled task
$Settings = New-ScheduledTaskSettingsSet -AllowStartIfOnBatteries -DontStopIfGoingOnBatteries -StartWhenAvailable -RunOnlyIfNetworkAvailable -DontStopOnIdleEnd

# Create principal that defines the GMSA
$Principal = New-ScheduledTaskPrincipal -UserID "$env:USERDOMAIN$UserName" -LogonType Password -RunLevel Highest
# Create the scheduled task using a splat for readability
$Splat = @{
    Principal = $Principal
    TaskName = "ADHealthCheck"
    Action = $Action
    Trigger = $Trigger
    RunLevel = "Highest"
    Settings = $Settings
}
Register-ScheduledTask @Splat

你完成了！此时，计划任务将按照上述脚本之一中提供的时间间隔执行。

概括

哇！如果您从第一部分开始就已经了解了，那么您现在应该知道 AD 健康是一个深奥的主题。这一主题涉及的内容太多，即使是两篇冗长的博客文章也无法涵盖。

但是，到目前为止，您应该拥有足够的知识和预构建的 PowerShell 框架，以便在其他 Active Directory 运行状况检查出现时插入它们。

进一步阅读

• 关于AD和灾难恢复你可能不知道的一些事情
• DCDIAG 实际上......做什么？