隔離狀態中的應用程式佈建

Microsoft Entra 布建服務會監視設定的健康情況。 它也會將狀況不良的應用程式置於「隔離」狀態。 如果針對目標系統進行的呼叫大多或全部失敗,則布建作業會標示為隔離中。 失敗的範例是因為管理員認證無效而收到錯誤。

隔離時:

  • 累加循環的頻率會逐漸減少為每天一次。
  • 所有錯誤都已修正且下一個同步處理周期開始之後,布建作業就會從隔離區中移除。
  • 如果布建作業停留在隔離區超過四周,則布建工作會停用(停止執行)。

如何? 知道我的應用程式是否處於隔離狀態?

有三種方式可以檢查應用程式是否處於隔離狀態:

  • 在 Microsoft Entra 系統管理中心,流覽至 [身分識別>應用程式>企業應用程式] 應用程式><名稱>>[布建],並檢閱隔離訊息的進度列。

    Provisioning status bar showing quarantine status

  • 在 Microsoft Entra 系統管理中心,流覽至 [活動:隔離] 上的 [身分識別>監視與健康情況>稽核記錄>] 篩選,並檢閱隔離歷程記錄。 如上所述,進度列中的檢視會顯示布建目前是否處於隔離狀態。 稽核記錄會顯示應用程式的隔離歷程記錄。

  • 使用 Microsoft Graph 要求 Get synchronizationJob 以程序設計方式取得布建作業的狀態:

        GET https://graph.microsoft.com/beta/servicePrincipals/{id}/synchronization/jobs/{jobId}/
  • 檢查您的電子郵件。 當應用程式置於隔離區時,會傳送一次性通知電子郵件。 如果隔離原因變更,則會傳送更新的電子郵件,以顯示隔離的新原因。 如果您沒有看到電子郵件:

    • 請確定您已在應用程式的布建組態中指定有效的 通知電子郵件
    • 請確定通知電子郵件收件匣上沒有垃圾郵件篩選。
    • 請確定您尚未取消訂閱電子郵件。
    • 檢查電子郵件的來源 azure-noreply@microsoft.com

為什麼我的應用程式處於隔離狀態?

以下是您的應用程式可能進入隔離的常見原因

描述 建議的動作
SCIM 合規性問題: 傳回 HTTP/404 找不到回應,而不是預期的 HTTP/200 OK 回應。 在此情況下,Microsoft Entra 布建服務已向目標應用程式提出要求,並收到非預期的回應。 檢查管理員認證一節。 查看應用程式是否需要指定租使用者URL,且URL是否正確。 如果您沒有看到問題,請連絡應用程式開發人員,以確保其服務符合 SCIM 規範。 https://tools.ietf.org/html/rfc7644#section-3.4.2
無效的認證: 嘗試授權、存取目標應用程式時,我們收到來自目標應用程式的回應,指出提供的認證無效。 流覽至布建組態 UI 的 [管理員認證] 區段,並使用有效的認證再次授權存取權。 如果應用程式位於資源庫中,請檢閱應用程式組態教學課程,以取得不再需要的步驟。
重複的角色: 從 Salesforce 和 Zendesk 等特定應用程式匯入的角色必須是唯一的。 流覽至 Microsoft Entra 系統管理中心的應用程式指令清單 ,並移除重複的角色。

取得布建作業狀態的 Microsoft Graph 要求會顯示下列隔離原因:

  • EncounteredQuarantineException 表示已提供無效的認證。 布建服務無法建立來源系統與目標系統之間的連線。
  • EncounteredEscrowProportionThreshold 表示布建超過委付閾值。 當超過 40% 的布建事件失敗時,就會發生此情況。 如需詳細資訊,請參閱下方的委付閾值詳細數據。
  • QuarantineOnDemand 表示我們偵測到您的應用程式有問題,並手動將它設定為隔離。

委付臨界值

如果符合比例的委付閾值,布建作業將會進入隔離狀態。 此邏輯可能會變更,但運作大致如下:

