自動化使用 Azure Active Directory 對於 SaaS 應用程式的使用者佈建和取消佈建Automate user provisioning and deprovisioning to SaaS applications with Azure Active Directory

SaaS 應用程式的自動化使用者佈建是什麼?What is automated user provisioning for SaaS apps?

Azure Active Directory (Azure AD) 可讓您自動化建立、 維護和移除在雲端中的使用者身分識別 (SaaS) 應用程式,例如 Dropbox、 Salesforce、 ServiceNow 等等。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.

這項功能可讓您: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.
  • 確保您的應用程式和系統中的身分識別,可根據目錄或您人力資源系統中的變更保持在最新狀態。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:

  • 比對來源和目標系統之間現有身分識別的功能。The 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 應用程式移除使用者的身分識別,以保護您的組織。Securing your organization by instantly removing users' identities from key SaaS apps when they leave the organization.
  • 輕鬆地匯入大量使用者的特定 SaaS 應用程式或系統。Easily importing a large number of users into a particular SaaS application or system.
  • 有一組原則,以判斷誰佈建,而且誰能夠登入應用程式。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. 針對選取的應用程式,佈建服務可以也建立、 更新和移除其他身分識別相關的物件,例如群組和角色。For selected applications, the provisioning service can also create, update, and remove additional identity-related objects, such as groups and roles.

佈建 圖 1:Azure AD 佈建服務Provisioning Figure 1: The Azure AD Provisioning Service

輸出佈建 圖 2:從 Azure AD 至熱門 SaaS 應用程式的「輸出」使用者佈建工作流程Outbound Provisioning Figure 2: "Outbound" user provisioning workflow from Azure AD to popular SaaS applications

輸入佈建 圖 3:從熱門人力資本管理 (HCM) 應用程式至 Azure Active Directory 和 Windows Server Active Directory 的「輸入」使用者佈建工作流程Inbound Provisioning 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?

支援許多熱門 SaaS 應用程式和人力資源系統,以及用於實作 SCIM 2.0 標準的特定部分的應用程式的一般支援預先整合的 azure AD 功能。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:

  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. 例如,您可以指定只有「部門」屬性為「銷售」的使用者應在佈建範圍中。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.

設定

注意

您也可以使用 Microsoft Graph API來設定和管理 Azure AD 使用者佈建服務。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. 建立使用者帳戶之後,佈建服務會偵測,並會快取新的使用者用來執行所有未來的作業,該使用者的目標系統的識別碼。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. 比對的使用者帳戶之後,佈建服務會偵測,並會快取新的使用者用來執行所有未來的作業,該使用者的目標系統的識別碼。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、 和中支援某些應用程式。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. 建立使用者帳戶之後,佈建服務會偵測,並會快取新的使用者用來執行所有未來的作業,該使用者的目標系統的識別碼。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. 如果它是新指派的帳戶,會比對,佈建服務會偵測,並會快取新的使用者用來執行所有未來的作業,該使用者的目標系統的識別碼。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.

注意

您可以選擇性地停用Create更新,或刪除透過作業目標物件動作中核取方塊對應一節。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 入口網站或使用適當的「圖形 API」來手動停止服務The service is manually stopped using the Azure portal, or using the appropriate Graph API command
  • 使用 Azure 入口網站中的 [清除狀態並重新啟動] 選項,或使用適當的「圖形 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.
  • 佈建程序因為高錯誤率而進入隔離 (如下所示),並處於隔離狀態超過四週。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. 如果使用者持續發生失敗,則會開始降低重試頻率,逐漸調整回每天僅嘗試一次。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
  • 使用者擁有它沒有 unique 條件約束在目標系統中,來源系統中的屬性值和相同的值會出現在另一個使用者記錄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 入口網站中已設定電子郵件通知的電子郵件。This state is indicated in the provisioning summary report and via email if email notifications were configured in the Azure portal.

處於隔離狀態時,增量同步處理的頻率會逐漸降低成一天一次。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. 如果佈建作業處於隔離狀態超過四週,系統就會將它停用。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 sync or an incremental sync.

針對初始同步處理,作業時間取決於許多因素,包括佈建,範圍中的使用者和群組的數目和執行的使用者和來源系統中的群組總數。For initial syncs, the job time depends on many factors, including the number of users and groups in scope for provisioning, and the total number of users and group in the source system. 本節稍後將完整列出會影響初始同步處理效能的因素摘要。A comprehensive list of factors that affect initial sync performance are summarized later in this section.

增量同步處理的作業時間取決於在該同步處理週期偵測到的變更數量。For incremental syncs, the job time depends on the number of changes detected in that sync cycle. 如果少於 5,000 個使用者或群組成員發生變更,則作業可以在單一增量同步處理週期內完成。If there are fewer than 5,000 user or group membership changes, the job can finish within a single incremental sync cycle.

下表摘要說明常見佈建案例的同步處理時間。The following table summarizes synchronization times for common provisioning scenarios. 在這些案例中,來源系統是 Azure AD,而目標系統是 SaaS 應用程式。In these scenarios, the source system is Azure AD and the target system is a SaaS application. 同步處理時間被衍生自 ServiceNow、 工作場所、 Salesforce 和 G Suite 的 SaaS 應用程式的同步處理作業的統計分析。The sync times are derived from a statistical analysis of sync jobs for the SaaS applications ServiceNow, Workplace, Salesforce, and G Suite.

