隔離狀態中的應用程式佈建
Microsoft Entra 布建服務會監視設定的健康情況。 它也會將狀況不良的應用程式置於「隔離」狀態。 如果針對目標系統進行的呼叫大多或全部失敗,則布建作業會標示為隔離中。 失敗的範例是因為管理員認證無效而收到錯誤。
隔離時:
- 累加循環的頻率會逐漸減少為每天一次。
- 所有錯誤都已修正且下一個同步處理周期開始之後,布建作業就會從隔離區中移除。
- 如果布建作業停留在隔離區超過四周,則布建工作會停用(停止執行)。
如何? 知道我的應用程式是否處於隔離狀態?
有三種方式可以檢查應用程式是否處於隔離狀態:
在 Microsoft Entra 系統管理中心,流覽至 [身分識別>應用程式>企業應用程式] 應用程式><名稱>>[布建],並檢閱隔離訊息的進度列。
在 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}” 取代為 同步作業的標識符。
意見反應
https://aka.ms/ContentUserFeedback。
即將登場:在 2024 年,我們將逐步淘汰 GitHub 問題作為內容的意見反應機制,並將它取代為新的意見反應系統。 如需詳細資訊,請參閱:提交並檢視相關的意見反應