Azure Active Directory による SaaS アプリへのユーザー プロビジョニングとプロビジョニング解除の自動化Automate user provisioning and deprovisioning to SaaS applications with Azure Active Directory

Azure Active Directory (Azure AD) を使用すると、Dropbox、Salesforce、ServiceNow などのクラウド (SaaS) アプリケーションで、ユーザー ID の作成、保守、削除を自動化できます。Azure Active Directory (Azure AD) lets you automate the creation, maintenance, and removal of user identities in cloud (SaaS) applications such as Dropbox, Salesforce, ServiceNow, and more. これは、SaaS アプリの自動化されたユーザー プロビジョニングとして知られています。This is known as automated user provisioning for SaaS apps.

この機能を使用すると次のことができます。This feature lets you:

  • 新しいユーザーがチームまたは組織に加わるときに、適切なシステムで新しいアカウントを自動的に作成できます。Automatically create new accounts in the right systems for new people when they join your team or organization.
  • ユーザーがチームまたは組織を離れるときに、適切なシステムでアカウントを自動的に非アクティブ化できます。Automatically deactivate accounts in the right systems when people leave the team or organization.
  • アプリとシステムの ID は、ディレクトリ (人事システム) の変更に基づいて最新の状態に保たれることが保証されます。Ensure that the identities in your apps and systems are kept up-to-date based on changes in the directory, or your human resources system.
  • ユーザー以外のオブジェクト (グループなど) をサポートするアプリケーションにそれらをプロビジョニングします。Provision non-user objects, such as groups, to applications that support them.

自動化されたユーザー プロビジョニングには、次の機能も含まれています。Automated user provisioning also includes this functionality:

  • ソース システムとターゲット システムとの間で既存の ID を一致させる機能。Ability to match existing identities between source and target systems.
  • ソース システムからターゲット システムにフローするユーザー データを定義する、カスタマイズ可能な属性マッピング。Customizable attribute mappings that define what user data should flow from the source system to the target system.
  • プロビジョニング エラーのためのオプションの電子メール通知。Optional email alerts for provisioning errors.
  • 監視とトラブルシューティングに役立つレポートとアクティビティ ログ。Reporting and activity logs to help with monitoring and troubleshooting.

自動プロビジョニングを使用する理由Why use automated provisioning?

この機能を使用する一般的な動機は、次のとおりです。Some common motivations for using this feature include:

  • 手動によるプロビジョニング プロセスに関連するコスト、非効率性、および人的エラーを回避する。Avoiding the costs, inefficiencies, and human error associated with manual provisioning processes.
  • 独自に開発したプロビジョニング ソリューションやプロビジョニング スクリプトのホスティングとメンテナンスに伴うコストを回避する。Avoiding the costs associated with hosting and maintaining custom-developed provisioning solutions and scripts.
  • ユーザーが組織を離れるときに、主要な SaaS アプリからその ID をすぐに削除することで、組織のセキュリティを高める。Securing your organization by instantly removing users' identities from key SaaS apps when they leave the organization.
  • 多くのユーザーを特定の SaaS アプリまたは SaaS システムに簡単にインポートする。Easily importing a large number of users into a particular SaaS application or system.
  • 誰をプロビジョニングし、誰がアプリにサインインできるようにするかを、1 つのポリシー セットで決定する。Having a single set of policies to determine who is provisioned and who can sign in to an app.

自動プロビジョニングのしくみHow does automatic provisioning work?

Azure AD プロビジョニング サービスは、SaaS アプリや他のシステムに対してユーザーをプロビジョニングするために、各アプリケーション ベンダーから提供されるユーザー管理 API エンドポイントに接続します。The Azure AD Provisioning Service provisions users to SaaS apps and other systems by connecting to user management API endpoints provided by each application vendor. これらのユーザー管理 API エンドポイントを使用すると、Azure AD ではプログラムによってユーザーを作成、更新、削除できます。These user management API endpoints allow Azure AD to programmatically create, update, and remove users. また、一部の限られたアプリケーションについては、ID に関連したその他のオブジェクト (グループ、ロールなど) をプロビジョニング サービスで作成、更新、削除することができます。For selected applications, the provisioning service can also create, update, and remove additional identity-related objects, such as groups and roles.

