ステージ 3: Intune SDK を iOS アプリに統合する

ステージの目標

• Intune App SDK をダウンロードします。
• Intune App SDK に含まれるファイルについて説明します。
• アプリケーションで Intune App SDK を参照します。
• Intune App SDK がビルドに適切に含まれていることを確認します。
• MSAL で認証した後、MAM 管理用の新しいアカウントを登録します。
• 企業データを削除するには、ログアウト時にアカウントの登録を解除します
• (推奨)MAM ログをアプリに組み込みます。

前提条件

• Xcode 14.0 以降がインストールされている macOS コンピューターが必要です。

• アプリは iOS 14.0 以降を対象とする必要があります。

• Intune App SDK for iOS ライセンス条項を確認します。 レコードのライセンス条項のコピーを印刷して保持します。 iOS 用 Intune App SDK をダウンロードして使用することにより、お客様はそのようなライセンス条項に同意するものとします。 同意しない場合は、ソフトウェアを使用しないでください。

• GitHub で Intune App SDK for iOS 用のファイルをダウンロードします。

SDK リポジトリの内容

• IntuneMAMSwift.xcframework: Intune App SDK 動的フレームワーク。 Intune クライアント アプリケーション管理を有効にするには、このフレームワークをアプリ/拡張機能にリンクすることをお勧めします。 ただし、一部の開発者は、静的フレームワーク (IntuneMAMStatic.xcframework) のパフォーマンス上の利点を好む場合があります。 以下を参照してください。

• IntuneMAMStatic.xcframework: Intune App SDK 静的フレームワーク。 開発者は、動的フレームワークではなく静的フレームワークをリンクすることを選択できます。 静的フレームワークの実行可能コードはビルド時にアプリ/拡張機能バイナリに直接埋め込まれているため、静的ライブラリを使用すると起動時のパフォーマンス上の利点があります。 ただし、アプリに拡張機能が含まれている場合、静的フレームワークをアプリと拡張機能にリンクすると、実行可能コードが各アプリ/拡張機能バイナリに埋め込まれるので、アプリ バンドル サイズが大きくなります。 一方、動的フレームワークを使用する場合、アプリと拡張機能は同じ Intune SDK バイナリを共有できるため、アプリのサイズが小さくなります。

• IntuneMAMSwiftStub.xcframework: Intune App SDK Swift スタブ フレームワーク。 このフレームワークは、アプリ/拡張機能がリンクする必要がある IntuneMAMSwift.xcframework と IntuneMAMStatic.xcframework の両方の必須の依存関係です。

• IntuneMAMConfigurator: Intune 管理に必要な最小限の変更でアプリまたは拡張機能の Info.plist を構成するために使用されるツール。 アプリまたは拡張機能の機能によっては、Info.plist をさらに手動で変更することが必要になる場合があります。

• libIntuneMAMSwift.xcframework: Intune App SDK 静的ライブラリ。 Intune MAM iOS SDK のこのバリアントは非推奨となり、今後の更新で削除される予定です。 静的ライブラリをリンクせず、代わりにアプリ/拡張機能を動的フレームワーク (IntuneMAMSwift.xcframework) または静的フレームワーク (IntuneMAMStatic.xcframework) にリンクすることをお勧めします。

• IntuneMAMResources.bundle: SDK が依存するリソースを含むリソース バンドル。 リソース バンドルは、非推奨の静的ライブラリ (libIntuneMAMSwift.xcframework) を統合するアプリにのみ必要であり、今後の更新で削除されます。

Intune App SDK のしくみ

iOS 用 Intune App SDK の目的は、最小限のコード変更で iOS アプリケーションに管理機能を追加することです。 コードの変更が少ないほど、市場投入までの時間は短くなりますが、モバイル アプリケーションの一貫性と安定性には影響しません。

プロセス フロー

次の図は、iOS 用 Intune App SDK のプロセス フローを示しています。

SDK をモバイル アプリにビルドする

Intune App SDK を有効にするには、次の手順に従います。

1. IntuneMAMSwift.xcframeworkまたはIntuneMAMStatic.xcframeworkをターゲットにリンクする: xcframework バンドルをプロジェクト ターゲットのフレームワーク、ライブラリ、埋め込みコンテンツの一覧にドラッグします。 IntuneMAMSwiftStub.xcframeworkに対してこれらの手順を繰り返します。 メイン アプリの場合は、追加された xcframeworks の両方の [埋め込み] 列で [埋め込み & 記号] を選択します。 拡張機能の場合は、[埋め込み不可] を選択します。

   

