MDM（Intune など）で管理している Windows 端末をリセットした後、アプリ起動時に「This app has been blocked by your system administrator（このアプリはシステム管理者によってブロックされています）」と表示され、さらに「管理者として実行」もできない――この状態は、端末側で“権限”と“アプリ制御”が同時に詰んでいるケースが多いです。本記事では、Windows LAPS（Windows LAPS）で安全にローカル管理者権限へ到達する方法と、UAC を資格情報入力プロンプトに切り替えて運用で詰まらない設計、そしてブロック原因の切り分け・復旧手順を、Intune 前提で具体的にまとめます。
まず押さえるべきポイント：このメッセージは「権限不足」だけが原因ではない
「このアプリはシステム管理者によってブロックされています」は、単純に“管理者権限がない”から出ているとは限りません。特に MDM 管理端末では、リセット直後から次のような制御が再適用され、ユーザー操作が封じられることがあります。
- WDAC（Windows Defender Application Control / App Control for Business）による実行ブロック
- AppLocker による実行ブロック
- SmartScreen / 評判ベース保護の強制（組織ポリシー）
- UAC の動作が「自動的に拒否」になっており、資格情報入力が出ない
- ローカル管理者が不在（または無効）で、昇格先が存在しない
ここで重要なのは、「UAC のプロンプトが出る／出ない問題」と「アプリがそもそも実行禁止の問題」は別物だという点です。UAC を出せるようにしても、WDAC/AppLocker でブロックされているアプリは実行できないことがあります。
症状からの切り分け（最短で原因に近づく表）
| 症状 | 濃厚な原因 | まずやること | 直し方の方向性 |
|---|---|---|---|
| 「管理者として実行」を押しても資格情報入力が出ず、即ブロック/拒否される | UAC が自動拒否／標準ユーザー昇格が禁止 | UAC 設定（標準ユーザーの昇格動作）を確認 | UAC を「資格情報の入力を要求」に変更 |
| 管理者でログオンしても特定アプリだけ同じ文言で起動不可 | WDAC / AppLocker の実行ブロック | ブロックログ（CodeIntegrity/AppLocker）を採取 | 許可ルール追加、ポリシー修正、署名/配布方法見直し |
| リセット後から OS 標準ツール（cmd/PowerShell/設定）まで制限される | セキュリティベースライン/デバイス制限が過剰、想定外の割当 | Intune 割当（適用対象グループ）と競合ポリシーを確認 | ベースライン/構成プロファイルの段階適用・例外設計 |
| リセットすると毎回同じ制限に戻る | Autopilot 登録により再自動構成（同じ構成が戻る） | Autopilot/Enrollment/構成の再適用順序を確認 | 初期構成（ブートストラップ）で詰まらない設計へ変更 |
結論：LAPS は「解除ツール」ではないが、“詰み”を回避する最重要の土台になる
質問の核心である「LAPS（Windows LAPS）ポリシーを作成して適用すれば改善できるか？」に対しては、次のように整理すると分かりやすいです。
- LAPS は、ブロックされたアプリを直接“解除”する機能ではありません。
- 一方で、ローカル管理者アカウントのパスワードを安全に管理し、必要なときだけ管理者権限に到達できるため、リセット後に「昇格できず何もできない」状況の突破口になります。
- つまり、LAPS は復旧作業（ポリシー修正・ログ採取・設定変更）を実行できる状態に戻すための“運用設計”として効きます。
Windows LAPS で実現できること
- 端末ごとにユニークでローテーションされるローカル管理者パスワードを管理できる
- 必要なときだけ、LAPS で取得した資格情報でUAC 昇格やローカル管理者ログオンができる
- パスワードを使った後に自動で再ローテーションさせるなど、運用の安全性を高められる
Windows LAPS だけでは解決しないこと（ここを誤解するとハマる）
- WDAC/AppLocker が正しいアプリまでブロックしている場合、管理者になっても実行できない（ポリシー自体を直す必要がある）
- 端末がネットワークに出られずポリシーが降りない/同期できない場合、LAPS 設定自体が反映されないことがある
- LAPS は“存在するローカルアカウント”のパスワードを管理する仕組みなので、管理対象アカウントが存在しない/無効だと運用できない
LAPS 導入前に確認しておくチェック（表）
| 確認項目 | なぜ重要か | 確認の目安 |
|---|---|---|
| 管理対象のローカル管理者アカウントが存在する | LAPS はアカウントを“作る”機能ではないため | 組み込み Administrator を使うのか、専用 LocalAdmin を作るのか決める |
| 誰が LAPS パスワードを閲覧できるか（権限設計） | 閲覧権限が広いと “万能パスワード閲覧” になりリスク | ヘルプデスク/運用管理者に最小権限で付与 |
| パスワードのローテーションと使用後リセット | 使い回しや漏えい耐性が大きく変わる | 有効期限、使用後の再設定（Post-authentication action）を検討 |
| MDM リセット直後でも“詰まらない”初期構成順序 | WDAC 等が先に強制されると復旧が難しい | ブートストラップで LAPS/UAC/ローカル管理者準備を先行 |
「管理者資格情報の入力を求める UAC プロンプト」を出すベストな方法
今回の状況で最も効くのは、UAC の標準ユーザー昇格動作を「資格情報の入力を要求する」にすることです。これにより、通常ユーザーでサインインしていても、管理者権限が必要な操作でユーザー名とパスワードの入力ダイアログが表示されます。
そして、その入力先としてLAPS で管理されたローカル管理者を使う、という組み合わせが「詰み」を避ける王道パターンです。
UAC の推奨設計（資格情報プロンプト＋セキュアデスクトップ）
- 標準ユーザーの昇格動作：資格情報の入力を要求
- 可能なら：セキュア デスクトップでのプロンプト（画面が暗転して別デスクトップで入力）
- UAC を無効化しない（UAC 無効化は運用・セキュリティ面で副作用が大きい）
UAC 関連ポリシーの要点（表）
| ポリシー名（概念） | 推奨値 | 狙い | 注意点 |
|---|---|---|---|
| 標準ユーザーの昇格プロンプト動作 | 資格情報の入力を要求（できればセキュアデスクトップ） | 管理者権限が必要なときに“入力欄”を出す | 「自動的に拒否」だと永遠に詰む |
| セキュアデスクトップでのプロンプト | 有効 | 資格情報の盗み見/フックをされにくくする | リモート操作ツールの種類によっては見え方が変わる |
| 管理者の昇格プロンプト動作 | 運用方針に合わせる（同意/資格情報） | 管理者ログオン時の手順を統一する | “無条件に昇格”は避けたいケースが多い |
「出したいのに UAC が出ない」典型パターン
UAC を資格情報入力にしたはずなのに、現場で「出ない」ことがあります。よくある原因は次のとおりです。
- 標準ユーザーの昇格動作が「自動拒否」のまま（ベースラインや別プロファイルで上書き）
- ユーザーがすでにローカル管理者グループに入っていて、想定と違う UAC の流れになっている
- ブロックの主体が WDAC/AppLockerで、UAC 以前に実行が拒否されている
- 端末側の制御で「管理者として実行」自体が制限されている（制限系プロファイル、シェル制限など）
Intune（Entra ID/MDM）環境での具体的な対応ステップ
ここからは、質問文の「想定される具体的な対応ステップ」を、実務で詰まりにくい形に落とし込んだ手順として整理します。現場では“一発で直す”より、復旧できる状態を作ってから原因を潰すのが成功率が高いです。
ステップ：Windows LAPS を構成して「ローカル管理者への到達手段」を確保する
狙い：端末ごとのローカル管理者パスワードを安全に管理し、必要なときだけ利用できる状態にする。
- ポリシー作成の考え方
- 管理対象アカウントを決める（組み込み Administrator を使うか、専用 LocalAdmin を作って管理するか）
- バックアップ先を決める（Entra ID へのバックアップ or Active Directory へのバックアップ）
- パスワード長・複雑性・有効期限（ローテーション間隔）を決める
- 使用後の自動リセット（Post-authentication actions）を検討する
運用上のおすすめ：組み込み Administrator は無効化されている設計も多いため、専用のローカル管理者アカウント（例：LocalAdmin）を作成し、そのパスワードを LAPS で管理する方式が安定します。アカウント作成自体は、Intune の「ローカル ユーザーとグループ」設定（またはスクリプト/プロアクティブ修復）で用意します。
ステップ：UAC を「資格情報の入力を要求する」動作に変更する
狙い：標準ユーザーのままでも、管理者が必要な操作でユーザー名/パスワード入力を促すようにする。
Intune では、次のいずれかの方法で UAC 関連設定を管理することが多いです。
- 設定カタログ（Settings catalog）で「ローカル ポリシー / セキュリティ オプション」相当の UAC 設定を配布
- セキュリティ ベースラインで UAC 項目を調整（ただし上書き・競合に注意）
- すでに別のベースラインがあるなら、競合を避けて一元化する（複数ソースから同系統を配布しない）
現場のコツ：UAC は「意図せず強くなりすぎる」「別のベースラインで戻される」が起きやすい領域です。復旧目的なら、まずはテスト用グループに限定して段階的に適用し、実機で “プロンプトが出るか” を必ず確認してください。
ステップ：ブロックの原因となっているアプリ制御を見直す（WDAC/AppLocker/SmartScreen）
狙い：「正しいアプリまでブロックしている」状態を解消する。ここが根本解決です。
管理者権限に到達できる（＝LAPS＋UACで操作できる）ようになったら、次を優先します。
- どの制御がブロックしているかを特定する（WDAC か、AppLocker か、SmartScreen か）
- ブロック対象の実行ファイルのパス、署名、発行元、ハッシュを把握する
- Intune 側のポリシー（App control / Application control / ベースライン / デバイス制限）を見直し、許可ルールまたは配布方法（署名付きMSI化、管理インストーラ、信頼済み経路）を検討する
復旧の実践フロー：LAPS＋UAC を“先に効かせて”からブロックを潰す
以下は、現場で再現率が高い「詰み解除」フローです。ポイントは、いきなりブロック解除を狙わず、まず復旧権限を確保することです。
フロー：まずは“管理者になれる道”を作る
| 手順 | やること | 狙い | チェックポイント |
|---|---|---|---|
| 準備 | LAPS ポリシーを作り、対象デバイス（またはグループ）に割り当てる | ローカル管理者資格情報の取得 | 管理対象アカウントが存在/有効である |
| 準備 | UAC を標準ユーザー「資格情報入力」へ変更するポリシーを割り当てる | 昇格プロンプトを出す | 競合ポリシー（ベースライン）で戻されていない |
| 端末側 | 管理者権限が必要な操作を実行し、UAC で LAPS 管理のローカル管理者を入力 | 一時的に管理者として作業 | プロンプトが出ない場合は UAC 設定/競合を再確認 |
フロー：ブロックの主体を特定して、ポリシーを直す
管理者権限に到達できたら、次は「何がブロックしているか」を特定します。やみくもに設定を触ると、さらに復旧しづらい状態になることがあるため、ログから当てにいくのが安全です。
ログ確認の目安
- AppLocker：イベント ビューアーの AppLocker ログ（EXE/MSI/スクリプトなど）
- WDAC：Code Integrity（コード整合性）系のログ
- SmartScreen：Defender/保護履歴やイベント（環境により見え方が異なる）
Intune を使っているなら、端末に直接入れなくても、「診断の収集（Collect diagnostics）」でログを回収できるケースがあります。リセット直後で端末側の操作が詰んでいるときほど、MDM 側からログを取れる設計が効いてきます。
「このアプリはシステム管理者によってブロックされています」の原因候補と対策（具体例）
同じ文言でも原因は複数あり、対処も変わります。以下は、現場で遭遇頻度の高いパターンです。
WDAC（App Control for Business）でブロックされている
WDAC は、許可された実行ファイル/署名/パス以外を強く制限できます。強力な反面、リセット後に想定外のアプリが軒並み弾かれて復旧作業に必要なツールまで動かないことがあります。
- 対策の方向性
- ブロックされた実行ファイルを特定し、WDAC ポリシーに許可（署名ベース推奨）
- 配布するアプリを、信頼できる配布経路に統一（署名付き、管理インストーラ、企業配布）
- 復旧用に、最小限の管理ツールが動く“ブートストラップ”ポリシー設計にする
AppLocker でブロックされている
AppLocker は、EXE/MSI/スクリプト/パッケージアプリなどをルールで制御できます。パス規則の設計が甘いと、ユーザープロファイル配下（Downloads や Desktop）から起動するツールが弾かれやすく、リセット後に“何もできない”状態になりがちです。
- 対策の方向性
- 署名ルール中心にする（発行元ベース）
- 必要最小限の管理ツールは Program Files 配下など“許可される場所”から動かす運用に寄せる
- スクリプト制御を強める場合は、管理者の復旧導線（LAPS/UAC/診断収集）を先に確保
UAC の動作が「自動拒否」で、資格情報入力が出ない
標準ユーザーの昇格要求が「自動的に拒否」になっていると、ユーザーは永久に管理者に到達できません。セキュリティベースラインやデバイス制限が、意図せずこの状態を作ることがあります。
- 対策の方向性
- 標準ユーザーの昇格動作を「資格情報の入力を要求」に変更
- セキュアデスクトップ有効化
- ベースラインと個別プロファイルの競合を整理（どちらが勝っているかを明確に）
“リセット後に詰む構成”を避けるための設計（これが長期的に効く）
今回のような問題は、個別端末の復旧だけで終わらせると再発します。特に Autopilot＋Intune 運用では、リセット＝再適用なので、初期構成の順序設計が重要です。
推奨：ブートストラップ（初期段階）で最低限の復旧導線を作る
- LAPS（ローカル管理者の安全な管理）は早い段階で適用
- UAC（資格情報入力）も早い段階で適用
- WDAC/AppLocker を強くする場合は、ログ採取・診断・必要ツールが動く状態を先に担保
- 構成を一気に当てず、段階適用（ステージング）で詰みを回避する
復旧しやすい運用パターン（表）
| 運用パターン | メリット | デメリット/注意 | 向いている組織 |
|---|---|---|---|
| LAPS＋UAC資格情報入力＋ローカルAdmin（専用） | 端末単位で安全に昇格でき、復旧しやすい | 閲覧権限設計が必須 | ヘルプデスクが多拠点/多数端末を支える |
| Entra ID グループをローカル管理者に付与（最小） | クラウドアカウントで管理が一本化しやすい | 付与範囲が広いとリスクが上がる | 権限管理（PIM 等）を回せる |
| WDAC を最初から強制（例外なし） | セキュリティ強度は高い | 初期設計を誤ると復旧不能になりやすい | アプリが限定され、運用成熟度が高い |
現場で役立つ「すぐ確認できる」チェックリスト
最後に、同様の問い合わせが来たときに、対応者が短時間で状況を整理できるチェック項目をまとめます。
端末側の確認
- サインインしているのは標準ユーザーか、ローカル管理者か
- UAC の資格情報入力ダイアログが出る設定になっているか（出ないなら“自動拒否”を疑う）
- ブロックされるのは特定アプリだけか、管理ツールも含めて広範囲か
Intune/MDM 側の確認
- LAPS ポリシーが対象デバイスに割り当たっているか
- UAC 設定が別のベースライン/プロファイルで上書きされていないか
- WDAC/AppLocker 相当のアプリ制御が適用されていないか（適用順序や対象グループを含む）
- リセット後に同じ状態へ戻るなら、Autopilot/Enrollment を含めた“再適用設計”が適切か
まとめ：LAPS＋UAC で「詰み」を回避し、ログからブロック主体を潰す
MDM 管理下の Windows 端末をリセットした後に「このアプリはシステム管理者によってブロックされています」が出て管理者操作もできない場合、まずは復旧できる状態（管理者に到達できる道）を作るのが最優先です。
- Windows LAPSでローカル管理者パスワードを安全に管理し、必要なときだけ使えるようにする
- UAC を資格情報入力モードにして、標準ユーザーでも昇格手段を確保する
- その上で、WDAC/AppLocker/SmartScreenなど「ブロックの主体」をログで特定し、ポリシー/配布設計を修正する
この順序で進めると、目の前の端末を救うだけでなく、次のリセットや新規展開でも同じ事故を起こしにくい、強い運用に繋がります。
コメント