Azure AD プロビジョニング サービス 図 1: Azure AD プロビジョニング サービスAzure AD Provisioning Service Figure 1: The Azure AD Provisioning Service

出力方向のユーザー プロビジョニング ワークフロー 図 2: Azure AD から主要 SaaS アプリケーションへの "出力方向" のユーザー プロビジョニング ワークフローOutbound user provisioning workflow Figure 2: "Outbound" user provisioning workflow from Azure AD to popular SaaS applications

入力方向のユーザー プロビジョニング ワークフロー 図 3: 主要な人材管理 (HCM) アプリケーションから Azure Active Directory および Windows Server Active Directory への "入力方向" のユーザー プロビジョニング ワークフローInbound user provisioning workflow Figure 3: "Inbound" user provisioning workflow from popular Human Capital Management (HCM) applications to Azure Active Directory and Windows Server Active Directory

Azure AD の自動ユーザー プロビジョニングで利用できるアプリケーションとシステムWhat applications and systems can I use with Azure AD automatic user provisioning?

Azure AD は、一般に普及している多くの SaaS アプリや人事管理システムとの連携にあらかじめ対応しているほか、SCIM 2.0 標準の特定の領域を実装するアプリにも広く対応しています。Azure AD features pre-integrated support for many popular SaaS apps and human resources systems, and generic support for apps that implement specific parts of the SCIM 2.0 standard.

事前統合されたアプリケーションPre-integrated applications

Azure AD が事前統合プロビジョニング コネクタをサポートするすべてのアプリケーションの一覧については、ユーザー プロビジョニングのためのアプリケーション チュートリアルの一覧に関するページを参照してください。For a list of all applications for which Azure AD supports a pre-integrated provisioning connector, see the list of application tutorials for user provisioning.

他のアプリのプロビジョニングのサポートを要求するために Azure AD エンジニア リング チームに問い合わせる場合は、Azure Active Directory フィードバック フォーラムからメッセージを送信してください。To contact the Azure AD engineering team to request provisioning support for additional applications, submit a message through the Azure Active Directory feedback forum.

注意

アプリで自動ユーザー プロビジョニングをサポートするには、まず、外部プログラム上でのユーザーの作成、保守、削除の自動化の実現に必要なユーザー管理 API を提供する必要があります。In order for an application to support automated user provisioning, it must first provide the necessary user management APIs that allow for external programs to automate the creation, maintenance, and removal of users. そのため、すべての SaaS アプリがこの機能と互換性があるとは限りません。Therefore, not all SaaS apps are compatible with this feature. ユーザー管理 API をサポートするアプリでは、Azure AD エンジニア リング チームがこれらのアプリケーションにプロビジョニング コネクタを作成できるようになります。この作業の優先順位は現在の顧客と見込み顧客のニーズによって決まります。For apps that do support user management APIs, the Azure AD engineering team can then build a provisioning connector to those apps, and this work is prioritized by the needs of current and prospective customers.

SCIM 2.0 をサポートするアプリケーションの接続Connecting applications that support SCIM 2.0

SCIM 2.0 ベースのユーザー管理 API を実装するアプリケーションを汎用的に接続する方法については、SCIM を使用した Azure Active Directory からアプリケーションへのユーザーおよびグループの自動プロビジョニングに関するページをご覧ください。For information on how to generically connect applications that implement SCIM 2.0 -based user management APIs, see Using SCIM to automatically provision users and groups from Azure Active Directory to applications.

アプリケーションへの自動プロビジョニングを設定する方法How do I set up automatic provisioning to an application?