不論系統管理員認證或SCIM合規性等問題的失敗計數為何,作業都可以進入隔離區。 不過,一般而言,5,000 個失敗是開始評估是否因為太多失敗而隔離的最低點。 例如,有 4,000 個失敗的作業不會進入隔離區。 但是,有 5,000 個失敗的工作會觸發評估。 評估會使用下列準則:

  • 如果超過 40% 的布建事件失敗,或有超過 40,000 個失敗,布建作業將會進入隔離狀態。 參考失敗不會計入 40% 閾值或 40,000 閾值的一部分。 例如,更新管理員或群組成員失敗是參考失敗。
  • 未成功布建 45,000 名使用者的工作會導致隔離,因為它超過 40,000 個閾值。
  • 一項工作,其中 30,000 個使用者布建失敗,5,000 個成功會導致隔離,因為它超過 40% 閾值和 5,000 個最小值。
  • 有 20,000 個失敗和 100,000 次成功的作業不會進入隔離區,因為它未超過 40% 的失敗閾值或 40,000 個失敗上限。
  • 有 60,000 個失敗的絕對臨界值,可同時考慮參考和非參考失敗。 例如,40,000 個用戶無法布建,且 21,000 個管理員更新失敗。 總計為 61,000 個失敗,超過 60,000 個限制。

重試持續時間

某些連接器記載的邏輯可能不同,以確保最佳的客戶體驗,但我們通常會在失敗後有下列重試週期:

失敗之後,第一次重試會在6小時內發生。

  • 第二次重試會在第一次失敗后的 12 小時發生。
  • 第三次重試會在第一次失敗后的 24 小時發生。

在第三次重試之後,每隔 24 小時重試一次。 重試會在第一次失敗之後持續 28 天,之後移除委付專案並停用作業。
如果上述任何重試都取得成功的回應,作業會自動從隔離區中取出,並應繼續定期同步處理行為。

如何? 我的應用程式無法隔離嗎?

首先,解決導致應用程式置於隔離區的問題。

  • 檢查應用程式的布建設定,以確定您已輸入有效的 管理員 認證。 Microsoft Entra ID 必須與目標應用程式建立信任。 請確定您已輸入有效的認證,且您的帳戶具有必要的許可權。

  • 檢閱布 建記錄 檔,以進一步調查造成隔離的錯誤,並解決錯誤。 移至 [活動] 區段中的 Microsoft Entra ID>Enterprise Apps>布建記錄 (預覽)。

解決問題之後,請重新啟動佈建作業。 應用程式布建設定的某些變更,例如屬性對應或範圍篩選,將會自動重新啟動布建。 應用程式布建頁面上的進度列會指出布建上次啟動的時間。 如果您需要手動重新啟動布建作業,請使用下列其中一種方法:

  • 使用 Microsoft Entra 系統管理中心重新啟動布建作業。 在應用程式的 [布建 ] 頁面上,選取 [ 重新啟動布建]。 此動作會完全重新啟動布建服務,這可能需要一些時間。 完整的初始週期將會再次執行,這會清除 escrows、將應用程式從隔離中移除,並清除任何浮水印。 服務接著會再次評估來源系統中的所有使用者,並判斷這些使用者是否在佈建範圍內。 當您的應用程式目前處於隔離狀態,如本文所討論,或您需要變更屬性對應時,這非常有用。 請注意,由於需要評估的物件數目,初始迴圈需要比一般累加循環更長的時間來完成。 您可以在這裡深入瞭解初始和累加循環的效能。

  • 使用 Microsoft Graph 重新啟動 佈建作業。 您將完全控制重新啟動的內容。 您可以選擇清除委付(重新啟動累算至隔離狀態的委付計數器)、清除隔離(從隔離中移除應用程式),或清除浮水印。 使用下列要求:

        POST /servicePrincipals/{id}/synchronization/jobs/{jobId}/restart

將 “{ID}” 取代為應用程式識別符的值,並將 “{jobId}” 取代為 同步作業的標識符。