Intune デバイス・マネージャーの追加

オンラインで編集

Microsoft™ Intune をデバイスマネージャーとして設定します。

始める前に

このタスクを完了するには管理者権限が必要です。
IBM® Verify 管理者として管理コンソールにログインしてください。

注：mTLS による認証が必要な各テナントには、

「vanity」というホスト名が設定されました。「独自ホスト名の取得」を参照してください。
バニティホスト名用にエッジインフラストラクチャ（Akamai）にアップロードされたテナントのルートCA証明書および中間CA証明書。

デバイスは、クライアント証明書を使用して、テナントの独自ホスト名に対して直接認証を行います。以下のエンドポイントが使用されます。

認証： https://{vanity-hostname}/v1.0/mdm/mtls
SCEPの業務： https://{vanity-hostname}/v1.0/mdm/scep

このタスクについて

サポートされているオペレーティング・システム

Windows 8.1 以降
MacOS 10.13 以降

信頼モデル

VerifyはSCEP認証局（CA）として機能し、登録されたデバイスにクライアント証明書を発行します。設定したルート証明書、中間証明書、およびSCEP証明書プロファイルにより、この証明書発行プロセスが有効になります。

相互 TLS 認証（ mTLS ）では、デバイスが認証を試みる際、そのクライアント証明書をVerifyに提示します。この証明書は、Verify CA に対して検証され、暗号的な信頼関係を確立するとともに、デバイスの身元を確認します。

証明書の検証が成功すると、Verifyは設定された権限を使用してMicrosoft Graph APIにクエリを実行し、Intuneからデバイスのリアルタイムの状態およびコンプライアンス情報を取得します。この主要なコンプライアンス情報には、以下の内容が含まれます：

デバイスのコンプライアンス状態（準拠／非準拠／不明）。 Intune でデバイスがコンプライアンス違反となった場合、証明書自体は自動的に失効しません。ユーザー情報およびデバイス情報のキャッシュ有効期限が切れるたびに、 IBM Verify はMicrosoft Graph APIにクエリを送信し、Intuneから現在のデバイスのコンプライアンス状態を取得します。テナントがポリシーベースのアクセス制御を使用している場合、この complianceState 属性（およびその他のデバイス属性）は、 IBM Verify で設定されたアクセスポリシーに基づいて評価されます。これらの方針により、～するかどうかが決まります
- アクセスを許可する（ポリシーで非準拠デバイスの使用が許可されている場合）。
- 追加の認証を要求する（ステップアップ認証）。
- アクセスを拒否する（ポリシーで準拠デバイスのみと定められている場合）。
アプリケーションには、コンプライアンス要件を定義するアクセスポリシーを設定することができます。 complianceState を含むデバイスの属性は、Verify によって取得され、登録が正常に完了した後に保存されます。デバイスの属性は、キャッシュのタイムアウトで指定された一定期間キャッシュされ、キャッシュの有効期限が切れた後にIntuneから再度取得されます。
注：準拠していないデバイスを恒久的にブロックする必要がある場合は、 IBM Verify からそのデバイスを削除してください。これにより、そのデバイスの証明書も失効します。無効化された証明書は、管理対象のクライアントデバイスから自動的に削除されるわけではありません。
デバイスの管理状態（管理対象／非管理対象）アクセスポリシーの評価には、以下のデバイス属性が利用可能です。
- 新規デバイス
- デバイスのプラットフォーム
- デバイス・コンプライアンス

これらの属性はすべて、アクセスポリシーの決定に利用できるようになっています。「アクセスポリシーの管理」を参照してください。

注：デバイスが不正アクセスを受けた場合は、 IBM Verify からそのデバイスを削除してください。これにより、直ちに証明書の失効手続きが開始されます。そのデバイスに関連付けられているすべての証明書は、直ちに失効されます。そのデバイスは、たとえ証明書ファイルをまだ保持していたとしても、認証を行うことができなくなりました。

