LoginSignup
3
2
@shokolate(Shoko Shikata)

【雑記】Microsoft Entra joined 端末の管理者権限をユーザーから剝奪する方法

Last updated at Posted at 2024-02-26

「Windows デバイスのローカル管理者権限はエンドユーザーに渡したくない」と言ったこと/言われたことはありますか？
「現行環境でセキュリティ施策として権限剝奪を実施しており、Intune 導入後も継続したい」や、「なんかセキュリティ施策として良いと聞く」といった理由で、Entra join した Intune managed devices でこれをやりたい！ ということは私もよく聞きます。

この希望に対し、どう実現するか。
方法は何パターンかありますが、以下の順で検討を進めると割とスムーズに取捨選択ができます。

  • 現行のデバイス運用を踏まえて Microsoft Entra join 方法を決める
  • 採択した join 方法にて利用可能な管理者権限剥奪方法を検討する！

本記事では、よくある Entra join 方法と、よくある権限剝奪方法についてまとめます！

Microsoft Entra join 方法

基本的に、Windows Autopilot を利用しない場合、エンドユーザーは自身のアカウントを使って Entra join したデバイスのローカル管理者権限を持ちます。

よく使われる1 Entra join の方法としては、以下があります。
(Entra hybrid join や co-management で利用可能な方法は割愛します。)

# 利用方法 概要 操作主 操作ステップ ローカル管理者権限
1 Windows Autopilot 事前にハッシュ情報が Windows Autopilot サービスに登録されたデバイスにて、初回起動画面 (OOBE, Out of Box Experience) の組織のサインインページにて、組織のアカウントでサインインする エンドユーザー User-driven Microsoft Entra join: Deploy the device Autopilot の構成により、エンドユーザーアカウントの権限レベル (標準 or 管理者) を選択可能
2 Windows セットアップ 工場出荷直後の初回起動画面 (OOBE) のマイクロソフトアカウントサインイン画面にて、組織のアカウントでサインインする エンドユーザー または 管理者 (DEM2アカウント利用時) Microsoft Entra join a new Windows device during the out of box experience セットアップを実施したアカウント (エンドユーザーまたはDEM2) がローカル管理者権限を持つ
3 Windows 設定アプリ Windowsを起動し、ローカルアカウント 3 でサインインした後に「設定」アプリを起動し、[アカウント] > [職場または学校にアクセスする] > [接続] より組織のアカウントでサインインする エンドユーザー または 管理者 (DEM2アカウント利用時) 仕事用デバイスを仕事用ネットワークまたは学校ネットワークに参加する > [既に構成されているデバイスをWindows 10するには] 接続を実施したアカウント (エンドユーザーまたはDEM2) がローカル管理者権限を持つ

Windows Autopilot を利用していない組織では、上表の #2 または #3 を採用することになります。
また、多くの企業環境では社給デバイスを事前にキッティングする (マスタや手動含む、Intune以外の方法でデバイスの初期設定を適用する) ため、その場合は #3 を採用することになります。
すると、セットアップ/接続を実施したエンドユーザーがローカル管理者権限を持つ挙動となるため、冒頭の要件を実現するには工夫が必要になります。

2024年 6月 27日追記：
当記事の記載内容には古い情報が含まれます。
現在、Entra ID にてプレビュー中の以下設定を使うと、Entra join を実施したユーザーがローカル管理者権限を持つデフォルト挙動を制御することができるそうです。

  • 該当設定名：登録するユーザーは、Microsoft Entra 参加の間にそのデバイス上のローカル管理者として追加されます (プレビュー)
    Registering user is added as local administrator on the device during Microsoft Entra join (Preview)
    image.png

(参考：Limit local administrators on Microsoft Entra joined devices)

なお、2024年 6月にリリースされた新しい Autopilot ソリューションである、Windows Autopilot デバイスの準備 を利用されている場合、当該 Entra ID 設定に関わる既知の事象があるためご注意ください。(2024年 6月時点。)

管理者権限を剝奪する方法

