Adam The Automator

これは、Active Directoryヘルスチェックに関する二部構成のシリーズのパートIIです。 読む必要はありませんが、この記事で学習するPowerShellスクリプトがどのように構築されたかを知りたい場合は、Active Directoryヘルスチェックツールの構築:パートI.

パートIでは、複数のテストの数とそれらが重要な理由を学習しました。 それでは、それらすべてを一緒に引っ張って、ツールを構築してみましょう。 このパートでは、パートIで説明したすべてのActive Directoryヘルスチェックをテストフレームワークに変換します。 また、さまざまな広告ヘルスチェックの結果をPesterやPRTGと呼ばれる監視ツールなどのツールに出力する方法についても説明します。

この記事で学ぶツールの完成版をフォローしたり、確認したりするには、GitHubからADHealthCheck-NoResult.ps1スクリプトをダウンロードしてください。

目次

出力

を共通のオブジェクトタイプと簡単な生成方法で定義すると、テスト結果を選択したツールに変換するのがはるかに簡単になります。

すべての潜在的なツールのための均一な出力を作成するために、私はPowerShellクラスを使用することを選択しました。 必須ではありませんが、それは私がここで取ることを選んだアプローチです。 主なポイントは、すべてのADヘルスチェックが同じタイプの出力を返すようにすることです。

PowerShellクラスは、PowerShellオブジェクトがどのように表示され、何をすべきかを定義するスキーマです。 以下に示す各行は、オブジェクトが返すプロパティを表します。 あなたは私が十のプロパティを返すために、各広告のヘルスチェックに計画しています以下を見ることができます。

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

このクラスの作成を促進するために、New-AdhcResultというヘルパー関数を使用します。 この関数は、クラスとあなたが一緒に従う必要がありますすべてを作成します。 この関数は、カスタムの型オブジェクトを出力します。

ADヘルスチェックツールの実行

まず、ADヘルスチェックスクリプトをダウンロードしてドメインコントローラにコピーします。 PowerShell ISEで開き、実行します。 ツールのこの部分は情報を返しません。

Thsスクリプトが実行され、各チェックの結果が$TestResults変数に複数のオブジェクトとして格納されます。 これらのオブジェクトは、後でレポートを生成したり、さまざまなツールに出力したりするために使用します。 ヘルスチェックの結果をこのような変数に保持すると、別の結果を作成してNew-AdHcResultコマンドを使用することを選択した場合に、さらに結果を追加できます。

スクリプトの実行が終了すると、$TestResults変数に格納されているADヘルスチェックオブジェクトの完全なセットが必要になります。 これで、コンソールから$TestResultsを実行し、生の結果を見ることができます。

広告ヘルスチェックの結果をツールで表示する

すべてのチェックは共通のオブジェクトタイプであるため、PesterやPRTGなどのいくつかのツールを使

このセクションでは、extentというツールを使用してHTMLレポートを作成し、PRTGでレポートを表示する方法を学習します。Pesterを使用してnUnit XMLファイルを作成する

まず、PowerShellオブジェクトをツールが理解できる形式で変換する必要があります。 ほとんどのツールはXML、より具体的にはnUnit XMLを理解しています。 これは、結果を表示するためにさまざまなツールにインポートできる形式です。

PowerShellを使用しているので、PESTERテストフレームワークを使用してADヘルスチェックスクリプトからの出力を読み取り、nUnit XMLファイルを生成します

昇格されたPowerShellコンソールでInstall-Moduleを実行すると、Pesterをダウンロードできます。 以下のコマンドは、最新のPesterバージョンのインストールを強制します。 Pesterが署名されている発行者証明書はWindows10に付属しているため、SkipPublisherCheckパラメーターを使用してインストールする必要があります。

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

Pesterが使用可能になったら、スクリプトを実行して、一連のPesterテストを動的に作成できます。

注:私が提供したPowerShellスクリプトを使用せずに、自分でPesterテストを作成することもできます。

