Google Workspace から Microsoft 365 へ移行後、Intune（Entra ID 参加）で管理した Windows 端末にサインインしたのに、Office やアプリを入れようとすると「要求された操作には昇格が必要です」で止まる――。本稿はこの“詰み”を再現・原因・恒久対策・復旧まで一気通貫で解説します。
現象の整理：移行直後に起きる「昇格が必要」ロック
- Windows PC を初期化し、職場のデバイスとして登録（Microsoft Entra ID 参加／Intune 管理）。
- ユーザーでサインイン後、Office やアプリのインストール、設定変更、コマンド実行がすべて UAC の管理者資格情報を要求。
- Microsoft Entra ID（旧 Azure AD）側でユーザーに多数のロールを付与しても、端末のローカルでは標準ユーザーのままで管理者操作ができない。
- 管理者の追加も不可で、実質ロックアウト。
なぜ起こるのか：クラウドの「ロール」と Windows の「ローカル権限」は別物
Microsoft Entra の Global Administrator などのクラウド ロールは、Microsoft 365 や Entra ポータル／Intune などクラウド側の操作に効く権限です。一方で、Windows 端末で UAC を超えてアプリを入れたり設定を変えたりするには、端末のローカル Administrators グループに所属している必要があります。ここは自動で連動しません（設計上の分離）。
例外・注意点として、テナント設定や Autopilot プロファイル次第で「初回サインインユーザー」や「Device Administrators（テナントの追加ローカル管理者）」がローカル管理者になる構成もあります。しかし移行・再初期化・プロファイル設定漏れ・反映の遅延などが重なると、意図せず標準ユーザーで固定され、今回のようなロックイン状態に陥りがちです。
概念対応表
| 対象 | 主な用途 | 具体例 | ローカル管理者化 |
|---|---|---|---|
| Entra ロール | クラウド管理（ポータル／API） | Global Admin, Intune Admin など | 自動ではならない（別途ポリシーや設定が必要） |
| 端末ローカル グループ | Windows の管理操作 | Administrators, Users など | Intune 等で明示的に付与する |
| Autopilot プロファイル | 初期セットアップの体験制御 | ユーザー アカウント種別（標準/管理者） | プロファイル設定に依存（標準が推奨） |
| Device Administrators | テナント一括でローカル管理者を追加 | 追加ローカル管理者（全 AADJ デバイス） | 適切に構成すればローカル管理者にできる |
まずは現状を確認（5 分チェック）
「構成が想定通りか／どこで止まっているか」を切り分けます。
- 参加状態を確認
dsregcmd /statusAzureAdJoined : YES なら Entra 参加、MDMUrl があり Device state: Managed なら Intune 管理中と読めます。 - ローカル管理者グループの中身
net localgroup administratorsまたは PowerShell：Get-LocalGroupMember -Group "Administrators"ここに自分のユーザー（例：AzureAD\[email protected]）やAzureAD\Device Administratorsが無いと、UAC に阻まれます。環境によって「AzureAD\」が「Microsoft Entra\」表記になる場合があります。 - MDM 同期の起動
［設定 > アカウント > 職場または学校にアクセスする > 情報 > 同期］、または Company Portal で［同期］。 - MDM 診断採取（必要に応じて）
mdmdiagnosticstool -area DeviceEnrollment;DeviceProvisioning;Autopilot -cab C:\Temp\MDM.cab
解決策（推奨順）：Intune でローカル管理者を明示的に配布する
二度と迷わない鉄板は、Intune の「ローカル ユーザー グループ メンバーシップ」機能で Administrators グループに必要なユーザー/グループをポリシーとして配布することです。これにより、端末が同期さえすれば確実にローカル管理者が構成されます。
方法 A：エンドポイント セキュリティ > アカウント保護 > ローカル ユーザー グループ メンバーシップ
- Intune 管理センターで、エンドポイント セキュリティ > アカウント保護 > ローカル ユーザー グループ メンバーシップ を開き、新しいポリシーを作成。
- 対象グループは「Windows 11/10 企業端末」のみを含む動的デバイス グループを推奨。検証リング（パイロット/広範/全社）を分けます。
- グループ Administrators の設定で、追加（Add）に管理したいユーザー/グループ（例：IT 管理部の Entra グループ、または緊急用ローカル ユーザー）を指定。
- 割り当て範囲（スコープタグ）や適用優先度を整えて保存。端末側で同期が走ると数分〜十数分で反映。
反映確認コマンド
Get-LocalGroupMember -Group "Administrators"
whoami /groups | findstr /i "S-1-5-32-544"Administrators（SID: S-1-5-32-544）に自身（もしくは所属グループ）が含まれていれば、次回 UAC では「はい」ボタンで昇格できます。
よくあるつまずき
- ユーザー指定のフォーマット違い：
[email protected]（UPN）で指定するのが安全。Display Name だけの指定は避ける。 - 競合ポリシー：別ポリシーやスクリプトが Administrators を置換（Replace）していると上書きされる。追加（Add）で運用するか、意図を明確に。
- 端末未同期：Company Portal から明示同期、または
dsregcmd /refreshprtで PRT 更新後に再同期。
方法 B：テナントの「Device Administrators」で一括付与
Entra 管理センターの デバイス設定（Additional local administrators on Azure AD joined devices） に、テナント共通のローカル管理者グループを定義しておくと、すべての Entra 参加デバイスに反映できます。少人数の運用者を全社でローカル管理者にする用途に有効です。個別制御が必要な場合は方法 A を優先してください。
方法 C：Autopilot で「初回ユーザーは標準 or 管理者」を明示
新規導入・再展開時は、Autopilot 配置プロファイルのユーザー アカウント種別を標準（推奨）または管理者に設定します。標準にする場合でも、方法 A/B のどちらかで「操作が必要な人だけ昇格」できる設計にしておくと、セキュリティと運用の両立が図れます。
方法 D（暫定）：スクリプトでローカル管理者に追加
緊急対応として、該当端末に一時的に適用するスクリプトで追加する方法です（恒久策では必ず方法 A/B に移行）。
# PowerShell（管理者で実行）
$upn = "[email protected]" # 付与したいユーザー
Add-LocalGroupMember -Group "Administrators" -Member ("AzureAD\" + $upn)
# 環境により "Microsoft Entra\" プレフィックス表記になる場合ありIntune の「デバイス > スクリプト」で SYSTEM コンテキスト実行にすれば、端末側の管理者権限が無くても適用できます（ただし配布・検知の制御が難しいため暫定限定）。
操作不能になったときのリカバリー
すでに誰もローカル管理者でない場合、次の順で低侵襲から検討します。
- Intune リモート操作
- 同期の強制／ポリシー再適用で復帰するケースがあります。
- 状況に応じて Autopilot リセットや ワイプ（必要なら「登録情報とユーザーを保持」／保持しない）を実行し、再展開でローカル管理者を正しく構成。
- 回復 USB で初期化
Windows 回復ドライブから初期化後、Autopilot（事前登録）もしくは手動 Entra 参加。初回サインイン時点でローカル管理者付与の設計（方法 A/B/C）を満たすようにプロファイル／ポリシーを整備してから着手します。 - プロビジョニング パッケージ（PPKG）
プロビジョニングでローカル管理者の作成／参加設定を含め、オフラインで復旧するシナリオも有効です。現場に USB 配布し、最小限のタッチで戻せます。
再発防止：最小権限と緊急手段を両立
- 標準ユーザーが原則：常時ローカル管理者は不要。必要作業のみ昇格させる。
- Intune Endpoint Privilege Management（EPM）：標準ユーザーのまま、特定のセットアップ／実行ファイルだけ昇格ルールで許可。現場の「都度管理者パスワード」要求を無くす切り札です。
- クラウド版 LAPS（Windows LAPS）：ビルトイン Administrator のパスワードを端末ごとに強力な乱数でローテーションし、必要時だけ参照。Break‑Glass用途として必携。
- Device Administrators の最小化：全社ローカル管理者に含めるのは最小人数に限定。監査と期限管理を。
- アプリは Intune で配布：Microsoft 365 Apps、WinGet/LOB/MSI を SYSTEM コンテキストで配布すれば、ユーザーがローカル管理者でなくても自動導入できます。
- ブレークグラス（緊急用）アカウント：条件付きアクセスの影響外に置き、多要素・保管・定期サインイン試験を徹底。
配布手段の比較
| 手段 | 適用範囲 | 反映速度 | 運用のしやすさ | 主な用途 |
|---|---|---|---|---|
| ローカル ユーザー グループ メンバーシップ（Intune） | デバイス グループ単位 | 数分〜十数分 | 高（ポリシーで一元管理） | 部門や役割ごとのローカル管理者付与 |
| Device Administrators（テナント設定） | 全 AADJ 端末 | 設定後継続 | 中（粒度は粗い） | 少数のコア管理者を全社で昇格 |
| Autopilot（ユーザー標準/管理者） | 新規／再展開端末 | 初回セットアップ時 | 高（設計が鍵） | 初期体験の標準化と誤設定防止 |
| スクリプト（暫定） | 個別端末 | 即時 | 低（管理が煩雑） | 緊急時のみ |
アプリ配布は「ユーザーに管理者を渡さない」設計で
「Office を入れたいからローカル管理者が必要」という誤解がよくあります。正しくは、Intune のアプリ配布を使い、SYSTEM 権限で静かに展開するのがベストです。
- Microsoft 365 Apps：アプリ種別「Microsoft 365 Apps（Windows）」を選び、チャンネルやアプリ構成を指定して割り当て。
- WinGet アプリ：Windows アプリ（WinGet）で一般的なツールを配布。検出ルールやバージョン固定で再現性を確保。
- MSI/EXE/ストア アプリ：必要に応じて LOB アプリや新 Microsoft Store 連携も活用。
この設計にすると、ユーザーは標準のままでも必要なアプリが自動で届き、「昇格が必要」ダイアログ自体が出ません。
FAQ：よくある質問と落とし穴
Q. Entra で Global Admin を付けたのに管理者にならないのはなぜ？
A. クラウド ロールはあくまでクラウドの操作権です。ローカル Administrators は別に管理されます。テナントの Device Administrators や Intune のローカルグループ ポリシーで明示的に付与してください。
Q. 初回サインインしたユーザーが自動でローカル管理者になるのでは？
A. Autopilot のプロファイルやテナント設定次第です。標準ユーザー運用が推奨されるため、初回から管理者にしない設計（＋必要者のみ昇格）を選ぶ組織が増えています。
Q. どうしても今すぐ 1 台だけ管理者化したい。
A. Intune スクリプトで Add-LocalGroupMember を SYSTEM 実行する暫定策はあります。ただし恒久策としてポリシー化（方法 A/B）に必ず移行してください。
Q. 「AzureAD\」と「Microsoft Entra\」の表記が端末ごとに違う。
A. OS バージョンやロケールで見え方が異なります。実体は同じ ID プロバイダーです。グループ/ユーザー指定は UPN（[email protected]）を基本にしましょう。
Q. 権限を配ったのに UAC でユーザー名/パスワード入力を求められる。
A. 反映前の可能性があります。サインアウト/サインイン、gpupdate /force（ハイブリッドの場合）、MDM 同期、whoami /groups で所属を再確認してください。
検証・運用チェックリスト（配布前に 30 分で確認）
| 項目 | 合格基準 | 確認方法 |
|---|---|---|
| デバイス参加状態 | AzureAdJoined: YES / Managed: YES | dsregcmd /status |
| Administrators メンバー | 対象ユーザー/グループが含まれる | Get-LocalGroupMember -Group Administrators |
| UAC 動作 | 「はい」ボタンで昇格できる（資格情報要求ではない） | 管理者での PowerShell 起動を試す |
| アプリ配布 | Intune の割り当てで自動導入 | Company Portal／Intune レポート |
| 緊急復旧手段 | LAPS/回復 USB/ブレークグラスが運用可能 | 手順書と保管場所の点検 |
付録：トラブルシューティングで役立つコマンド集
:: Entra 参加/PRT/MDM 状態
dsregcmd /status
:: ローカル管理者の一覧
net localgroup administrators
powershell -NoP -C "Get-LocalGroupMember -Group 'Administrators'"
:: 自分の所属グループ（Administrators の SID は S-1-5-32-544）
whoami /groups | findstr /i 544
:: MDM 同期
powershell -NoP -C "(Get-ScheduledTask -TaskName 'PushLaunch' -TaskPath '\Microsoft\Windows\EnterpriseMgmt').Count"
# Company Portal または 設定 > 職場または学校 > 情報 > 同期 でも可
:: MDM 診断
mdmdiagnosticstool -area MDM -cab C:\Temp\mdm.cab
:: 一時的にユーザーをローカル管理者へ（暫定）
powershell -NoP -C "Add-LocalGroupMember -Group 'Administrators' -Member ('AzureAD' + '[[email protected]](mailto:[email protected])')"まとめ：ローカル管理者は「配る」のではなく「設計する」
「要求された操作には昇格が必要です」は、設計次第で根本から消せます。ポイントは次の 3 つです。
- ローカル権限はクラウド ロールとは別。Intune/Device Administrators/Autopilot のいずれかで明示的に付与する。
- 標準ユーザー運用＋EPM＋Intune アプリ配布で、そもそも昇格ダイアログを見せない。
- LAPS とブレークグラスで「もしも」に備え、復旧手段を常に維持する。
これらをポリシーとして体系化すれば、移行直後のロックインも、日々の“管理者ください問題”も終わります。端末は管理でなく設計で安定させましょう。
参考テンプレート：ポリシー配布の運用フロー
- 設計：役割（ヘルプデスク／現場責任者／IT 管理）ごとのローカル管理者要否を定義。
- グルーピング：動的グループで端末を「パイロット／広範／全社」の 3 リングに分類。
- 方法 A を実装：ローカル ユーザー グループ メンバーシップで Administrators に対象グループを追加。
- 方法 B を実装：Device Administrators にコア管理者だけを追加。
- EPM ルール：インストーラーや設定ツールごとに昇格許可ルールを定義。
- アプリ配布：Microsoft 365 Apps／業務アプリを SYSTEM で配布。
- LAPS/回復手順：緊急参照手順・保存場所をドリルで確認。
- 可観測性：失敗端末の検出（レポート/アラート）と自動再試行のタスクを用意。
ケーススタディ：移行一斉初期化で管理者が消えた
ある中堅企業では、Google Workspace から Microsoft 365 Business Standard へ段階移行する際、現場で初期化→手動 Entra 参加→ユーザー標準のまま運用を開始した結果、アプリ導入や VPN 設定で詰まり、IT へ「管理者パスワードください」コールが殺到しました。
対策として、（1）Intune の「ローカル ユーザー グループ メンバーシップ」で現場責任者のみ Administrators に追加、（2）EPM で業務インストーラーの昇格を許可、（3）アプリは Intune で SYSTEM 配布、（4）LAPS を全端末に展開。以後 UAC トラブルが激減し、ヘルプデスクの問い合わせは 70% 以上削減されました。
最後に：実装チェックポイント（抜け漏れ防止）
- Administrators の構成はポリシーで再現可能になっているか。
- 「ローカル管理者＝常時」ではなく、「必要時のみ昇格」になっているか。
- アプリは「ユーザーが入れる」のではなく「自動で届く」ようにしたか。
- LAPS／Break‑Glass／回復 USB の保管と定期演習をしているか。
- 退職・異動時のローカル管理者からの自動除外が設計に含まれているか（動的グループ＋ライフサイクル）。
コメント