SCEPサーバーのシステム要件

外部のSCEPインフラは不要です。 SCEPサーバー機能はmdm-brokerサービスに組み込まれており、すべての標準的なSCEP操作を処理します：

GetCACaps - CAの機能を返します
GetCACert - CA証明書チェーンを返す
PKIOperation - 証明書の登録および更新リクエストを処理します

IBM Verify 統合されたSCEPサーバーおよび認証局（CA）を提供します。管理対象デバイスは、標準のSCEPプロトコル（PKIOperation）を介して、Verify SCEPエンドポイントに証明書署名要求（CSR）を送信します。 VerifyはSCEPサーバーおよび署名CAの両方の役割を果たし、設定されたSCEPプロファイルに従ってこれらのリクエストを処理し、署名付きクライアント証明書を発行します。

SCEP証明書のライフサイクル全体（生成、署名、保存、更新を含む）は、Verifyによって内部で処理されます。

注：MacOS 版Safariをご利用の場合、Intuneデバイスマネージャーによって発行されたクライアント証明書について、確認のメッセージが表示されないという問題が発生する可能性があります。この問題を解決するには、MacOS キーチェーン ID 設定を構成する必要があります。

Macで「キーチェーンアクセス」を開きます。
クライアント証明書の ID 設定を追加します。
ID 設定の場所をテナント認証 URL + (スペース) + (com.apple.Safari)に設定します。例えば、https://{tenant_vanity_hostname}/uscです。

「IDの優先順位」は現在、「キーチェーンアクセス」＞「ログイン」＞「すべての項目」に表示され、証明書の確認画面も正常に動作します。

手順

「認証」＞「デバイスマネージャー」を選択します。
「デバイスマネージャーを追加」を選択します。
設定したいデバイスマネージャーの種類を選択してください。
「次へ」を選択します。
「一般設定」ページで、以下の情報を入力してください。
- 表示された欄に「デバイスマネージャー」と入力してください。
- メニューから IDプロバイダーを選択してください。
- メニューからトラストの種類を選択してください。デバイスの信頼設定を行うには、ユーザーは設定済みの一次認証方式を使用してログインする必要があります。デバイスの信頼性により、既存の認証セッションに対して管理対象のデバイス属性が提供されます。
  注：CI-114829 の「デバイスとユーザー認証の分離」機能は、ご要望に応じて有効化できます。この機能をご希望の場合は、 IBM の営業担当者、または IBM の担当者までご連絡いただき、本機能の有効化をご希望であることをお伝えください。権限をお持ちの場合は、サポートチケットを作成してください。 IBM Verify 無料体験版では、サポートチケットを作成することはできません。
- ユーザー・アカウントに対してジャストインタイム・プロビジョニングを有効にするかどうかを選択します。
  注：ユーザーアカウントのジャスト・イン・タイム（JIT）プロビジョニングは、「ユーザーおよびデバイスの信頼」が選択されている場合にのみ適用されます。
- クライアント証明書の有効期間を選択してください。デバイスマネージャーは、90日、180日、365日、または3年間の有効期間を持つ証明書を発行するように設定できます。デフォルトでは、選択期間は3年間です。組織は、自社のセキュリティポリシーやコンプライアンス要件に合わせて有効期間を選択できます。有効期間を短くすれば、証明書が不正利用された場合のリスクにさらされる期間が短縮されますが、逆に長くすれば更新作業の頻度を減らすことができます。
- デバイスごとに証明書の最大数を指定します。証明書の有効期限が、SCEPプロファイルで設定された更新閾値を下回ると、デバイスによって自動的に更新が行われます。このデバイスは自動的に更新リクエストを送信します。更新プロセスはエンドユーザーにとって透明性が高く、手動での操作は一切必要ありません。更新が正常に完了すると、古い証明書は自動的に失効します。
  Verifyは、さまざまなシナリオにおいて包括的な証明書失効処理を実施します。
  - 証明書の更新
  - Verifyからのデバイスの削除
  - Verifyからのユーザー削除
  - 証明書の有効期限
