企業ネットワークの認証基盤として広く利用されるActive Directoryでは、ドメインコントローラー(DC)の設定は極めて重要です。その中でもUnconstrained Delegation(制限なし委任)はセキュリティに直結する要素として注目されます。本記事では、その背景や設定方法、考慮事項を詳しく解説します。
Unconstrained Delegationとは
ドメインコントローラー(DC)や特定のホスト上で、任意のユーザーになりすませる機能を許可するKerberosの仕組みを指します。Kerberosチケットを保持していると、あたかもそのユーザー本人であるかのように他のサービスへアクセスできるため、利便性が高い一方でセキュリティリスクも大きくなります。
Kerberos認証とDelegationの仕組み
Kerberosは「チケット」と呼ばれる仕組みを中心に動作します。クライアントがドメインコントローラー(KDC)に認証を依頼すると、TGT(Ticket Granting Ticket)が発行され、これをもとに各サーバーへのサービスチケットを取得します。
通常、Delegation(委任)は「あるサービスが、クライアントの代わりに別のサービスへアクセスする」必要があるときに用いられます。
Kerberosの基本フロー
- ユーザーがドメインにログオンし、KDCからTGTを取得する。
- ユーザー(またはサービス)はTGTを提示し、KDCから必要なサービスチケットを取得する。
- サービスチケットをサービスに提示することで、サービスへのアクセスを確立する。
- Delegationを行う場合、サービスがユーザーのTGTやサービスチケットを利用して他のサービスを呼び出す。
このとき、Unconstrained Delegation(制限なし委任)が有効だと、当該サーバーが取得したチケットを用いて、事実上どんなサービスにもユーザー本人としてアクセスできるため、強力ではありますがリスクも伴います。
DCにおけるUnconstrained Delegationのデフォルト動作
なぜドメインコントローラーではデフォルトなのか
ドメインコントローラーはKerberosのKDCとして機能するだけでなく、ユーザーやサービスアカウントの認証要求に対してチケットを発行する中心的な役割を担います。そのため、DC自体にはユーザーやコンピューターのトークン情報や認証情報が集まりやすい構造があります。
Microsoftの設計上、少なくとも1台のドメインコントローラーは信頼される必要があり、Kerberosプロトコルを円滑に動作させるためにUnconstrained Delegationが有効化されていると考えられています。
「Do not trust this computer for delegation」を有効にできるのか
理論上はドメインコントローラーのコンピューターアカウントに対して「Do not trust this computer for delegation」を設定することは可能です。しかし、以下のような問題が生じる可能性があります。
- Kerberosチケットの発行や利用に不整合が発生し、認証障害のリスクが高まる
- Active Directory全体での認証プロセスに影響が及び、ログインやサービス利用に支障が出る
- DC上の他機能(例：DNSやLDAPクエリ)にも予期せぬ副作用が出る
そのため、実運用環境ではDCのUnconstrained Delegationを無効化することはほぼ行われず、どうしてもセキュリティ要件が厳しい場合は別途テスト環境で十分に検証したり、マイクロソフトサポートへ事前に問い合わせるなどが推奨されます。
Unconstrained Delegationを無効化する場合の手順例
以下は、実行を推奨するわけではなく、あくまで技術的な参考としての一例です。
- テスト用のドメイン環境を用意する（本番では絶対に直に変更しない）。
- Active Directory ユーザーとコンピューター(ADUC)などからDCのコンピューターアカウントのプロパティを開き、「Delegation」タブを確認する。
- 「Do not trust this computer for delegation」を選択し、OKを押下して設定を保存する。
- DCを再起動し、ドメイン認証の動作を確認する。
- 不具合が出る場合は、速やかに設定を元に戻す。
実際には、上記を行うとドメインコントローラーとしての基本動作に不具合が生じるケースが多いため、慎重な検証が不可欠です。
PowerShellによるプロパティの確認
ドメインコントローラーや他のコンピューターアカウントのDelegation設定を確認する方法として、PowerShellを利用する例を示します。
# "DC01"というコンピューターアカウントの場合
Get-ADComputer -Identity "DC01" -Properties * | Select-Object Name,
userAccountControl,
trustedForDelegation,
msDS-AllowedToDelegateTotrustedForDelegationがTrueになっている場合はUnconstrained Delegationが有効msDS-AllowedToDelegateToに値があればConstrained DelegationやRBCDが設定されている可能性がある
ただし、この情報だけでは内部的な動作すべてを把握できないこともあるため、実際にはドメイン全体の監査ログやイベントログを併せて確認することが重要です。
Constrained DelegationやResource-Based Constrained Delegationとの比較
Unconstrained Delegation以外の方法として「Constrained Delegation」や「Resource-Based Constrained Delegation(RBCD)」が存在します。以下は簡単な比較表です。
| 項目 | Unconstrained Delegation | Constrained Delegation | Resource-Based Constrained Delegation |
|---|---|---|---|
| 特徴 | 該当ホストが任意のサービスへのアクセスをユーザーとして代行可能 | アクセス可能なサービスを明示的に指定 | リソース側で委任を制御。より柔軟かつセキュア |
| 設定箇所 | コンピューターアカウントのプロパティ（制限なし委任） | 委任元のコンピューターアカウントにアクセス先を指定 | 委任先（リソースサーバー）のACLで指定 |
| セキュリティリスク | 非常に高い（DCや侵害されたサーバーが全ユーザーに成りすまし可能） | 中程度（アクセス先が限定される） | 低い（リソース側の制御が厳密） |
| 主な用途 | DCなど伝統的に無制限に信頼が必要なケース | 特定のバックエンドサービスを利用するフロントエンドWebサーバーなど | マイクロサービス構成など、柔軟な権限設計が必要な場合 |
DC以外の通常サーバーやサービスアカウントでは、セキュリティリスクの低減のためにConstrained DelegationやRBCDを利用するのが望ましいとされています。
セキュリティリスクと対策
Unconstrained Delegationのリスク
- なりすまし攻撃の範囲拡大: 攻撃者がUnconstrained Delegationが有効なサーバーを乗っ取った場合、任意のユーザーになりすませるため、ドメイン全体に甚大な被害が及びかねない
- 特権アカウントの流出: ドメイン管理者など、特権アカウントのチケットが悪用されると、ドメイン全体が制御下に入る可能性がある
DCにおける対策の考え方
ドメインコントローラーはWindowsドメイン基盤の要であるため、最も厳重なセキュリティ対策を施す必要があります。
- 物理セキュリティ: DCが設置されるサーバールームやデータセンターの入退室管理
- ネットワーク分離: DCへのアクセスは最小限の管理用端末や管理者のみが可能なように設計
- 監査ログの取得: Windows Event LogやSIEMでの継続的な監視
- グループポリシーの厳格化: 不要なサービスやプロトコルを有効にしない
実運用上、ドメインコントローラーのUnconstrained Delegationを無理に無効化するよりも、DC全体のセキュリティを物理・論理の両面から強化し、侵入を防ぐ複数の仕組みを用意する方が一般的です。
運用における具体的なベストプラクティス
1. DC以外のサーバーはConstrained Delegation/RBCDを使う
DCには多くの場合Unconstrained Delegationを残さざるを得ませんが、アプリケーションサーバーやファイルサーバーなどではConstrained Delegation/RBCDへの移行を推奨します。Kerberos Delegationを細かく制御することで、侵害範囲を局所化できます。
2. サービスアカウントの最小特権化
不要な特権を付与したアカウントを使うと、万が一侵害された際に被害が拡大します。サービスアカウントには最低限の権限だけを付与し、定期的な見直しを行いましょう。
3. 定期的なパッチ適用とセキュリティ更新
ドメインコントローラーはWindows Server OSの脆弱性が直撃するため、最新パッチや更新プログラムの適用が特に重要です。ゼロデイ攻撃や既知の脆弱性を放置すると、Unconstrained Delegationの存在と相まって被害が大きくなる可能性があります。
4. 監査・ログモニタリングの徹底
ドメインコントローラーでの認証イベントはすべてのユーザーやサービスに関わるため、イベントビューアやセキュリティ情報イベント管理(SIEM)ツールなどで集中管理を行うと効果的です。日頃の正常な振る舞いを把握しておけば、攻撃や異常を早期に検知できます。
無効化を検討する場合の留意点
ビジネス要件とセキュリティ要件のバランス
ドメインコントローラーのUnconstrained Delegationを無効化できたとしても、システム全体が正常に動作しなくなるリスクがあります。特に大規模環境や複数ドメインを管理しているケースでは、ビジネス要件を満たせなくなる可能性があるため、関係各所との調整が必要です。
段階的テストと段階的導入
一度に全DCを無効化するのではなく、テスト用のDCや小規模の子ドメインなど限定された範囲で実験を行い、認証障害やログの挙動を確認します。その上で、問題がなければ段階的に拡大する方法がリスクを最小限に抑えるコツです。
Microsoftサポートやコミュニティリソースの活用
Microsoftの公式ドキュメントやサポートサービス、またはITコミュニティのフォーラムから情報を得ることが大切です。公式にはDCのUnconstrained Delegationを無効化することは推奨されていないケースが多いですが、最新のバージョンや更新で挙動が変わる場合もあるため、常に最新の情報を入手するとよいでしょう。
まとめ
ドメインコントローラーにおけるUnconstrained Delegationは、Active Directory全体の認証を円滑に行うための仕組みとして、デフォルトで有効になっています。セキュリティリスクを考慮すると、無効化したいと思う場面もあるかもしれませんが、実際にはDCに対して完全に無効化するのは難しい上に、システム全体に影響が及ぶ恐れが極めて高いです。
したがって、もっとも現実的な方法は、DC自体には物理・ネットワーク両面で高いセキュリティ対策を講じつつ、DC以外のサーバーやアプリケーションにはConstrained DelegationやResource-Based Constrained Delegationを適切に設定し、サービスアカウントに必要最小限の権限を付与するというベストプラクティスを徹底することです。
今後のアップデートやセキュリティパッチで挙動が変わる可能性もあるため、常に最新情報を追いつつ、運用環境におけるテストと監査ログのモニタリングを続けることをおすすめします。
コメント