Azure Active Directory ポータルを使用して、選択したアプリケーションに対する Azure AD プロビジョニング サービスを構成します。Use the Azure Active Directory portal to configure the Azure AD provisioning service for a selected application.

  1. Azure Active Directory ポータル を開きます。Open the Azure Active Directory portal.

  2. 左側のウィンドウで、 [エンタープライズ アプリケーション] を選択します。Select Enterprise applications from the left pane. 構成済みのすべてのアプリの一覧が表示されます。A list of all configured apps is show.

  3. [+ 新しいアプリケーション] を選択して、アプリケーションを追加します。Choose + New application to add an application. シナリオに応じて、次のいずれかを追加します。Add either of the following depending on your scenario:

    • [独自のアプリを追加する] オプションでは、カスタム開発の SCIM の統合がサポートされます。The Add your own app option supports custom-developed SCIM integrations.
    • [ギャラリーから追加する] > [注目のアプリケーション] セクションに表示されるアプリケーションすべてが、自動プロビジョニングに対応しています。All applications in the Add from the gallery > Featured applications section support automatic provisioning. 追加のアプリケーションについては、ユーザー プロビジョニングのためのアプリケーション チュートリアルの一覧を参照してください。See the list of application tutorials for user provisioning for additional ones.
  4. 詳細を指定し、 [追加] を選択します。Provide any details and select Add. 新しいアプリがエンタープライズ アプリケーションの一覧に追加され、そのアプリケーションの管理画面が表示されます。The new app is added to the list of enterprise applications and opens to its application management screen.

  5. ユーザー アカウントでのアプリのプロビジョニング設定を管理するには、 [プロビジョニング] を選択します。Select Provisioning to manage user account provisioning settings for the app.

    プロビジョニング設定画面を表示します

  6. [プロビジョニング モード] で [自動] オプションを選択し、管理者の資格情報、マッピング、開始と停止、および同期の設定を指定します。Select the Automatic option for the Provisioning Mode to specify settings for admin credentials, mappings, starting and stopping, and synchronization.

    • [管理者資格情報] を展開し、Azure AD をアプリケーションのユーザー管理 API に接続するために必要な資格情報を入力します。Expand Admin credentials to enter the credentials required for Azure AD to connect to the application's user management API. このセクションでは、資格情報でエラーが発生した場合、またはプロビジョニング ジョブが検疫に移行した場合の電子メール通知を有効にすることもできます。This section also lets you enable email notifications if the credentials fail, or the provisioning job goes into quarantine.

    • [マッピング] を展開し、ユーザー アカウントをプロビジョニングまたは更新する場合に、Azure AD とターゲット アプリケーションの間でフローするユーザー属性を表示および編集します。Expand Mappings to view and edit the user attributes that flow between Azure AD and the target application when user accounts are provisioned or updated. ターゲット アプリケーションが対応していれば、必要に応じてグループのプロビジョニングとユーザー アカウントをこのセクションで構成することができます。If the target application supports it, this section lets you optionally configure provisioning of groups and user accounts. テーブルでマッピングを選択すると右側にマッピング エディターが開き、ユーザー属性を表示してカスタマイズできます。Select a mapping in the table to open the mapping editor to the right, where you can view and customize user attributes.

      スコープ フィルターにより、ターゲット システムへのプロビジョニングまたはプロビジョニング解除の対象となるソース システム内のユーザーとグループをプロビジョニング サービスに指定します。Scoping filters tell the provisioning service which users and groups in the source system should be provisioned or deprovisioned to the target system. [属性マッピング] ウィンドウで [ソース オブジェクト スコープ] を選択し、特定の属性値でフィルター処理します。In the Attribute mapping pane, select Source Object Scope to filter on specific attribute values. たとえば、"Department" 属性が "Sales" であるユーザーのみをプロビジョニングの対象として指定することができます。For example, you can specify that only users with a "Department" attribute of "Sales" should be in scope for provisioning. 詳細については、スコープ フィルターの使用に関するページをご覧ください。For more information, see Using scoping filters.

      詳細については、属性マッピングのカスタマイズに関するページを参照してください。For more information, see Customizing Attribute Mappings.

    • 現在実行中かどうかなど、アプリケーションのプロビジョニング サービスの動作は、 [設定] で制御します。Settings control the operation of the provisioning service for an application, including whether it's currently running. [スコープ] メニューでは、割り当て済みのユーザーとグループだけをプロビジョニングの対象とするか、Azure AD ディレクトリ内のすべてのユーザーをプロビジョニングの対象とするかを指定できます。The Scope menu lets you specify whether only assigned users and groups should be in scope for provisioning, or if all users in the Azure AD directory should be provisioned. ユーザーとグループの "割り当て" の詳細については、「Azure Active Directory でエンタープライズ アプリにユーザーまたはグループを割り当てる」を参照してください。For information on "assigning" users and groups, see Assign a user or group to an enterprise app in Azure Active Directory.

