「このADサーバ、管理者アカウント全員でログインしてるから、誰でも普通に再起動ボタン押せちゃうんですよね」
こういう状態の現場って結構多いんじゃないでしょうか。
Domain Adminsに入っているからと言って、緊急時でも何でもないのに気軽にシャットダウンできてしまう状態、地味に怖くないですか。（そもそも Domain Admins のメンバーは極力増やさないが吉ですが、、汗）
「じゃあ、シャットダウンできる人を絞ればいいのでは」と思って、実際にnlab.localのラボ環境で試してみました。
結論から言うと、思っていたよりもつまずきポイントが多い検証になりました。
まず、一般ユーザーで検証しようとして詰んだ
最初の計画はシンプルでした。「Domain Usersだけの一般ユーザーでログインして、シャットダウンできることを確認 → その後権限を絞って、シャットダウンできなくなることを確認」という流れを考えていました。
ところが、Domain Usersにしか所属していないテストユーザーでDCにログオンしようとしたところ、そもそもログオンできませんでした。
すごく初歩的な概念なのですが、Windows Serverでは「ローカルログオンを許可する」（SeInteractiveLogonRight）という別の権利があり、デフォルトでこれに一般のDomain Usersは含まれていません。
つまり「シャットダウン権限を絞る」以前に、一般ユーザーはそもそもドメインコントローラーに対話ログオンする資格自体がないという前提を、頭では分かっていたつもりでしたが、実際に手を動かして「あ、あれ..？なんでログインできないんだっけ？」と考えさせられてしまいました。。
検証対象をDomain Adminsの中の1人に切り替える
一般ユーザーでの検証は諦めて、方針を変えました。「Domain Adminsの中でも、特定の1人だけシャットダウンさせない」という冒頭でお伝えした、より実務に近いシナリオで検証することにしました。
環境には、Domain Adminsに2ユーザーが所属しています。
Administratoradm_tier0
このadm_tier0だけシャットダウンできないようにする、というのが今回のゴールです。
GPOの場所と、あえて全部消してみた設定
編集したGPOと設定箇所はこちらです。
GPO名：Default Domain Controllers Policy
パス：コンピューターの構成
→ ポリシー
→ Windowsの設定
→ セキュリティの設定
→ ローカルポリシー
→ ユーザー権利の割り当て
→ システムのシャットダウンユーザー権利の割り当て（User Rights Assignment） 「誰が何をする権利を持つか」を制御するGPOのカテゴリ。ファイルやオブジェクトへのアクセス許可（ACL）とは別軸で、OSレベルの操作権限（ログオン・シャットダウン・時刻変更など）を制御する。
デフォルトでこの設定に入っていたメンバーは以下の4グループでした。
Administrators
Backup Operators
Print Operators
Server Operators今回は「正しく機能するか」を確認する目的も兼ねて、あえてこの4グループを全部削除するところから始めました。
実務でこれをやると、Backup OperatorsやServer Operatorsの権限も一緒に消えることになるので、正直あまりおすすめできる手順ではありません。ご注意を、、（この点は後述します）
1回目：Administratorだけを対象にしてみる
まずはAdministratorのみをシャットダウン対象に設定し、gpupdate /forceを実行。
adm_tier0で再ログオンし直し、シャットダウンボタンを押そうとしたところ——
現在、利用できる電源オプションがありません。というメッセージが表示され、シャットダウンメニュー自体が使えない状態になりました。想定通りの結果です。
2回目：個別ユーザー指定ではなく、グループ経由に変更
Administratorを直接指定するのではなく、ShutdownUsersという専用グループを新規作成し、そこにAdministratorのみを追加する形に変更しました。
GPOの対象もShutdownUsersグループに差し替え、gpupdate /forceを実行。
adm_tier0で再度確認したところ、引き続きシャットダウンできないことを確認できました。ここまでは想定通りです。
3回目：adm_tier0にシャットダウン権限を付け直す
最後に、adm_tier0にもシャットダウンを許可したくなったので、adm_tier0でログインしたまま「Active Directoryユーザーとコンピューター」を開き、ShutdownUsersグループにadm_tier0自身を追加。gpupdate /forceを実行しました。
その後、シャットダウンボタンを確認しても、変わらず「現在、利用できる電源オプションがありません。」のまま。「あれ、設定が間違っているのか？」と一瞬焦りましたが、原因は単純でした。
ユーザー権利の割り当て系のポリシーは、ログオントークンに紐づいて評価されるため、gpupdate /forceだけでは反映されず、サインアウト→再サインインが必要でした。ファイル共有のアクセス許可のように、その場でアクセスし直せば即座に反映される類の設定とは挙動が違うのですね。。
サインアウトしてadm_tier0で再ログオンし直したところ、無事にシャットダウンボタンが復活しました。
今回わかったこと
① Domain Usersだけでは、そもそもDCに対話ログオンできない
シャットダウン権限を絞る以前の、大前提の話でした。この記事で最初につまずいたポイントです。（検証以前のお話ですね、、笑）
② ユーザー権利の割り当ては、個別ユーザーよりグループ指定が基本
今回はあえてAdministrator単体で試しましたが、実務では最初からShutdownUsersのような専用グループを作ってグループ単位で管理するのが素直です。人の異動・退職のたびにGPOを直接編集するのは事故のもとです。
③ 変更の反映には、gpupdateだけでなくサインアウトが必要な場合がある
「設定したのに反映されない」と焦ったときは、対象のポリシーがセッション評価型かどうかを疑うのが良さそうです。ユーザー権利の割り当て系は基本的にこれに当てはまるようです。
④ デフォルトの許可グループを安易に全部削除するのは危険
今回は検証のためにBackup Operators・Print Operators・Server Operatorsも含めて削除しましたが、実務でこれをやると、バックアップ担当者が緊急時にサーバーを再起動できない、といった別のトラブルを招きます。絞りたいのは「特定の個人」であって、「運用上必要な組み込みグループ」まで巻き込まないよう、既存グループは残したままShutdownUsersのような追加グループで管理する方が安全ですね。
実務でやるなら、こんな設計がおすすめ
今回の検証を踏まえると、実務で「シャットダウン権限を絞りたい」場合はこういう設計が現実的だと思います。
- 既存の
Administrators等の組み込みグループの権限はそのまま残す - 特定のTier0管理者だけを対象にしたい場合は、Tier0専用のOU・GPOを別途用意し、そのGPOの中で「システムのシャットダウン」を上書きする
- 変更後は必ずサインアウト→再ログオンでの反映確認をセットで行う
Tierモデルの考え方については「AD特権アカウントの設計」で詳しく解説しています。今回のような細かい権限制御も、Tierモデルの発想の延長線上にあります。
GPOそのものの基本設計については「GPO設計入門」もあわせてどうぞ。
コメント