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

Služba zřizování Azure AD monitoruje stav vaší konfigurace. Umístí také aplikace, které nejsou v pořádku, do stavu karantény. Pokud většina nebo všechny hovory provedené v cílovém systému konzistentně selžou, ú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 po opravení všech chyb 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 kontroly, jestli je aplikace v karanténě:

  • V Azure Portal přejděte na Azure Active Directory>Enterprise><název aplikaceprovisioning>> a zkontrolujte indikátor průběhu zprávy o karanténě.

    Provisioning status bar showing quarantine status

  • V Azure Portal přejděte do filtru Azure Active Directory>Audit Logs> on Activity: Quarantine and review the quarantine history. 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í žádosti Microsoft Graph Získat synchronizační úlohu 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. Když se aplikace umístí do karantény, odešle se 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 se vám e-mail nezobrazuje:

    • Ujistěte se, že jste zadali platný e-mail s oznámením v konfiguraci zřizování pro aplikaci.
    • Ujistěte se, že v doručené poště s oznámením není žádný filtr 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ě?

Popis Doporučená akce
Problém s dodržováním předpisů SCIM: Odpověď HTTP/404 Nebyla nalezena místo očekávané odpovědi HTTP/200 OK. V tomto případě služba zřizování Azure AD 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 problém nevidíte, obraťte se na vývojáře aplikací a ujistěte se, že jejich služba vyhovuje předpisům SCIM. https://tools.ietf.org/html/rfc7644#section-3.4.2
Neplatné přihlašovací údaje: Při pokusu o autorizaci jsme dostali od cílové aplikace odpověď, která označuje, ž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, kde najdete požadované kroky.
Duplicitní role: Role importované z určitých aplikací, jako je Salesforce a Zendesk, musí být jedinečné. Přejděte do manifestu aplikace v Azure Portal a odeberte duplicitní roli.

Žádost microsoftu Graph o získání stavu úlohy zřizování ukazuje následující důvod karantény:

  • 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í při selhání více než 40 % událostí zřizování. Další informace najdete v podrobnostech o prahové hodnotě escrow níže.
  • QuarantineOnDemand znamená, že jsme zjistili problém s vaší aplikací a ručně ho nastavili na karanténu.

Prahové hodnoty pro 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ě takto:

Úloha může přejít do karantény bez ohledu na počty selhání problémů, jako jsou přihlašovací údaje správce nebo dodržování předpisů SCIM. Obecně však platí, že 5 000 selhání je minimální, abyste mohli začít vyhodnocovat, jestli se má karanténa vyhodnocovat 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ím, úloha zřizování přejde do karantény. Referenční chyby nebudou počítány jako součást prahové hodnoty 40 % nebo 40 000 prahových hodnot. Například selhání aktualizace manažera nebo člena skupiny je referenční chyba.
  • Úloha, ve které bylo neúspěšně zřízeno 45 000 uživatelů, 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 prahovou hodnotu 40 % a minimálně 5 000.
  • Úloha s 20 000 selháními a 100 000 úspěšností by nešla do karantény, protože nepřekračuje 40% prahovou hodnotu selhání nebo 40 000 selhání max.
  • Existuje absolutní prahová hodnota 60 000 selhání, která představují referenční i nere reference selhání. Například 40 000 uživatelů se nepodařilo zřídit a 21 000 aktualizací správce se nezdařilo. Celkový počet je 61 000 selhání a překračuje limit 60 000.

Návody dostat aplikaci mimo karanténu?

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ávce. Azure AD musí vytvořit vztah důvěryhodnosti s cílovou aplikací. Ujistěte se, že jste zadali platné přihlašovací údaje a váš účet má potřebná oprávnění.

  • Projděte si protokoly zřizování a zjistěte, které chyby způsobují karanténu, a vyřešte chybu. V části Aktivita přejděte na Azure Active Directory> Enterprise Protokoly zřizování aplikací>(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í Azure Portal 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í, která 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ě, protože tento článek popisuje 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.

  • K restartování úlohy zřizování použijte Microsoft Graph. 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í žádost:

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

Nahraďte {ID} hodnotou ID aplikace a nahraďte {jobId} ID synchronizační úlohy.