範圍設定Scope configuration 範圍中的使用者、群組和成員Users, groups, and members in scope 初始同步處理時間Initial sync time 增量同步處理時間Incremental sync time
僅同步已指派的使用者與群組Sync assigned users and groups only < 1,000< 1,000 < 30 分鐘< 30 minutes < 30 分鐘< 30 minutes
僅同步已指派的使用者與群組Sync assigned users and groups only 1,000 - 10,0001,000 - 10,000 142 - 708 分鐘142 - 708 minutes < 30 分鐘< 30 minutes
僅同步已指派的使用者與群組Sync assigned users and groups only 10,000 - 100,00010,000 - 100,000 1,170 - 2,340 分鐘1,170 - 2,340 minutes < 30 分鐘< 30 minutes
同步 Azure AD 中的所有使用者和群組Sync all users and groups in Azure AD < 1,000< 1,000 < 30 分鐘< 30 minutes < 30 分鐘< 30 minutes
同步 Azure AD 中的所有使用者和群組Sync all users and groups in Azure AD 1,000 - 10,0001,000 - 10,000 < 30 - 120 分鐘< 30 - 120 minutes < 30 分鐘< 30 minutes
同步 Azure AD 中的所有使用者和群組Sync all users and groups in Azure AD 10,000 - 100,00010,000 - 100,000 713 - 1,425 分鐘713 - 1,425 minutes < 30 分鐘< 30 minutes
同步 Azure AD 中的所有使用者Sync all users in Azure AD < 1,000< 1,000 < 30 分鐘< 30 minutes < 30 分鐘< 30 minutes
同步 Azure AD 中的所有使用者Sync all users in Azure AD 1,000 - 10,0001,000 - 10,000 43 - 86 分鐘43 - 86 minutes < 30 分鐘< 30 minutes

針對 [僅同步已指派的使用者與群組] 設定,您可以使用下列公式來判斷初始同步處理時間的預估最小值和最大值:For the configuration Sync assigned user and groups only, you can use the following formulas to determine the approximate minimum and maximum expected initial sync times:

Minimum minutes =  0.01 x [Number of assigned users, groups, and group members]
Maximum minutes = 0.08 x [Number of assigned users, groups, and group members] 

影響初始同步處理完成時間的因素摘要:Summary of factors that influence the time it takes to complete an initial sync:

  • 佈建範圍中的使用者和群組總數。The total number of users and groups in scope for provisioning.

  • 來源系統 (Azure AD) 中存在的使用者、群組和群組成員總數。The total number of users, groups, and group members present in the source system (Azure AD).

  • 無論使用者佈建範圍中的就會對應到目標應用程式中的現有使用者,或必須建立第一次。Whether users in scope for provisioning are matched to existing users in the target application, or need to be created for the first time. 為其第一次建立所有使用者的同步處理作業需要約兩次只要做為同步處理的作業的所有使用者都會都對應到現有的使用者。Sync jobs for which all users are created for the first time take about twice as long as sync jobs for which all users are matched to existing users.

  • 稽核記錄中的錯誤數目。Number of errors in the audit logs. 如果有許多錯誤且佈建服務已進入隔離狀態,效能就會變差。Performance is slower if there are many errors and the provisioning service has gone into a quarantine state.

  • 目標系統實作的要求速率限制和節流設定。Request rate limits and throttling implemented by the target system. 有些目標系統會實作要求率限制和節流,這可能會影響在大型的同步處理作業期間的效能。Some target systems implement request rate limits and throttling, which can impact performance during large sync operations. 在這樣的情況下,太快收到太多要求的應用程式,可能會因此降低其回應速率或關閉連線。Under these conditions, an app that receives too many requests too fast might slow its response rate or close the connection. 若要改善效能,連接器必須進行調整,傳送應用程式要求的速度不可比應用程式處理這些要求的速度快。To improve performance, the connector needs to adjust by not sending the app requests faster than the app can process them. 由 Microsoft 所建置的佈建連接器會進行這項調整。Provisioning connectors built by Microsoft make this adjustment.

  • 指派群組的數目和大小。The number and sizes of assigned groups. 同步指派群組所花的時間可能比同步使用者的時間長。Syncing assigned groups takes longer than syncing users. 指派群組的數目和大小會影響效能。Both the number and the sizes of the assigned groups impact performance. 如果應用程式啟用群組物件同步處理的對應,則除了使用者外,群組屬性 (例如群組名稱和成員資格) 也會一起同步。If an application has mappings enabled for group object sync, group properties such as group names and memberships are synced in addition to users. 比起只同步使用者物件,這些額外的同步處理將會花費更長時間。These additional syncs will take longer than only syncing user objects.

如何判斷是否已正確佈建使用者?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 入口網站中的稽核記錄的詳細資訊,請參閱佈建報告指南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?

如需將使用者佈建輸出到應用程式的範例逐步部署方案,請參閱適用於使用者佈建的身分識別部署指南For an example step-by-step deployment plan for outbound user provisioning to an application, see the Identity Deployment Guide for User Provisioning.

更多常見問題More frequently asked questions

對 SaaS 應用程式的自動使用者佈建是否適用於 Azure AD 中的 B2B 使用者?Does automatic user provisioning to SaaS apps work with B2B users in Azure AD?

是的就可以使用 Azure AD 使用者佈建服務,以佈建 B2B (或來賓) 使用者在 SaaS 應用程式的 Azure AD 中。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. 如需如何設定支援的 SaaS 應用程式的詳細資訊,請從 B2B 使用者登入,請參閱 < 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.