2. 次の iOS フレームワークをプロジェクトに追加します。

   • MessageUI.framework
   • Security.framework
   • CoreServices.framework
   • SystemConfiguration.framework
   • libsqlite3.tbd
   • libc++.tbd
   • ImageIO.framework
   • LocalAuthentication.framework
   • AudioToolbox.framework
   • QuartzCore.framework
   • WebKit.framework
   • MetricKit.framework

3. キーチェーン共有を有効にする (まだ有効になっていない場合) には、各プロジェクト ターゲットで [機能 ] を選択し、[ キーチェーン共有 ] スイッチを有効にします。 次の手順に進むには、キーチェーンの共有が必要です。

   注:

   プロビジョニング プロファイルでは、新しいキーチェーン共有値をサポートする必要があります。 キーチェーン アクセス グループでは、ワイルドカード文字をサポートする必要があります。 これを確認するには、テキスト エディターで .mobileprovision ファイルを開き、 キーチェーン アクセス グループを検索し、ワイルドカード文字があることを確認します。 例:

   <key>keychain-access-groups</key>
   <array>
   <string>YOURBUNDLESEEDID.*</string>
   </array>
   

4. キーチェーン共有を有効にした後、手順に従って、Intune App SDK がデータを格納する別のアクセス グループを作成します。 キーチェーン アクセス グループは、UI を使用するか、エンタイトルメント ファイルを使用して作成できます。 UI を使用してキーチェーン アクセス グループを作成する場合は、次の手順に従ってください。

   1. モバイル アプリにキーチェーン アクセス グループが定義されていない場合は、アプリのバンドル ID を 最初 のグループとして追加します。

   2. 共有キーチェーン グループ com.microsoft.intune.mam を既存のアクセス グループに追加します。 Intune App SDK では、このアクセス グループを使用してデータを格納します。

   3. 既存のアクセス グループに com.microsoft.adalcache を追加します。

      

   4. 上記の Xcode UI を使用してキーチェーン アクセス グループを作成するのではなく、エンタイトルメント ファイルを直接編集する場合は、キーチェーン アクセス グループの先頭に $(AppIdentifierPrefix) を付けます (Xcode はこれを自動的に処理します)。 例:

      • $(AppIdentifierPrefix)com.microsoft.intune.mam
      • $(AppIdentifierPrefix)com.microsoft.adalcache

      注:

      エンタイトルメント ファイルは、モバイル アプリケーションに固有の XML ファイルです。 これは、iOS アプリで特別なアクセス許可と機能を指定するために使用されます。 アプリに以前エンタイトルメント ファイルがなかった場合は、キーチェーン共有を有効にすると (手順 3)、Xcode によってアプリ用のファイルが生成されたはずです。 アプリのバンドル ID がリストの最初のエントリであることを確認します。

5. アプリが UIApplication canOpenURL に渡す各プロトコルを、アプリの Info.plist ファイルの LSApplicationQueriesSchemes 配列に含めます。 この配列にリストされているプロトコルごとに、 -intunemam で追加されたプロトコルのコピーも配列に追加する必要があります。 さらに、 http-intunemam、 https-intunemam、 microsoft-edge-http-intunemam、 microsoft-edge-https-intunemam、 smart-ns、 zips、 lacoonsecurity、 wandera、 lookoutwork-ase、 skycure、 betteractiveshield、 smsec、 mvisionmobile、 scmx、および intunemam-mtd を配列に追加する必要があります。 アプリで mailto: プロトコルを使用している場合は、 ms-outlook-intunemam も配列に追加する必要があります。 次の手順に進む前に、変更を保存してください。

   アプリが LSApplicationQueriesSchemes リストの領域を使い果たした場合、Intune MAM SDK も実装することが知られているアプリの "-intunemam" スキームを削除できます。 アプリが LSApplicationQueriesSchemes リストから "scheme-intunemam" を削除すると、 canOpenURL() はそれらのスキームに対して正しくない応答を返す可能性があります。 この問題を解決するには、代わりにそのスキームの [IntuneMAMPolicy isURLAllowed:url isKnownManagedAppScheme:YES] を呼び出す必要があります。 この呼び出しは、ポリシーによって URL が開かれるのをブロックした場合に NO を返します。 true が返された場合、アプリは空の ID で canOpenURL() を呼び出して、URL を開くことができるかどうかを判断できます。 例:

   BOOL __block canOpen = NO;
   if([policy isURLAllowed:urlForKnownManagedApp isKnownManagedAppScheme:YES])
   {
       [[IntuneMAMPolicyManager instance] setCurrentThreadAccountId:"" forScope:^{
       canOpen = [[UIApplication sharedApplication] canOpenURL:urlForKnownManagedApp];
       }];
   }
   