アプリ管理画面で、 [監査ログ] を選択し、Azure AD プロビジョニング サービスによって実行されたすべての操作の記録を表示します。In the app management screen, select Audit logs to view records of every operation run by the Azure AD provisioning service. 詳細については、プロビジョニング レポートに関するガイドを参照してください。For more information, see the provisioning reporting guide.

例 - アプリの監査ログ画面

注意

Azure AD ユーザー プロビジョニング サービスは、Microsoft Graph API を使用して構成および管理することもできます。The Azure AD user provisioning service can also be configured and managed using the Microsoft Graph API.

プロビジョニング中の動作What happens during provisioning?

Azure AD がソース システムである場合、プロビジョニング サービスは、Azure AD Graph API の差分クエリ機能を使用してユーザーとグループを監視します。When Azure AD is the source system, the provisioning service uses the Differential Query feature of the Azure AD Graph API to monitor users and groups. プロビジョニング サービスは、ソース システムとターゲット システムに対して初期同期を実行した後、増分同期を定期的に行います。The provisioning service runs an initial sync against the source system and target system, followed by periodic incremental syncs.

初期同期Initial sync

プロビジョニング サービスが開始されたときに行われる最初の同期では、次の処理が実行されます。When the provisioning service is started, the first sync ever run will:

  1. ソース システムのすべてのユーザーとグループにクエリを実行し、属性マッピングで定義されているすべての属性を取得します。Query all users and groups from the source system, retrieving all attributes defined in the attribute mappings.
  2. 返されたユーザーおよびグループを、構成済み割り当てまたは属性ベースのスコープ フィルターを使用してフィルター処理します。Filter the users and groups returned, using any configured assignments or attribute-based scoping filters.
  3. ユーザーが割り当て済み、またはプロビジョニング対象の場合、サービスはターゲット システムに対してクエリを実行し、指定された照合属性を使用して、一致するユーザーがいないかどうかを確認します。When a user is assigned or in scope for provisioning, the service queries the target system for a matching user using the specified matching attributes. 例:ソース システムの userPrincipal 名が一致属性であり、ターゲット システムの userName にマップされる場合、プロビジョニング サービスは、ターゲット システムにクエリを実行し、ソース システムの userPrincipal 名の値と一致する userName がないかどうかを確認します。Example: If the userPrincipal name in the source system is the matching attribute and maps to userName in the target system, then the provisioning service queries the target system for userNames that match the userPrincipal name values in the source system.
  4. 一致するユーザーがターゲット システムで見つからない場合、ソース システムから返された属性を使用してユーザーが作成されます。If a matching user isn't found in the target system, it's created using the attributes returned from the source system. ユーザー アカウントが作成された後、プロビジョニング サービスは新しいユーザー用のターゲット システムの ID を検出しキャッシュします。これはそのユーザーの将来の操作すべてを実行するときに使用されます。After the user account is created, the provisioning service detects and caches the target system's ID for the new user, which is used to run all future operations on that user.
  5. 一致するユーザーが見つかった場合、そのユーザーは、ソース システムによって提供された属性を使用して更新されます。If a matching user is found, it's updated using the attributes provided by the source system. ユーザー アカウントが照合された後、プロビジョニング サービスは新しいユーザー用のターゲット システムの ID を検出しキャッシュします。これはそのユーザーの将来の操作すべてを実行するときに使用されます。After the user account is matched, the provisioning service detects and caches the target system's ID for the new user, which is used to run all future operations on that user.
  6. 属性マッピングに "参照" 属性が含まれている場合、サービスは、ターゲット システムで追加の更新を実行して参照先オブジェクトを作成し、リンクします。If the attribute mappings contain "reference" attributes, the service does additional updates on the target system to create and link the referenced objects. たとえば、あるユーザーがターゲット システムで "Manager" 属性を持ち、それがターゲット システムで作成された別のユーザーにリンクされている場合があります。For example, a user may have a "Manager" attribute in the target system, which is linked to another user created in the target system.
  7. 初期同期の終了時に基準値を保持します。これは、以降の増分同期の始点になります。Persist a watermark at the end of the initial sync, which provides the starting point for the later incremental syncs.

