システムエンジニアXの「プログラミング以外」の話 50代会社員SEのお仕事・副業・システム運用の経験談
Windows GPO Active Directory グループポリシー Kerberos MS16-072 セキュリティ Windows Server

【解説】GPOのコンピューター構成を取得するアカウントの正体とSYSVOLの罠

公開:

※本記事には広告を含みます。

はじめに

Active Directoryでグループポリシー（GPO）を運用している際、「端末に適用される『コンピューターの構成』は、一体どのアカウントの権限でドメインコントローラー（SYSVOL）へ読み取りに行っているのか？」と疑問に思ったことはないでしょうか。

私も過去に、セキュリティ対策としてGPOのセキュリティフィルターから「Authenticated Users」を削除し、特定の対象グループだけに絞り込んだところ、すべての端末でポリシーが一切適用されなくなり、原因特定に半日以上奔走した苦い経験があります。

実は、コンピューターポリシーを取得しに行く主体は「コンピューター名$（マシンアカウント）」であり、さらにマイクロソフトの仕様変更（MS16-072）以降、ユーザーポリシーの読み取りにもマシンアカウントのアクセス権が必須となっています。

この記事では、「コンピューターの構成」を取得する認証コンテキストの仕組み、SYSVOL共有へのアクセスフロー、そして現場で多発する「セキュリティフィルターの落とし穴」を徹底解説します。

読み終えるころには、ポリシー適用失敗の根本原因を理論的に解明し、二度と認証トラブルで迷わなくなります。

この記事の要点

  • 「コンピューターの構成」をDCから取得しに行く主体は、OSの Local System（NT AUTHORITY\SYSTEM） 権限で動く「コンピューターアカウント（ホスト名$）」 である
  • 2016年のセキュリティ更新（MS16-072）以降、ユーザーポリシーであっても「コンピューターアカウント」にSYSVOL読み取り権限がないと適用が失敗する
  • セキュリティフィルター処理で特定のユーザー/端末に限定する場合は、「Authenticated Users」から「適用」権限のみを外し、「読み取り」権限を残すのが鉄則である
項目 動作確認・検証環境
検証年月 2026年3月
対象OS Windows Server 2022 / Windows 11 Pro 23H2・24H2
プロトコル Kerberos認証 / SMB (Port 445) / LDAP (Port 389)
関連セキュリティ更新 MS16-072 (KB3163622)

結論：「コンピューター名$」がKerberos認証でSYSVOLを読みに行く

結論からお伝えすると、Windowsが起動時やバックグラウンド更新時に「コンピューターの構成」を取得する際、ネットワーク上では「ドメイン名\コンピューター名$」というマシンアカウントとしてKerberos認証を行い、DCの \\domain\SYSVOL 共有へアクセス しています。

ローカルPC内では NT AUTHORITY\SYSTEM（Local System）として動作する「Group Policy Client サービス（gpsvc）」が、外部ネットワークに対しては端末自身のActive Directoryコンピューターオブジェクトの資格情報を使用して通信を行います。

コンピューターポリシー vs ユーザーポリシーの認証コンテキスト比較

ポリシー種別 実行サービス ネットワーク通信時の認証アカウント SYSVOL上のアクセス権要件
コンピューターの構成 gpsvc (Local System) ドメイン名\端末ホスト名$ (Domain Computers) 「Domain Computers」または「Authenticated Users」の読み取り権限
ユーザーの構成 gpsvc (User Context) サインイン中のドメインユーザー ＋ 端末ホスト名$ 対象ユーザー ＋ コンピューター側の読み取り権限（MS16-072）

現場で最も多発するトラブル：MS16-072とセキュリティフィルターの罠

インフラ管理者が一度は必ずハマるのが、「特定のユーザーグループだけにGPOを当てたい」としてセキュリティフィルターを弄った際に起きるトラブルです。

MS16-072（KB3163622）以前の挙動

かつてのWindowsでは、ユーザーポリシーを取得する際、サインインしている「ユーザー自身のKerberosチケット」だけでSYSVOL上のGPOフォルダ（GPT.INI など）を読み取っていました。

しかし、この仕様には「悪意あるユーザーが中間者攻撃（MitM）で偽のポリシーを挿入できる」という脆弱性がありました。

仕様変更後：ユーザーポリシーも「コンピューターアカウント」が検証する

脆弱性を塞ぐため、Microsoftは仕様を変更しました。

現在のWindowsでは、ユーザーポリシーであっても、まず端末のマシンアカウント（コンピューター名$）がSYSVOLへアクセスして改ざんがないかを検証し、その後にユーザーがポリシーを読み込む 二段構えのアーキテクチャになっています。

やってはいけないミス：Authenticated Usersの全削除

