SaaS

Microsoft Intune のプロアクティブな修復で Windows デバイスに一時的なローカル管理者権限を付与する

はじめに

こんにちは、すかんくです。今回は Microsoft Endpoint Manager（以下 MEM）で作ってみたコンテンツを共有してみる回です。

Windows を Azure AD Join させた上で MEM 管理される際、多くいただくリクエストとして「Windows のローカル管理者権限を、エンドユーザーに一時的に付与したい」というものがあるので、これを解決する方法について検討・実装してみました。

※冒頭は検討背景や実装方法の検討に関しての話になるため、実装部分が気になるという方は [作成手順] や [動作確認] の章までスキップしてください。

本番利用に関しての注意

本記事で記載する内容に関しては、本機能は検証目的で作成したものであり本番環境での運用を想定しておりません。

もし展開される場合には、社内にて十分な検証と修正を重ねた上で、慎重なご判断をいただければと思います。

検討の背景

検討に至った背景として、このようなお話を伺うことが多くあります。

現状 Windows デバイスにはエンドユーザーのローカル管理者（Administrators）権限を付与している。
本来は標準ユーザー（Users）権限としたいが、業務の中で管理者権限が必要となる可能性を排除しきれず、踏み出せていない。

何かしらの理由で、上記のような状況から権限回収に踏み出す必要性が出てきた場合、どのように進めるのが良いでしょうか？というのが検討のきっかけになります。

個人的な回答としては、各事業部・職種から一部のエンドユーザーにご協力いただき、少しずつ影響度の確認範囲を広めていく取り組みが必要になるかと思います。
※業務フロー等の既存資産を活用すれば、確認範囲の限定が可能かもしれませんが、組織環境次第なところがあるため検討外とします。

この場合、エンドユーザーから「協力するのは構わないが、業務が停止してしまう事態も避けたい」という要望が出ることは容易に想像できます。

つまり 情報システム管理者としては、「一時的に標準ユーザーから管理者権限に昇格できる仕組みが欲しい」ということになり、「これを MEM で実現可能か？」という流れで今回の検討に至りました。

補足

「ローカル管理者が必要な業務を特定した結果を基に、対処方針を検討する」が後続タスクとして存在することを補足しておきます。
特定業務だけを別デバイスへ切り出すのか、特定ユーザーだけはローカル管理者権限の付与が必要とするのか、判断は様々だと思います。理由付けとリスク把握・対策さえ明確であればどのような判断も尊重されるものだと考えます。

ここで記載しておきたいのは、一時的にローカル管理者権限を付与する仕組みというのは永続的に利用するものではない、ということになります。

実現方針の検討

MEM や Azure AD では、幾つかの方法で Azure AD Join した Windows デバイスのローカル管理者権限をコントロールすることが出来ます。検討機能と採用可否、その理由を含めご紹介します。

Intune – アカウント保護

MEM 管理センターの [エンドポイント セキュリティ] > [アカウント保護] から、Azure AD に存在するユーザー/グループを指定して Windows デバイス上の管理者として指定することが可能です。

本機能を “デバイス単位” でポリシー化・メンバーアサインの運用を行うことで、”一時的にローカル管理者権限” を付与することは可能です。
しかし、運用的な負荷やポリシーの同期までに時間が掛かるという欠点があり、本案は採用を見送っています。

補足：本機能を用いずに CSP でのカスタム構成プロファイル展開も可能です。

LocalUsersAndGroups ポリシー CSP – Windows Client Management
ポリシー CSP の LocalUsersAndGroups 領域の詳細を確認します。
learn.microsoft.com

Azure AD – デバイス管理者ロール

Azure AD にてグローバル管理者 及び デバイス管理者ロールを付与されているユーザーは、Azure AD Join した全てのデバイスに対してローカル管理者権限が付与されます。

一見良さそうに感じるのですが、エンドユーザーが自身が利用するデバイス以外にもローカル管理者の権限を持つことになります。
標準ユーザーでの業務に問題が発生した際のみ利用する想定とはいえ、これではローカル管理者を持つ範囲が逆に広まってしまうため、本案についても見送りました。

ローカルコマンド – net localgroup

MEM / Azure AD の標準機能では実現が難しいことが判明したため、コマンド実行での管理を検討しました。
調べると、net localgroup コマンドにより、通常の Azure AD ユーザーをローカルの Administrators グループに追加することが可能そうでした。

実行例：net localgroup administrators /add "AzureAD\<UserUpn>"

