MENU

Windows Server 2019｜「NT SERVICE\ALL SERVICES」を『サービスとしてログオン』に復元する最短手順と安全設計

PowerShell

Windows Server 2019 で、「サービスとしてログオン」（SeServiceLogonRight）から既定で登録されている NT SERVICE\ALL SERVICES を誤って削除してしまうと、さまざまなサービスのインストールや起動が突然失敗し始めます。インストーラーの途中でロールバックしたり、イベントログに「要求されたログオンの種類は、このコンピューターではアカウントに許可されていません（エラー 1385）」と記録されるのが典型です。

さらに厄介なのは、secpol.msc（ローカル セキュリティ ポリシー）の「ユーザー権利の割り当て」画面で、この NT SERVICE\ALL SERVICES を検索・参照できず、GUIだけでは元に戻せないことです。本記事では、最短で安全に復元する具体手順、ドメイン参加時の落とし穴、検証とトラブルシューティングまで、実運用で困らないレベルまで掘り下げて解説します。

目次

質問概要

状況：Windows Server 2019 で「サービスとしてログオン（Log on as a service）」の権限から既定で登録されている NT SERVICE\ALL SERVICES を誤って削除してしまった。
問題：ローカル グループ ポリシー エディター（secpol.msc）ではこのアカウントを検索できず、再登録できない。元に戻す方法は？ デバイスを工場出荷状態に初期化すれば復旧するのか？

結論（最短手順）

最も再現性が高いのは、secedit で既定のユーザー権利（USER_RIGHTS）を再適用する方法です。1～2分で終わり、NT SERVICE\ALL SERVICES（SID: S-1-5-80-0） を含む既定の割り当てが丸ごと戻ります。既存の権限カスタマイズを保持したい場合は「cfg（INF）エクスポート→編集→再適用」の手動ルートが適しています。

背景知識：NT SERVICE\ALL SERVICESとは？

  • 特殊な「サービスSID」グループで、S-1-5-80-0 という固定SIDに対応します。表示名は各言語環境でも基本的に NT SERVICE\ALL SERVICES です。
  • これが SeServiceLogonRight（サービスとしてログオン） に含まれることにより、「サービスとして実行されるあらゆるサービス」に必要なログオン権が付与され、MSI/MSIX インストーラーでのサービス登録や、サービスアカウント切り替え時の起動が成功します。
  • 削除されると、広範なサービスが一斉に失敗する可能性があるため、最優先で復旧すべき項目です。

なぜ GUI（secpol.msc）だけでは戻せないのか

NT SERVICE\ALL SERVICES は「ユーザー／グループ選択」ダイアログでは解決できない 特殊なSIDエイリアスのため、名前検索にヒットしません。その結果、GUI操作のみでの再追加は現実的でなく、バックエンドのセキュリティ データベース（LSAポリシー）に対して secedit 等で設定を流し込むのが安全・確実です。

復元手段の比較

手段手順メリット / 注意点
① secedit スクリプトで既定値を再構築（推奨）公開系スクリプトに頼らず、secedit /configure でOS既定の USER_RIGHTSを再適用します。下の「方法①」で完全スクリプトを提示。✔ 確実・高速。
⚠ USER_RIGHTS全体が既定化されるため、過去の細かな権限カスタムは再度付け直しが必要な場合あり。
② cfg（INF）を手動編集して適用secedit /export /cfg でポリシーを抽出し、[Privilege Rights] の SeServiceLogonRight へ NT SERVICE\ALL SERVICES（または *S-1-5-80-0）を追記し、secedit /configure で戻す。✔ 変更範囲を最小化。既存の権限はそのまま維持。
⚠ 記法ミスに注意。複数値はカンマ区切り、既存行は置き換えず末尾に追記。
③ OSの初期化／再展開サーバーを初期状態へ戻す（再インストール／イメージ再展開）。ローカルのユーザー権利は既定に戻るため、本件も復旧。✔ 100% 既定状態に戻る。
⚠ アプリ／データ／設定が失われるため最終手段。

方法①：seceditで「ユーザー権利」を既定へ再構築（推奨）

前提

  • ローカル管理者権限の PowerShell（または管理者コマンド プロンプト）で実行
  • 必要に応じてメンテナンス時間帯に実施（User Rights が既定化されるため、意図せず剥がれる個別権限がないか後続で確認）

