Defender for Identity で gMSA を使ってアクション アカウントを設定してみた

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

- ディレクトリ サービス アカウント (DSA)
- **アクション アカウント** ←この記事で紹介します

**アクション アカウント**は主に以下の役割を担います。
- ユーザーの無効化
- ユーザーのパスワードリセット
参考：https://docs.microsoft.com/ja-jp/defender-for-identity/remediation-actions

アクション アカウントは強い権限を付与する性質上 gMSA を使用して構成をすることが強く推奨されています。
そのため、本記事では **gMSA を使用したアクション アカウントの設定**について紹介します。

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


## gMSA の作成
アクションアカウント用に gMSA を作成します。
DSA 用に作成したセキュリティグループを流用するため、まだ DSA の設定をされていない方は以下の記事をご覧ください。
[Defender for Identity で gMSA を使ってディレクトリ サービスアカウント (DSA) を設定してみた](URL:https://qiita.com/nm_suisai/items/0b00220201a11023e02d)
https://docs.microsoft.com/ja-jp/defender-for-identity/directory-service-accounts

(1) Active Directory Powershell モジュールを搭載したコンピューターにて、PowerShell を起動します。
(2) 以下コマンドを実行し KDS ルート キーを作成します。
```powershell:
add-kdsrootkey -effectivetime ((get-date).addhours(-10))
```
(3) 以下のコマンドを実行し、gMSA を作成します。青文字の部分をご自身の環境に合うように修正してください。
```powershell:
$gMSA_AccountName = 'mdiSvc02'
$gMSA_HostsGroupName = 'mdiSvc01Group'
New-ADServiceAccount -Name $gMSA_AccountName -DNSHostName "$gMSA_AccountName.$env:USERDNSDOMAIN" -PrincipalsAllowedToRetrieveManagedPassword $gMSA_HostsGroupName
```
(4) ドメイン コントローラーにて管理者権限でPowershell を立ちあげ以下コマンドを実行します。
これにより既存の Kerberos チケットを消去し、ドメイン コントローラーが新しい Kerberos チケットを要求するよう強制します。
```powershell:
klist purge -li 0x3e7
```
(5) 各サーバーにてローカル管理者権限で Powershell を立ち上げ、以下コマンドを実行します。
これにより gMSA アカウントをインストールします。
```powershell:
Install-ADServiceAccount -Identity 'mdiSvc02'
```
成功すると以下のように表示されます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/668292/1a348e35-5d2b-f33a-6405-25cb8fe12459.png)

これでアクション アカウントに設定するための gMSA の設定が完了しました。
アクション アカウントはパスワードリセットやユーザーの無効化をするため、それに必要な権限の付与をこれから行います。

ということは、ディレクトリ サービス アカウント (DSA) とアクション アカウントに必要な権限が異なるということなので
**gMSA は使いまわさず、 DSA 用とアクション アカウント用で分けて作るのがよい**かと思います。

## gMSA へのアクセス権付与