平時はローカル Users グループに割り当てて起き、緊急時には本コマンドを MEM から配布することで一時的に Administrators グループに追加するという仕組化が可能そうです。

Azure AD 参加済みデバイス上のローカル管理者を管理する方法 – Microsoft Entra
Windows デバイスのローカル管理者グループに Azure のロールを割り当てる方法について説明します。
learn.microsoft.com

実装方針の検討

ローカルコマンドにより、デバイスの Administrators グループから出し入れする方針が定まったので、実装方法を検討します。

今回の検討では、平時監視や運用負荷なども加味して以下の実装要件を定めました。

  • Administrators 権限を付与できること
  • 繰り返し権限を変更可能
  • 平時は Users 権限であることを監視可能
  • 運用時に API 等を用いた自動化が可能なこと

MEM によるコマンド実行

MEM のコマンド実行機能としては、主に以下の３つが利用できます。

  • PowerShell
    • .ps1 をアップロードして配布する機能。一度きりの実行。
  • Win32 アプリ
    • 専用パッケージを作成・配布する機能。アプリやコマンド等の様々な形式で配布が可能。
  • プロアクティブな修復
    • スクリプトによりデバイスの状態監視・修復する機能。定期実行機能が備わっている。

対応表

コマンド実行機能と今回の要件にける対応表は以下となります。
結論として、今回は [プロアクティブな修復] 機能を用いて実装することにしました。

要件PowerShellWin32 アプリプロアクティブ
な修復
Administrators 権限付与○○○
繰り返し権限を変更可能×○○
平時は Users 権限であることを監視可能××○
運用時に API 等を用いた自動化が可能なこと○○○
同期間隔
※サービス起動時を除く		８時間毎
※一度切りの実行		８時間毎最短１時間毎
※スケジュール設定次第

作成手順

以降では作成手順について記載します。

前提条件

今回利用する機能と、その前提条件を記載します。

  • エンドポイント分析（プロアクティブな修復の前提条件）
    • Azure AD Join / Hybrid Azure AD Join
    • Windows 10 ver 1903 以降
    • 2021 年 7 月以降の累積的な更新プログラムの適用
    • Windows 10/11 Enterprise E3 または E5 

詳細については、以下のドキュメントをご確認ください。

エンドポイント分析とは – Microsoft Endpoint Manager
エンドポイント分析の概要。
learn.microsoft.com
チュートリアル – プロアクティブな修復 – Microsoft Endpoint Manager
プロアクティブな修復を使用してユーザーを強化するためのチュートリアル
learn.microsoft.com

エンドポイント分析の展開

プロアクティブな修復を利用するには、まずエンドポイント分析機能の有効化とプロファイルの配布が必要となります。
既にプロファイル配布まで完了されている方は、[プロアクティブな修復パッケージの登録] までスキップしてください。

① MEM 管理センターで、[レポート] > [エンドポイント分析] をクリック。

② [開始] をクリック。（必要に応じて、収集スコープの変更が可能です。）

③ [設定] に移動し、[Intune データ収集ポリシー] が “接続済み” になっていることを確認します。

④ [デバイス] > [構成プロファイル] に移動し、[Intune データ収集ポリシー] が作成されていること・割り当てが適切であることを確認します。

以上で手順は完了です。
必要に応じて、デバイスにプロファイルが適用されたことを確認してください。

プロアクティブな修復パッケージの登録

今回は [Users 権限を監視するパッケージ] と [Administrators 権限を付与するパッケージ] の２つを作成し、専用のデバイスグループをリンクさせる形でメンバーにアサインします。

事前準備

① 後続の作業を開始する前に、テスト用の Azure AD グループをご準備ください。

② 今回は Teams の Incoming Webhook を用いて実行通知を飛ばすため、テスト用 チャネルに Incoming Webhook アプリを追加し、URI を取得しておきます。
※本作業は必須ではございません

③ 以下４つのスクリプトを、UTF-8 形式の .ps1 ファイルとして保存してください。

  • Users_Detect.ps1
try {
    $localAdministrators = net localgroup Administrators
    if ($localAdministrators -like "AzureAD\*"){
        Write-Host "Delete localAdministrator"
        exit 1
    }
    else {
        Write-Host "No problem"
        exit 0
    }
}
catch {
    $errMsg = $_.Exception.Message
    return $errMsg
    exit 1
}
  • Users_Remediation.ps1
    • 13 行目を [事前準備 ②] で取得した URI に書き換えます。
    • 通知が不要な方は、9~17 行目をコメントアウトしてください。