6. アプリで FaceID がまだ使用されていない場合は、 NSFaceIDUsageDescription Info.plist キー が既定のメッセージで構成されていることを確認します。 この手順は、iOS がアプリで FaceID を使用する方法をユーザーに知らせるために必要です。 Intune アプリ保護ポリシー設定を使用すると、IT 管理者によって構成されたときに、FaceID をアプリ アクセスの方法として使用できます。

7. SDK リポジトリに含まれている IntuneMAMConfigurator ツールを使用して、アプリの Info.plist の構成を完了します。 このツールには、次の 3 つのパラメーターがあります。

   プロパティ	使用方法
   -私	<Path to the input plist>
   - e	<Path to the entitlements file>
   - o	(省略可能) <Path to the output plist>

   '-o' パラメーターが指定されていない場合、入力ファイルはインプレースで変更されます。 このツールはべき等であり、アプリの Info.plist またはエンタイトルメントが変更されるたびに再実行する必要があります。 また、最新リリースで Info.plist 構成要件が変更された場合に備えて、Intune SDK を更新するときに、ツールの最新バージョンをダウンロードして実行する必要があります。

Xcode ビルド設定

アプリには、"Strip Swift Symbols"(STRIP_SWIFT_SYMBOLS) と "Enable Bitcode"(ENABLE_BITCODE) の両方が NO に設定されている必要があります。

ファイル プロバイダー拡張子の統合

ファイル プロバイダー拡張機能には、完全な SDK の統合を困難にする可能性がある特定のメモリ要件があります。 簡単にするために、静的ライブラリ libIntuneMAMSwiftFileProvider.xcframework があります。これは、ファイル プロバイダー拡張機能専用の SDK の削除されたバージョンです。 これは、FileProvider 拡張機能の UI 以外の部分に対するであることに注意してください。 完全な SDK をファイル プロバイダー UI 拡張機能に統合する必要があります。

これらのライブラリの 1 つをファイル プロバイダー拡張機能と統合するには、上記のように SDK を静的ライブラリとして統合する手順に従います。 ContainingAppBundleId設定を必ず含めます。

レプリケートされていないファイル プロバイダー拡張子の統合

アプリが NSFileProviderExtension プロトコルを実装している場合、アプリはレプリケートされていないファイル プロバイダーを使用しています。 iOS 16.0 より前に作成されたすべてのファイル プロバイダーはレプリケートされません。

で - startProvidingItemAtURL:completionHandler: [[IntuneMAMPolicy instance]shouldFileProviderEncryptFiles]を使用してファイルを暗号化する必要があるかどうかを確認します。 実際のファイル暗号化には、IntuneMAMFileProtectionManager で encryptFile:forAccountId: API を使用します。 また、暗号化が必要な場合は、暗号化されたファイルのコピーをクラウド ストレージに格納したくないので、ファイルのコピーを共有します。

In - importDocumentAtURL:toParentItemIdentifier:completionHandler: IntuneMAMFileProtectionManager の API を使用してファイルが暗号化されているかどうかを確認します。 その後、decryptFile:toCopyPath: IntuneMAMFileProtectionManager の API を使用して暗号化を解除します。 マルチ ID アプリでは、移行先の所有者の IntuneMAMPolicy の canReceiveSharedFile: API に対して確認して、所有者がファイルを受信できるかどうかを確認します。

レプリケートされたファイル プロバイダー拡張機能の統合

アプリが NSFileProviderReplicatedExtension プロトコル (iOS 16.0 で追加) を実装している場合、アプリはレプリケートされたファイル プロバイダーを使用しています。

で - fetchContentsForItemWithIdentifier:version:request:completionHandler: [[IntuneMAMPolicy instance]shouldFileProviderEncryptFiles]を使用してファイルを暗号化する必要があるかどうかを確認します。 実際のファイル暗号化には、IntuneMAMFileProtectionManager で encryptFile:forAccountId: API を使用します。 また、暗号化が必要な場合は、暗号化されたファイルのコピーをクラウド ストレージに格納したくないので、ファイルのコピーを共有します。