手順（PowerShellスクリプト例：そのまま実行可）

# === 0) 作業用フォルダーとバックアップ ===
$Work = 'C:\Temp\secpol-restore'
New-Item -ItemType Directory -Path $Work -Force | Out-Null
secedit /export /cfg "$Work\before.cfg" | Out-Null
# 既存セキュリティDBの退避（失敗しても続行）
$secdb = "$env:WINDIR\security\database\secedit.sdb"
if (Test-Path $secdb) { Copy-Item $secdb "$Work\secedit_before.sdb" -ErrorAction SilentlyContinue }

# === 1) 既定の USER_RIGHTS を再適用 ===

# defltbase.inf は OS 既定のセキュリティテンプレート

secedit /configure /cfg "$env:WINDIR\inf\defltbase.inf" `        /db "$env:WINDIR\security\database\secedit.sdb"`
/areas USER_RIGHTS /overwrite

# === 2) ポリシー更新と結果確認 ===

gpupdate /force | Out-Null
secedit /export /cfg "$Work\after.cfg" | Out-Null
Select-String -Path "$Work\after.cfg" -Pattern '^SeServiceLogonRight' | ForEach-Object { $_.Line }

実行結果の読み方：
最後に出力される SeServiceLogonRight = ... の行に NT SERVICE\ALL SERVICES または *S-1-5-80-0 が含まれていれば復元完了です。GUIで再確認する場合は secpol.msc → ローカル ポリシー → ユーザー権利の割り当て → サービスとしてログオン を開きます。

注意点

  • USER_RIGHTS領域全体を既定化します。過去に意図的に足した権限（例：特定ユーザーの「バッチ ジョブとしてログオン」など）がある場合、再付与が必要になることがあります。
  • ドメイン参加環境では、上位のGPOで「ログオンを拒否（SeDenyServiceLogonRight）」が設定されていると、許可よりも拒否が優先されます。後述の「ドメイン/GPOの確認」を必ず実施してください。

方法②：cfg（INF）を書き換えて最小変更で復元

手順概要

  1. 管理者権限のコンソールで現在のローカルセキュリティ設定をエクスポート
  2. [Privilege Rights] の SeServiceLogonRight 行に NT SERVICE\ALL SERVICES（または *S-1-5-80-0）をカンマ区切りで追記
  3. seceditで再適用 → 再起動（必要に応じて）

コマンドと編集例

:: 1) エクスポート
secedit /export /cfg C:\secpol.cfg

:: 2) C:\secpol.cfg をメモ帳で開き、[Privilege Rights] セクションを探す
::    SeServiceLogonRight の行に追記（複数値はカンマ区切り／スペース可）
:: 【例A：行が存在しない場合】
::   SeServiceLogonRight = *S-1-5-80-0
:: 【例B：既に値がある場合（末尾に追記）】
::   SeServiceLogonRight = *S-1-5-80-0, BUILTIN\Administrators

:: 3) 再適用（USER_RIGHTSのみ反映）
secedit /configure /db C:\Windows\Security\Database\secedit.sdb ^
/cfg C:\secpol.cfg /areas USER_RIGHTS

:: 4) 設定反映（必要に応じて再起動）
gpupdate /force

ポイント：

  • *S-1-5-80-0 の先頭のアスタリスク（*）はSIDとして解釈させるための記号です。ローカライズ差異に影響されず堅牢です。
  • NT SERVICE\ALL SERVICES という名前表記でも適用可能です（内部的に S-1-5-80-0 に展開されます）。
  • INF形式は「後勝ち」なので、同じキーを複数行に分けて記述しないでください。必ず1行にカンマ区切りで列挙します。

方法③：OSの初期化／再展開（最終手段）

ローカル セキュリティ ポリシーは OS 既定へ戻りますので、NT SERVICE\ALL SERVICES も復元されます。ただしサーバー運用では現実的でないことが多く、アプリ／データ消失のリスクがあるため本稿では代替不可時の最終手段と位置付けます。Server OS では「Reset this PC」に相当する仕組みの有無や運用ポリシーが組織により異なるため、通常は方法①または②で解決してください。

復旧後の確認チェックリスト