ServiceNow、G Suite、Box など、アプリケーションの中には、ユーザーのプロビジョニングだけでなく、グループとそのメンバーのプロビジョニングをサポートしているものがあります。Some applications such as ServiceNow, G Suite, and Box support not only provisioning users, but also provisioning groups and their members. このような場合、グループのプロビジョニングがマッピングで有効になっていると、プロビジョニング サービスは、ユーザーとグループを同期したうえで、グループ メンバーシップを同期します。In those cases, if group provisioning is enabled in the mappings, the provisioning service synchronizes the users and the groups, and then later synchronizes the group memberships.

増分同期Incremental syncs

初期同期後に行われる他のすべての同期で、次の処理が実行されます。After the initial sync, all other syncs will:

  1. ソース システムにクエリを実行し、前回の基準値が保存された後に更新されたユーザーおよびグループがないかどうかを確認します。Query the source system for any users and groups that were updated since the last watermark was stored.
  2. 返されたユーザーおよびグループを、構成済み割り当てまたは属性ベースのスコープ フィルターを使用してフィルター処理します。Filter the users and groups returned, using any configured assignments or attribute-based scoping filters.
  3. ユーザーが割り当て済み、またはプロビジョニング対象の場合、サービスはターゲット システムに対してクエリを実行し、指定された照合属性を使用して、一致するユーザーがいないかどうかを確認します。When a user is assigned or in scope for provisioning, the service queries the target system for a matching user using the specified matching attributes.
  4. 一致するユーザーがターゲット システムで見つからない場合、ソース システムから返された属性を使用してユーザーが作成されます。If a matching user isn't found in the target system, it's created using the attributes returned from the source system. ユーザー アカウントが作成された後、プロビジョニング サービスは新しいユーザー用のターゲット システムの ID を検出しキャッシュします。これはそのユーザーの将来の操作すべてを実行するときに使用されます。After the user account is created, the provisioning service detects and caches the target system's ID for the new user, which is used to run all future operations on that user.
  5. 一致するユーザーが見つかった場合、そのユーザーは、ソース システムによって提供された属性を使用して更新されます。If a matching user is found, it's updated using the attributes provided by the source system. 新しく割り当てられたアカウントが照合された場合、プロビジョニング サービスは新しいユーザー用のターゲット システムの ID を検出しキャッシュします。これはそのユーザーの将来の操作すべてを実行するときに使用されます。If it's a newly assigned account that is matched, the provisioning service detects and caches the target system's ID for the new user, which is used to run all future operations on that user.
  6. 属性マッピングに "参照" 属性が含まれている場合、サービスは、ターゲット システムで追加の更新を実行して参照先オブジェクトを作成し、リンクします。If the attribute mappings contain "reference" attributes, the service does additional updates on the target system to create and link the referenced objects. たとえば、あるユーザーがターゲット システムで "Manager" 属性を持ち、それがターゲット システムで作成された別のユーザーにリンクされている場合があります。For example, a user may have a "Manager" attribute in the target system, which is linked to another user created in the target system.
  7. 以前プロビジョニングの対象だったユーザーが対象から外れた場合 (割り当てられていない場合を含む)、サービスは、更新を通じてターゲット システムのユーザーを無効にします。If a user that was previously in scope for provisioning is removed from scope (including being unassigned), the service disables the user in the target system via an update.
  8. 以前プロビジョニングの対象だったユーザーが、ソース システムで無効にされた場合、または論理削除された場合、サービスは、更新によってターゲット システムのユーザーを無効にします。If a user that was previously in scope for provisioning is disabled or soft-deleted in the source system, the service disables the user in the target system via an update.
  9. 以前プロビジョニングの対象だったユーザーが、ソース システムから物理的に削除された場合、サービスは、ターゲット システムのユーザーを削除します。If a user that was previously in scope for provisioning is hard-deleted in the source system, the service deletes the user in the target system. Azure AD では、論理削除されたユーザーは、削除されてから 30 日後に物理的に削除されます。In Azure AD, users are hard-deleted 30 days after they're soft-deleted.
  10. 増分同期の終了時に新しい基準値を保持します。これは、以降の増分同期の始点になります。Persist a new watermark at the end of the incremental sync, which provides the starting point for the later incremental syncs.