- ユーザーおよびデバイスの情報を保持する分数を指定します。
「次へ」を選択します。
API 認証情報ページで、 Azure （ Active Directory ）のアプリケーションの API 詳細を入力してください。
- 既にアプリケーションがある場合は、「フォームのみ」を選択します。
  1. アプリケーション ID、シークレット、およびテナント名を指定します。
  2. あらかじめ定義された属性のリストから選択 Unique user identifier するか、「カスタムルール」を選択して属性のマッピングを指定します。カスタムルールを使用することを選択した場合、カスタム属性とルールを追加できます。属性値を計算するルールを入力してください。例えば、以下のとおりです。
```
requestContext.email[0].split('@')[0]
```
    注：カスタムルールの選択は、デバイス信頼には適用されません。ただし、用意されている入力欄に適切な属性を入力することは可能です。
  3. 「資格情報のテスト」を選択して資格情報を検証します。
  4. 「次へ」を選択します。
- アプリケーションを作成する場合は、「ステップを表示」を選択し、その手順に従います。
  1. Azure ポータルで、 Azure Active Directory > 「アプリ登録」に移動し、「新規登録」を選択します。
  2. アプリケーションの登録ページで、以下の詳細を指定します。
    
    名前
    
    意味のあるアプリ名を入力してください。例： IBM Verify。
    
    サポートされているアカウントの種類
    
    任意の組織ディレクトリーの「アカウント」を選択します。
    
    リダイレクト URI
    
    注： アプリ登録の設定におけるリダイレクトURIは、空欄のままにしておくことができます。
  3. 「レジスター」を選択します。
  4. アプリの概要ページで、アプリケーション (クライアント) ID 値をコピーし、「アプリ ID の入力」フィールドに貼り付けます。
  5. アプリのナビゲーションページで、「管理」の下にある「証明書とシークレット」を選択し、「新しいクライアントシークレット」を選択します。
  6. 説明を入力し、「有効期限」でオプションを選択して「追加」をクリックします。
  7. クライアント・シークレットを「アプリ秘密鍵の入力」フィールドに貼り付けます。
  8. 「テナント名」には、Microsoft Entra ID のテナント名を入力してください。
  9. 一意のユーザー識別子属性を選択するか、入力してください。
  10. アプリのナビゲーションページで、「管理」の下にある「 API 権限」を選択し、「権限を追加」を選択します
  11. 「Intune」を選択し、次に「アプリケーションのアクセス許可」を選択します。 scep_challenge-provider のチェック・ボックスを選択します。
  12. 「許可の追加」を選択します。
  13. アプリケーションのナビゲーション・ペインの「管理」で、「API 許可」を選択し、「許可の追加」を選択します。
  14. 「 Microsoft Graph」を選択し、次に「アプリケーションのアクセス許可」を選択します。
  15. 「 DeviceManagementManagedDevices 」のチェックボックスを選択します。「 Read.All 」、「 User.Read.All 」、および「 Application.Read.All 」。
  16. 「許可の追加」を選択します。
  17. 「Microsoft に管理者の同意を与えます」を選択し、「はい」を選択します。
  18. 「資格情報のテスト」を選択して資格情報を検証します。
    「認証情報のテスト」ボタンは、以下を確認します
    - 資格情報は正しい形式で指定されています。
    - クライアントIDとクライアントシークレットは有効です。
    - Microsoft Entra ID にアクセスできます。
    - OAuth のアクセストークンは、Microsoftから取得できます。
    以下の項目はテスト対象外です：
    - DeviceManagementManagedDevices.Read.AllAPIの権限（例：）
    - Microsoft Graph からユーザーの /dev に関する情報を読み取る機能
    - Microsoft Graph API エンドポイントへのネットワーク接続
    - テナント設定の完了状況
    テストの合格数：
    
    https://login.microsoftonline.com/{tenant}/oauth2/v2.0/tokenOAuth からアクセストークンを正常に取得しました。
    
    注：認証テストに合格したからといって、統合が正常に機能するとは限りません。このテストでは、認証のみが検証され、APIの権限やデータへのアクセスは検証されません。完全な検証を行うには、実際のデバイス登録テストが必要です。
    
    テストに失敗しました：
    
    HTTP 400のレスポンスが、以下のエラーと共に返されます：Connection to MicrosoftIntune failed.
    
    一般的な原因としては、無効なクライアントIDやシークレット、テナント名の誤り、ネットワークの問題、または有効期限が切れた認証情報などが挙げられます。
    
    トラブルシューティング
    
    HTTP の動作確認 ：成功時は SCEP URL を返し、失敗時はエラーメッセージを返す。
    
    Azure の設定を確認する ： Azure ポータルでクライアントID、シークレット、テナント名を確認してください。
    
    API 権限の確認 ：必要な Microsoft Graph 権限が、管理者の承認を得て付与されていることを確認してください。
    
    エンドツーエンドのテスト ：実際のデバイス登録を試行し、完全な統合を確認する。
  19. 「次へ」を選択します。