try {
    # delete localAdministorators
    $subKey = Get-Item -Path "Registry::HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CloudDomainJoin\JoinInfo"
    $guid = $subKey.GetSubKeyNames()
    $aadjInfo = Get-ItemProperty -Path "Registry::HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CloudDomainJoin\JoinInfo\$guid"
    $userEmail = $aadjInfo.userEmail
    net localgroup administrators /delete "AzureAD\$userEmail"
    
    # toast
    $win32Bios = Get-WMIObject -Class Win32_Bios
    $psComputername = $win32Bios.PSComputername
    $text = "Temporary administrator rights for user: $userEmail have been removed to device: $psComputername"
    $URI = 'Teams Incoming Webhook URI'
    $body = ConvertTo-JSON @{
        text  = $text
    }
    Invoke-RestMethod -uri $URI -Method Post -body $body -ContentType 'application/json'

    # exit
    Write-Host "Delete localAdministrators complete"
    exit 0
}
catch {
    $errMsg = $_.Exception.Message
    return $errMsg
    exit 1
}
  • Administrators_Detect.ps1
try {
    $localAdministrators = net localgroup Administrators
    if ($localAdministrators -like "AzureAD\*"){
        Write-Host "Already exists"
        exit 0
    }
    else {
        Write-Host "Add localAdministrator"
        exit 1
    }
}
catch {
    $errMsg = $_.Exception.Message
    return $errMsg
    exit 1
}
  • Administrators_Remediation.ps1
    • 13 行目を [事前準備 ②] で取得した URI に書き換えます。
    • 通知が不要な方は、9~17 行目をコメントアウトしてください。
try {
    # Add localAdministorators
    $subKey = Get-Item -Path "Registry::HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CloudDomainJoin\JoinInfo"
    $guid = $subKey.GetSubKeyNames()
    $aadjInfo = Get-ItemProperty -Path "Registry::HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CloudDomainJoin\JoinInfo\$guid"
    $userEmail = $aadjInfo.userEmail
    net localgroup administrators /add "AzureAD\$userEmail"
    
    # toast
    $win32Bios = Get-WMIObject -Class Win32_Bios
    $psComputername = $win32Bios.PSComputername
    $text = "Temporary administrator rights for user: $userEmail have been added to device: $psComputername"
    $URI = 'Teams Incoming Webhook URI'
    $body = ConvertTo-JSON @{
        text  = $text
    }
    Invoke-RestMethod -uri $URI -Method Post -body $body -ContentType 'application/json'

    # exit
    Write-Host "Add localAdministrators complete"
    exit 0
}
catch {
    $errMsg = $_.Exception.Message
    return $errMsg
    exit 1
}

Users 権限の監視用パッケージ

① [エンドポイント分析] > [プロアクティブな修復] に移動し、[+スクリプトパッケージの作成] をクリックします。

② 任意の [名前/説明/公開者] を記入し、[次へ] をクリックします。

③ 検出スクリプトファイルに [Users_Detect.ps1]を、修復スクリプトファイルに [Users_Remediation.ps1] をアップロードし、[次へ] をクリックします。

④ 必要に応じてスコープタグを設定します。（今回は割愛）
⑤ [組み込まれたグループ] にて [任意のグループ] を追加し、[スケジュール] を [毎時:1] に設定します。
⑥ [除外されたグループ] に [事前準備 ①] で作成したグループを追加し、[次へ] をクリックします。

割り当てについて

本番環境で実施される場合、いきなり [すべてのデバイス] を割り当てないでください。

追加のデバイスグループを作成いただき、最小限の影響範囲での動作確認を推奨いたします。

⑦ [作成] をクリックし、パッケージが作成されたことを確認します。

Administrators 昇格用パッケージ

① [エンドポイント分析] > [プロアクティブな修復] に移動し、[+スクリプトパッケージの作成] をクリックします。

② 任意の [名前/説明/公開者] を記入し、[次へ] をクリックします。

③ 検出スクリプトファイルに [Administrators_Detect.ps1]を、修復スクリプトファイルに [Administrators_Remediation.ps1] をアップロードし、[次へ] をクリックします。

④ 必要に応じてスコープタグを設定します。（今回は割愛）
⑤ [組み込まれたグループ] にて [事前準備 ①] で作成したグループを追加し、[スケジュール] を [毎時:1] に設定します。
⑥ [次へ] をクリックします。

⑦ [作成] をクリックし、パッケージが作成されたことを確認します。

以上で手順は完了です。

動作確認

続いて、動作確認を行います。

事前準備

プロファイルの適用確認

