プロジェクトで Intune を担当していると、「ユーザーには、情シス部門が許可した端末だけ利用させたい！」という希望を聞くことがあります。
プラットフォームによっては Intune の機能範囲で対応することが難しいのですが、Entra ID の条件付きアクセス設定も組み合わせることでなんとか実現できました！
本記事では、実際にどのように構成したのか、テナント設定にフォーカスしてまとめます。
仮想要件
承認したデバイスに限定して利用許可したい希望の背景としては、「現行運用がそうだから」という理由をよく聞きます。
今回は、以下を仮想要件とします。
- 要件： 申請ベースで BYOD の登録・利用を許可する
- 背景： 現状の運用で基本的に申請ベースでデバイス利用許可をしており、次期 Microsoft 365 基盤でも同様の運用を継続したい
対象
直近であったプロジェクトでは Intune 管理対象プラットフォームが Windows, iOS/iPadOS, Android, macOS の 4 つありました。
-
社給端末： Windows 11
← Windows Server AD に参加するため、Entra hybarid join を行う -
BYOD： Windows 11, iOS/iPadOS, Android, macOS
← Entra register を行う
Hybrid join する社給の Win11 は制限無く、Register する各種プラットフォームのデバイスにおいて申請ベースの運用をすることを要件とします。
ちなみに、BYOD の iOS/iPadOS, Android の場合、データ保護観点のみが機能要件であれば、MAM のみ (アプリ保護ポリシーのみ) 利用する管理形態も可能です。
データ保護以外の観点で一部OSに対する制御も実装したいといった機能要件があれば、MDM 登録して管理する形態が採用されます。
実現方法
調査 > 検証 > 検討し、最終的に2つの方法で実現しました。
Intune では機能によってサポートするプラットフォームに差異があり、今回もその制約によりプラットフォームによって採用方式を分けることにしました。
- 【Intune】登録制限と業務デバイスのIDを使う方法： iOS/iPadOS, macOSで利用可能
- 【Entra ID】条件付きアクセス デバイスフィルターとデバイス拡張属性使う方法： 1. を利用できない Windows と Android で利用
方法1. 【Intune】登録制限と業務用デバイスのID
参考：
1. 基本動作
Intune では「登録デバイスのプラットフォームの制限」を使い、プラットフォームごとに「個人所有」デバイスの登録 (BYOD 方式のデバイス登録) を「許可する/ブロックする」を設定することができます。
今回のように、「BYOD は基本的に登録ブロックするが特定の端末 (申請を受けて情シスが許可した端末) だけ登録を許可したい」場合は、プラットフォームの制限にて個人所有デバイス登録をブロックしたうえで、登録許可したい特定端末だけ「業務用デバイスのID」にシリアル番号を登録すると実現できます。
- プラットフォーム制限で「個人所有」を「ブロック」に設定する
- 事前にユーザーから申請を受けたデバイスのシリアル番号を「業務用デバイスのID」としてテナント登録する
← 事前にシリアル番号登録しておいたデバイスのみ MDM 登録可能になる！
事前に「業務用デバイスのID」を登録しないと、デバイス登録がブロックされます。
実際のユーザーエクスペリエンスとしては、登録を試行したデバイス上で「Management Profile をダウンロードできるがインストールできない」ことでエラーが発生する (結果登録できない) という動きになります。
本設定に起因する登録エラーについては拙記事もご参考ください：Intune デバイス登録エラーをトラブルシュートする！ (登録ブロック、タイムアウト)
「業務用デバイスのID」は IMEI 番号とシリアル番号の利用がサポートされています (プラットフォーム差異あり) が、IMEI 番号を複数持つ端末が存在することからシリアル番号の利用が推奨されています。(参考：Identify devices as corporate-owned)
このため、本記事では「業務用デバイスのID」= シリアル番号登録 として記載しました。
ただし、公開情報にあるとおり「業務用デバイスのID」は Windows 10/11 非対応 (いにしえの Windows Mobile は対応していたらしい) で、Android もバージョン 12 以降でサポート外になってしまいます。
(バージョン 12 以降でサポートが終わるのは Android Enterprise personally-owned work profile 登録方式の場合。Android Enterprise corporate-owned work profile / fully managed / dedicated devices ではバージョンによらずサポート外。)
このため、iOS/iPadOS, macOS ではこの方法を採用し、Windows, Android については別の方法 (方法2. 後述) を使います。
2024年 7月 8日追記：
当記事の記載内容には古い情報が含まれます。
直近の Intune 更新にて、Windows 11 22H2 (KB5035942) 以降向けに業務用デバイスの識別子サポートが追加されました！
2. 環境設定
登録デバイスのプラットフォームの制限
テナント全体 (すべてのデバイス) に適用したい設定のため、既定で用意されている「すべてのユーザー」プロファイルを編集して設定します。
当環境では以下の設定を実装しました。
| # | 種類 | 設定項目 | 値 (例) | 備考 |
|---|---|---|---|---|
| 1 | Android Enterprise (仕事用プロファイル) | プラットフォーム | 許可 | Android Enterprise personally-owned work profile 方式で MDM 登録するため、許可 |
| 2 | Android Enterprise (仕事用プロファイル) | versions | － | OSバージョンによる登録制御は実施しない |
| 3 | Android Enterprise (仕事用プロファイル) | 個人所有 | 許可 | BYOD 登録を許可 |
| 4 | Android Enterprise (仕事用プロファイル) | デバイス製造元 | － | デバイス製造元による登録制御は実施しない |
| 5 | Android デバイス管理者 | プラットフォーム | ブロック | Android Enterprise personally-owned work profile 方式で MDM 登録する場合は、本方式をプラットフォームごとブロックする必要がある |
| 6 | iOS/iPadOS | プラットフォーム | 許可 | MDM 登録するため、許可 |
| 7 | iOS/iPadOS | versions | － | OSバージョンによる登録制御は実施しない |
| 8 | iOS/iPadOS | 個人所有 | ブロック | BYOD は基本的に登録ブロックし、IT部門が承認したデバイスのみ「業務用デバイスのID」を登録してデバイス登録を許可する |
| 9 | macOS | プラットフォーム | 許可 | MDM 登録するため、許可 |
| 10 | macOS | 個人所有 | ブロック | BYOD は基本的に登録ブロックし、IT部門が承認したデバイスのみ「業務用デバイスのID」を登録してデバイス登録を許可する |
| 11 | Windows | プラットフォーム | 許可 | MDM 登録するため、許可 |
| 12 | Windows | versions | － | OSバージョンによる登録制御は実施しない |
| 13 | Windows | 個人所有 | 許可 | BYOD 登録を許可 |
ポイントは以下です。
- 「プラットフォーム」設定： 管理対象のプラットフォーム (Windows, iOS/iPadOS, Android Enterprise, macOS) については「許可」する (Android デバイス管理者は、2024年8月でサポート終了する、かつ Android Enterprise personally-owned work profile 利用時はブロックが推奨される)
- 「個人所有」設定： 管理対象のプラットフォームのうち、「業務用デバイスのID」を利用する iOS/iPadOS, macOS は「ブロック」し、利用できない Windows, Android は「許可」する
業務用デバイスのID
運用フェーズにて、必要に応じて登録してもらいます。(初期構築時は何も登録しない。)
申請量に応じて、1レコードずつ、または CSV ファイルで一括登録してもらう想定です。
方法2. 【Entra ID】条件付きアクセス デバイスフィルターとデバイス拡張属性
参考：
- Conditional Access: Filter for devices
- Azure AD cmdlets to work with extension attributes
- 条件付きアクセスで[デバイスのフィルター]を使う (2)
「業務用デバイスのID」のサポートプラットフォーム制約によって方法1. は iOS/iPadOS, macOS のみ利用できる方法のため、お客様と会話し、Windows と Android については、利用許可の段階で申請ベースにすることになりました。
2024年 7月 8日追記：
当記事の記載内容には古い情報が含まれます。
直近の Intune 更新にて、Windows 11 22H2 (KB5035942) 以降向けに業務用デバイスの識別子サポートが追加されました！
1. 基本動作
Entra ID の「条件付きアクセスポリシー」にてアクセス制御を構成する際、「デバイスのフィルター」条件を使って、デバイスの属性に応じて適用するポリシーを振り分けることができます。
デバイスのフィルターによる属性判定対象は Entra ID に登録済みのデバイスとなるため、Entra ID 登録前のブロックに本機能を使うことはできませんが、Entra ID 登録後のアクセス許可/ブロック制御に使うことができます。
- 条件付きアクセスでプラットフォームごとに許可/ブロック条件を構成する
(Windows, Android はフィルターを使って属性に応じて適用するポリシーを分ける)- BYOD iOS/iPadOS, macOS 許可ポリシー： 「準拠済みデバイス」許可
- Windows, Android ブロックポリシー： 社給 (Hybrid joined) または 特定の属性 (device.extensionAttribute1 -eq "Approved") を持つデバイス以外ブロック
- 社給 Windows 許可ポリシー： 「準拠済みデバイス」許可
- BYOD Windows, Android 許可ポリシー： 特定の属性 (device.extensionAttribute1 -eq "Approved") を持つデバイスは、「準拠済みデバイス」の場合許可
- 管理対象外プラットフォーム ブロックポリシー： iOS/iPadOS, macOS, Windows, Android 以外のプラットフォーム (Windows Phone, Linux, ChromeOS, Blackberry, etc.) のデバイスはブロック
- ユーザーによる BYOD 登録後、Windows, Android については申請に応じ、利用を許可するデバイスに Entra ID 上で特定の属性 (device.extensionAttribute1, "Approved") を設定する
← 属性付与された準拠済みのデバイスのみクラウドアプリが利用可能になる！ (利用を許可されない (特定の属性を持たない) デバイスはアクセスブロックされる)
該当プロジェクトのお客様では、アクセス制御の要件として「組織に管理されたデバイスであること」と「コンプライアンスポリシーに準拠していること」がありました。
これを踏まえて、条件付きアクセスポリシーで「準拠済みデバイス」の許可条件を構成しています。
特にアクセス制御要件が無い場合は、ブロックポリシーの対象外とすればアクセスが許可される (ブロックされない) ため、許可ポリシーを構成する必要はありません。
2. 環境設定
条件付きアクセス ポリシー
1) BYOD iOS/iPadOS, macOS 許可ポリシー 設定
BYOD として利用される iOS/iPadOS, macOS について、「準拠済みデバイス」であればクラウドアプリへのアクセスを許可するポリシーです。
当環境では以下表の設定を実装しました。
| # | 大項目 | 中項目 | 小項目 | 値 (例) | 備考 |
|---|---|---|---|---|---|
| 1 | ポリシー名 | － | － | Require compliant iOS/iPadOS/macOS for test users | ポリシー制御内容が分かりやすいような任意の文字列を設定 (検証環境のため "test users" 表記) |
| 2 | ユーザー | 対象 | － | すべてのユーザー | － |
| 3 | ユーザー | 対象外 | － | break-glass アカウント、ディレクトリ同期アカウント、ゲストアカウント | 緊急アクセス用アカウントはすべての条件付きアクセスポリシーから除外 |
| 4 | リソース | 対象 | － | すべてのクラウドアプリ | － |
| 5 | リソース | 対象外 | － | Microsoft Intune, Microsoft Intune Enrollment | Intune サービス関連アプリは除外 |
| 6 | 条件 | デバイスプラットフォーム | 対象 | 任意 | 当テナントでは除外構成しているが、他の条件付きアクセスポリシーとの兼ね合いによっては対象プラットフォームを明示的に構成しても可 |
| 7 | 条件 | デバイスプラットフォーム | 対象外 | Windows, Android | 5) のポリシーでブロックされない管理対象プラットフォームのうち、WindowsとAndroid以外はこのポリシーの対象となる |
| 8 | 許可 | － | － | アクセス権の付与 - デバイスは準拠しているとしてマーク済みである必要があります | 組織に管理された (MDM登録された)、コンプライアンス準拠済みデバイスを許可 |
| 9 | ポリシーの有効化 | － | － | オン | － |
※1: 写真では場所条件を構成していますが、検証環境の都合で構成したもので要件には関係無いため表では割愛しています。
※2: 検証環境では Graph API 実行時のアプリ認証用のエンタープライズ アプリがあり、これも除外対象として設定しています。(このため除外アプリカウントが3になっています。) 要件には関係無いため表では割愛しています。
※3: ゲストアカウントはマネージドデバイス (準拠済みデバイス) を前提とせず、別途条件付きアクセスポリシーを構成して多要素認証による認証強化を実装しています。
2) Windows, Android ブロックポリシー 設定
社給 (Hybrid joined) または 特定の属性 (device.extensionAttribute1 -eq "Approved") を持つデバイス以外をブロックするポリシーです。対象は Windows, Android です。
当環境では、管理者が承認したデバイスに付与する属性に「extensionAttribute1」、値は「Approved」を使用しました。
- device.extensionAttribute1 -eq "Approved"
(属性と値を変える場合は、それに応じてデバイスフィルターの設定を変えて利用ください。)
当環境では以下表の設定を実装しました。
| # | 大項目 | 中項目 | 小項目 | 値 (例) | 備考 |
|---|---|---|---|---|---|
| 1 | ポリシー名 | － | － | Block unmanaged Android/Windows for test users | ポリシー制御内容が分かりやすいような任意の文字列を設定 (検証環境のため "test users" 表記) |
| 2 | ユーザー | 対象 | － | すべてのユーザー | － |
| 3 | ユーザー | 対象外 | － | break-glass アカウント、ディレクトリ同期アカウント、ゲストアカウント | 緊急アクセス用アカウントはすべての条件付きアクセスポリシーから除外 |
| 4 | リソース | 対象 | － | すべてのクラウドアプリ | － |
| 5 | リソース | 対象外 | － | Microsoft Intune, Microsoft Intune Enrollment | Intune サービス関連アプリは除外 |
| 6 | 条件 | デバイスプラットフォーム | 対象 | Windows, Android | － |
| 7 | 条件 | デバイスのフィルター | フィルター処理されたデバイスをポリシーから除外する | device.trustType -eq "ServerAD" -or device.extensionAttribute1 -eq "Approved" | 社給 (device.trustType -eq "ServerAD") または 特定の属性 (device.extensionAttribute1 -eq "Approved") を持つデバイスはポリシー適用対象外 |
| 8 | 許可 | － | － | アクセスのブロック | － |
| 9 | ポリシーの有効化 | － | － | オン | － |
3) 社給 Windows 許可ポリシー 設定
Entra hybrid join した社給 Windows に対するポリシーです。「準拠済みデバイス」の場合アクセスを許可します。(環境構築後の全社展開のタイミングなど、ラグが懸念される場合は一時的に「準拠済み」をOR条件として利用しても可)
当環境では以下表の設定を実装しました。
| # | 大項目 | 中項目 | 小項目 | 値 (例) | 備考 |
|---|---|---|---|---|---|
| 1 | ポリシー名 | － | － | Require compliant or HAADJ'd device for test users | ポリシー制御内容が分かりやすいような任意の文字列を設定 (検証環境のため "test users" 表記) |
| 2 | ユーザー | 対象 | － | すべてのユーザー | － |
| 3 | ユーザー | 対象外 | － | break-glass アカウント、ディレクトリ同期アカウント、ゲストアカウント | 緊急アクセス用アカウントはすべての条件付きアクセスポリシーから除外 |
| 4 | リソース | 対象 | － | すべてのクラウドアプリ | － |
| 5 | リソース | 対象外 | － | Microsoft Intune, Microsoft Intune Enrollment | Intune サービス関連アプリは除外 |
| 6 | 条件 | デバイスプラットフォーム | 対象 | Windows | HAADJできるのはWindowsのみなので設定としては冗長だが、運用時ポリシー対象が分かりやすいように構成 |
| 7 | 条件 | デバイスのフィルター | フィルター処理されたデバイスをポリシーに含める | device.trustType -eq "ServerAD" | 社給 (device.trustType -eq "ServerAD") デバイスがポリシー適用対象 |
| 8 | 許可 | － | － | アクセスの許可 - デバイスは準拠しているとしてマーク済みである必要があります AND Microsoft Entra ハイブリッド参加済みデバイスが必要 | 本ポリシーが適用されるのはHAADJデバイスのため後者の条件は冗長だが、Entra ID の全社展開時ラグが懸念される場合は一時的にOR条件に切り替えて利用することを念頭に2つの条件を構成 |
| 9 | ポリシーの有効化 | － | － | オン | － |
4) BYOD Windows, Android 許可ポリシー 設定
BYOD 利用目的で Entra register された Windows, Andorid のうち、管理者が承認のもと付与した属性を持つデバイスのアクセスを許可するポリシーです。対象は属性を持つデバイス、許可条件は「準拠済みデバイス」です。
当環境では、管理者が承認したデバイスに付与する属性に「extensionAttribute1」、値は「Approved」を使用しました。
- device.extensionAttribute1 -eq "Approved"
(属性と値を変える場合は、それに応じてデバイスフィルターの設定を変えて利用ください。)
当環境では以下表の設定を実装しました。
| # | 大項目 | 中項目 | 小項目 | 値 (例) | 備考 |
|---|---|---|---|---|---|
| 1 | ポリシー名 | － | － | Require compliant Android/Windows BYOD device for test users | ポリシー制御内容が分かりやすいような任意の文字列を設定 (検証環境のため "test users" 表記) |
| 2 | ユーザー | 対象 | － | すべてのユーザー | － |
| 3 | ユーザー | 対象外 | － | break-glass アカウント、ディレクトリ同期アカウント、ゲストアカウント | 緊急アクセス用アカウントはすべての条件付きアクセスポリシーから除外 |
| 4 | リソース | 対象 | － | すべてのクラウドアプリ | － |
| 5 | リソース | 対象外 | － | Microsoft Intune, Microsoft Intune Enrollment | Intune サービス関連アプリは除外 |
| 6 | 条件 | デバイスプラットフォーム | 対象 | Windows, Android | － |
| 7 | 条件 | デバイスのフィルター | フィルター処理されたデバイスをポリシーに含める | device.extensionAttribute1 -eq "Approved" | 管理者が承認のもと付与した属性を持つデバイスがポリシー適用対象 |
| 8 | 許可 | － | － | アクセスの許可 - デバイスは準拠しているとしてマーク済みである必要があります | 組織に管理された (MDM登録された)、コンプライアンス準拠済みデバイスを許可 |
| 9 | ポリシーの有効化 | － | － | オン | － |
5) 管理対象外プラットフォーム ブロックポリシー 設定
iOS/iPadOS, macOS, Windows, Android 以外のプラットフォーム (Windows Phone, Linux, ChromeOS, Blackberry, etc.) のデバイスを接続元とする場合、アクセスをブロックするポリシーです。
当環境では以下表の設定を実装しました。
| # | 大項目 | 中項目 | 小項目 | 値 (例) | 備考 |
|---|---|---|---|---|---|
| 1 | ポリシー名 | － | － | Block unsupported device platforms | ポリシー制御内容が分かりやすいような任意の文字列を設定 |
| 2 | ユーザー | 対象 | － | すべてのユーザー | － |
| 3 | ユーザー | 対象外 | － | break-glass アカウント | 緊急アクセス用アカウントはすべての条件付きアクセスポリシーから除外 |
| 4 | リソース | 対象 | － | すべてのクラウドアプリ | － |
| 5 | 条件 | デバイスプラットフォーム | 対象外 | Windows, iOS, Android, macOS | iPadOS は iOS扱いのため、iPadOS も対象外となる |
| 6 | 許可 | － | － | アクセスのブロック | － |
| 7 | ポリシーの有効化 | － | － | オン | － |
デバイス拡張属性
運用フェーズにて、必要に応じて設定してもらいます。(対象デバイスがテナントに無いため、初期構築時は何も設定しない。)
申請量に応じては複数台一括で設定したいということがあるかもなど、潜在的な運用検討事項が積み残しとしてありますが、検証段階では1台ずつ Graph Explorer から設定しました。
(参考：条件付きアクセスで[デバイスのフィルター]を使う (2))
実はデバイス拡張属性は Entra ID の管理ポータル UI から設定することができず、Graph Explorer の UI または PowerShell で Graph API を実行するといった方法が想定されますが、いずれにせよオブジェクト ID と属性を指定して実行する必要があります。
1) オブジェクト ID の 確認
i. 「マイ アカウント」ページで確認する
申請対象の BYOD Windows/Android の他にユーザーが登録済みデバイスを利用している場合に使える確認方法です。
- ユーザーが BYOD Windows/Android を登録する
- ユーザーが別端末で「マイ アカウント」(myaccount.microsoft.com) にアクセスし、デバイスページから該当デバイスのオブジェクトIDを確認する
- ユーザーが情シス担当者にオブジェクトIDを申告する
属性付与前の BYOD Windows/Android が接続元の場合、「マイ アカウント」(myaccount.microsoft.com) へのアクセスがブロックされるため、step 2. は別端末 (社給Windows, BYOD iOS/iPadOS/macOS, 属性付与された BYOD Windows/Android) で実施する必要があります。
ii. デバイス名、登録者、登録日時から特定する
申請対象の BYOD Windows/Android 以外の端末をユーザーが利用していない場合、「マイ アカウント」にアクセスできないため別の方法で端末のオブジェクト ID を特定する必要があります。(若干情シス(管理者)側の負荷が高くなります。)
- ユーザーが BYOD Windows/Android を登録する
- ユーザーが以下情報を情シス担当者に申告する
- 登録者 (自分の氏名、メールアドレス。できればUPN。)
- 登録日時
- デバイス名
- プラットフォーム (Android? Windows?)
- 情シス担当者は、ユーザーから申告を受けた情報をもとに Entra ID 管理ポータル上でデバイスのオブジェクト ID を特定する
Android についてはデバイス名が管理ポータル上では「<登録者UPNの@以前>_AndroidForWork_<登録日時UTC>」になるため注意
2) デバイス拡張属性 設定
オブジェクト ID を特定した情シス担当者が、デバイス拡張属性を設定します。
(参考：条件付きアクセスで[デバイスのフィルター]を使う (2))
条件付きアクセスポリシーのデバイスフィルターで使用している値と一致するものを設定します。
当環境では、属性に「extensionAttribute1」、値は「Approved」を使用しました。
(属性と値を変える場合は、それに応じてデバイスフィルターの設定ならびにこの工程の設定を読み変えてください。)
3. 動作確認
属性付与前後のサインインログを比較すると、意図したとおりポリシーが適用されていることが確認できます。
Windows (Entra ID registered)
1) 属性付与前
Windows/Android ブロックポリシー (Block unmanaged Android/Windows for test users) が適用され、アクセスがブロックされます。
2) 属性付与後
BYOD Windows/Android 許可ポリシー (Require compliant Android/Windows BYOD device for test users) が適用され、「準拠済みデバイス」許可条件を満たしていることによりアクセスが許可されます。
Android Enterprise personally-owned work profile
1) 属性付与前
Windows/Android ブロックポリシー (Block unmanaged Android/Windows for test users) が適用され、アクセスがブロックされます。
本記事では記載を割愛しましたが、当テナントではアプリ保護ポリシー導入にともない、「承認されたクライアント アプリ」または「アプリ保護ポリシー」を許可条件とする条件付きアクセスポリシー (Require approved client apps or app protection policies) を構成しています。
ブロックポリシーが適用される場合はアプリ保護ポリシー適用ができず、「承認されたクライアント アプリ」または「アプリ保護ポリシー」を許可条件とする条件付きアクセスポリシー (Require approved client apps or app protection policies) にも失敗するという結果になりました。
2) 属性付与後
BYOD Windows/Android 許可ポリシー (Require compliant Android/Windows BYOD device for test users) が適用され、「準拠済みデバイス」許可条件を満たしていることによりアクセスが許可されます。
Android Enterprise の場合、個人用プロファイルにインストールされたアプリを接続元としたアクセスは Entra ID にデバイス情報が連携されず、「準拠済みデバイス」許可条件を満たしていないとみなされてアクセスがブロックされます。
(参考：Blocking access to Microsoft 365 outside the Android for Work Profile with Endpoint Manager)
Android Enterpriseで「準拠済みデバイス」許可条件を満たすにはデバイスがコンプライアンスポリシーに準拠していることに加え、仕事用プロファイルにインストールされたアプリを接続元とする必要があります。
なお、仕事用プロファイルにインストールするアプリは事前に Intune からマネージド Google Play ストア アプリとして展開しておく必要がある点、要注意です。
(参考：Manage Android personally-owned/corporate-owned work profile devices with Intune)
さいごに
思っていたよりも長めの記事になってしまいました。
みなさまの野良デバイス対策の一助になれば幸いです...
なお、この記事の内容が活用できるのは、冒頭の仮想要件に記載したような要件が発生した場合など、ある程度限定されるかと思います。
例えば、「準拠済みデバイス (セキュリティ要件をクリアしたデバイス) であればアクセス許可する」と割り切れる場合や、DEMアカウントをはじめとしたアカウント縛り または IPアドレス縛りで登録運用するぜ！ という企業環境であれば、この記事に記載したような対応は不要になります。
さいごに、この記事の下書きを作成したのが2023年12月末～2024年1月あたりの時期のため、一部表現が古い (「業務用デバイスのID」は、サービスリリース 2402 Intune テナント上で「業務用デバイスの識別子」になっている) ですがご容赦ください...