グループポリシー管理エディター（GPMC）で「セキュリティフィルター処理」から Authenticated Users を削除し、代わりに 営業部グループ だけを追加するとどうなるでしょうか。

  1. 営業部グループ には「読み取り」と「グループポリシーの適用」が付与される。
  2. しかし、端末のコンピューターアカウント（PC-01$）は Authenticated Users から外れたため、SYSVOLの読み取り権限を失う。
  3. クライアント端末がSYSVOLへアクセスできず、イベントログに「アクセスが拒否されました」と記録されてポリシー適用が全停止する。

正しい設定手順：委任タブで「Domain Computers」に読み取り権限を与える

特定のグループだけにポリシーを適用したい場合は、以下のいずれかの手順を踏みます。

  • 方法A（推奨）:
    「委任」タブを開き、「Authenticated Users」の権限から「グループポリシーの適用」のチェックだけを外し、「読み取り」権限はそのまま残す。
  • 方法B:
    「委任」タブで 「Domain Computers」グループを追加し、「読み取り」権限を明示的に付与 する。

SYSVOL内の特定ファイルへの「アクセス拒否（Deny）」は可能か？

「SYSVOL共有内にある特定のスタートアップスクリプトを、一般社員に見られたくないのでNTFSアクセス権で拒否（Deny）したい」という相談をよく受けます。

結論：技術的には可能だが、運用上は絶対に推奨されない

SYSVOL内のフォルダやスクリプトに対して、特定ユーザーの「読み取り拒否（Deny ACE）」を設定することは可能です。拒否されたユーザーがログオンした際、そのスクリプトは実行されずエラーとなります。

しかし、これには以下の重大なデメリットがあります。

  1. GPO自体の同期・レプリケーション不整合:
    ドメインコントローラー間でSYSVOLを同期するDFS-R（分散ファイルシステムレプリケーション）が、非標準のACLによって同期エラーを起こすリスクがある。
  2. 保守の破綻:
    GPMCのGUIからはSYSVOLの深層NTFS権限が見えないため、数年後に別の管理者がトラブルシューティングした際に「なぜか特定ユーザーだけ動かない」という原因不明の怪奇現象になる。
  3. パスワード隠蔽の役には立たない:
    スクリプト内に管理者パスワードやAPIキーを直書きしている場合、アクセス権で隠そうとしても事故の元です。機密情報はスクリプトに埋め込まず、Azure Key VaultやLAPS、証明書認証を活用してください。

よくある質問（FAQ）

Q: クライアントPCがドメインコントローラーと通信するポートは何番ですか？

A: 主に以下のポートを使用します。端末がポリシーを取得できない場合は、ファイアウォールでこれらがブロックされていないか確認してください。
- Port 445 (TCP): SMB（SYSVOL共有からのファイル取得）
- Port 88 (TCP/UDP): Kerberos認証
- Port 389 / 636 (TCP/UDP): LDAP / LDAPS（ADオブジェクトの検索）
- Port 53 (TCP/UDP): DNS（ドメインコントローラーの名前解決）

Q: 「アクセスが拒否されました」エラーが出ているか確認するコマンドは？

A: PowerShellで gpresult /h C:\Temp\report.html を実行し、「拒否されたGPO」のセクションを確認します。理由に「アクセス拒否」または「セキュリティで保護されています」と表示されている場合、マシンアカウントまたはユーザーアカウントのSYSVOL読み取り権限不足が確定します。

まとめ

グループポリシーの内部動作と認証アカウントのポイントは以下の通りです。

  • 「コンピューターの構成」は、ローカルの SYSTEM 権限から ネットワーク上では コンピューター名$ としてKerberos認証 して取得される
  • MS16-072以降、ユーザーポリシーの適用にも 端末マシンアカウントのSYSVOL読み取り権限が必須
  • セキュリティフィルターを変更する際は、「Authenticated Users」または「Domain Computers」の読み取り権限を絶対に剥奪しない
  • SYSVOL内のACLを直接手動変更（Deny設定など）することは避け、GPOの正規のフィルタリング機能を使用する

Active Directoryの認証仕様を正しく把握しておくことで、ポリシー適用のトラブル時に迷宮入りすることなく、最短で問題を解決できるようになります。

関連記事

免責規定

この記事で提供される情報は、一般的なガイダンスを目的としており、すべての環境やシステムでの動作を保証するものではありません。

OSのバージョンやリリースによっては、記載されている事が実行できない、または異なる結果をもたらす可能性があります。 また、会社所有のパソコン、スマホ、タブレットなどでは、ポリシーや権限によって実行できない場合があります。

この記事の情報を使用することによって生じる問題や結果について、筆者およびサイト管理者は責任を負いません。 すべての操作は自己責任で行ってください。

最後までお読みいただきありがとうございました。
またお会いしましょう！
← 記事一覧に戻る