### 1. [サービスとしてのログオン] 権限の付与
[こちら](URL:https://qiita.com/nm_suisai/items/0b00220201a11023e02d#1-%E3%82%B5%E3%83%BC%E3%83%93%E3%82%B9%E3%81%A8%E3%81%97%E3%81%A6%E3%81%AE%E3%83%AD%E3%82%B0%E3%82%AA%E3%83%B3-%E6%A8%A9%E9%99%90%E3%81%AE%E4%BB%98%E4%B8%8E)を参照して設定して下さい。
この設定を忘れるとアクション アカウントがサービスとしてログオンできないため、パスワードリセットやユーザーの無効化ができなくなります。
当然のことですが、この設定をうっかり忘れ半日ほど動かないアクションアカウントとにらめっこしてました(;^_^A

### 2. 応答アクション用のアクセス権付与
アクションアカウント用に gMSA にはいくつか強い権限を付与する必要があります。
(1) [Active Directory ユーザーとコンピューター] を開きます。
(2) [表示] - [拡張機能] の順に遷移し、チェックを入れます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/668292/3bd5d3e8-bf5c-e4fc-dbfa-61ed1b4e8239.png)
(3) 関連するドメインまたは OU を右クリックし、[プロパティ] を選択します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/668292/aab899c1-ab36-1d17-2348-7ccda22e045b.png)
(4) [セキュリティ]タブに移動し、[詳細設定] を選択します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/668292/4f5300aa-9dc1-2b6a-c965-2c190e969fe7.png)
(5) [追加] を選択します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/668292/18194385-234c-caa3-7cd9-67c30357d455.png)
(6) [プリンシパルの選択] - [オブジェクトの種類] の順に遷移し、[サービス アカウント] のチェックボックスに印を入れます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/668292/d5572023-5111-9a0b-31f3-a6bdb1a02dec.png)
(7) [選択するオブジェクト名を入力してください] ボックスに gMSA アカウント の名前を入力し [OK] を選択します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/668292/2d1e4ee1-b67d-f1cd-4031-bbc38e75556f.png)
(8) [適用先] フィールドで [子ユーザー オブジェクト] を選択しします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/668292/17fa3ac7-fdda-0887-56c1-0c329303352a.png)
MS Docs には書かれていませんでしたが、画面一番右下に遷移して

(9) [アクセス許可:] の「パスワードのリセット」にチェックをつけ、以下の[プロパティ:]を設定し、[OK] をクリックします。
- パスワードの強制的なリセットを有効にするプロパティ
    - pwdLastSet の読み取り
    - pwdLastSet の書き込み
- ユーザーを無効にするプロパティ
    - userAccountControl の読み取り
    - userAccountControl を書き込む

(10) (5) ~ (7) をもう一度実施し、新規のアクセス許可エントリを作成します。
(11) (10) にて作成したアクセス許可エントリの [適用先:] フィールドで [子グループ オブジェクト] を選択します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/668292/f41b8f98-2fab-8391-0330-c3bea3294931.png)
(12) 次の[プロパティ:]を設定し、[OK] を選択します。
- メンバーの読み取り
- メンバーの書き込み

(13) [OK] を選択して、終了します。

## アクション アカウントを MDI 管理ポータルにて設定する
(1) グローバル管理者の権限で https://security.microsoft.com/ にアクセスします。
※https://portal.atp.azure.com/ でも可能ですが、こちらのポータルサイトでの設定方法を以下に紹介します。
(2) [設定] - [ID] - [全般 | アクション アカウントの管理] の順に遷移します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/668292/60ed696c-7246-52bb-c66d-402f59aeb812.png)
(3) [+ 資格情報の追加] をクリックして、「アカウント名」「ドメイン」を入力します。このとき「アカウント名」の末尾に必ず「$」をつけてください。[保存] をクリックして終了します。

## アクション アカウントを検証する
アクション アカウントを使用した **1. ユーザーを無効にする** と **2. ユーザー パスワードのリセット** を検証してみます。
アクションアカウントの応答について改めて [Microsoft Docs](URL:)
- ユーザーを無効にする
    - ユーザーがネットワークにログインできなくなる
    - 侵害されたユーザーが横に移動してデータを流出させたり、ネットワークをさらに侵害することを防ぐ
- ユーザー パスワードのリセット
    - 次回のログオン時にパスワードを変更するようにユーザーに求められる
    - このアカウントをこれ以上使用できなくなる
参考：https://docs.microsoft.com/ja-jp/defender-for-identity/remediation-actions

アーキテクチャ図は以下の通りです。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/668292/2ae2893a-1d27-18a7-b3f0-eec9eed1b46c.png)
参考：https://www.microsoft.com/en-us/videoplayer/embed/RE4U7Pe

### 1. ユーザーを無効にする
前提として、Azure AD とパスワードハッシュ同期している Active Directory 環境及びドメイン コントローラーに MDI を構築しています。
また Azure AD Connect ではパスワード ライトバック機能が有効になっています。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/668292/0403dc28-5564-8eaf-7550-6a8b7dc41f45.png)
今回使用するユーザーは winter という名称で、AD から AAD に同期されているハイブリッド ID となります。

