MENU

サービスアカウントをローカル管理者に入れつつRDP・対話ログオンを禁止する方法（gMSA/GPO）

Active Directory

アプリ要件で「サービスアカウントを各端末のローカル Administrators（管理者）に追加してほしい」と言われた一方で、「そのアカウントは人が使うものではないので、RDP（リモートデスクトップ）や対話ログオンは絶対にさせたくない」——この矛盾は現場で頻出します。この記事では、セキュリティを落とさずに要件を満たすための現実的な解決策を、優先順位つきで具体的に解説します。

目次

結論：最も安全で運用しやすい順の解決策

まず結論です。できる限り「人がログオンできる前提のアカウント」を作らない方向に寄せ、それでも要件上ローカル管理者が避けられない場合は “拒否（Deny）” のユーザー権利でログオン経路を塞ぎます。

優先方針狙い向いている環境注意点
最優先gMSA（グループ Managed Service Account）でサービス実行パスワード運用を排除し、サービス用途に最適化ドメイン環境（AD）アプリが gMSA に対応しているか要確認
次善「ローカル管理者」要件を棚卸しして最小権限に落とす攻撃面（横展開・資格情報窃取）を根本的に縮小ドメイン/ワークグループ両方権限調整に検証が必要（が、長期的に最も効く）
要件で必須ローカル管理者に入れつつ、GPO/ローカルポリシーで RDP・対話ログオンを拒否「管理者だがサインインできない」状態を作るドメイン/ワークグループ両方“拒否” は強力。適用範囲ミスで事故りやすい

なぜ危険なのか：ローカル管理者＋サービスアカウントが抱える典型リスク

「ローカル管理者に入れる」だけでもリスクは上がりますが、さらに “人がログオンできる” 形で残してしまうと、攻撃者にとって便利な踏み台になります。代表例は次のとおりです。

  • 資格情報の窃取：端末上でサービスアカウントが使われていると、状況次第で認証情報がメモリやキャッシュに残り得ます。
  • 横展開（Lateral Movement）：同じパスワードを複数端末で使っていると、1台の侵害が一気に全台へ広がります。
  • RDP ログオン＝操作可能：ローカル管理者なら、ツール配置・権限昇格・ログ消去などの“次の一手”が取りやすくなります。
  • 監査の難しさ：人がログオンできるアカウントは「誰が・いつ・なぜ使ったか」が曖昧になりやすく、運用事故の原因になります。

したがって、狙いはシンプルです。

  • そもそも人がログオンできない形（gMSA）にする
  • できる限り管理者権限を外す（最小権限）
  • どうしても管理者なら、ログオン経路を “拒否” で塞ぐ

最優先：gMSA（Managed Service Account）を使って「人が使えない」前提に寄せる

ドメイン環境であれば、最初に検討したいのが gMSA（Group Managed Service Account） です。最大の利点は、パスワードを人が知る必要がなく、定期ローテーションも OS/AD が担保しやすいことです。結果として「人がログオンして使う」運用から自然に遠ざけられます。

gMSA が向いている理由

観点通常のドメインユーザー（svc_***）gMSA（svc_***$）
パスワード管理人が作成・保管・ローテーションAD が自動管理（人が知る必要がない）
漏えい時の影響同一パスワード運用だと横展開しやすい設計次第で取得できる端末を限定しやすい
対話ログオン耐性可能（設定しなければ普通にログオンできる）“人がログオンして使う”運用に寄せにくい
監査/運用退職・異動・引継ぎで混乱しがちサービス用途に固定しやすい

gMSA 導入のざっくり手順（PowerShell例）

環境差はありますが、検証で使える “典型手順” を載せます。運用では必ず 検証OU を作って段階適用してください。

## 1) KDS ルートキー（未作成の場合）
Add-KdsRootKey -EffectiveTime ((Get-Date).AddHours(-10))