観点具体的な確認方法期待する結果
ポリシーの値secedit /export /cfg C:\after.cfg を実行し、
SeServiceLogonRight の行を確認		NT SERVICE\ALL SERVICES または *S-1-5-80-0 を含む
GUI確認secpol.msc → ユーザー権利の割り当て → サービスとしてログオン一覧に NT SERVICE\ALL SERVICES が表示される
イベントログインストール／起動に失敗していたサービスの再試行後、
システムログ（Service Control Manager）を確認		「要求されたログオンの種類は許可されていません」エラーが解消
拒否権限の有無SeDenyServiceLogonRight（ログオンを拒否：サービス）に
対象アカウントが入っていないかチェック		対象が含まれていないこと（拒否は許可より優先）

ドメイン参加環境で必ず確認すべきこと（GPO/RSoP）

ローカルポリシーで直しても、上位のグループポリシーが次回適用時に上書きするケースがあります。特にセキュリティベースラインやハードニングGPOで「SeServiceLogonRight の再定義」「SeDenyServiceLogonRight の設定」が施されていると、症状が再発します。

  1. 適用ポリシーの特定：gpresult /r /scope computer /v で、当該サーバーに適用中の GPO を洗い出します。
  2. 有効設定の確認：RSoP（rsop.msc） または GPMC（gpmc.msc） から、
    コンピューターの構成 → ポリシー → Windows の設定 → セキュリティの設定 → ローカル ポリシー → ユーザー権利の割り当て
    の 「サービスとしてログオン」「ログオンを拒否：サービス」を確認します。
  3. ポリシー側の是正：NT SERVICE\ALL SERVICES（S-1-5-80-0） が許可に含まれ、拒否に含まれないよう編集・リンク順を調整します。

ポイント：拒否は許可より優先されます。トラブル時は、まず SeDenyServiceLogonRight に不要なエントリが入っていないかを確認しましょう。

トラブルシューティング（それでも直らない場合）

1) セキュリティデータベース破損の疑い

稀に %WINDIR%\Security\Database\secedit.sdb が破損していると、適用が反映されないことがあります。次の手順でリビルドします（実施前に必ずバックアップ）。

:: サービス停止は不要だが、メンテ時間推奨
takeown /f "%WINDIR%\Security\Database\secedit.sdb"
icacls "%WINDIR%\Security\Database\secedit.sdb" /grant Administrators:F
ren  "%WINDIR%\Security\Database\secedit.sdb" secedit.broken.sdb

:: 既定の USER_RIGHTS を再適用してDBを再生成
secedit /configure /cfg "%WINDIR%\inf\defltbase.inf" ^
/db "%WINDIR%\Security\Database\secedit.sdb" /areas USER_RIGHTS /overwrite
gpupdate /force

2) セキュリティテンプレート（defltbase.inf）が見つからない

標準では %WINDIR%\inf\defltbase.inf にあります。存在しない場合は OS コンポーネントの破損が疑われるため、手動編集ルート（方法②）を用いるか、SFC/DISM による修復を検討してください。

3) 依然としてインストールが失敗する

  • インストーラーが個別のサービス アカウント（例：ドメインユーザー）で登録しようとしており、そのアカウントに SeServiceLogonRight が足りない。
  • GPOによって「ログオンを拒否：サービス」に対象が入っている。
  • サービス自体のバイナリや依存関係の問題（エラー 7000/7009 など）。

上記を切り分けるには、イベントビューア（システムログ）と gpresult の併用が有効です。

運用のコツとベストプラクティス

  • サーバー構築直後のスナップショット（仮想ならチェックポイント）を必ず作成。ユーザー権利の誤変更からの復旧が圧倒的に容易になります。
  • Hardening適用前に、SeServiceLogonRight の既定値を secedit /export で控える。
  • 変更申請フローに「ユーザー権利の割り当て」チェックを組み込む。権限削除は影響範囲が広いためレビュー必須。
  • 言語の違いに左右されないよう、スクリプトでは SID（*S-1-5-80-0）で指定するのが堅牢。

クイック・コピー用スニペット集

1) 既定USER_RIGHTSを再適用（最短）

secedit /configure /cfg %WINDIR%\inf\defltbase.inf ^
        /db %WINDIR%\Security\Database\secedit.sdb ^
        /areas USER_RIGHTS /overwrite
gpupdate /force

2) 現在値の確認（SeServiceLogonRight）

secedit /export /cfg C:\after.cfg
findstr /B /C:"SeServiceLogonRight" C:\after.cfg