テストデバイスに対して、[Intune データ収集ポリシー] が適用されていることを確認してください。

デバイス確認

① [コンピューターの管理] > [ローカルユーザーとグループ] > [グループ] > [Administrators] を開きます。
② テストデバイスのローカル Administrators に、対象ユーザーが存在しないことを確認します。

テスト手順

① [プロアクティブな修復パッケージの登録 – 事前準備 ①] にて作成した、Azure AD セキュリティグループへテスト用デバイスを追加します。

② テストデバイスにパッケージが展開されるため、次のステップを参考に適用状況をご確認いただけます。

補足

デバイスをログインしたまま放置されるの場合、適用に最長１時間掛かります。
再起動を行うことで、サービスが再起動されるためパッシブに取得することが可能です。

実際のユーザー案内については、組織のユースケースによって異なると思いますので、動作確認の上でご検討ください。

適用状況の確認

テナント確認

① 作成したパッケージから、[デバイスの状態] へ移動します。
② [修復の状態] が “問題解決” となっていれば、ローカル Administrators の追加が完了しています。

デバイス確認

① [コンピューターの管理] > [ローカルユーザーとグループ] > [グループ] > [Administrators] を開きます。
② メンバーに対象の Azure AD ユーザーが存在することを確認します。

（オプション）Teams 通知の確認

① Teams Incoming Webhook の URI を追加いただいた方は、Teams 上でも実行状態を確認いただけます。

変更の適用

変更の適用が確認された後、デバイスに対して実際にローカル管理者権限を適用させるには再起動が必要となります。これは Windows 既定の動作であり、回避は不可となります。

次項 [今後の展望] にも記載しますが、エンドユーザーへの通知機能を実装するなど、ユーザー案内を機能化することで対応が可能であると考えています。

変更の削除

エンドユーザーにてローカル管理者権限が必要となる操作が完了した後、[プロアクティブな修復パッケージの登録 – 事前準備 ①] にて作成した、Azure AD セキュリティグループからテスト用デバイスを削除します。

これにより、ローカル Administrators グループに追加されたユーザーが、[Users 権限の監視用パッケージ] によって自動削除されます。

なお、[変更の適用] で記載した通り、本変更についてもデバイスの再起動が必要となります点にご注意ください。

今後の展望

もし今回作成した仕組みに関して、本気で展開することを考えると以下の要素が不足していると考えています。
今回のスクリプトを参考に自由に改修してみていただければと思います。

（Must）エンドユーザーのデバイスへ通知する機能
  • 実際には端末を再起動しなければ変更が適用されないため、現状の機能内ではユーザー案内が不足している
    • 適用が確認できた後に、ユーザーへデバイスを再起動するよう連絡が必要
    • Windows PowerShell でトースト通知の処理を追加する
    • 昇格機能については Win32 アプリとして配布し MEM 標準のトースト機能を利用する
    • Teams などのコミュニケーションツールへ通知する
（Must）標準ユーザーを追加する機能
  • 既にローカル管理者権限を持つ組織が “権限移行” に本機能を採用する場合は、現状のスクリプトでは不足がある
    • net localgroup で Users にメンバー追加する処理が必要
    • もしくは、Users にメンバー追加する用のパッケージを別途作成する
（Want）フロンドエンド周り（メンバーアサインの自動化）
  • 現状セキュリティグループにデバイスオブジェクトを追加する処理は手動で行う必要がある
    • Microsoft Graph API と自動化サービスを組み合わせメンバーアサインに関するタスクを自動化
    • 申請フローと組み合わせることで、有効期限の実装など
（Want）追加ユーザーの指定
  • 現状のパッケージでは [Administrators に追加されるユーザー = 登録作業を実施したユーザー] となっている。
    • 実際には、登録作業を実施した以外のユーザーでも指定可能だと尚よい

最後に

いかがだったでしょうか？

今回はプロアクティブな修復機能を用いて、Windows デバイスに一時的なローカル管理者権限を付与するための仕組みについて検討してみました。

プロアクティブな修復は、こういった定期タスク化や状態監視・修復処理にとても良い機能ですので、是非ご活用いただければと思います。

冒頭でも申し上げましたが、本機能は検証目的で作成したものであり本番環境での運用を想定しておりません。もし利用される場合には、十分に検証と修正を重ねていただけますと幸いです。

ではまた！

すかんく

2022/1 入社、Identity チームのすかんくと申します。
ブログでは IdP 関連の機能紹介を中心に記載していこうと思います。
好きな漫画はアイシールド21・ハイキュー・ベイビーステップです。

記事一覧