「特権アカウントを守る」というと、パスワードを長くする・MFAを設定する、といった対策を思い浮かべる人が多いと思います。
ADにはある グループ に所属させるだけで複数の攻撃手法を同時に無力化できる、地味だけど強力な仕組みがあります。それが Protected Users グループです。
今回は実際に検証環境で特権アカウントを追加し、何が変わるのかを確認してみました。
Protected Usersグループとは
Protected Users（保護されたユーザー）グループ
Windows Server 2012 R2以降で利用できる組み込みのセキュリティグループ。所属させたアカウントに対して、複数の認証保護を自動的に強制する。設定項目を1つずつ調整する必要がなく、グループに入れるだけで有効になるのが特徴。
似た仕組みとしてAdminSDHolderがありますが、役割が違います。AdminSDHolderは「特権グループのACLを保護する」仕組みで、Protected Usersは「認証そのものを強化する」仕組みです。両方を組み合わせて使うのが実務上の理想形です。
何が防げるのか
Protected Usersに所属させると、以下の制限が自動的にかかります。
| 制限内容 | 防げる攻撃・リスク |
|---|---|
| NTLM認証が一切使えなくなる | Pass-the-Hash攻撃 |
| Kerberosの事前認証でDES・RC4暗号が使用不可（AESのみ） | Kerberoasting（RC4チケットのオフラインクラック） |
| TGTの有効期限が4時間を超えて更新することができなくなる | チケット窃取後の悪用可能時間の短縮 |
| 委任（delegation）の対象にできなくなる | 委任設定の悪用によるなりすまし |
| 資格情報のキャッシュが無効化される | オフライン環境でのキャッシュ経由の攻撃 |
個人的に一番効果が大きいと感じたのは、Kerberoasting対策としての側面です。「Kerberoasting対策＝gMSA化」というイメージが強かったのですが、Protected UsersでRC4を使えなくするだけでも、オフラインクラックの難易度は大きく上がります。gMSA化が難しいサービスアカウントには使えませんが（Protected Usersは人が使う特権アカウント向け）、管理者アカウントの保護には即効性があります。
KerberoastingとPass-the-Hashの詳しい仕組みについては「KerberoastingとDCSyncの仕組みと防御策」「AD攻撃手法と要塞化」も参照してください。
実際に追加してみる
Active Directoryユーザーとコンピューター（ADUC）から、対象アカウントをグループに追加します。
まず対象ユーザーのプロパティ画面を開き、「所属するグループ」タブを確認します。
※ADUCで特権アカウント（例：adm_tier0）のプロパティを開き、
「所属するグループ」タブを表示した画面
「追加」ボタンから「Protected Users」を検索して追加します。
※グループの選択ダイアログで「Protected Users」を入力し、
検索結果から選択している画面
PowerShellでも同じことができます。
# 対象アカウントをProtected Usersに追加する
Add-ADGroupMember -Identity "Protected Users" -Members "<ユーザー名>"
# 追加されたか確認する
Get-ADGroupMember -Identity "Protected Users"コマンド1つで完結するので、複数アカウントに展開する場合はPowerShellの方が早いです。
追加後、何が変わったか確認する
設定を反映させるには、対象アカウントで一度ログオフ・再ログオンするか、Kerberosチケットを更新する必要があります。
TGTの有効期限が短縮されているかはklistコマンドで確認できます。
# 現在のKerberosチケットの状態を確認する
klist
通常10時間のTGT有効期限（Renew Time等）が4時間に短縮されていることがわかる
また、それと付随して更新期限も7日間から4時間に短縮しています。
NTLM認証が使えなくなっていることも確認できます。Protected Usersに所属するアカウントでNTLM認証が必要な操作（IPアドレス指定での接続など）を試すと、認証エラーになるはずです。
導入前に確認しておきたいこと
良いことずくめに見えますが、導入前に必ず確認しておきたい点があります。
NTLMに依存した古いアプリケーション・システムがないかが最大の注意点です。
Protected Usersに入れたアカウントはNTLM認証が一切使えなくなるため、そのアカウントでログオンする古いアプリやサービスがNTLMしか対応していない場合、突然ログオンできなくなります。
対策としては、いきなり全管理者アカウントに適用せず、まず1〜2アカウントで試してから展開範囲を広げるのがおすすめです。
実際、今回の検証でも「本当に業務影響がないか」を確かめてから本番投入する慎重さが重要だと感じました。
またオフラインキャッシュも無効化されるため、ネットワーク的にDCに到達できない状況ではログオンできなくなる点もご注意ください。
まとめ
Protected Usersグループは、設定項目を1つずつ調整する手間なく、複数の攻撃対策をまとめて実現できる便利な仕組みです。
ただし「入れれば安心」ではなく、NTLM依存アプリへの影響とオフライン利用の可否は事前に確認してから展開してください。
まずは自分の環境で、Domain Adminsに所属するアカウントのうち1つをProtected Usersに追加してみて、TGTの有効期限がどう変わるか試してみてください。
特権アカウント保護の全体設計については「AD特権アカウントの設計｜Tier0保護と管理者アカウント分離の実務」もあわせてご覧ください。
あわせてご覧ください
- AD特権アカウントの設計｜Tier0保護と管理者アカウント分離の実務
- KerberoastingとDCSyncの仕組みと防御策｜AD攻撃の2大手法を解説
- gMSAとは？設定手順と使いどころをわかりやすく解説
コメント