Zřizování aplikací ve stavu karantény

Služba zřizování Microsoft Entra monitoruje stav vaší konfigurace. Umístí také aplikace, které nejsou v pořádku, do stavu karantény. Pokud většina nebo vše z volání provedených v cílovém systému konzistentně selže, úloha zřizování se označí jako v karanténě. Příkladem selhání je chyba, která se zobrazila kvůli neplatným přihlašovacím údajům správce.

V karanténě:

• Frekvence přírůstkových cyklů se postupně snižuje na jednou za den.
• Úloha zřizování se odebere z karantény, jakmile se opraví všechny chyby a spustí se další cyklus synchronizace.
• Pokud úloha zřizování zůstane v karanténě déle než čtyři týdny, je úloha zřizování zakázaná (přestane běžet).

Návody vědět, jestli je moje aplikace v karanténě?

Existují tři způsoby, jak zkontrolovat, jestli je aplikace v karanténě:

• V Centru pro správu Microsoft Entra přejděte do části Zřizovací název>>aplikace Aplikace<>Identit>Applications>Enterprise a zkontrolujte indikátor průběhu zprávy o karanténě.

  

• V Centru pro správu Microsoft Entra přejděte do filtru protokolů> auditu monitorování identit>a stavu>v aktivitě: Karanténa a zkontrolujte historii karantény. Zobrazení na indikátoru průběhu, jak je popsáno výše, ukazuje, jestli je zřizování aktuálně v karanténě. Protokoly auditu zobrazují historii karantény pro aplikaci.

• Pomocí požadavku Microsoft Graph Get syncJob můžete programově získat stav úlohy zřizování:

        GET https://graph.microsoft.com/beta/servicePrincipals/{id}/synchronization/jobs/{jobId}/

• Zkontrolujte si e-mail. Při umístění aplikace do karantény se odešle jednorázový e-mail s oznámením. Pokud se důvod karantény změní, odešle se aktualizovaný e-mail s novým důvodem karantény. Pokud nevidíte e-mail:

  • Ujistěte se, že jste v konfiguraci zřizování pro aplikaci zadali platný e-mail s oznámením.
  • Ujistěte se, že ve složce doručené pošty s oznámením nedochází k filtrování spamu.
  • Ujistěte se, že jste neodhlásili odběr e-mailů.
  • Kontrola e-mailů z azure-noreply@microsoft.com

Proč je moje aplikace v karanténě?

Níže jsou uvedené běžné důvody, proč může vaše aplikace přejít do karantény.

Popis	Doporučená akce
Problém s dodržováním předpisů SCIM: Místo očekávané odpovědi HTTP/200 OK byla vrácena odpověď HTTP/404 Nenalezena. V tomto případě služba zřizování Microsoft Entra vytvořila požadavek na cílovou aplikaci a přijala neočekávanou odpověď.	Zkontrolujte část přihlašovacích údajů správce. Zjistěte, jestli aplikace vyžaduje zadání adresy URL tenanta a zda je adresa URL správná. Pokud se problém nezobrazuje, obraťte se na vývojáře aplikací a ujistěte se, že jejich služba dodržuje předpisy SCIM. https://tools.ietf.org/html/rfc7644#section-3.4.2
Neplatné přihlašovací údaje: Při pokusu o autorizaci jsme obdrželi od cílové aplikace odpověď, která indikuje, že zadané přihlašovací údaje jsou neplatné.	Přejděte do části přihlašovacích údajů správce uživatelského rozhraní konfigurace zřizování a znovu povolte přístup s platnými přihlašovacími údaji. Pokud je aplikace v galerii, projděte si kurz konfigurace aplikace a vyhledejte požadované kroky.
Duplicitní role: Role importované z určitých aplikací, jako jsou Salesforce a Zendesk, musí být jedinečné.	Přejděte do manifestu aplikace v Centru pro správu Microsoft Entra a odeberte duplicitní roli.

Žádost o získání stavu úlohy zřizování v Microsoft Graphu ukazuje následující důvod pro karanténu:

• EncounteredQuarantineException označuje, že byly zadané neplatné přihlašovací údaje. Služba zřizování nemůže navázat připojení mezi zdrojovým systémem a cílovým systémem.
• EncounteredEscrowProportionThreshold označuje, že zřizování překročilo prahovou hodnotu escrow. K této podmínce dochází v případě, že došlo k selhání více než 40 % událostí zřizování. Další informace najdete níže v podrobnostech o prahové hodnotě escrow.
• QuarantineOnDemand znamená, že jsme zjistili problém s vaší aplikací a ručně jsme ji nastavili na karanténu.

Prahové hodnoty escrow

Pokud je splněná prahová hodnota proporcionální escrow, úloha zřizování přejde do karantény. Tato logika se může změnit, ale funguje přibližně tak, jak je popsáno níže:

