Defender for Identity で gMSA を使ってディレクトリ サービスアカウント (DSA) を設定してみた

はじめに

Microsoft Defender for Identity (MDI) は Active Directory の侵害検出・応答ソリューションです。
MDI を使用するには Active Directory に存在するユーザー アカウントや gMSA を使用して、以下 2 つの管理アカウントを構成する必要があります。

• Directory Service Account (DSA)
• Action Account

Directory Service Account (DSA) は主に以下の役割を担います。

• MDI センサーが LDAP を使用してドメイン コントローラーに接続するための資格情報となる
• ドメイン コントローラへのネットワーク トラフィック、監視対象イベント、監視対象の ETW アクティビティに表示されるエンティティに関する情報等の照会
• ドメイン内のエンティティ（ユーザー やグループ、コンピューター等）に対する変更の追跡
• MDI センサーによるLDAP クエリを介した他ドメインのエンティティからのアクティビティ情報の取得
• ローカル管理者グループのメンバーの一覧の取得 ※SAM-R の設定が別途必要
  参考：https://docs.microsoft.com/ja-jp/defender-for-identity/directory-service-accounts#introduction

Action Account は主に以下の役割を担います。

• ユーザーの無効化
• ユーザーのパスワードリセット
  参考：https://docs.microsoft.com/ja-jp/defender-for-identity/remediation-actions

上記の管理アカウントは gMSA を使用して構成をすることがベストプラクティスとなっています。
そのため、本記事では gMSA の作成方法と DSA の設定について紹介します。

gMSA の公開資料及び詳細は以下をご確認ください。
https://docs.microsoft.com/ja-jp/windows-server/security/group-managed-service-accounts/group-managed-service-accounts-overview

gMSA を作成する

1. KDS ルート キーを確認する

gMSA のパスワードを作成するには KDS ルート キーが必要です。
そのため、まずは KDS ルート キーがドメインに存在するかを確認します。

(1) DC にサインインします。
(2) [Active Directory サイトとサービス] を開きます。
(3) ツールバーで [表示(V)] を選択し、[サービス ノードの表示(S)] にチェックします。

(4) [Services] を展開し、[Group Key Distribution Service] - [Master Root Keys] の順にクリックします。

上記のように [Master Root Keys] が空白の場合、KDS ルート キーを作成する必要があります。

2. KDS ルート キーを作成する

(1) ドメイン管理者の権限でドメイン コントローラーにサインインします。
(2) PowerShell を管理者権限で開きます。
(3)以下コマンドを実行します。

add-kdsrootkey -effectivetime ((get-date).addhours(-10))

実行結果は以下の通りです。

また、[Active Directory サイトとサービス] に戻ると KDS ルート キーが増えていることが分かります。

(4) 地理的に分散したドメイン コントローラーがあり、レプリケートに時間がかかる場合は下記のコマンドを実行してください。
※ 下記コマンドを実行することでドメイン コントローラへのレプリケートが完了されているようにするため KDS ルート キーは既定で 10 時間使用できないセーフガードがかかります。

add-kdsrootkey -effectiveimmediately

3. gMSA を作成する

(1) Active Directory Powershell モジュールを搭載したコンピューターにて、PowerShell を起動します。
(2) 以下のコマンドを実行し、Active Directory の Powershell モジュールをインストールします。

Import-Module -Name ActiveDirectory

以下のコマンドを実行することで、事前にシステムにインストールされているモジュールの確認も可能です。

Get-Module -Name ActiveDirectory -ListAvailable

(3) 以下のコマンドを実行します。青文字の部分をご自身の環境に合うように修正してください。

# Set the variables
$gMSA_AccountName = 'mdiSvc01'
$gMSA_HostsGroupName = 'mdiSvc01Group'
$gMSA_HostNames = 'DC1', 'DC2', 'DC3', 'DC4', 'DC5', 'DC6', 'ADFS1', 'ADFS2'

# Create the group and add the members
# "Set the variables"で宣言した $gMSA_HostsGroupName のセキュリティグループに $gMSA_HostNames のホストを追加しています
$gMSA_HostsGroup = New-ADGroup -Name $gMSA_HostsGroupName -GroupScope Global -PassThru
$gMSA_HostNames | ForEach-Object { Get-ADComputer -Identity $_ } |
    ForEach-Object { Add-ADGroupMember -Identity $gMSA_HostsGroupName -Members $_ }

# Create the gMSA
# 末尾の PrincipalsAllowedToRetrieveManagedPassword 属性で、gMSA アカウントのパスワードを読み取る権限をセキュリティ グループ $gMSA_HostsGroupName 及びそれに含まれるホストに付与しています
New-ADServiceAccount -Name $gMSA_AccountName -DNSHostName "$gMSA_AccountName.$env:USERDNSDOMAIN" -PrincipalsAllowedToRetrieveManagedPassword $gMSA_HostsGroupName