「Intune 利用環境でエンドユーザーに端末ロール管理者権限を持たせない方法はあるか？」と Microsoft Intune サポートに問い合わせた (2023年9月) ところ、#1, #2の方法があるとのことでした。
また、現場事例ベースだと #3 の方法をとっている企業様もいらっしゃいます。
そして、開発 (#4) ができると可能性は無限大です。
(すみません、尺の関係で開発物の具体例は今回割愛します。別途記事にできたら、と思います。)

# 方法 概要 備考
1 Windows Autopilot の Deployment プロファイル Windows Autopilot でプロビジョニングされるデバイスにサインインするユーザーの権限 (標準 or 管理者) を定義できるプロファイル Autopilot でデバイス プロビジョニングすることが利用前提となる。
2 Microsoft Intune のローカル ユーザー グループ メンバーシップ プロファイル Windows デバイス上のローカル グループのメンバーを追加、削除、または置換できるプロファイル 払い出し済みで、これから Entra join・Intune 登録する端末でも利用可能。
3 運用でまきとる 登録専用アカウントを使用しデバイス登録する。デバイス登録後にプライマリユーザーをエンドユーザーアカウントに変更する。 登録専用アカウントがローカル管理者権限を持つ。エンドユーザーアカウントは標準権限 (管理者権限を持たない)。新規端末払い出し時に使われる方法。
4 開発する Intune 登録済みデバイスの環境を探索して、エンドユーザーから権限をはく奪できるようなスクリプトを開発する。 管理者が作成したスクリプトは、「スクリプト」「アプリ」「修復」いずれかのIntune機能を使って展開が可能。なお、スクリプト内の処理内容に関しては Microsoft サポートを受けられない。

前述の Entra join 方法と各剝奪方法の特徴を踏まえて考えると、各 join 方法で利用可能な権限剝奪方法は以下のような分布図になります。

▼join方法 / 剥奪方法▶ #1 Autopilot #2 プロファイル #3 運用 #4 開発
#1 Autopilot ◎ △ × ○
#2 セットアップ × △ ○ ○
#3 設定アプリ × △ ○ ○

(凡例 ◎: 最適！、○: 使える、△: いまいち、×: 仕様上利用不可)

2024年 6月 27日追記 (再掲)：
当記事の記載内容には古い情報が含まれます。
現在、Entra ID にてプレビュー中の以下設定を使うと、Entra join を実施したユーザーがローカル管理者権限を持つデフォルト挙動を制御することができるそうです。

  • 該当設定名：登録するユーザーは、Microsoft Entra 参加の間にそのデバイス上のローカル管理者として追加されます (プレビュー)
    Registering user is added as local administrator on the device during Microsoft Entra join (Preview)
    image.png

(参考：Limit local administrators on Microsoft Entra joined devices)

なお、2024年 6月にリリースされた新しい Autopilot ソリューションである、Windows Autopilot デバイスの準備 を利用されている場合、当該 Entra ID 設定に関わる既知の事象があるためご注意ください。(2024年 6月時点。)

各剝奪方法の特徴

1. Windows Autopilot の Deployment プロファイル

参考： Configure Autopilot profiles

Windows Autopilot によるデバイスプロビジョニングの契機となる、デプロイプロファイル4にて、プライマリユーザーの権限を標準 or 管理者にするか、定義することができます。

  • 本方法のメリット： ユーザーに一度も管理者権限を付与することなくデバイスをプロビジョニングすることができる！
  • 本方法のデメリット：
    • Windows Autopilot の機能であるため、Windows Autopilot を導入せず Intune のみ導入・利用している環境では利用できない。
    • ユーザーに一度も管理者権限が付与されないため、一旦付与してから剝奪したい組織には不適。(実際過去にこういう要望もありました。)

設定場所は以下です。

  • ポータルパス5： Microsoft Intune 管理センター (intune.microsoft.com) > [デバイス] > [登録] > [デプロイ プロファイル]
    image.png

2. Microsoft Intune のローカル ユーザー グループ メンバーシップ プロファイル

参考：

2022年に登場した、新しめの機能です。
本プロファイルを使うと、Windows デバイス上のローカル グループのメンバーを構成 (追加/削除/置換) することができます。
メンバーはユーザー単位、グループ単位どちらも指定できます。
ただし、今回の要望実現方式としてはメリットよりも圧倒的デメリットによりほとんどの組織で実質利用できないと思います。

  • 本方法のメリット： Intune ネイティブのポリシー機能である
    • Windows Autopilot 未導入環境でも利用できる。
    • Microsoft Intune サポートからのサポートを受けることができる。
    • 開発不要で利用できる。
    • 1 ローカルグループ：1 ユーザー：ターゲットデバイス 単位の細かい制御が可能
      • 従来、Microsoft Entra join (旧称 Azure AD join) した端末のローカル管理者権限はグローバル管理者またはデバイス管理者が持つが、どちらもテナント全体の権限となり、テナントに参加したすべてのデバイスのローカル管理者となる強い権限だった。本機能を使うと、ターゲットを限定して、最小範囲で最小権限を付与することができる。
  • 本方法のデメリット： Entra join によって付与された管理者権限のはく奪には適さない (圧倒的運用負荷)
    • 今回のような場合、メンバー (ユーザー) とターゲット (デバイス) を 1:1 にしたポリシーを作成する必要がある。(つまり、デバイス毎にポリシーを作成する必要がある。)　
      • ローカルグループ：Administrators
      • 操作：削除
      • メンバー：デバイスによってAdministratorsグループから削除したいメンバーが異なる
      • ターゲット：複数デバイス

例えば、1000台管理端末のある環境では、本ポリシーでローカル管理者権限をエンドユーザーから剥奪するには、各デバイスに対応した計1000個のポリシーを作成する必要があります。とても現実的ではなく運用できないため、この目的でこのポリシーを使うのは不適と言わざるを得ません。

なお、メリット欄に記載したように、グローバル管理者やデバイス管理者権限の代替として数台単位でローカル管理者を追加したい場合の利用には適しています。

  • ポータルパス4： Microsoft Intune 管理センター (intune.microsoft.com) > [エンドポイントセキュリティ] > [アカウント保護]

image.png

3. 運用でまきとる (登録専用アカウント利用 + プライマリユーザーの変更)

参考：

Device Enrollment Manager (DEM2) アカウントを使ってデバイスを登録する方法です。
以下のステップでデバイスが利用可能になります。

  • 利用ステップ：
    • DEM アカウントでデバイスを Entra join する (自動的にIntuneに登録される)
    • Intuneに登録されたデバイスのプライマリユーザーとして、エンドユーザーのアカウントを設定する (エンドユーザーアカウントは端末のローカル管理者権限を持たない)
    • デバイスをユーザーに払い出す
    • ユーザーが自身の Entra ID でデバイスにサインインし、利用する

本記事で前提としているユーザー アフィニティありの使い方 (ユーザー:デバイス=1:1 の使い方) では、プライマリユーザーの変更はマストになります。
(ユーザー アフィニティありの利用シナリオでは、プライマリユーザーを設定することが想定された利用方法であり、設定しないとサポートが受けられません。)

  • 本方法のメリット：
    • エンドユーザーに一度も管理者権限を持たせないことが可能。
    • 管理者操作により Entra join, Intune 自動登録を行うため、デバイス登録に関わるユーザー操作が不要。
  • 本方法のデメリット： 主に運用負荷。
    • ユーザーに一度も管理者権限が付与されないため、一旦付与してから剝奪したい組織には不適。
    • 管理者がデバイスを Entra join する必要がある。
    • 登録専用アカウント自体にIntuneライセンスを付与する必要があり、その分ライセンスを1消費する。
    • デバイスとプライマリユーザーを 1:1 で対にして設定する必要がある。
      • 現在 Intune の標準機能範囲では、プライマリユーザーの設定は１台ずつのみ可能。(複数デバイスに対し一括操作することはできない。)
      • Graph API を使うと、スクリプトを1回実行する毎に複数デバイス分プライマリユーザーを設定することが可能だが、スクリプトに参照させるCSV上にてデバイスとプライマリユーザーを 1:1 で対にして設定する必要がある。 (結局煩雑)

十台前後の規模の環境 (そもそも組織規模が小~中程度である、試験的にEntra join端末を利用している、PoC中である、など) だと、登録上限 (一般ユーザーは15台まで) に引っかからないことから、登録専用アカウントにDEM権限を振らずに使う、ということも可能ではあります。
ただその場合も、ユーザー アフィニティありのデバイス運用を行うのであれば、デバイス登録後のプライマリユーザー変更作業は必要になります。

なお、DEMアカウントにはIntuneライセンスが必要です。(ユーザーライセンスでOK)
デバイス登録時は、DEMアカウントについたユーザーライセンスでIntune登録でき、その後プライマリユーザー変更後は各ユーザーについたライセンスでIntune利用ができます。

4. 開発

Intune には、奥の手として、管理者が自力で作成したものを展開できる機能があります。

# 機能名 展開可能ファイル拡張子 公開情報 概要
1 スクリプト .ps1 Use PowerShell scripts on Windows 10/11 devices in Intune 1時間周期で端末上の Intune Management Extension (IME) エージェントが割り当て有無をポールし、割り当てがあれば実行する。(実行タイミングの細かい制御はできない。) 基本的に1度実行に成功するとその後は再実行されない。(失敗時はリトライロジックあり。)
2 Win32 アプリ .intunewin Win32 app management in Microsoft Intune Intune上に配置可能な拡張子は「.intunewin」のみだが、ほとんどどのような実行モジュールも intunewin にラッピングすれば実行が可能。(よく使うのは exe や bat, ps1, vbs, msi, reg など。）1時間周期で端末上の IME エージェントがアプリポール、処理する。
3 修復 (旧称：プロアクティブな修復) .ps1 Remediations 検出スクリプトと修復スクリプトのペア、または検出スクリプトのみで登録が可能。管理者が選択したタイミング (X日ごとにX時、毎X時間ごと、１回だけ) で端末上で IME エージェントが実行する。

上記3つすべて Windows 端末側では Intune Management Extension (IME) エージェントがポール・実行します。IME はかなり綿密な処理ログを残してくれるため、慣れると設計しやすいです。

基本的に、管理者がカスタムで用意する処理内では以下のことに注意が必要です。

  • サイレントで実行できること
  • スクリプト内で再起動をキックしないこと

語りだすとこの話題でこの記事を乗っ取ってしまうくらい長くなるので、今回はこの程度で。。
Intune で開発！というと、Intune 導入プロジェクトの基本設計～詳細段階ではこうしたデバイスの処理の開発が発生し、運用設計段階で要望があれば Graph API を使った管理業務の自動化を考えることになります。
開発自体行わないプロジェクトも多いですが、結構楽しいので、枠組みがしっかりしており泥沼化しない砂場であれば要望に応じて開発するのもいいと私は思います。

その後私も開発してみましたが、すかんく先生の記事が大いに参考になりました。
また、現在「修復」機能は出力された文字列を管理ポータルに表示することもできるので、そういったところもカスタムできる楽しさがありました。

なお「プロアクティブな修復」は、現在「修復」に改名されています。Microsoft Intune サポートに確認したところ、現在はエンドポイント分析の一部機能という扱いではなく、エンドポイント分析へのオンボードも不要で「修復」の利用が開始できるとのことです。

さいごに

本記事では、現場ではよく聞く「Windows のローカル管理者権限をユーザーに付与したくない」要望に対する、実現方法についてまとめてみました。

こうしてみると、やはり Windows Autopilot の deployment プロファイルで権限を付与しないことが一番楽なように思えます。
ただ、Autopilot を使わない環境でも方法がないわけではないです。
なお今回のこの記事では Intune で可能な方法に絞ってまとめましたが、過去には Intune 以外のツールで権限剝奪を実施されていたお客様もいらっしゃいました。

なお物理から離れてクラウド PC に目を向けると、Windows 365 は「ユーザー設定」コンソールでローカル管理者権限を付与する/しない を構成できるようです。
(参考：Windows 365 Enterprise docs - User settings)

余談ですが、プリンタドライバなど、ユーザーに管理者権限がないとインストールできない業務アプリもあります。
これまでは、セキュリティ (管理者権限剥奪) をとるか、生産性 (ユーザーセルフサービスで管理権限を使う業務を行う) をとるか、トレードオフの関係にありました。
それが、Intune では Endpoint Privilege Management (EPM) 機能 (単体追加ライセンスまたはIntune Suite アドオンライセンスが必要、2023年4月GA) の登場により、セキュリティも生産性もいいとこどりできるようになりました。
EPM を使うと、標準権限のユーザーが特定のアプリを実行する時に限定して一時的に管理者権限を付与できます。
(参考：Use Endpoint Privilege Management with Microsoft Intune)

ユーザーに管理者権限を付与しない、というセキュリティポリシーの考え方は Intune 以前からあり、多くの組織で実施されています。
残念ながら、今ある Entra join 方法ではエンドユーザーに管理者権限を付与してしまうものがありますが、もしかするとこれも今後変わるかも可能性もあります！ (Who knows!)
その日が来るまでは、プロファイル/運用/開発などでの対応、がんばりましょう☆

2024年 6月 27日追記 (再掲)：
当記事の記載内容には古い情報が含まれます。
現在、Entra ID にてプレビュー中の以下設定を使うと、Entra join を実施したユーザーがローカル管理者権限を持つデフォルト挙動を制御することができるそうです。

  • 該当設定名：登録するユーザーは、Microsoft Entra 参加の間にそのデバイス上のローカル管理者として追加されます (プレビュー)
    Registering user is added as local administrator on the device during Microsoft Entra join (Preview)
    image.png

(参考：Limit local administrators on Microsoft Entra joined devices)

なお、2024年 6月にリリースされた新しい Autopilot ソリューションである、Windows Autopilot デバイスの準備 を利用されている場合、当該 Entra ID 設定に関わる既知の事象があるためご注意ください。(2024年 6月時点。)

  1. プロビジョニングパッケージの記載説明を割愛したことについてここで懺悔します。Microsoft Intune サポートによると、プロビジョニングパッケージを使ってEntra join・Intune登録されたデバイスはプライマリユーザーが空欄になり「共有デバイス」扱いになるそうです。個々人のユーザーに払い出して個人と紐づく利用をしたい場合は、各デバイスのプライマリユーザーとして各エンドユーザーアカウントを設定する運用が必要になるそうです。 ↩

  2. Device Enrollment Manager Account (デバイス登録マネージャーアカウント)、略してDEMアカウントです。DEMアカウントとは、Intuneにデバイスを一括登録する権限を持つ特別なアカウントです。Entra ID 上でユーザーアカウントを作成し、Intune 管理センター上でDEM権限を付与して作成します。DEMアカウントはIntuneのデバイス上限設定の上限を超えて、1アカウントにつき1,000台まで端末を登録できます。DEMアカウントで登録されたデバイスは「共有デバイス」扱いとなり、個々人のユーザーに払い出して個人と紐づく利用をしたい場合は、各デバイスのプライマリユーザーとして各エンドユーザーアカウントを設定する運用が必要です。(参考：Add device enrollment managers) ↩ ↩2 ↩3 ↩4 ↩5

  3. 接続を実施する際のローカルアカウント自体に、ローカル管理者権限が必要！ ↩

  4. その他のポリシー・プロファイル (コンプライアンスポリシー、構成プロファイルやアプリ) の適用は任意だが、デプロイプロファイルの適用は Autopilot 利用において必須。 ↩ ↩2

  5. 当方のテナントでは、先日デバイスノードのプレビュー表示をオンにしました。プレビュー有効化以前は、該当設定ペイン名称は「登録」ではなく「デバイスの登録」だったと思います。プレビュー表示後、「構成プロファイル」が「構成」になったり、「スクリプト」と「修復」が合体して「スクリプトと修復」になったりマイナーチェンジが結構ありました。今後もこういった変更がありそうなため、すみませんがポータルパスはフィーリングでご参考にしてください。 ↩

3
2
1

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
3
2