「ユーザーのプロパティ」ページ（「ユーザーおよびデバイスの信頼」を選択した場合に表示されます）または「デバイスのプロパティ」（「デバイスの信頼」を選択した場合に表示されます）で、デバイスマネージャーの属性を属性に IBM Verify マッピングします。

注：属性名は大文字小文字を区別せず、重複する属性は使用できません。
1. デバイスマネージャーの属性を選択します。
  マッピングに使用できる Intune デバイスマネージャーの属性は、Microsoft Graph API エンドポイントから返されるものです：
  - /deviceManagement/managedDevices
  - /users/{userId}
  - Intuneのユーザー属性については、Microsoftの「ユーザーリソースタイプ」のドキュメントに記載されています。「この記事」メニューから「プロパティ」を選択します。
  - Intuneのデバイス属性については、 Microsoftのドキュメント（ managedDevice ）で説明されています。「この記事」メニューから「プロパティ」を選択します。
  注：デバイス属性をVerifyにマッピングするには、その属性名の先頭に「 mdmDevice:: 」という文字列を付ける必要があります。たとえば、デバイス属 complianceState 性を「Verify」にマッピングしたい場合は、次のように記述する必要があります
```
mdmDevice::complianceState 
```
  ユーザー属性には接頭辞は必要ありません。
  
  登録済みの単一デバイスからのマップなどの mdmDevice::complianceState デバイス属性。複数のデバイスが関与する状況では、この値に不整合が生じる可能性があります。ユーザーが1台のデバイスに限定されることが想定される場合のみ、デバイスの属性をVerifyにマッピングしてください。
2. （任意）： メニューから変形を選択してください。
3. 必須： マッピング先の属性 Verify を選択してください。
4. ユーザーのプロファイルに属性を保管する方法を選択します。
（任意）： 「属性を追加」をクリックします。
カスタムルールを使用するように選択した場合、カスタム属性を1つずつルールに追加できます。属性値を計算するルールを入力してください。例えば、以下のとおりです。
```
idsuser.email[0].split('@')[0]
```
「テストを実行」をクリックして、ルールが正常に動作するか確認してください。
「保存して続行」を選択します。
デバイス・マネージャーが保存されます。
ルート証明書プロファイルを作成します。

表示された指示に従ってください。
1. 提供されている以下のルート証明書およびプロファイル証明書 .zip ファイルをダウンロードしてください。
2. Microsoft Endpoint Manager にサインインし、 [デバイス] > [構成プロファイル] を開きます。
3. ルート証明書プロファイルを作成するには、「プロファイルの作成」を選択し、以下の設定を行います：
  
  プラットフォーム
  
  適切なプラットフォームを選択します。
  
  プロファイル
  
  信頼された証明書。