注意

[マッピング] セクションの [対象オブジェクトのアクション] チェック ボックスを使用して、 [作成][更新] 、または [削除] 操作を必要に応じて無効にできます。You can optionally disable the Create, Update, or Delete operations by using the Target object actions check boxes in the Mappings section. 更新中にユーザーを無効にするロジックは、"accountEnabled" などのフィールドの属性マッピングでも制御されます。The logic to disable a user during an update is also controlled via an attribute mapping from a field such as "accountEnabled".

プロビジョニング サービスは、バックツーバック増分同期を、次のいずれかのイベントが発生するまで、各アプリケーションに固有のチュートリアルで定義された間隔で無期限に実行し続けます。The provisioning service continues running back-to-back incremental syncs indefinitely, at intervals defined in the tutorial specific to each application, until one of the following events occurs:

  • Azure Portal または適切な Graph API コマンドを使用してサービスが手動で停止されたThe service is manually stopped using the Azure portal, or using the appropriate Graph API command
  • Azure Portal の [Clear state and restart](状態をクリアして再起動) オプション、または適切な Graph API コマンドを使用して、新しい初期同期がトリガーされた。A new initial sync is triggered using the Clear state and restart option in the Azure portal, or using the appropriate Graph API command. この操作では、保存された基準値がクリアされ、すべてのソース オブジェクトが再評価されます。This action clears any stored watermark and causes all source objects to be evaluated again.
  • 属性マッピングまたはスコープ フィルターの変更によって、新しい初期同期がトリガーされた。A new initial sync is triggered because of a change in attribute mappings or scoping filters. また、この操作では、保存された基準値がクリアされ、すべてのソース オブジェクトが再評価されます。This action also clears any stored watermark and causes all source objects to be evaluated again.
  • 高いエラー率によりプロビジョニング プロセスが検疫に移行し (以下を参照)、そのまま 4 週間を超えて検疫にとどまっている。The provisioning process goes into quarantine (see below) because of a high error rate, and stays in quarantine for more than four weeks. この場合、サービスは自動的に無効になります。In this event, the service will be automatically disabled.

エラーと再試行Errors and retries

ターゲット システムでのエラーが原因で個々のユーザーの追加、更新、または削除がターゲットシステム上で行えない場合、その操作は次の同期サイクルで再試行されます。If an individual user can't be added, updated, or deleted in the target system because of an error in the target system, then the operation is retried in the next sync cycle. ユーザーの再試行が失敗し続けると、その頻度は減少し始め、1 日 1 回になるように段階的にスケール バックします。If the user continues to fail, then the retries will begin to occur at a reduced frequency, gradually scaling back to just one attempt per day. エラーを解決するには、管理者が監査ログで "プロセス エスクロー" イベントがないかどうかを確認し、根本原因を特定して、適切な対応を取る必要があります。To resolve the failure, administrators must check the audit logs for "process escrow" events to determine the root cause and take the appropriate action. たとえば、次のような一般的なエラーがあります。Common failures can include:

  • ターゲット システムで必要な属性がソース システムのユーザーに設定されていないUsers not having an attribute populated in the source system that is required in the target system
  • ソース システムのユーザーの属性値に対して、ターゲット システムに一意の制約があり、同じ値が他のユーザー レコードに存在するUsers having an attribute value in the source system for which there's a unique constraint in the target system, and the same value is present in another user record

このようなエラーを解決するには、ソース システムで影響を受けるユーザーの属性値を調整するか、競合が発生しないように属性マッピングを調整します。These failures can be resolved by adjusting the attribute values for the affected user in the source system, or by adjusting the attribute mappings to not cause conflicts.

検疫Quarantine

