Microsoft Defender for Identityの「Troubleshooting known issues」は、単なるエラー一覧ではなく、センサー停止、gMSA認証、プロキシ、証明書、VMware、Windows Server 2025でのv3移行制限など、運用停止につながりやすい既知の問題を整理した管理者向けの実務資料です。
結論から言うと、管理者が最優先で確認すべきなのは、センサーのバージョン、Windows Server 2025の移行可否、gMSAまたはDSAの扱い、プロキシ・証明書・ポート設定、Windowsイベント監査とRPC監査です。特にDefender for Identityセンサーv3.xへの移行を進めている環境では、「移行できるサーバー」と「v2.xのまま残すべきサーバー」を切り分けないと、検知の空白や不要なヘルスアラートにつながります。
Microsoft Defender for Identityの既知の問題で押さえるべき変更点
Microsoft Defender for Identityは、オンプレミスActive DirectoryやMicrosoft Entra IDなどのIDシグナルを収集し、資格情報の悪用、横展開、権限昇格などのIDベース攻撃を検出・調査・対応するためのMicrosoft Defender製品です。センサーはID基盤上でWindowsイベントやネットワークトラフィックを解析し、Microsoft Defenderポータルに情報を送信します。(Microsoft Learn)
今回の「Troubleshooting known issues」で実務上の注目点になるのは、以下の3つです。
| 確認ポイント | 管理者への影響 | 優先度 |
|---|---|---|
| Windows Server 2025のv3.x移行制限 | Windows Server 2025のドメインコントローラーは、現時点でv2.xからv3.xへの移行がサポートされない | 高 |
| v3.xセンサーの前提条件 | Windows Server 2019以降、March 2026以降の累積更新、Defender for Endpointの導入などが必要 | 高 |
| gMSA/DSAの扱い | v3.xではLocalSystemを使用するが、v2.xとの混在環境ではワークスペース単位の資格情報検証が残る | 高 |
| 監査設定の自動化 | 手動GPOやPowerShell設定では監査ヘルスアラートが残る場合があり、自動Windows監査設定の利用が推奨される | 中 |
| プロキシ・証明書・ポート | インストール失敗、ライセンスエラー、通信断の原因になりやすい | 高 |
特に注意したいのは、Windows Server 2025上のドメインコントローラーです。Microsoftの「What’s new」では、Windows Server 2025のドメインコントローラーをDefender for Identityセンサーv2.xからv3.xへ移行することは現時点でサポートされておらず、v3.x対応が利用可能になるまではv2.xを継続利用するよう案内されています。(Microsoft Learn)
影響を受けやすい環境
今回の既知の問題は、すべてのMicrosoft Defender利用者に同じ影響があるわけではありません。影響が大きいのは、オンプレミスActive Directoryを持ち、Defender for Identityセンサーを複数サーバーに展開している組織です。
影響が大きいケース
以下に当てはまる場合は、早めに設定確認を行うべきです。
- ドメインコントローラーでDefender for Identityセンサーを運用している
- センサーv2.xからv3.xへの移行を計画している
- Windows Server 2025のドメインコントローラーを利用している
- AD FS、AD CS、Microsoft Entra Connectを含むハイブリッドID基盤を運用している
- gMSAまたはDirectory Service Accountを設定している
- プロキシ、SSLインスペクション、閉域ネットワーク、ExpressRouteを利用している
- VMware上のドメインコントローラーにセンサーを導入している
Defender for Identityセンサーv3.xは、ドメインコントローラー上のAD FS、AD CS、Microsoft Entra ConnectなどのIDロールをサポートします。一方で、ドメインコントローラーではないAD FS、AD CS、Microsoft Entra Connectサーバーでは、v2.xセンサーを使うよう案内されています。(Microsoft Learn)
Windows Server 2025ではv3.x移行を急がない
もっとも誤解しやすいポイントは、「Windows Server 2025をサポートしている」ことと「Windows Server 2025のドメインコントローラーをv3.xへ移行できる」ことは別、という点です。
公式の既知の問題では、Windows Server 2025のドメインコントローラーをv3.xへ移行することは現在サポートされていません。したがって、Windows Server 2025のドメインコントローラーでは、v3.x移行を前提に作業計画を組まず、v2.xセンサーを継続利用する判断が必要です。(Microsoft Learn)
管理者が取るべき判断
| サーバー種別 | 推奨判断 |
|---|---|
| Windows Server 2019以降のドメインコントローラー | 前提条件を満たせばv3.x展開または移行を検討 |
| Windows Server 2025のドメインコントローラー | v3.x移行は現時点で避け、v2.xを継続 |
| ドメインコントローラーではないAD FS、AD CS、Entra Connectサーバー | v2.xセンサーを利用 |
| Windows Server 2016以前のドメインコントローラー | v2.x要件とOSライフサイクルを確認 |
移行計画では、「全台を一括でv3.xへ移行する」のではなく、OS、サーバーロール、Defender for Endpointの導入状況、累積更新プログラム、監査設定を棚卸ししてから対象を分けることが重要です。
センサーv3.xの前提条件を確認する
Defender for Identityセンサーv3.xを展開する場合、単にインストーラーを実行すればよいわけではありません。公式ドキュメントでは、v3.xセンサーの有効化前に複数の前提条件を満たす必要があるとされています。(Microsoft Learn)
主な前提条件
| 項目 | 確認内容 |
|---|---|
| OS | Windows Server 2019以降 |
| 更新プログラム | March 2026以降の累積更新プログラム |
| Defender for Endpoint | センサーを実行するサーバーにオンボード済みであること |
| 既存センサー | v2.xセンサーが同時に展開されていないこと |
| 権限 | Security Administrator、または必要なUnified RBAC権限 |
| メモリ | 仮想環境ではメモリを常時割り当てる |
| 監査 | Windowsイベント監査とRPC監査を構成 |
v3.xでは、CPU使用率は30%、メモリ使用量は1.5GBに制限されます。ただし、他サービスの負荷が高いドメインコントローラーでは、センサー側が制限されていてもサーバー全体のパフォーマンスに影響する可能性があります。容量計画なしに展開すると、「センサーは起動しているが一部イベントを処理できない」という状態になりやすいため、負荷の高い拠点DCや仮想化基盤では事前評価が必要です。(Microsoft Learn)
gMSAとDSAの扱いに注意する
センサーv2.xとv3.xでは、Active Directoryへのアクセスに使うアカウントの考え方が変わります。
v2.xではDirectory Service Account、gMSA、アクションアカウントを使う構成があります。一方、v3.xではActive Directoryデータの読み取りや修復アクションにLocalSystemを使用し、DSAやgMSAは使用しません。Microsoftは、v3.xセンサーを含む環境では、Microsoft Defenderポータルのアクションアカウント設定で「センサーのローカルシステムアカウントを自動的に使用する」設定を選ぶよう案内しています。(Microsoft Learn)
ただし、v2.xとv3.xが混在する環境では注意が必要です。ワークスペースにDSAまたはgMSAが残っている限り、v3.xセンサーを含む全センサーで資格情報検証が行われます。そのため、v3.xでは実際にはgMSAを使っていなくても、「Directory services user credentials are incorrect」のようなヘルスアラートが出る場合があります。(Microsoft Learn)
失敗しやすい運用例
よくある失敗は、v3.xへ一部移行したあとに「もうgMSAは不要」と判断して削除してしまうことです。まだAD FS、AD CS、Entra Connectなどでv2.xセンサーが残っている場合、v2.x側の動作に影響します。
逆に、全センサーをv3.xへ移行済みなのにワークスペース側のDSAやgMSA設定を残したままにすると、不要な資格情報検証やヘルスアラートの原因になります。
判断基準はシンプルです。
| 状態 | 対応 |
|---|---|
| v2.xセンサーが残っている | DSA/gMSAを維持し、権限とパスワードを確認 |
| v3.xセンサーのみ | ワークスペースレベルのDSA/gMSA削除を検討 |
| v2.xとv3.xが混在 | ヘルスアラートの原因が実使用か検証だけかを切り分ける |
センサーが起動しない場合はgMSAと時刻を確認する
既知の問題で頻出するのが、センサーサービスが起動しないケースです。ログにgMSAパスワードを取得できない旨のエラーが出る場合、ドメインコントローラーまたは該当セキュリティグループに、gMSAパスワード取得権限がない可能性があります。(Microsoft Learn)
確認に使える代表的なPowerShellコマンドは以下です。
Get-ADServiceAccount mdiSvc01 -Properties PrincipalsAllowedToRetrieveManagedPassword権限を追加した直後でもエラーが続く場合は、Kerberosチケットに古いグループ情報が残っていることがあります。その場合はサーバー再起動、または管理者権限のコマンドプロンプトで以下を実行してKerberosチケットを破棄します。
klist -li 0x3e7 purgeまた、Secure Time Seedingに関連してgMSAのPasswordLastSetやLastLogonDateが未来日になると、センサーが起動できない場合があります。この場合は暫定対応として正しい日付属性を持つ新しいgMSAを作成し、根本原因の調査はディレクトリサービス側のサポート依頼を検討します。(Microsoft Learn)
プロキシと証明書の問題は「ライセンスエラー」に見えることがある
Defender for Identityのトラブルシューティングで厄介なのは、表示されるエラー名と実際の原因が一致しないケースです。
たとえば、センサー登録時に「ライセンス問題で登録に失敗した」と表示されても、実際にはプロキシ認証の問題である場合があります。公式情報では、プロキシが407ではなく401または403を返すと、センサー側がプロキシ認証エラーではなくライセンスエラーとして解釈する場合があると説明されています。(Microsoft Learn)
確認すべき点は以下です。
| 症状 | 確認する設定 |
|---|---|
| ライセンスエラーに見える | *.atp.azure.comへプロキシ経由で認証なしに到達できるか |
| サービス接続エラー | 必要なルート証明書がローカルコンピューターに入っているか |
| インストール時の通信失敗 | Defender for IdentityクラウドサービスへHTTPSで到達できるか |
| SSL関連エラー | SSLインスペクションやTLS関連レジストリ値を確認 |
v2.xの前提条件では、プロキシ、ExpressRoute、ファイアウォール経由の通信方法が整理されています。プロキシ利用時はセンサーURLの許可、明示的な許可リスト、SSLインスペクション非対応といった制約を確認する必要があります。(Microsoft Learn)
ポートとネットワーク設定で確認すべき項目
センサー通信エラーでは、localhostのTCP 444がブロックされていないか確認します。これはセンサーサービスとアップデーターの通信に関係します。(Microsoft Learn)
また、名前解決や検知品質に影響するポートも見落とせません。v2.xセンサーでは、DNS、NTLM over RPC、NetBIOS、RDPなどを使ってIPアドレスからコンピューター名を解決する場面があります。名前解決の成功率が低いと、検知精度の低下や誤検知増加につながる可能性があります。(Microsoft Learn)
| 用途 | ポート例 | 確認ポイント |
|---|---|---|
| クラウド通信 | TCP 443 | *.atp.azure.comまたはワークスペースURLへの送信 |
| センサー内部通信 | TCP 444 | localhost間通信をブロックしていないか |
| DNS | TCP/UDP 53 | 逆引きゾーンを含めて確認 |
| NTLM over RPC | TCP 135 | センサーから対象端末へ到達できるか |
| NetBIOS | UDP 137 | ファイアウォールで遮断されていないか |
| LDAP/LDAPS | TCP/UDP 389、TCP 636など | 複数フォレスト環境で特に確認 |
VMware環境ではLSO/TSOを確認する
VMware上の仮想マシンにDefender for Identityセンサーを導入している場合、「一部のネットワークトラフィックが分析されない」「VMware上のセンサーでネットワーク構成の不一致」といったヘルスアラートが出ることがあります。公式情報では、ゲストOS側のNIC設定でIPv4 TSO Offloadを無効化する対応が示されています。(Microsoft Learn)
確認には以下のコマンドを使えます。
Get-NetAdapterAdvancedProperty | Where-Object DisplayName -Match "^Large*"LSOが有効な場合は、対象アダプターで無効化します。
Disable-NetAdapterLso -Name "アダプター名"この変更は一時的なネットワーク断を起こす可能性があり、環境によっては再起動が必要です。本番ドメインコントローラーで実施する場合は、メンテナンス時間帯を確保してください。
Windowsイベント監査とRPC監査を後回しにしない
Defender for Identityは、多くの検知でWindowsイベントログに依存します。v3.xセンサーでは、自動Windowsイベント監査の利用が推奨されています。手動のGPOやPowerShellで正しく構成していても、一部のv3環境では監査関連のヘルスアラートが残る場合があり、その場合はDefender for Identityポータルの「Settings > Advanced features」でAutomatic Windows auditing configurationを有効にすることが解決策として示されています。(Microsoft Learn)
さらに、v3.xセンサーではRPC監査も重要です。公式のヘルスアラート一覧では、「Sensor v3.x RPC Audit Misconfigured」が定義されており、Unified Sensor RPC Audit構成タグが正しく適用されていない場合、一部の高度なID検知に必要な可視性が下がる可能性があると説明されています。(Microsoft Learn)
展開後は、以下の順序で確認すると漏れを減らせます。
| 順序 | 作業 | 目的 |
| -: | —————- | ——————- |
| 1 | センサーが正常に表示されるか確認 | 通信と登録の確認 |
| 2 | Health issuesを確認 | 初期不備の検出 |
| 3 | 自動Windows監査を有効化 | イベント収集の安定化 |
| 4 | RPC監査タグを適用 | v3.xの高度な検知に必要な設定を反映 |
| 5 | 24時間程度のヘルス状態を確認 | 日次検証系のアラートを確認 |
インストール・移行前のチェックリスト
Defender for Identityの既知の問題は、発生してからログを追うより、展開前に潰せるものが多くあります。以下のチェックリストを運用前の確認項目として使うと、トラブルを減らせます。
| チェック項目 | 確認内容 |
|---|---|
| サーバーの役割 | ドメインコントローラーか、AD FS/AD CS/Entra Connect単体か |
| OSバージョン | Windows Server 2019以降か、Windows Server 2025か |
| センサー世代 | v2.x継続か、v3.x新規展開・移行か |
| 更新プログラム | v3.xではMarch 2026以降の累積更新を適用済みか |
| Defender for Endpoint | 対象サーバー自体がオンボード済みか |
| gMSA/DSA | v2.xに必要な資格情報が残っているか、v3.x移行後に整理できるか |
| プロキシ | *.atp.azure.comなど必要通信を許可しているか |
| 証明書 | 必要な信頼済みルート証明書が入っているか |
| 仮想化設定 | VMwareのLSO/TSO、Hyper-Vの動的メモリを確認したか |
| 監査設定 | Windowsイベント監査とRPC監査を構成したか |
| ログ場所 | インストールログとセンサーログを調査できるか |
トラブル発生時はHealth issuesとログを起点に切り分ける
問題が起きた場合は、最初からサーバー設定を総当たりで変更するのではなく、Microsoft DefenderポータルのHealth issuesとローカルログを組み合わせて切り分けます。
Health issuesページでは、グローバルな問題とセンサー単位の問題を確認できます。ステータスにはOpen、Closed、Suppressedがあり、メンテナンスなど一時的に想定される問題は7日間抑制できます。(Microsoft Learn)
ログ確認では、展開ログとセンサーログの場所を把握しておくことが重要です。Defender for Identityの展開ログは、インストールしたユーザーの一時ディレクトリに保存されます。既定ではC:\Users\Administrator\AppData\Local\Temp、または%temp%の1階層上で確認できます。(Microsoft Learn)
よくある切り分けの流れ
| 症状 | 最初に見る場所 | 次に確認する設定 |
|---|---|---|
| センサーが起動しない | センサーログ、Health issues | gMSA権限、Log on as a service、Kerberosチケット |
| 登録できない | 展開ログ | プロキシ、証明書、ライセンス、通信先URL |
| 通信断が出る | Health issues | TCP 443、TCP 444、ファイアウォール |
| 検知が少ない | Health issues、イベントログ | Windows監査、RPC監査、イベントログDACL |
| VMwareで分析不足 | Health issues | LSO/TSO、NIC設定、リソース割り当て |
| v3移行できない | Sensorsページ、公式制限 | Windows Server 2025かどうか |
管理者が次に取るべき対応
まず行うべきことは、センサー一覧の棚卸しです。各センサーについて、OS、サーバーロール、センサー世代、Defender for Endpointの有無、gMSA/DSAの利用状況、ヘルスアラートを一覧化してください。
次に、Windows Server 2025のドメインコントローラーを抽出し、v3.x移行対象から外します。Windows Server 2019以降のドメインコントローラーについては、March 2026以降の累積更新、Defender for Endpoint、監査設定、RPC監査タグを確認したうえで、v3.x展開または移行を進めます。
最後に、v2.xとv3.xが混在する間は、gMSA/DSAのヘルスアラートを「実際の認証失敗」なのか「ワークスペース単位の検証によるもの」なのか切り分けます。全台移行後にだけ、不要なDSA/gMSA設定を整理するのが安全です。
Microsoft Defender for Identityの既知の問題は、センサー単体の不具合というより、Active Directory、Windows Server、Defender for Endpoint、プロキシ、証明書、監査ポリシーが交差する運用問題として発生します。移行作業の前に前提条件と制限を確認し、Health issuesとログを起点に管理すれば、検知停止や不要なアラートを最小限に抑えられます。
コメント