で - createItemBasedOnTemplate:fields:contents:options:request:completionHandler: IntuneMAMFileProtectionManager で isFileEncrypted: API を使用してファイルが暗号化されているかどうかを確認します。 その後、decryptFile:toCopyPath: IntuneMAMFileProtectionManager の API を使用して暗号化を解除します。 マルチ ID アプリでは、移行先の所有者の IntuneMAMPolicy の canReceiveSharedFile: API に対して確認して、所有者がファイルを受信できるかどうかを確認します。

レプリケートされたファイル プロバイダーが NSFileProviderItem を作成してシステムに渡す任意の場所で、アイテムの所有者 ID を使用して IntuneMAMFileProtectionManager の protectFileProviderItem:forAccountId: API を呼び出します。 NSFileProviderItem オブジェクトが拡張機能内で作成および永続化される場所によっては、NSFileProviderReplicatedExtension の各プロトコル メソッドでこれを行う必要がある場合があります。

Intune App SDK の設定を構成する

アプリケーションの Info.plist ファイルの IntuneMAMSettings ディクショナリを使用して、Intune App SDK を設定および構成できます。 IntuneMAMSettings ディクショナリが Info.plist ファイルに表示されない場合は、作成する必要があります。

IntuneMAMSettings ディクショナリの下で、次のサポートされている設定を定義して Intune App SDK を構成できます。

これらの設定の一部は前のセクションで取り上げられていた可能性があり、一部の設定はすべてのアプリに適用されない場合があります。

アプリ保護ポリシーを受け取る

概要

Intune アプリ保護ポリシーを受け取るために、アプリは Intune MAM サービスで登録要求を開始する必要があります。 Intune 管理センターでアプリを構成して、デバイス登録の有無にかかわらずアプリ保護ポリシーを受け取ることができます。 Mobile Application Management (MAM) を使用すると、デバイスを Intune モバイル デバイス管理 (MDM) に登録する必要なく、Intune でアプリを管理できます。 どちらの場合も、ポリシーを受け取るために Intune MAM サービスに登録する必要があります。

ADAL または MSAL を既に使用しているアプリ

MSAL を既に使用しているアプリでは、ユーザーが正常に認証された後、IntuneMAMEnrollmentManager インスタンスで registerAndEnrollAccountId メソッドを呼び出す必要があります。

/*
 *  This method will add the account to the list of registered accounts.
 *  An enrollment request will immediately be started.
 *  @param accountId The Entra object ID of the account to be registered with the SDK
 */

(void)registerAndEnrollAccountId:(NSString *_Nonnull)accountId;

サインインに成功すると、MSALResult オブジェクトに結果が送信されます。 上記の API の accountId パラメーターとして、MSALResult 内で tenantProfile.identifier を使用します。

registerAndEnrollAccountId メソッドを呼び出すと、SDK によってユーザー アカウントが登録され、このアカウントに代わってアプリの登録が試行されます。 何らかの理由で登録が失敗した場合、SDK は 24 時間後に自動的に登録を再試行します。 デバッグ目的で、アプリは、登録要求の結果に関する 通知をデリゲートを介して受信できます。

この API が呼び出されると、アプリは引き続き通常どおりに機能できます。 登録が成功した場合、SDK はアプリの再起動が必要であることをユーザーに通知します。 その時点で、ユーザーはすぐにアプリを再起動できます。

[[IntuneMAMEnrollmentManager instance] registerAndEnrollAccountId:@"3ec2c00f-b125-4519-acf0-302ac3761822"];

ADAL または MSAL を使用しないアプリ

ADAL または MSAL を使用してユーザーにサインインしないアプリでも、API を呼び出して SDK でその認証を処理することで、Intune MAM サービスからアプリ保護ポリシーを受け取ることができます。 アプリは、Microsoft Entra ID を持つユーザーを認証していないが、データを保護するためにアプリ保護ポリシーを取得する必要がある場合に、この手法を使用する必要があります。 たとえば、アプリのサインインに別の認証サービスが使用されている場合、またはアプリがサインインをまったくサポートしていない場合です。 これを行うには、アプリケーションは、IntuneMAMEnrollmentManager インスタンスで loginAndEnrollAccount メソッドを呼び出すことができます。

/**
 *  Creates an enrollment request which is started immediately.
 *  If no token can be retrieved for the identity, the user will be prompted
 *  to enter their credentials, after which enrollment will be retried.
 *  @param identity The UPN of the account to be logged in and enrolled.
 */
 (void)loginAndEnrollAccount: (NSString *)identity;