ターゲット システムに対する呼び出しのほとんどまたはすべてが、常にエラー (管理者の資格情報が無効である場合など) が原因で失敗する場合、プロビジョニング ジョブは "検疫" 状態になります。If most or all of the calls made against the target system consistently fail because of an error (such as for invalid admin credentials), then the provisioning job goes into a "quarantine" state. この状態は、プロビジョニング概要レポート、または電子メール (電子メール通知が Azure portal で構成されている場合) で示されます。This state is indicated in the provisioning summary report and via email if email notifications were configured in the Azure portal.

検疫に移行すると、増分同期の頻度は徐々に減少し、最終的には 1 日 1 回になります。When in quarantine, the frequency of incremental syncs is gradually reduced to once per day.

問題を引き起こしているすべてのエラーが修正されたら、プロビジョニング ジョブは検疫から削除され、次の同期サイクルが開始します。The provisioning job will be removed from quarantine after all of the offending errors are fixed and the next sync cycle starts. プロビジョニング ジョブが検疫にとどまっている期間が 4 週間を超えると、そのプロビジョニング ジョブは無効になります。If the provisioning job stays in quarantine for more than four weeks, the provisioning job is disabled.

ユーザーをプロビジョニングするにはどのくらいの時間がかかりますか。How long will it take to provision users?

プロビジョニング ジョブで実行されているのが初期プロビジョニング サイクルか増分サイクルかによって、パフォーマンスが異なります。Performance depends on whether your provisioning job is running an initial provisioning cycle or an incremental cycle. プロビジョニングにかかる時間、およびプロビジョニング サービスの状態を監視する方法について詳しくは、ユーザー プロビジョニングの状態の確認に関するページをご覧ください。For details about how long provisioning takes and how to monitor the status of the provisioning service, see Check the status of user provisioning.

ユーザーが正しくプロビジョニングされているかどうかを確認する方法How can I tell if users are being provisioned properly?

ユーザー プロビジョニング サービスによって実行された操作はすべて、Azure AD の監査ログに記録されます。All operations run by the user provisioning service are recorded in the Azure AD audit logs. これには、ソース システムとターゲット システムに対して実行されたすべての読み取りおよび書き込み操作と、各操作の際に読み取られたり書き込まれたりしたユーザー データが含まれます。This includes all read and write operations made to the source and target systems, and the user data that was read or written during each operation.

Azure portal で監査ログを確認する方法については、プロビジョニング レポートに関するガイドをご覧ください。For information on how to read the audit logs in the Azure portal, see the provisioning reporting guide.

ユーザー プロビジョニングに関する問題のトラブルシューティング方法How do I troubleshoot issues with user provisioning?

自動ユーザー プロビジョニングをトラブルシューティングする方法のシナリオ ベースのガイダンスについては、「アプリケーションに対するユーザーの構成およびプロビジョニングに関する問題」を参照してください。For scenario-based guidance on how to troubleshoot automatic user provisioning, see Problems configuring and provisioning users to an application.

自動ユーザー プロビジョニングを展開するためのベスト プラクティスWhat are the best practices for rolling out automatic user provisioning?

アプリケーションに対する出力方向のユーザー プロビジョニングを展開するための段階的なデプロイ計画の例については、ユーザー プロビジョニングのための ID デプロイ ガイドをご覧ください。For an example step-by-step deployment plan for outbound user provisioning to an application, see the Identity Deployment Guide for User Provisioning.

よく寄せられる質問Frequently asked questions

SaaS アプリへの自動ユーザー プロビジョニングは、Azure AD の B2B ユーザーに対応しますか。Does automatic user provisioning to SaaS apps work with B2B users in Azure AD?

はい、Azure AD ユーザー プロビジョニング サービスを使って、Azure AD の B2B (またはゲスト) ユーザーを SaaS アプリケーションにプロビジョニングすることは可能です。Yes, it's possible to use the Azure AD user provisioning service to provision B2B (or guest) users in Azure AD to SaaS applications.