Úloha může přejít do karantény bez ohledu na počty selhání v případě problémů, jako jsou přihlašovací údaje správce nebo dodržování předpisů SCIM. Obecně však platí, že minimálně 5 000 selhání je začít vyhodnocovat, jestli se má umístit do karantény kvůli příliš velkému počtu selhání. Například úloha se 4 000 selháními by nešla do karantény. Úloha s 5 000 selháními by ale aktivovala vyhodnocení. Vyhodnocení používá následující kritéria:

• Pokud dojde k selhání více než 40 % událostí zřizování nebo dojde k více než 40 000 selhání, úloha zřizování přejde do karantény. Selhání odkazů se nebudou počítat jako součást prahové hodnoty 40 % nebo prahové hodnoty 40 000. Selhání aktualizace manažera nebo člena skupiny je například selháním odkazu.
• Úloha, ve které bylo 45 000 uživatelů neúspěšně zřízeno, by vedlo k karanténě, protože překračuje 40 000 prahových hodnot.
• Úloha, ve které 30 000 uživatelů selhalo zřizování a 5 000 bylo úspěšné, by vedlo k karanténě, protože překračuje 40% prahovou hodnotu a minimálně 5 000.
• Úloha s 20 000 selháními a 100 000 úspěchů by nepřešla do karantény, protože nepřekračuje 40% prahovou hodnotu selhání nebo maximálně 40 000 selhání.
• Existuje absolutní prahová hodnota 60 000 selhání, která odpovídá referenčním i nenákazovým selháním. Například 40 000 uživatelů se nepodařilo zřídit a 21 000 aktualizací správce se nezdařilo. Celková hodnota je 61 000 selhání a překračuje limit 60 000.

Doba trvání opakování

Logika zdokumentovaná zde může být pro určité konektory odlišná, aby se zajistilo nejlepší uživatelské prostředí, ale obecně máme následující cykly opakování po selhání:

Po selhání dojde k prvnímu opakování za 6 hodin.

• Druhé opakování proběhne 12 hodin po prvním selhání.
• Třetí opakování proběhne 24 hodin po prvním selhání.

Po 3. opakování se budou opakovat každých 24 hodin. Opakování bude pokračovat po dobu 28 dnů po prvním selhání, po kterém se odebere položka escrow a úloha je zakázaná.
Pokud některý z výše uvedených opakování získá úspěšnou odpověď, úloha se automaticky umístí do karantény a obnoví pravidelné chování synchronizace.

Návody dostat aplikaci z karantény?

Nejprve vyřešte problém, který způsobil umístění aplikace do karantény.

• Zkontrolujte nastavení zřizování aplikace a ujistěte se, že jste zadali platné přihlašovací údaje Správa. ID Microsoft Entra musí vytvořit vztah důvěryhodnosti s cílovou aplikací. Ujistěte se, že jste zadali platné přihlašovací údaje a že váš účet má potřebná oprávnění.

• Projděte si protokoly zřizování a prozkoumejte, které chyby způsobují karanténu, a vyřešte chybu. V části Aktivita přejděte do protokolů zřizování podnikových aplikací>Microsoft Entra ID>(Preview).

Po vyřešení problému restartujte úlohu zřizování. Určité změny nastavení zřizování aplikace, jako jsou mapování atributů nebo filtry oborů, se automaticky restartují zřizování za vás. Indikátor průběhu na stránce zřizování aplikace označuje, kdy bylo zřizování naposledy spuštěno. Pokud potřebujete úlohu zřizování restartovat ručně, použijte jednu z následujících metod:

• Pomocí Centra pro správu Microsoft Entra restartujte úlohu zřizování. Na stránce Zřizování aplikace vyberte Restartovat zřizování. Tato akce plně restartuje službu zřizování, což může nějakou dobu trvat. Znovu se spustí úplný počáteční cyklus, čímž se zruší úschovy, aplikace se odebere z karantény a vymažou se všechny vodoznaky. Služba pak znovu vyhodnotí všechny uživatele ve zdrojovém systému a určí, jestli jsou v oboru pro zřizování. To může být užitečné, když je vaše aplikace aktuálně v karanténě, jak popisuje tento článek, nebo potřebujete provést změnu mapování atributů. Všimněte si, že dokončení počátečního cyklu trvá déle než typický přírůstkový cyklus kvůli počtu objektů, které je potřeba vyhodnotit. Další informace o výkonu počátečních a přírůstkových cyklů najdete tady.

• Pomocí Microsoft Graphu restartujte úlohu zřizování. Budete mít plnou kontrolu nad tím, co restartujete. Můžete se rozhodnout vymazat escrows (chcete-li restartovat čítač escrow, který nabíhá směrem ke stavu karantény), vymazat karanténu (odebrat aplikaci z karantény) nebo vymazat vodoznaky. Použijte následující požadavek:

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

Nahraďte {ID} hodnotou ID aplikace a nahraďte {jobId} ID úlohy synchronizace.