認証ポリシーサイロを使うべきなのは、Active Directory で高権限ユーザーや重要なサービスアカウントを「この端末・このホスト・この範囲でしか使わせない」と明確に閉じ込めたいときです。認証ポリシーは TGT の有効期間やサインイン元、サービス チケット発行条件を定義し、認証ポリシーサイロはそのルールをユーザー・コンピューター・サービスの集合にまとめて適用する入れ物として機能します。評価ポイントは Kerberos の AS/TGS 交換で、アプリ内部の認可やネットワーク分離まで自動で置き換える万能策ではありません。 (Microsoft Learn)
逆に、目的が NTLM の削減だけなら NTLM 監査・制限ポリシーのほうが先ですし、サービスアカウントのパスワード運用を楽にしたいだけなら gMSA や dMSA が先です。認証ポリシーサイロは強力ですが、向く場面と向かない場面がはっきりしている機能です。この記事では、その線引きを実務目線で整理します。 (Microsoft Learn)
認証ポリシーサイロは何をする機能か
まず混同しやすいのが、「認証ポリシー」と「認証ポリシーサイロ」は別物だという点です。認証ポリシーはルール本体で、認証ポリシーサイロはそのルールを関連アカウントのまとまりに適用するためのコンテナーです。単発の保護対象ならポリシーだけでも運用できますが、複数の高価値アカウントを“役割単位”で分けるならサイロのほうが管理しやすくなります。 (Microsoft Learn)
| 項目 | 認証ポリシー | 認証ポリシーサイロ |
|---|---|---|
| 役割 | TGT 有効期間、サインイン元、サービス チケット発行条件を定義する | 複数アカウントにポリシーをまとめて適用する |
| 主な対象 | ユーザー、コンピューター、サービス | ユーザー、コンピューター、サービス |
| 向く場面 | 1〜少数アカウントの保護 | 人・端末・サービスを運用単位で束ねたい |
| 運用上の特徴 | サイロなしで直接適用できる | 1つのアカウントは1つのサイロにしか入れない |
サイロ設計で見落としやすいのは、アカウントは1つのサイロにしか属せないことと、サイロを作る前に少なくとも1つの認証ポリシーが必要なことです。さらに、サイロは既定で監査モードなので、作成しただけでは保護が有効になりません。監査で影響を見てから Enforce に進めるのが基本です。 (Microsoft Learn)
先に結論：認証ポリシーサイロを使うべき場面
判断を急ぐなら、次の表で十分です。これは Microsoft の仕様を前提にした実務判断です。 (Microsoft Learn)
| 場面 | 判断 | 理由 |
|---|---|---|
| Domain Admin や Enterprise Admin を専用端末だけで使わせたい | 使う価値が高い | 人・端末・接続先の関係が固定しやすい |
| 重要サービスアカウントを特定ホストだけで使わせたい | 使う価値が高い | サービスの実行場所を明確に縛れる |
| 単一の管理アカウントだけ守りたい | ポリシー単体を先に検討 | サイロまで作ると運用が重くなりやすい |
| NTLM をなくしたい・減らしたい | 別策が先 | 認証ポリシーサイロの主戦場は Kerberos |
| LocalSystem / Network Service / 仮想アカウント中心 | 向きにくい | サービス単位ではなくホスト単位の制御になりやすい |
| レガシー端末や Kerberos armoring 未整備が残る | まず監査と整備 | 端末制限の前提がそろわないと失敗しやすい |
要するに、複数の高価値アカウントを、専用端末や専用ホストとセットで分離したいならサイロ向きです。反対に、プロトコル移行、単一アカウント保護、古いサービス運用の延命が主目的なら、別の打ち手のほうが効果的です。 (Microsoft Learn)
使う価値が高い4つの場面
高権限ユーザーを PAW やジャンプサーバーに固定したい
最も分かりやすい使いどころは、フォレスト管理者やドメイン管理者のような高価値アカウントを、PAW や管理用ジャンプサーバーからの作業だけに限定するケースです。Microsoft も、フォレスト管理者を専用サイロに入れ、ドメイン コントローラーや管理コンソール以外からの認証を失敗させる例を示しています。特権端末側は Privileged workstation と Credential Guard まで組み合わせて初めて強い防御線になるため、サイロ単独ではなく「専用アカウント + 専用端末 + 専用接続先」で設計するのが現実的です。 (Microsoft Learn)
たとえば、次のような形です。
- 通常業務用アカウントと管理用アカウントを分離する
- 管理用アカウントは Protected Users を検討する
- 管理用アカウントのサインイン元を PAW や bastion に限定する
- 接続先は DC、AD 管理サーバー、管理用ファイル共有などに絞る
- メールや Web 閲覧は別端末・別アカウントで行う
この設計で特に重要なのが、ビルトイン Administrator (S-1-5-<domain>-500) は認証ポリシーの対象外だという点です。非常用を含めて全部サイロで縛れると思うと危険です。通常運用は名前付き管理アカウントに寄せ、既定 Administrator は別管理にしたほうが事故を防げます。 (Microsoft Learn)
重要サービスアカウントを決まったホストに閉じ込めたい
バックアップ、監視、IIS アプリプール、バッチ、自動化基盤など、「このサービスはこのサーバー群でしか動かしてはいけない」が明確な場合も、認証ポリシーサイロは有効です。サービス アカウントに対して、どのデバイスからサインインできるか、どのサービスに対して認証できるかを条件で絞れるため、資格情報が盗まれても横展開しにくくなります。複数サーバーで同じ ID が必要なら gMSA、Windows Server 2025 以降で機械 ID への強い結び付けまで欲しいなら dMSA との相性が良いです。 (Microsoft Learn)
一方で、サービスが LocalSystem、Network Service、仮想アカウントのまま動いているなら要注意です。これらはネットワークアクセス時にホストのコンピューター アカウントを使うため、「サービスごとに閉じ込めたい」つもりでも実態はサーバー単位の制御になりやすいからです。サービス分離を本気でやるなら、まず専用のサービス ID へ切り出すところから始めたほうが失敗しません。 (Microsoft Learn)
運用チームやワークロード単位で認証境界を分けたい
認証ポリシーサイロは、単体アカウントの保護よりも、「このチームはこの端末群からこの基盤だけを触る」という運用境界の設計で真価を発揮します。たとえば、AD 管理、バックアップ運用、監視運用、SQL 運用を同じ万能管理アカウントに寄せず、チームごとに専用 ID と専用接続元を持たせる構成です。サイロ内アカウントには silo claim も付与できるため、claims-aware なファイルサーバーなどでは認可条件にも活用できます。 (Microsoft Learn)
逆に、1人の管理者が1つのアカウントで何役も兼ねる運用だと、1アカウント1サイロの制約がすぐにボトルネックになります。その場合は、サイロを増やす前に「役割ごとに別の管理 ID を持てるか」を見直したほうが筋が良いです。 (Microsoft Learn)
外部委託やベンダー管理者を踏み台経由に固定したい
外部ベンダーや運用委託の高権限アクセスを、決められた bastion や踏み台サーバーだけに限定したい場面でも相性は良好です。人・端末・接続先の関係が固定されているほど、サイロの設計は分かりやすく、監査もしやすくなります。反対に、「どこからでも作業する」「接続先が日々変わる」運用では例外が増え、サイロの価値が薄れやすくなります。 (Microsoft Learn)
第一候補にしないほうがよい場面
NTLM を減らしたい・止めたい
NTLM 削減が主目的なら、認証ポリシーサイロは第一候補ではありません。認証ポリシーは Kerberos の AS/TGS 交換で評価され、NTLM にその制限を直接適用できません。実際、Microsoft のログでは Event ID 101 が「認証ポリシーが必要だが NTLM には適用できないため失敗した」ケースとして記録されます。NTLM の棚卸しと抑止には、NTLM の監査・制限ポリシーや、Windows Server 2025 / Windows 11 24H2 以降の SMB NTLM ブロックのような専用機能を使うほうが正攻法です。 (Microsoft Learn)
単一アカウント、または少数アカウントだけを守りたい
保護対象が1アカウント、あるいはごく少数なら、サイロを作らず認証ポリシーを直接そのアカウントに割り当てたほうがシンプルです。サイロは「人・端末・サービスのまとまり」を運用単位で管理する器なので、対象が小さいと管理コストのほうが勝ちやすくなります。 (Microsoft Learn)
レガシー端末や Kerberos armoring 未整備が残っている
ユーザーのサインイン元を端末で制限するには、ドメイン コントローラーがホストの ID を検証できることが前提で、そのために Kerberos armoring と Dynamic Access Control の整備が必要です。未対応 OS や未構成端末が残る環境では失敗が出やすく、公式ドキュメントもまず監査モードで影響確認することを強く勧めています。 (Microsoft Learn)
オフライン前提の端末やブレークグラス運用
Protected Users を併用すると、オフライン サインインは使えず、TGT は既定で 4 時間に制限されます。さらにビルトイン Administrator は認証ポリシーの対象外です。したがって、「非常用アカウントも含めて全部をサイロで統一管理する」より、通常運用用 ID とブレークグラス用 ID を明確に分けておくほうが現実的です。 (Microsoft Learn)
導入前に確認する前提条件
いきなり本番で Enforce する前に、少なくとも次の5点は見てください。ここが曖昧なまま進めると、失敗原因の多くが「機能のバグ」ではなく「前提不足」になります。 (Microsoft Learn)
| 確認項目 | 確認ポイント | よくある見落とし |
|---|---|---|
| 機能レベル | 認証ポリシー/サイロは Windows Server 2012 R2 DFL の機能 | DC OS は新しくても DFL を上げていない |
| ADAC の画面 | Authentication ノードが見えるか | ドメイン管理者で見ていない、DFL 不足 |
| 端末制限の前提 | Kerberos armoring / DAC の設定が DC とクライアントでそろっているか | 一部端末だけ未対応、GPO 未設定 |
| Protected Users の前提 | 高権限ユーザーに有効だが、サービス/コンピューターは対象外 | 古いアカウントの AES 鍵未整備 |
| サービス ID の整理 | sMSA/gMSA/dMSA か、少なくとも専用アカウントか | LocalSystem / Network Service のまま |
この表の根拠は、機能レベルの仕様、ADAC の表示条件、Kerberos armoring の要件、Protected Users の制約、サービスアカウントの選択基準です。監査結果を見るための AuthenticationPolicyFailures-DomainController ログも、先に有効化しておくべきです。 (Microsoft Learn)
失敗しやすいポイントと見方
運用でつまずきやすいのは、「サイロの設計」より「監査と例外整理」です。特に DC の認証ログは、Enforce 前の段階で必ず見ておくべきです。 (Microsoft Learn)
| Event ID | 何が起きたか | まず見るポイント |
|---|---|---|
| 101 | NTLM 認証がポリシー理由で失敗 | アプリや接続が Kerberos ではなく NTLM に落ちていないか |
| 105 | 許可されていない端末からの TGT 要求 | AllowedToAuthenticateFrom と Kerberos armoring |
| 106 | 許可されていないサービスへのサービス チケット | AllowedToAuthenticateTo の条件 |
| 305 | 105 の監査版 | まだ Enforce 前の段階での予兆 |
| 306 | 106 の監査版 | 例外接続の洗い出し |
これらは Microsoft\Windows\Authentication 配下の AuthenticationPolicyFailures-DomainController ログで確認できます。Event 101 が出たらまず NTLM を疑い、105/305 なら端末制限、106/306 なら接続先制限を見ると切り分けが早くなります。 (Microsoft Learn)
もう1つの定番トラブルが、Protected Users の扱いです。Protected Users は AES 前提で、古いアカウントや古い DC で変更されたパスワードが残ると認証できないことがあります。また、高権限グループの全員を一気に投入するとロックアウトの危険があります。少人数でテストしながら広げるのが安全です。 (Microsoft Learn)
代替策と併用策
認証ポリシーサイロは強力ですが、単独で完結する機能ではありません。目的別に別の技術へ役割分担すると、設計がかなり安定します。 (Microsoft Learn)
| 目的 | まず検討する技術 | 認証ポリシーサイロとの関係 |
|---|---|---|
| 特権端末そのものを強くする | PAW / Privileged workstation + Credential Guard | 併用前提 |
| 複数サーバーで使うサービス ID | gMSA | 代替または併用 |
| 1台に強く束縛したい高セキュリティなサービス ID | dMSA | Windows Server 2025 以降では有力 |
| NTLM の棚卸しと抑止 | NTLM 監査・制限ポリシー | 別領域 |
| 委任を止めたい | Account is sensitive and cannot be delegated | 補完策 |
| 単一アカウントだけ守りたい | 認証ポリシー直接適用 | サイロ不要 |
特にサービスアカウントは、gMSA で複数サーバー対応、dMSA でデバイス ID への強いバインドという整理が分かりやすいです。NTLM は将来的な縮小・廃止の方向なので、「サイロで何とかする」より専用の監査・制限機能で減らしていくほうがブレません。 (Microsoft Learn)
小さく始める導入順
迷ったら、最初は次の順で進めると失敗しにくいです。
- 守る対象を「高権限ユーザー」「重要サービスアカウント」「許可端末」「許可接続先」で棚卸しする。
- 高権限ユーザーは通常業務 ID と管理 ID を分離し、端末側は PAW や Credential Guard を先に固める。 (Microsoft Learn)
- サービスは LocalSystem のままにせず、sMSA / gMSA / dMSA への移行可否を決める。 (Microsoft Learn)
- 認証ポリシーを先に作り、その後にサイロを作る。PowerShell なら
New-ADAuthenticationPolicy、New-ADAuthenticationPolicySilo、Grant-ADAuthenticationPolicySiloAccess、Set-ADAccountAuthenticationPolicySiloが中心になる。 (Microsoft Learn) - まず監査のみで回し、DC の
AuthenticationPolicyFailures-DomainControllerログと Event 101/105/106/305/306 を確認する。 (Microsoft Learn) - 例外接続をつぶせたら、小さな範囲から Enforce し、役割ごとの別 ID 運用へ広げる。 (Microsoft Learn)
認証ポリシーサイロは、「設定項目を増やす機能」ではなく、「高価値アカウントをどこで使ってよいかを Kerberos ベースで切り分ける機能」です。高権限ユーザーを専用端末に固定する、重要サービスアカウントを特定ホストに閉じ込める、運用チームごとに認証境界を分ける。この3つのどれかに当てはまるなら、導入を真剣に検討する価値があります。逆に、NTLM 抑止、単一アカウント保護、LocalSystem 中心のサービス運用なら、別策を先に選んだほうが早く成果が出ます。 (Microsoft Learn)
次にやるべきことは、まず保護対象を3系統だけ選ぶことです。たとえば「Domain Admin 用 ID」「バックアップ用 gMSA」「ベンダー用管理 ID」です。その3系統を監査モードのサイロで試し、ログに出る例外を潰してから本番に広げる。この順番なら、認証ポリシーサイロを無理なく実戦投入できます。 (Microsoft Learn)
コメント