ただし、B2B ユーザーが、Azure AD を使用して SaaS アプリケーションにサインインするには、SaaS アプリケーションで、SAML ベースのシングル サインオン機能が特定の方法で構成されている必要があります。However, for B2B users to sign in to the SaaS application using Azure AD, the SaaS application must have its SAML-based single sign-on capability configured in a specific way. B2B ユーザーからのサインインをサポートするように SaaS アプリケーションを構成する方法の詳細については、「B2B コラボレーション用の SaaS アプリの構成」を参照してください。For more information on how to configure SaaS applications to support sign-ins from B2B users, see Configure SaaS apps for B2B collaboration.

SaaS アプリへの自動ユーザー プロビジョニングは、Azure AD の動的グループに対応しますか。Does automatic user provisioning to SaaS apps work with dynamic groups in Azure AD?

はい。Yes. "割り当てられているユーザーおよびグループのみを同期する" ように構成されている場合、Azure AD ユーザー プロビジョニング サービスは、SaaS アプリケーションのユーザーを、動的グループのメンバーであるかどうかに基づいて、プロビジョニングまたはプロビジョニング解除できます。When configured to "sync only assigned users and groups", the Azure AD user provisioning service can provision or de-provision users in a SaaS application based on whether they're members of a dynamic group. 動的グループは、「すべてのユーザーとグループを同期する」オプションにも対処します。Dynamic groups also work with the "sync all users and groups" option.

ただし、動的グループの使用は、Azure AD から SaaS アプリケーションへのエンドツーエンドのユーザー プロビジョニングのパフォーマンス全体に影響することがあります。However, usage of dynamic groups can impact the overall performance of end-to-end user provisioning from the Azure AD to SaaS applications. 動的グループを使用している場合は、これらの注意事項と推奨事項に留意してください。When using dynamic groups, keep these caveats and recommendations in mind:

  • SaaS アプリケーションで動的グループのユーザーをプロビジョニングまたはプロビジョニング解除する速度は、動的グループがメンバーシップの変更を評価する速さによって決まります。How fast a user in a dynamic group is provisioned or deprovisioned in a SaaS application depends on how fast the dynamic group can evaluate membership changes. 動的グループの処理状態を確認する方法の詳細については、「メンバーシップ ルールの処理状態をチェックする」を参照してください。For information on how to check the processing status of a dynamic group, see Check processing status for a membership rule.

  • 動的グループを使用しているときに、メンバーシップの喪失はプロビジョニング解除イベントになるので、ユーザープロビジョニングおよびプロビジョニング解除に留意してルールを慎重に考慮する必要があります。When using dynamic groups, the rules must be carefully considered with user provisioning and de-provisioning in mind, as a loss of membership results in a deprovisioning event.

SaaS アプリへの自動ユーザー プロビジョニングは、Azure AD の入れ子になった動的グループに対応しますか。Does automatic user provisioning to SaaS apps work with nested groups in Azure AD?

いいえ。No. "割り当てられたユーザーとグループのみを同期する" ように構成されている場合、Azure AD ユーザー プロビジョニング サービスは、入れ子になったグループに含まれているユーザーを読み取ったりプロビジョニングしたりすることができません。When configured to "sync only assigned users and groups", the Azure AD user provisioning service isn't able to read or provision users that are in nested groups. 明示的に割り当てられたグループの直接のメンバーであるユーザーだけを読み取ってプロビジョニングできます。It's only able to read and provision users that are immediate members of the explicitly assigned group.

これは、「アプリケーションへのグループベースの割り当て」の制限であり、シングル サインオンにも影響し、「SaaS アプリケーションへのアクセスをグループで管理する」で説明しています。This is a limitation of "group-based assignments to applications", which also affects single sign-on and is described in Using a group to manage access to SaaS applications.

対処法として、プロビジョニングする必要のあるユーザーを含んだグループを明示的に割り当てる (またはそれ以外の場合ではスコープする) 必要があります。As a workaround, you should explicitly assign (or otherwise scope in) the groups that contain the users who need to be provisioned.

Azure AD とターゲット アプリケーションの間のプロビジョニングでは、暗号化されたチャネルを使用していますか。Is provisioning between Azure AD and a target application using an encrypted channel?

はい。Yes. サーバー ターゲットに HTTPS SSL 暗号化を使用しています。We use HTTPS SSL encryption for the server target.