(1) セキュリティ管理者の権限で https://security.microsoft.com/ にアクセスします。
(2) 上部の検索バーにてユーザー名を入力、検索します。[ユーザー ページに移動] をクリックします。
今回は winter というハイブリッド ID のユーザーを使用します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/668292/105e366c-6253-d5cf-f442-fd37457eebe0.png)
(3) [...] をクリックすることで使用可能な応答アクションを確認できます。今回は[AD でユーザーを無効にする] をクリックします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/668292/3173ba59-6d04-1f5e-8cb5-5d78ae96a5ca.png)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/668292/91972d48-0e3c-c6ef-01aa-048902596710.png)
ユーザーを無効にすると「無効」タグが付きます。
また、Microsoft 365 Defender ポータルの [操作と報告] - [アクション センター]に推移すると
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/668292/0d3bf917-f9fc-f516-3f30-3566e61ee5c6.png)
ユーザーの無効化が完了していることが分かります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/668292/d98f1960-5ce8-8e7e-bc62-d9965040a70f.png)

(4) では、無効になったユーザーの挙動を確認してみます。
winter のアカウントを使用してドメイン参加端末に RDP 接続しようとしたところ、以下のエラーが出ました。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/668292/0ce6dd87-d904-6f6a-edfa-bd1d403857c1.png)

winter は AD から AAD に同期されたハイブリッド ID のため、Azure AD 認証をするサービス(Azure ポータルなど)にサインインできなくなっています。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/668292/901931a5-a738-0de4-e262-f38a9c41ea63.png)

ドメイン コントローラーでもユーザーの状況を下記のスクリプトを実行して確認してみます。
```powershell:
$User = Read-Host -Prompt 'Input the user name'; Get-ADUser -Filter {name -like $User -or samaccountname -like $User} | select SamAccountName, Enabled
```
ユーザーが無効であることが確認できます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/668292/e447bcc4-d5b4-962b-07c4-22ca215effc6.png)

[Active Directory ユーザーとコンピューター] を見ても、無効になっています。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/668292/026b20c3-491e-84b6-5868-2cc8dd75541d.png)
ここからは今まで通りユーザーの有効化ができるので、MDI の管理画面とオペレーションがずれないかの注意は必要そうです。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/668292/0d30c8e5-f424-1542-b83e-831db82aef55.png)


### 2. ユーザー パスワードのリセット
(1) セキュリティ管理者の権限で https://security.microsoft.com/ にアクセスします。
(2) 上部の検索バーにてユーザー名を入力、検索します。[ユーザー ページに移動] をクリックします。
先ほどと同様に winter というハイブリッド ID のユーザーを使用します。
(3) [...] をクリックすることで使用可能な応答アクションを確認できます。今回は[パスワードのリセットを強制する] をクリックします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/668292/91b5e642-04aa-6090-2598-0c84172596f0.png)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/668292/02c24836-c7e5-c16e-1aab-d6138c598969.png)
(4) パスワードリセットを強制されたユーザーの挙動を確認してみます。
winter のアカウントを使用してドメイン参加端末に RDP 接続しようとしたところ、以下のエラーが出ました。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/668292/33d06723-0aa5-1310-355d-aa9ef897ac3a.png)
Azure Portal へのサインイン試行をすると、以下のエラーが出ました。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/668292/f56053dc-502d-bcba-1aa6-097f249c8a0c.png)

もともと Azure AD にてユーザー リスク高とマークされている場合には、ユーザーによるセルフ サービス パスワード リセットができなくなる可能性があるため注意が必要です。

## おわりに
今回は Microsoft Defender for Identity の応答アクションについて作成、動作検証してみました。
セキュリティ アラートの確認からユーザーの無効化やパスワードリセットといった応答アクションが取れることにより、Active Directory の操作権限を渡す等のタイムラグなくより迅速な対応ができると感じました☺