3) INF（cfg）編集の雛形

[Privilege Rights]
; 既存値がある場合はカンマで追記
SeServiceLogonRight = *S-1-5-80-0

4) PowerShellでSID⇄アカウント名を確認

# S-1-5-80-0 が何に解決されるか
(New-Object System.Security.Principal.SecurityIdentifier('S-1-5-80-0')).
    Translate([System.Security.Principal.NTAccount]).Value
# 期待値: NT SERVICE\ALL SERVICES

よくある質問（FAQ）

Q. NT SERVICE\ALL SERVICES を再追加したのに、インストールが失敗します。 A. そのサービスが特定のユーザー（例：ドメインユーザー）で実行されるよう指定されている場合、そのユーザー自身に SeServiceLogonRight が必要です。また、SeDenyServiceLogonRight に入っていないかも確認してください。 Q. 日本語OSで名称は異なりますか？ A. 表示名は基本的に NT SERVICE\ALL SERVICES のままです。スクリプトは SID（*S-1-5-80-0） 指定が最も安心です。 Q. secpol.msc では絶対に追加できませんか？ A. 追加できるケースもありますが、オブジェクト選択ダイアログで解決されないことが多く、secedit（方法①/②）の方が確実です。 Q. 初期化したら復旧しますか？ A. はい。OS既定に戻るため復旧します。ただしサーバー運用では現実的でないため、まずは方法①/②を推奨します。

まとめ

  • 症状：サービスのインストール／起動が相次いで失敗。ログに「要求されたログオンの種類は許可されていません」。
  • 原因：NT SERVICE\ALL SERVICES（S-1-5-80-0） が SeServiceLogonRight から削除された。
  • 解決：最短は secedit で USER_RIGHTS を既定へ再適用。既存カスタム維持なら cfg編集→再適用。
  • 運用：GPOの上書きと「ログオン拒否」設定を必ず併せて確認。スクリプトはSID指定が堅牢。

付録：インシデント対応テンプレート（社内ナレッジ用）

項目記入例
発生日2025-10-31
影響範囲Windows Server 2019 計3台（アプリA/Bのサービスインストール失敗）
事象サービス登録時にエラー 1385、イベントID 7000/7009
根本原因SeServiceLogonRight から NT SERVICE\ALL SERVICES が削除
恒久対策方法①で復元後、GPOのベースラインを見直し。運用手順に「権限変更レビュー」を追加
再発防止構築直後の secedit エクスポートを資産管理へ保存。変更監査を有効化

参考コマンド チートシート

:: 直近の適用GPO一覧（コンピューター）
gpresult /r /scope computer /v

:: RSoPの起動（GUI）
rsop.msc

:: SeServiceLogonRight のみを既定へ戻す（cfg編集を使う場合）
secedit /export /cfg C:\wip.cfg
:: <編集：SeServiceLogonRight に *S-1-5-80-0 を追記>
secedit /configure /db %WINDIR%\Security\Database\secedit.sdb ^
/cfg C:\wip.cfg /areas USER_RIGHTS
gpupdate /force

本記事の要点（実務向けサマリー）

  • GUIで見つからない特殊SIDは、seceditで戻すのが王道。
  • 既定に寄せるなら方法①、最小変更なら方法②。
  • ドメイン環境ではGPOの拒否設定チェックが必須。
  • スクリプトはSID（*S-1-5-80-0）指定が安全。

ユーザー権利（SeServiceLogonRight）の豆知識

  • 同名の「ログオンを拒否：サービス（SeDenyServiceLogonRight）」が存在し、こちらが優先されることを必ず覚えておく。
  • サービス固有SID（NT SERVICE\<ServiceName>）だけを許可する設計は堅牢だが、運用負荷が上がる。一般的には ALL SERVICES を許可しつつ、不要サービスの無効化・削除で面を狭めるのが現実解。
  • セキュリティベースライン適用時は、インストール工程の前に適用するとトラブルを避けやすい。

以上、Windows Server 2019 で「NT SERVICE\ALL SERVICES」を SeServiceLogonRight に復元するための完全ガイドでした。現場でそのまま使えるコマンド・スクリプトを掲載しましたので、復旧と再発防止にお役立てください。

PowerShell
グループポリシー secedit Windows Server 2019 SeServiceLogonRight

この記事を書いた人

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

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

関連記事

コメント

コメントする

目次