このメソッドを呼び出すと、既存のトークンが見つからない場合、SDK によってユーザーに資格情報の入力が求められます。 SDK は、指定されたユーザー アカウントの代わりに Intune MAM サービスにアプリを登録しようとします。 メソッドは、ID として "nil" を使用して呼び出すことができます。 その場合、SDK はデバイス上の既存のマネージド ユーザーに登録するか (MDM の場合)、既存のユーザーが見つからない場合はユーザーにユーザー名の入力を求めます。

登録が失敗した場合、アプリはエラーの詳細に応じて、将来この API を再度呼び出すことを検討する必要があります。 アプリは、登録要求の結果に関する 通知を代理人を介して受け取ることができます。

この API が呼び出されると、アプリは正常に機能し続けることができます。 登録が成功した場合、SDK はアプリの再起動が必要であることをユーザーに通知します。 アプリを管理したら、IntuneMAMEnrollmentManagerのenrolledAccountIdを使用して Entra オブジェクト ID の値を照会する必要があります。 これは、アプリがこの登録済みアカウントに使用するすべての MAM SDK API に対して使用します。

例:

[[IntuneMAMEnrollmentManager instance] loginAndEnrollAccount:@"user@foo.com"];

起動時に Intune で認証と登録を処理できるようにする

アプリの起動が完了する前に、Intune SDK で ADAL/MSAL と登録を使用するすべての認証を処理し、アプリに常に APP ポリシーが必要な場合は、 loginAndEnrollAccount API を使用する必要はありません。 アプリの Info.plist の IntuneMAMSettings ディクショナリで、以下の 2 つの設定を YES に設定するだけです。

アプリに対してこのオプションを選択した場合、登録後にアプリの再起動を処理する必要はありません。

ユーザー アカウントの登録解除

ユーザーがアプリからサインアウトされる前に、アプリは SDK からユーザーの登録を解除する必要があります。 これにより、次が保証されます。

1. 登録の再試行は、ユーザーのアカウントに対して行われなくなります。

2. アプリ保護ポリシーが削除されます。

3. アプリが選択的ワイプを開始すると、企業データは削除されます (省略可能)。

ユーザーがサインアウトする前に、アプリは IntuneMAMEnrollmentManager インスタンスで次のメソッドを呼び出す必要があります。

/*
 *  This method will remove the provided account from the list of
 *  registered accounts.  Once removed, if the account has enrolled
 *  the application, the account will be un-enrolled.
 *  @note In the case where an un-enroll is required, this method will block
 *  until the Intune APP AAD token is acquired, then return.  This method must be called before  
 *  the user is removed from the application (so that required AAD tokens are not purged
 *  before this method is called).
 *  @param accountId The object ID of the account to be removed.
 *  @param doWipe  If YES, a selective wipe if the account is un-enrolled
 */
(void)deRegisterAndUnenrollAccountId:(NSString *)accountId withWipe:(BOOL)doWipe;

このメソッドは、ユーザー アカウントの Microsoft Entra トークンが削除される前に呼び出す必要があります。 SDK では、ユーザーに代わって Intune MAM サービスに特定の要求を行うために、ユーザー アカウントの Microsoft Entra トークンが必要です。

アプリがユーザーの企業データを単独で削除する場合は、 doWipe フラグを false に設定できます。 それ以外の場合、アプリは SDK に選択的ワイプを開始させることができます。 これにより、アプリの選択的ワイプ デリゲートが呼び出されます。

例:

[[IntuneMAMEnrollmentManager instance] deRegisterAndUnenrollAccountId:@"3ec2c00f-b125-4519-acf0-302ac3761822" withWipe:YES];

状態、結果、およびデバッグ通知

アプリは、Intune MAM サービスに対する次の要求に関する状態、結果、デバッグの通知を受け取ることができます。

• 登録要求
• ポリシー更新要求
• 登録解除要求

通知は、 IntuneMAMEnrollmentDelegate.hのデリゲート メソッドを介して表示されます。

/**
 *  Called when an enrollment request operation is completed.
 * @param status status object containing debug information
 */

(void)enrollmentRequestWithStatus:(IntuneMAMEnrollmentStatus *)status;

/**
 *  Called when a MAM policy request operation is completed.
 *  @param status status object containing debug information
 */
(void)policyRequestWithStatus:(IntuneMAMEnrollmentStatus *)status;

/**
 *  Called when a un-enroll request operation is completed.
 *  @Note: when a user is un-enrolled, the user is also de-registered with the SDK
 *  @param status status object containing debug information
 */

(void)unenrollRequestWithStatus:(IntuneMAMEnrollmentStatus *)status;

