Windows Server 2022への移行後に、非管理者ユーザーでサービスの開始や停止が行えず、頭を抱えていませんか？ 従来のWindows Server 2016では問題なく動作していた「sc」コマンドが「Access is denied.」と表示され、管理者権限が必須となってしまうケースがあります。本記事では、その原因や対策を具体的に紹介し、再び快適な運用を取り戻すためのポイントをわかりやすく解説します。
非管理者ユーザーがサービスを開始・停止できない背景
Windows Server 2022では、セキュリティ強化の一環として、非管理者ユーザーやローカルユーザーへの権限の割り当てが厳格化される傾向があります。これまでWindows Server 2016で問題なく行えていたサービス操作が、2022に切り替えた途端に「Access is denied.」となり実行できない現象は、サービスのセキュリティ記述子(SD)やグループポリシーの初期設定が原因になっている可能性が高いです。
サービスの制御においては、以下の要素が複合的に影響することがあります。
- サービスのSD（セキュリティ記述子）の設定
- グループポリシー（ユーザー権利の割り当てなど）の設定
- ネットワーク経由の認証方式やUACリモート制限
- OSのバージョンアップによるセキュリティ既定値の変更
これらを総合的に確認しないまま「Windows Server 2022にアップグレードすれば従来どおりの運用ができる」と考えていた場合、突然サービスの開始や停止が拒否されるというトラブルに直面してしまうことがあります。
Windows Server 2016から2022への変更点
Windows Server 2022では、ゼロトラストセキュリティの観点から、標準で有効になる保護機能や厳格化されたポリシーがいくつか存在します。以下のような要素が変更点として挙げられます。
- セキュリティ更新プログラムの適用範囲の拡大 従来よりも広範囲にわたってセキュリティ更新が実施され、既存機能に微妙な挙動変更が加わるケースがあります。
- グループポリシーの既定設定値変更 特に「ユーザー権利の割り当て」や「セキュリティオプション」で、権限周りが厳しく設定されている可能性があります。
- SMB通信やリモートアクセスの強化 リモートからサービスを操作する際に必要な権限やUACの扱い方に変更があり、従来の設定を引き継いでいても新しい制限が優先される場合があります。
こうした変更点により、非管理者ユーザーが「sc \\サーバー名 stop [サービス名]」や「sc \\サーバー名 start [サービス名]」を実行したときにアクセス拒否される状況が発生しやすくなっています。
ネットワーク経由のサービス制御におけるセキュリティ
「sc コマンド」を使ってリモートサーバー上のサービスを操作するには、ネットワーク越しに認証・通信が行われます。Windows Server 2022で強化されたリモートUACやリモート管理プロトコルの制限により、ローカルでの操作とは異なる認証プロセスが働き、非管理者アカウントがフル権限を付与されないことが多々あります。
もしローカルで同じアカウントを利用した際にサービス操作が可能で、リモート操作のときだけ拒否されるならば、LocalAccountTokenFilterPolicyの設定や、グループポリシー側での「ネットワーク経由での管理権限割り当て」に関するポリシーを見直す必要があります。
解決策1：ユーザー権利の割り当てを確認
まず取り組むべきは、グループポリシーの「ユーザー権利の割り当て」をチェックすることです。以下はローカルセキュリティポリシーでの設定例ですが、ドメイン環境ではドメインコントローラー側のグループポリシー管理コンソール(GPMC)で設定を反映させる必要があります。
ユーザー権利の割り当ての場所
コンピューターの構成
└─ Windows の設定
└─ セキュリティの設定
└─ ローカル ポリシー
└─ ユーザー権利の割り当て
ここで非管理者ユーザーがサービスの制御に必要な権限を持っているかを確認しましょう。例えば「サービスを管理する権限」や「バッチ ジョブとしてログオン」など、環境によっては予想外に必要となる権限があります。
具体的な設定例
サービス制御を許可したいユーザーグループ（例：SERVICE_OPERATORS）を用意し、そのグループに必要な権限を割り当てる方法が代表的です。以下のようにグループポリシーを設定すると、明示的に権限が付与されるため、トラブルシュートが容易になります。
| ポリシー名 | 推奨設定 | 説明 |
|---|---|---|
| サービスとしてログオン | SERVICE_OPERATORS グループを追加 | サービスの操作を行う際に必要になる場合がある |
| バッチジョブとしてログオン | SERVICE_OPERATORS グループを追加 | ジョブやタスクスケジューラからサービスを呼び出す際に必要 |
| ネットワーク経由からのログオンを拒否 | 該当グループが含まれていないことを確認 | 拒否設定があればアクセスできない |
このようにして権限が付与されているか確認し、必要があれば再度割り当てを行います。
解決策2：サービスSD（セキュリティ記述子）を再設定
Windows Server 2016でのSD設定を引き継いでいても、OSバージョンアップによってSDが意図せず書き換わったり、新しい既定値が優先されたりすることがあります。そこで「sc sdshow [サービス名]」で現在のSD文字列を確認し、設定を変更する必要があるかを判断します。
SD文字列の例
sc sdshow "W3SVC"
D:(A;;CCDCLCSWRPWPDTLOCRSDRC;;;SY)
(A;;CCDCLCSWRPWPDTLOCRSDRC;;;BA)
(A;;CCLCSWLOCRRC;;;AU)
S:(AU;FA;CCDCLCSWRPWPDTLOCRSDRC;;;WD)
これはあくまで一例です。実際の文字列はサービスによって異なります。非管理者ユーザー（もしくは特定のユーザーグループ）に対して、SERVICE_STARTやSERVICE_STOPを許可するアクセス制御エントリが含まれているかをチェックしましょう。
SD文字列の編集
もし足りない場合は、sc sdset [サービス名]コマンドで設定を追加変更できます。以下に例を示します。
sc sdset "MyService" D:(A;;CCLCSWLOCRRC;;;AU)S:(AU;FA;CCDCLCSWRPWPDTLOCRSDRC;;;WD)
実際に設定する場合は、現在のSDに対して不足分を追記する形で行うのが安全です。いきなり書き換えるのではなく、事前にバックアップを取ったうえで、慎重に操作しましょう。
解決策3：イベントビューアーでエラー内容を精査
サービスが開始・停止できない場合は、イベントビューアーのセキュリティログやシステムログにエラーが記録されている可能性があります。以下の手順で確認してみましょう。
イベントビューアーの確認
- 「サーバーマネージャー」を開く
- 「ツール」から「イベント ビューアー」を選択
- 左ペインの「Windows ログ」配下の「セキュリティ」や「システム」を展開
- 該当時刻に出力されているエラーや警告を探す
具体的に「どの権限が不足しているか」「どのポリシーがブロックしているか」がログに示される場合があります。そのエラーコードや詳細メッセージをもとに対処を進めると、正しい解決へ近づきやすくなります。
よくあるエラーコード例
- 0x80070005（E_ACCESSDENIED） 権限不足によるアクセス拒否を示す一般的なエラー
- 0xC0000022 NT権限に関するアクセス拒否エラー
解決策4：ローカルログオンとリモート操作で挙動を比較
もし非管理者ユーザーが直接サーバーにログオンできる環境ならば、まずローカルログオン時にサービスを操作できるかをテストしてみてください。ローカルログオン時には問題なく制御できるのに、リモートログオンやドメインからのアクセスでは拒否される場合、ネットワーク経由のUAC制限やLocalAccountTokenFilterPolicyの設定が影響していることが多いです。
LocalAccountTokenFilterPolicyの確認
以下のレジストリキーを確認し、値が「1」になっているかをチェックしてみましょう。
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
名前: LocalAccountTokenFilterPolicy
種類: REG_DWORD
値: 1 (既定は0)
この値が0のままだと、ネットワーク越しのアクセスに制限がかかる場合があります。もしセキュリティポリシー上問題がなければ、1に変更して再起動やポリシーの反映を行い、再度動作確認してみると改善する可能性があります。
解決策5：全般的なセキュリティポリシーと依存サービスを見直す
サービスによっては、別のサービスに依存していることがあります。たとえばAというサービスを停止する際に、Aが依存しているBというサービスの停止権限も必要になる場合があります。したがって、依存サービスの権限設定も確認しましょう。
また、Windows Server全体に適用されるセキュリティ強化ポリシー（たとえば「LDAP署名の必須化」や「SMB署名の必須化」など）によって、ネットワーク越しの操作が想定どおりにいかなくなるケースもあります。以下のようなチェックリストをもとに、サーバー全体を見直すのがおすすめです。
| 項目 | 確認内容 |
|---|---|
| 依存サービス | 依存先サービスの権限も含めて確認する |
| SMB署名 | リモートからのアクセスに制限をかけていないか |
| ファイアウォール設定 | サービス操作用のRPC通信がブロックされていないか |
| UACポリシー | UACのリモート制限が有効になり、トークンが昇格されていないか |
これらの項目を一通り点検することで、思わぬところにある制限に気づける場合があります。
具体的な運用例：SERVICE_OPERATORSグループを作成し権限を付与する
ここでは一例として、カスタムグループ「SERVICE_OPERATORS」を作成し、非管理者ユーザーをそこに所属させるアプローチを紹介します。
ステップ1：ローカルグループの作成
net localgroup SERVICE_OPERATORS /add
ドメイン環境ならば、ドメインのセキュリティグループを作成する方法が望ましいです。
ステップ2：ユーザーの所属
net localgroup SERVICE_OPERATORS ユーザー名 /add
上記コマンドで、操作を許可したいユーザーをグループに追加します。
ステップ3：グループに必要な権限を付与
「ローカルセキュリティポリシー」または「グループポリシー」で、SERVICE_OPERATORSグループに対してサービス制御関連の権限を付与します。具体的には「サービスとしてログオン」「バッチ ジョブとしてログオン」「ネットワーク経由のログオンが拒否されない」などです。
ステップ4：サービスSDの編集（必要に応じて）
特定のサービスに対して、SERVICE_OPERATORSグループにサービス開始・停止の権限を付与する必要がある場合、sc sdsetコマンドでSDを変更します。元のSD文字列を控えておき、そこにグループへのアクセス許可を追加する形が安全です。
トラブルシューティングポイント
上記の設定を行っても問題が解決しない場合、以下のポイントを追加で確認してみてください。
1. ドメインコントローラーとのポリシー競合
ドメイン環境では、ローカルポリシーよりもドメインポリシーが優先されることがあります。ドメインで一括管理されている場合は、DC上のグループポリシーオブジェクト(GPO)を見直し、意図しない設定が上書きされていないかを調査しましょう。
2. サービスアカウントの種類
サービスによっては、LocalSystemやNetworkService、ローカルユーザーなど、実行アカウントが異なります。たとえばNetworkServiceを使っているサービスを制御するために追加の権限が必要になるケースがありますので、アカウント周りも要チェックです。
3. イベントログの警告やエラーの再確認
イベントビューアーを確認すると、サービス開始・停止に絡むエラーだけでなく、関連するイベントとしてグループポリシーの適用ログやセキュリティ監査ログが記録されている場合があります。そこを見逃さないことで、新たなヒントを得られます。
まとめ：厳格化されたセキュリティを攻略しよう
Windows Server 2022において、非管理者ユーザーが「sc」コマンドでサービスを開始・停止できない背景には、OSのセキュリティ強化が深く関わっています。従来のWindows Server 2016とは異なる既定のポリシー設定が適用されているため、グループポリシーのユーザー権利の割り当てやサービスのSD設定、UACリモート制限などをひとつひとつ調整していく必要があります。
トラブルシューティングの大まかな流れとしては、まずはエラーログの確認、次にポリシーやSDの確認、最後にローカルログオンの挙動比較と依存関係のチェックを行います。そうすることで原因の特定が容易になり、最終的には非管理者ユーザーでもサービスの管理を安全に、そしてスムーズに行える環境に戻せるでしょう。
ぜひ本記事を参考に、自社のセキュリティ方針と運用効率をバランスよく保ちながらWindows Server 2022を活用してみてください。
コメント