## 2) gMSA 作成（例）
New-ADServiceAccount `
  -Name "gmsaApp01" `
  -DNSHostName "gmsaApp01.yourdomain.local" `
  -PrincipalsAllowedToRetrieveManagedPassword "GG_gMSAApp01_Hosts"

## 3) gMSA を利用するサーバー/端末を許可グループへ追加
# 例：対象コンピューターアカウントを GG_gMSAApp01_Hosts に追加（GUIでも可）

## 4) 対象端末で gMSA をインストール
Install-ADServiceAccount -Identity "gmsaApp01"

## 5) 確認
Test-ADServiceAccount -Identity "gmsaApp01"

サービスのログオンアカウントは、通常 DOMAIN\gmsaApp01$ のように末尾に $ が付きます（パスワード入力は不要/不可の形になります）。

gMSA でも「ローカル管理者に入れろ」と言われたら

本音では避けたいですが、要件として “どうしても” であれば、gMSA をローカル Administrators に追加すること自体は可能です。ただし、ここで妥協する場合でも、後述する 「RDP / 対話ログオン拒否」 を併用すると事故率が下がります（「設定で塞いだつもり」が、いつの間にか抜け道になりがちだからです）。

次善：本当に管理者が必要かを棚卸しして、最小権限に落とす

アプリ担当から「ローカル管理者必須」と言われても、実際は次のような “特定操作だけ” のために雑に Administrators が指定されているケースが多いです。

  • 特定フォルダー配下への書き込み（ログ、キャッシュ、アップデートファイル）
  • 特定レジストリキーへの書き込み（設定保存、インストーラー起動時のキー作成）
  • サービスの起動・停止、イベントログの参照、パフォーマンスカウンター参照
  • ファイアウォール例外の追加、ドライバー/フィルター導入（ここは本当に管理者が必要なことが多い）

つまり、やるべきは「権限を “大きく付ける” のではなく、“必要箇所にだけ付ける”」です。うまくいけば、ローカル管理者に入れずに済むため、セキュリティ効果が最も大きくなります。

最小権限化の進め方（現場で事故らないやり方）

ステップやることポイント
要件の分解「何をするために管理者が必要か」を操作単位に分解“インストール時だけ”と“稼働時”を分ける
アクセス先の洗い出しファイル/フォルダー、レジストリ、イベントログ、ネットワーク先を列挙ProcMon（Process Monitor）で実測すると速い
権限付与必要箇所へ ACL を付与、ユーザー権利を最小付与“Full Control” は最後の手段
監視失敗ログ、イベントログ、サービス起動失敗を監視「動いたからOK」ではなく “継続” を見る

「サービスとしてログオン」権限は別物

サービスアカウントに必要になりがちな基本権限は、Administrators ではなく 「サービスとしてログオン（Log on as a service）」 です。これはユーザー権利の割り当てで管理します。

  • 場所：コンピューターの構成 → Windows の設定 → セキュリティの設定 → ローカル ポリシー → ユーザー権利の割り当て
  • 設定名：サービスとしてログオン（Log on as a service）

逆に、ここが不足すると「サービスが起動しない」「資格情報が正しいのに 1069 で落ちる」などのトラブルになりがちです。

代表的な「最小権限」付与例（ファイル/レジストリ）

例として、アプリが C:\ProgramData\Vendor\App\ に書き込む場合、Administrators ではなく該当フォルダーにだけ権限を付けます。

icacls "C:\ProgramData\Vendor\App" /grant "DOMAIN\svc_app:(OI)(CI)M" /T

レジストリは GUI でもできますが、運用では PowerShell で “再現性” を持たせるのが楽です（検証・本番差分が減ります）。

要件上どうしても管理者：GPO/ローカルポリシーで RDP と対話ログオンを拒否する

ここからが本題です。「ローカル管理者に入れる必要があるが、RDP や対話ログオンはさせたくない」場合の最も実務的な落としどころは、“拒否（Deny）” のユーザー権利を使うことです。

重要なポイントは次の2つです。

  • “拒否（Deny）” は強い：一般に “許可（Allow）” より優先され、Administrators に入っていてもログオン自体を止められます。
  • 対象は「ユーザー」より「グループ」で管理する：アカウント個別指定は運用で破綻しやすいので、サービス専用グループを作って一括制御します。

まず作る：サービス専用の「対話ログオン禁止」グループ

ドメイン環境なら、次のようなグループ運用が鉄板です。

  • 例：GG_Service_NoInteractiveLogon（グローバルグループ）を作る
  • 対象のサービスアカウント（svc_xxx / gMSA など）をこのグループに入れる
  • GPO の「拒否」にこのグループを指定する

こうすると、新しいサービスアカウントが増えても「グループに入れるだけ」で統制できます。

拒否すべきユーザー権利（最小セット）

目的設定名（日本語）効果注意
RDP を禁止リモート デスクトップ サービス経由でのログオンを拒否
(Deny log on through Remote Desktop Services)		RDP（ログオン種別10）を拒否最優先。まずはここ
コンソール等の対話ログオンを禁止ローカルでのログオンを拒否
(Deny log on locally)		物理/コンソール等の対話ログオン（ログオン種別2）を拒否より徹底したい場合に追加
サービス起動を妨げないサービスとしてログオン
(Log on as a service)		サービス実行に必要「拒否」側に入れないこと

“RDP だけ塞げばOK” なら、まずは 「リモート デスクトップ サービス経由でのログオンを拒否」 だけでも成立します。運用の成熟度やリスク許容に応じて、「ローカルでのログオンを拒否」 を追加してください。

設定手順（ドメインGPO：推奨）

端末が複数あるなら、ローカル手作業ではなく GPO で統制するのが基本です。

  1. GPMC（グループ ポリシーの管理）で、新規 GPO を作成（例：GPO_BlockInteractiveLogon_ForServiceAccounts）
  2. 適用したいコンピューターが入っている OU にリンク（必要ならセキュリティフィルタリングで絞る）
  3. GPO を編集し、次へ進む：
    コンピューターの構成 → Windows の設定 → セキュリティの設定 → ローカル ポリシー → ユーザー権利の割り当て
  4. 「リモート デスクトップ サービス経由でのログオンを拒否」 を開き、GG_Service_NoInteractiveLogon を追加
  5. 必要に応じて 「ローカルでのログオンを拒否」 にも同じグループを追加
  6. 端末側で gpupdate /force（または次回バックグラウンド更新）
  7. 検証：対象アカウントで RDP ログオンが拒否されること、サービスは起動できることを確認

“拒否” のポリシーは影響が大きいので、いきなり全台適用しないのが鉄則です。検証 OU → 一部本番 OU → 全体適用の順で段階的に進めると安全です。

設定手順（ローカルポリシー：単体端末向け）

ワークグループ端末や一部の単体サーバーなど、GPO が使えないケースはローカルポリシーで対応します。

  1. gpedit.msc を開く
  2. コンピューターの構成 → Windows の設定 → セキュリティの設定 → ローカル ポリシー → ユーザー権利の割り当て
  3. 「リモート デスクトップ サービス経由でのログオンを拒否」 に対象ユーザー/グループを追加
  4. 徹底したい場合は 「ローカルでのログオンを拒否」 にも追加
  5. gpupdate /force /target:computer を実行（必要に応じて再起動）

「拒否」が効いているか確認するチェック方法

現場では “設定したつもり” が一番危険です。以下の観点で確認しましょう。

  • GPO の適用確認：gpresult /h C:\Temp\gp.html を出して、該当 GPO が適用されているかを見る
  • RSoP：rsop.msc で「ユーザー権利の割り当て」を確認
  • 実ログオン試験：対象アカウントで RDP ログオンを試し、拒否されることを確認（検証端末で実施）
  • イベントログ：セキュリティログ（4625 など）でログオン拒否の記録を追う

運用でよくある落とし穴：ここを外すと「止めたつもり」が崩れる

落とし穴：サービスアカウントを “個人の都合” で例外扱いしてしまう

「作業者が夜間対応で必要だから」「保守ベンダーがログインしたいと言っているから」と、例外的に RDP を許してしまうと、サービスアカウントが “共有特権ID” として腐ります。これは監査でも突っ込まれやすいパターンです。

対策は単純で、サービスアカウントは絶対に対話ログオン用途に使わないこと。作業が必要なら作業用ID（個人ID、もしくは期限付きの昇格手段）を用意します。

落とし穴：「拒否」に入れた結果、サービスが起動しなくなる

原因として多いのは次の3つです。

  • 「サービスとしてログオン」権限が付いていない
  • 別の GPO で「サービスとしてログオン」を上書きして消している（ユーザー権利は上書き系のため要注意）
  • 誤って「サービスとしてログオンを拒否」に入れている（環境によっては設定されていることがあります）

切り分けの最短ルートは、サービス起動失敗時のイベント（System ログ、アプリログ、サービス固有ログ）を確認し、対象アカウントの権利が不足していないかを RSoP で見ることです。

落とし穴：ローカル Administrators のメンバー管理が壊れる

「GPO でローカル Administrators に入れる」運用は、やり方を間違えると事故ります。代表的には以下です。

  • Restricted Groups で “置き換え” になってしまい、意図しないメンバーが消える
  • GPP（グループ ポリシーの設定：ローカルユーザーとグループ） の “更新” と “置換” を取り違える

運用設計としては、次の2層に分けると安全です。

目的推奨の管理単位例
ローカル Administrators への追加GPP で加算管理（Update）Administrators に DOMAIN\GG_AppLocalAdmins を追加
ログオン拒否（RDP/対話）ユーザー権利にグループ指定GG_Service_NoInteractiveLogon を Deny に追加

そして、アカウント個別ではなく「グループの入れ替え」で制御すると、運用が破綻しにくくなります。

ログで監査する：本当に対話ログオンが発生していないか

「拒否を設定した」だけで満足せず、監査で “実際に使われていない” ことを確認できると強いです。Windows のセキュリティログでは、ログオン種別を見ると状況がわかります。

ログオン種別意味よくある例見たいイベント
2対話（コンソール）物理端末でのログオン4624（成功）/ 4625（失敗）
3ネットワークSMB、共有アクセスなど4624/4625
5サービスサービスとしてのログオン4624
10リモート対話RDP4624/4625

サービスアカウントは基本的に ログオン種別 5 が中心になります。もし 2 や 10 が出ていたら、対話ログオンが発生している（あるいは試行されている）サインです。拒否設定の確認と、運用上の例外が混入していないかをチェックしましょう。

実装例：要件を満たしつつ事故らない「現場テンプレ」

最後に、よくある要件を想定した “安全寄りテンプレ” をまとめます。

テンプレ構成（ドメイン環境）

  • サービス実行アカウント：可能なら gMSA（無理なら svc_***）
  • ローカル管理者が必須なら、Administrators には アカウントではなくグループ を入れる
    • GG_AppLocalAdmins（この中に gMSA / svc を入れる）
  • 対話ログオンは禁止グループで統一
    • GG_Service_NoInteractiveLogon（この中に gMSA / svc を入れる）
  • GPO：
    • GPP で Administrators に GG_AppLocalAdmins を追加（加算管理）
    • ユーザー権利の割り当てで
      • 「リモート デスクトップ サービス経由でのログオンを拒否」＝GG_Service_NoInteractiveLogon
      • 必要なら「ローカルでのログオンを拒否」＝GG_Service_NoInteractiveLogon

テンプレ運用ルール（これを決めると強い）

ルール内容理由
サービスアカウントの対話ログオン禁止は例外なし保守作業は個人ID＋昇格で実施共有特権ID化を防ぐ
ローカル管理者は “期限付き” に寄せる可能ならインストール時だけ管理者、稼働後は最小権限へ恒久管理者を減らすのが最も効く
変更は検証OUから段階適用検証→一部→全体の順“拒否” の事故を防ぐ
監査ログで 2/10 を定期レビューサービスIDの対話ログオン試行を検知設定ミスや不正の早期発見

よくある質問

「リモート デスクトップ サービス経由でのログオンを拒否」だけで十分？

RDP だけ塞ぎたいなら最小構成として有効です。ただし、現場では “つい” コンソールログオン（画面の前でのログオン）が発生し得ます。サービス専用を徹底したいなら、「ローカルでのログオンを拒否」も併用したほうが事故が減ります。

拒否設定を入れたら、管理者権限があっても本当にログオンできなくなる？

一般にユーザー権利の割り当てでは 拒否（Deny）が優先されます。つまり、Administrators に入っていてもログオン経路を遮断できます。ただし、適用対象（OU・セキュリティフィルタ・グループ構成）を誤ると想定外のユーザーに影響するため、段階適用と検証が必須です。

サービスが起動しないときの最短チェックは？

まず 「サービスとしてログオン」 が付いているか、そして関連 GPO が上書きしていないかを確認してください。次に、イベントログ（System/アプリ）でサービス起動失敗の理由を見ます。対話ログオン拒否（RDP/ローカル）の設定自体が原因で止まることは多くありませんが、ユーザー権利が競合していると影響が出ます。

まとめ：安全性と要件を両立する“正攻法”

  • 可能なら gMSA を採用し、そもそも “人が使う前提” を排除する
  • 次に、アプリが本当に必要とする権限を棚卸しして 最小権限 に落とす
  • それでもローカル管理者が避けられないなら、GPO/ローカルポリシーの「拒否」で RDP と対話ログオンを確実に塞ぐ
  • 運用は「個別ユーザー」ではなく グループ設計で回す（増えても破綻しない）

「ローカル管理者に入れる」こと自体は妥協点になり得ますが、ログオン経路を適切に塞ぎ、監査で実態を追える状態にすれば、現実的にリスクを大きく下げられます。要件に引っ張られたまま “使える管理者アカウント” を放置せず、設計で縛っていきましょう。

Active Directory
GPO RDP gMSA ローカル管理者 サービスアカウント

この記事を書いた人

佐藤健司のアバター 佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

関連記事

コメント

コメントする

目次