(4) ドメイン コントローラーにて管理者権限でPowershell を立ちあげ以下コマンドを実行します。
これにより既存の Kerberos チケットを消去し、ドメイン コントローラーが新しい Kerberos チケットを要求するよう強制します。

klist purge -li 0x3e7

(5) 各サーバーにてローカル管理者権限で Powershell を立ち上げ、以下コマンドを実行します。
これにより gMSA アカウントをインストールします。

# Install the required PowerShell module:
Import-Module -Name ActiveDirectory

# Install the gMSA account
Install-ADServiceAccount -Identity 'mdiSvc01'

(6) 今後 DC や ADFS の役割を持つコンピューターが増えた場合は $gMSA_HostsGroupName で名称を定義したセキュリティ グループにホストを追加するオペレーションを確立してください。

gMSA の権限を編集する

MDI センサー サービスは DSA および gMSA アカウントの権限を偽装して LocalService として実行されます。
[サービスとしてのログオン] ポリシーにて gMSA アカウントにアクセス許可が付与されていない場合、権限の偽装は失敗し「ディレクトリ サービスのユーザー資格情報が正しくありません」という正常性アラートが表示されます。
上記を回避するためにgMSA へ 1. [サービスとしてのログオン] 権限の付与 を行います。
これは MDI センサーを導入したホストを対象に設定します。

また、横移動のアラートを検出するために 2. SAM-R に必要なアクセス許可の構成 と 3. ネットワーク経由でのアクセス許可の構成 を行います。
この設定により、DSA は特定のマシンのローカル管理者を識別できるようになります。
これはドメイン コントローラーを除くすべてのドメイン参加端末を対象に設定します。

最後に、4. 削除済みオブジェクトへのアクセス許可の構成 を行います。
これにより、削除されたオブジェクトの監視が可能になります。

1. [サービスとしてのログオン] 権限の付与

(1) まず各ドメイン コントローラーにて「サービスとしてログオン」可能なサービスに関する設定内容を使用しているポリシーに応じて確認します。

• ローカル ポリシーを使って設定している場合
  [ファイル名を指定して実行(R)] をクリックし、「secpol.msc」と入力して実行します。
  [セキュリティの設定] - [ローカル ポリシー] - [ユーザー権利の割り当て] - [サービスとしてのログオン] の順に遷移し、設定内容を確認します。
  

• グループ ポリシーを使って設定している場合
  [ファイル名を指定して実行(R)] をクリックし、「rsop.msc」と入力して実行します。
  [コンピューターの構成] - [Windows の設定] - [セキュリティの設定] - [ローカル ポリシー] - [ユーザー権利の割り当て] - [サービスとしてのログオン] の順に遷移し、設定内容を確認します。
  

(7) Default Domain Controllers Policy を開きます。[コンピューターの構成] - [ポリシー] - [Windows の設定] - [セキュリティの設定] - [ローカル ポリシー] - [ユーザー権利の割り当て] - [サービスとしてのログオン] の順に遷移し、(6) にて確認したサービス アカウントと作成した gMSA アカウント(今回は'mdiSvc01')を追加します。

2. SAM-R に必要なアクセス許可の構成

ドメイン コントローラー以外のすべての端末にて SAM-R のアクセス許可を構成している GPO が存在する場合は (4) から始めてください。

(1) ドメインコント ローラー以外の Windows 10, Windows Server 2016 以降のコンピューターからなる OU を準備します。
ない場合は以下手順で新規作成します。

1. [Active Directory ユーザーとコンピューター] を開きます。
2. ドメイン名を右クリックし、[新規作成] - [組織単位 (OU)] の順にクリックします
3. 任意の名称の OU を作成します。（例: mdisamr）
4. ドメインコント ローラー以外の Windows 10, Windows Server 2016 以降のコンピューターを OU に追加します。

(2) [グループ ポリシーの管理] を開きます。
(3) [グループ ポリシー オブジェクト] を右クリックし、[新規] を選択します。任意の GPO 名を付けます。
(4) (3) で作成した GPO を右クリックし、[編集] を選択します。
(5) [コンピューターの構成] - [ポリシー] - [Windows の設定] - [セキュリティの設定] - [ローカル ポリシー] - [セキュリティ オプション] - [ネットワーク アクセス - SAM をリモート呼び出しできるクライアントを制限する] をクリックします。
[セキュリティの編集] をクリックします。