4. 「作成」を選択します。
5. ルート証明書プロファイルに名前を付けます（例： WIN10_RootCA_Cert ）。その後、「次へ」を選択します。
6. 手順 1 でダウンロードしたルート証明書プロファイルをアップロードし、保存先を「コンピューター証明書ストア - ルート」に設定して、「次へ」を選択します。
7. 「割り当て先」をテスト対象のユーザーまたはグループに設定し、「次へ」を選択します。
8. 「作成」を選択します。
9. 中間証明書についてもステップ 2 から 8 を繰り返します。
「次へ」を選択します。
SCEP証明書プロファイルページで、 Azure （ Active Directory ）にアプリケーションのAPI詳細を入力してください。
- SCEP 証明書プロファイルが既にある場合は、「値のみ」を選択します。
  1. サブジェクトと SCEP URL を指定します。
  2. 「次へ」を選択します。
- SCEP 証明書プロファイルを作成する場合は、「ステップを表示」を選択し、その手順に従います。
  1. SCEP 証明書プロファイルを作成するには、「プロファイルの作成」を選択して、以下の設定を選択します。
    
    プラットフォーム
    
    適切なプラットフォームを選択します。
    
    プロファイル
    
    TrustedSCEP 証明書。
  2. 「作成」を選択します。
  3. ルート証明書プロファイルの名前 (例えば WIN10_RootCA_Cert) を指定し、「次へ」を選択します。
  4. 以下の構成設定を使用します。
    
    証明書タイプ
    
    ユーザー。
    
    サブジェクト名の形式
    
    カスタム。
    
    カスタム
    
    自動的に生成された CN。
    
    サブジェクトの別名
    
    ユーザーのプリンシパル名 (UPN)。
    
    証明書の有効期間
    
    1 年。
    
    キー格納プロバイダー (KSP)
    
    使用可能な場合は、トラステッド・プラットフォーム・モジュール (TPM) KSP に登録し、それ以外の場合は、ソフトウェア KSP に登録します。
    
    キー使用法
    
    キーの暗号化、デジタル署名。
    
    キー・サイズ (ビット)
    
    2048。
    
    ハッシュ・アルゴリズム
    
    SHA-2.
    
    ルート証明書
    
    手順 11 で作成し、名前を付けたルート証明書プロファイルを選択してください。
    
    拡張鍵使用法
    
    「事前定義値」メニューから「クライアント認証」を選択します。
    
    更新しきい値
    
    20.
    
    SCEP サーバー URL
    
    自動的に生成された URL。
  5. 「次へ」を選択し、接続のテスト対象のユーザーまたはグループを割り当てます。
  6. 「作成」を選択します。
  7. 「次へ」を選択します。
MDM スコープを設定します。
指示に従います。
1. Microsoft Endpoint Manager 管理センターで、 [すべてのサービス] > M365 Azure Active Directory > Azure Active Directory > [モビリティ (MDM および MAM)] を選択します。
2. 「Microsoft Intune」を選択して、Intune を設定します。
3. MDMユーザースコープから「一部」を選択し、MDMの自動登録機能を使用して、従業員のWindows™デバイス上の企業データを管理します。
  MDMの自動登録は、AADに参加しているデバイスおよびBYOD（個人所有デバイスの業務利用）のシナリオ向けに設定されています。
4. [グループの選択 ] > [選択したグループ/ユーザー ] > [割り当てグループとして選択] の順に選択します。
5. 「MAMユーザー」スコープから「一部」を選択し、従業員のデバイス上のデータを管理します。
6. [グループの選択 ] > [グループ/ユーザーの選択] > [割り当てられたグループとして選択] の順に選択します。
7. これ以外の構成値には、デフォルト値を使用します。
8. 「保存」を選択します。
「次へ」を選択します。
構成をテストします。
指示に従います。
「セットアップを完了」を選択します。
1. 設定を確認します。
2. 「変更を保存」を選択します。