以下の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 CategoryForeach($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に変換できるツールに渡すことができます。 これらのツールの1つはextentと呼ばれます。 Extentは、Nunit XMLファイルからHTMLレポートを作成するための便利なツールです。

まず、nunitreportと同じディレクトリにextentをダウンロードします。以前に作成したxmlファイル。 次に、PowerShellセッションで次のコマンドを実行します。 これらのコマンドは、HTMLファイルを格納するディレクトリを作成し、extentを実行します。変換を行うにはexeファイル。

# Create report directoryPS51> mkdir .\HTMLReports# Create the reportPS51> .\extent.exe -i .\NunitReport.xml -o .\HTMLReports\

完了すると、HTMLReportsディレクトリに二つのHTMLファイルがあります。 これらのファイルは、あなたがwebブラウザでそれらを開く以下のスクリーンショットのようになります。

Pesterテスト出力用のHTMLレポート
Pesterテスト出力用のHTMLレポート
Pesterテスト出力用のHTMLレポート
Pesterテスト出力用のHTMLレポート

PRTG

への広告ヘルスチェック結果の取り込みPRTGは、Paesslerが開発した一般的な監視ツールで、インフラストラクチャとサービスを監視するために使用できます。 このセクションでは、ヘルスチェックスクリプトが実行されたら、ヘルスチェックの結果をPRTGにプッシュする方法を学習します。

結果をPRTGにプッシュすると、ツールが情報を取得するのではなく、より多くの作業が必要になりますが、最終的にはセットアップに費やす時間の価値

前提条件

この記事で構築されたADヘルスチェックスクリプトの監視ツールとしてPRTGを正常に設定するには、次の点を確認してください:

  • PRTGは、SEND-AdhcResultToPrtgに設定されたすべてのドメインコントローラをPRTG
  • にインストールして構成しました。Ps1PowerShell script downloaded from GitHub
  • y0ur PRTG sensorのURLとポート

それぞれの前提条件が完了したら、これらのADヘルスチェック結果をPRTGにプッシュすることをお勧めする方法について、以下のステップバイステップの手順に従うことができます。

  1. Prtgでドメインまたは任意の名前を指定してデバイスを作成します。
  2. IdentityTokenがdirectory-adhealthcheckの高度なHTTPプッシュセンサーを作成します。 これは大文字と小文字が区別されることに注意してください!
  3. PRTGの各ドメインコントローラデバイスに対して、高度なHTTPプッシュセンサーを作成します。 IdentityTokenごとに、dc01-adhealthcheckなどの-adhealthcheckを各センサーに追加します。
  4. Send-AdhcResultToPrtg.ps1PowerShellスクリプトの内容を、ここで説明したADHealthCheck-NoResult.ps1PowerShellスクリプトの最後に追加します。
  5. 変数$PRTGUrlをPRTGセンサーのURLとポートに変更します。
  6. スクリプトを実行します。

完了すると、ADヘルスチェックスクリプトが完了すると、以下に示すようにprtgセンサーにステータスをプッシュするようになります。

広告の健康を示すPRTGセンサー
広告の健康を示すPRTGセンサー

Active Directoryヘルスチェックスクリプトのスケジュール

ADの正常性の監視は進行中のプロセスです。 アドホックなインスタンスではなく、常にテストを実行する必要があります。 Active Directoryヘルスチェックスクリプトを頻繁に実行するようにスケジュールしましょう。

これらのチェックを自動化する最も簡単な方法は、スクリプトをタスクスケジューラに追加し、ADユーザーアカウントまたはグループ管理のサービスアカウ

グループ管理サービスアカウント(gMSA)を使用すると、ADからパスワードを取得できる指定されたコンピュータアカウントのみがスケジュールされたタスクを自 しかし、いくつかの組織は、この贅沢を持っていないかもしれません。

ADユーザーアカウントの作成

まず、スケジュールされたタスクを実行するためにADユーザーアカウントを設定するために必要なものを分解してみましょう。

スケジュールされたタスクをユーザーアカウントとして実行する場合は、必ず自分のアカウントとして実行しないでください! この目的のために、常に別のユーザーアカウントを作成します。

時間を節約するために、以下のPowerShellスクリプトが表示されます。 これは、Domain Adminsグループの一部である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 -ForceNew-ADUser -Enabled $True -Path $OU -Name svcADHealthCheck -AccountPassword $SecureString# Restrict account to only Domain Controllers$DomainControllers = (Get-ADDomainController -Filter *).NameSet-ADAccount -Identity svcADHealthCheck -LogonWorkstations ($DomainControllers -Join ",")# Making it Domain Admin (Sorry)Add-ADGroupMember -Identity "Domain Admins" -Members svcADHealthCheck

グループ管理サービスアカウントを作成する

gMSAを使用してヘルスチェックを実行することは、環境でgMSAを使用していない場合は少しトリッキーですが、

KDSルートキーの作成

adヘルスチェックスクリプトを実行するgMSAアカウントを作成するには、KDSルートキーがまだない場合は、まずkdsルートキーを追加します。 ドメインコントローラーでPowerShellコマンドGet-KDSRootKeyを実行すると、KDSルートキーがあるかどうかを確認できます。

KDSルートキーを持っていない場合は、2012R2以降のドメインコントローラーのDomain Admins ADグループのユーザーアカウントの一部でAdd-KDSRootKey -EffectiveImmediatelyを実行して作成します。

キーを完全に有効にするには、他のドメインコントローラにレプリケートする必要があります。 このプロセスの詳細については、Microsoftのドキュメントを参照してください。

gMSAの作成

Kdsルートキーが作成されたら、PowerShellを使用してgMSAアカウントを作成する準備が整いました。 以下に、Domain Adminsグループ内のドメインコントローラからの認証のみを許可された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 passwordNew-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が作成され、最後のステップはすべてのドメインコントローラにインストールしてテストすることです。 これを行う1つの方法は、Invoke-CommandPowerShellコマンドを使用することです。 以下に、すべてのDcにgMSAをインストールし、正常に動作することを確認するPowerShellスクリプトが表示されます。

# This will run on all Domain ControllersInvoke-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–Logonという名前をバッチまたは別の名前として指定します。
  4. GPOを右クリックし、編集をクリックします。
  5. コンピュータの構成–>Windowsの設定–>セキュリティ設定–>ユーザー権利の割り当てに移動します。
  6. バッチジョブとしてログオンを左クリックし、プロパティをクリックします。
  7. ユーザーまたはグループの追加をクリックします。
  8. オブジェクトタイプをクリックし、サービスアカウントのみを選択し、OKをクリックします。
  9. 以前に作成したsvcADHealthCheckサービスアカウントを検索し、それを選択してOKをクリックします。

以下に示すように、広告オブジェクトのリストの下にgMSAが表示されます。

gMSAにバッチジョブとしてログオンする権限が与えられた
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

もう終わりだ! この時点で、スケジュールされたタスクは、上記のスクリプトのいずれかで指定された間隔で実行されます。

パートIからずっと続いたら、広告の健康が深い主題であることを今では知るべきである。 この1つのトピックには、2つの長いブログ記事でさえカバーできないほど多くのことがあります。

しかし、今では、十分な知識と、他のActive Directoryヘルスチェックが発生したときにプラグインできる事前に構築されたPowerShellフレームワークが必要です。

続きを読む

  • あなたはADと災害復旧について知らないかもしれないいくつかのもの
  • DCDIAGは実際に何をしますか…何をしますか?