(6) 既存の設定がある場合はそれに DSA (今回は'mdiSvc01')を追加し、新規に作成した GPO の場合はNTAUTHORITY/SYSTEM と BUILTIN\Administrators、DSA を追加し保存します。

3. ネットワーク経由でのアクセス許可の構成

(1) Default Domain Policy やそのほかのポリシーにて、[コンピューターの構成] - [ポリシー] - [Windows の設定] - [セキュリティの設定] - [ローカル ポリシー] - [ユーザー権利の割り当て] - [ネットワーク経由でのアクセス] が定義されていないかを確認します。
定義されていない場合は、設定をせず終了となります。

(2) 定義されている場合は、DSA を承認済みアカウントに追加します。

今回、「Windows 10, Windows Server 2016 以降」を対象に GPO を作成・適用したのはWindows 10, Windows Server 2016 以降のコンピューターで NTAUTHORITY/SYSTEM と BUILTIN\Administrators にのみ SAM-R 権限を付与するポリシーがハードコードされているからです。

4. 削除済みオブジェクトへのアクセス許可の構成

(1) コマンドプロンプトを管理者権限で立ち上げます。
(2) 以下のコマンドを実行して、削除されたオブジェクトコンテナーへの所有権を確認します。

dsacls "CN=Deleted Objects,DC=Contoso,DC=com" /takeownership

(3) 以下のコマンドを実行して、gMSA に削除されたオブジェクトコンテナーへのアクセス権を付与します。

dsacls "CN=Deleted Objects,DC=Contoso,DC=com" /G CONTOSO\mdiSvc01$:LCRP

(4) 完了すると以下のような画面が得られます。

MDI センサーを DC にインストールする

(1) グローバル管理者の権限で https://portal.atp.azure.com/ にアクセスします。
(2) [構成] - [システム | センサー] の順に遷移します。[ダウンロード] をクリックし、「Azure ATP Sensor Setup.zip」をダウンロードします。5 ~ 10 ほどかかるので待ちます。
このときアクセスキーをコピーしてエディタに貼り付けておきます。

(3) フォルダを解凍し、DC に配置します。フォルダ内には以下ファイルが入っていることが分かります。

(4) [コントロール パネル] - [プログラム] - [プログラムと機能] - [プログラムのアンインストールまたは変更] の順に遷移します。過去に Azure ATP 等を使用している場合は、winpcap が動いている可能性があり後継の npcap がうまく稼働しない可能性があるため確認します。
winpcap がある場合はアンインストールします。
(5) 「npcap-1.00-oem」を実行します。

(6) [Install] をクリックします。

(7) npcap のインストールが完了しました。

先ほど立ち上げたコントロールパネルを見ると、npcap が増えていることが分かります。

(8) 続けて、「Azure ATP Sensor Setup」を実行します。

(9) [言語を選択:] にて「日本語」を選択し、[次へ] をクリックします。

(10) 自動判定されたセンサーのタイプを確認し、[次へ]をクリックします。

(11) (2) でコピーしたアクセスキーを貼り付け、[インストール] をクリックします。
インストールパス C:\Program Files\Azure Advanced Threat Protection Sensor を確認します。
※

(13) インストールが完了しました。

(14) 以下 2 つのサービスが MDI によって胃実行されていることがタスク マネージャーよりわかります。

DSA を MDI 管理ポータルにて設定する

(1) グローバル管理者の権限で https://security.microsoft.com/ にアクセスします。
※https://portal.atp.azure.com/ でも可能ですが、こちらのポータルサイトでの設定方法を以下に紹介します。
(2) [設定] - [ID] - [全般 | ディレクトリ サービス アカウント] の順に遷移します。

(3) [+ 資格情報の追加] をクリックして、「アカウント名」「ドメイン」を入力します。このとき「アカウント名」の末尾に必ず「$」をつけてください。
「グループ管理サービスアカウント」のチェックボックスにを入れ、[保存] をクリックします。

(4) [設定] - [ID] - [全般 | ディレクトリ サービス アカウント] に戻り、センサーが問題なく実行されていることを確認します。

(5) センサーに異常があった場合、[設定] - [ID] - [全般 | 正常性の問題] にて確認できます。

さいごに

以上で gMSA を使ったディレクトリ サービスアカウント (DSA)の設定は完了となります。
次回は gMSA を使ったアクション アカウントの設定、デモをできればと思います。

本記事は以下の Blog を参考に検証・作成しました。

• https://windowsmanagementexperts.com/microsoft-defender-for-identity-group-managed-service-account-setup/microsoft-defender-for-identity-group-managed-service-account-setup.htm
• https://www.varonis.com/blog/powershell-active-directory-module
• https://docs.microsoft.com/ja-jp/defender-for-identity/directory-service-accounts