これらのデリゲート メソッドは、次の情報を持つ IntuneMAMEnrollmentStatus オブジェクトを返します。

• 要求に関連付けられているアカウントの accountId (オブジェクト ID)
• 要求に関連付けられているアカウントの ID (UPN)
• 要求の結果を示す状態コード
• 状態コードの説明を含むエラー文字列
• NSError オブジェクト。 このオブジェクトは、返すことができる特定の状態コードと共に、 IntuneMAMEnrollmentStatus.hで定義されます。

サンプル コード

デリゲート メソッドの実装例を次に示します。

- (void)enrollmentRequestWithStatus:(IntuneMAMEnrollmentStatus*)status
{
    NSLog(@"enrollment result for identity %@ with status code %ld", status.accountId, (unsigned long)status.statusCode);
    NSLog(@"Debug Message: %@", status.errorString);
}

- (void)policyRequestWithStatus:(IntuneMAMEnrollmentStatus*)status
{
    NSLog(@"policy check-in result for identity %@ with status code %ld", status.accountId, (unsigned long)status.statusCode);
    NSLog(@"Debug Message: %@", status.errorString);
}

- (void)unenrollRequestWithStatus:(IntuneMAMEnrollmentStatus*)status
{
    NSLog(@"un-enroll result for identity %@ with status code %ld", status.accountId, (unsigned long)status.statusCode);
    NSLog(@"Debug Message: %@", status.errorString);
}

アプリケーションの再起動

アプリが MAM ポリシーを初めて受け取った場合は、必要なフックを適用するために再起動する必要があります。 再起動が必要であることをアプリに通知するために、SDK は IntuneMAMPolicyDelegate.hにデリゲート メソッドを提供します。

 - (BOOL) restartApplication

このメソッドの戻り値は、アプリケーションが必要な再起動を処理する必要があるかどうかを SDK に通知します。

• true が返された場合、アプリケーションは再起動を処理する必要があります。

• false が返された場合、SDK は、このメソッドが返された後にアプリケーションを再起動します。 SDK には、アプリケーションを再起動するようにユーザーに指示するダイアログ ボックスがすぐに表示されます。

終了条件

ビルド プラグインを構成するか、コマンド ライン ツールをビルド プロセスに統合した後、正常に実行されていることを検証します。

• ビルドが正常にコンパイルされ、ビルドされていることを確認します。
• コンパイル済みアプリを起動し、App Protection Policy の対象になっていない Microsoft Entra ユーザーとログインし、アプリが期待どおりに機能することを確認します。
• アプリ 保護ポリシーを対象とする Microsoft Entra ユーザーと一緒に ログアウトしてこのテストを繰り返し、アプリが Intune によって管理され、再起動されたことを確認します。

統合のこの時点で、アプリは App Protection ポリシーを受け取って適用できるようになりました。 次のテストを実行して、統合を検証します。

最初のポリシー アプリケーション テスト

最初に次のテストを実行して、アプリ内のポリシー アプリケーションの完全なエンド ユーザー エクスペリエンスを理解します。

1. Microsoft Intune 管理センターで iOS App Protection ポリシーを作成します。 このテストでは、ポリシーを構成します。
   • [アクセス要件] で、既定の設定のままにします。 特に、"アクセス用の PIN" は "必須" である必要があります。
2. アプリ保護ポリシーがアプリケーションを対象にしていることを確認します。 ポリシー作成ウィザードで、アプリケーションのバンドル ID を手動で追加することが必要になる場合があります。
3. テスト アカウントを含むユーザー グループに App Protection ポリシーを割り当てます。
4. アプリケーションをインストールします。
5. App Protection Policy を対象とするテスト アカウントを使用して、アプリケーションにログインします。
6. Intune の管理画面でメッセージが表示されることを確認し、プロンプトがアプリを再起動することを確認します。 この画面は、SDK がこのアカウントのポリシーを正常に取得したことを示します。
7. アプリの PIN を設定するように求められたら、PIN を作成します。
8. マネージド アカウントをアプリケーションからログアウトします。
9. アプリケーションの周りを移動し、ログインせずに可能な限りアプリが期待どおりに動作することを確認します。

この手順の一覧は、アプリがアカウントを適切に登録し、認証コールバックを登録し、アカウントの登録を解除することを確認するための *最低限のテストです。 次のテストを実行して、他の App Protection Policy 設定によってアプリケーションの動作がどのように変更されるかをより徹底的に検証します。

次の手順

すべての 終了条件を完了したら、 ステージ 4: アプリ参加機能に進みます。