Aprowizowanie aplikacji w stanie kwarantanny

Usługa microsoft Entra provisioning monitoruje kondycję konfiguracji. Umieszcza również aplikacje w złej kondycji w stanie "kwarantanny". Jeśli większość lub wszystkie wywołania wykonywane względem systemu docelowego stale kończą się niepowodzeniem, zadanie aprowizacji jest oznaczone jako w kwarantannie. Przykładem błędu jest odebrany błąd z powodu nieprawidłowych poświadczeń administratora.

W kwarantannie:

• Częstotliwość cykli przyrostowych jest stopniowo zmniejszana do raz dziennie.
• Zadanie aprowizacji zostanie usunięte z kwarantanny po naprawieniu wszystkich błędów i rozpoczęciu następnego cyklu synchronizacji.
• Jeśli zadanie aprowizacji pozostaje w kwarantannie przez ponad cztery tygodnie, zadanie aprowizacji zostanie wyłączone (przestanie działać).

Jak mogę wiedzieć, czy moja aplikacja jest w kwarantannie?

Istnieją trzy sposoby sprawdzania, czy aplikacja znajduje się w kwarantannie:

• W centrum administracyjnym firmy Microsoft Entra przejdź do pozycji Identity Applications>Enterprise applications application>>provisioning (Aprowizowanie aplikacji<>dla przedsiębiorstw)>i przejrzyj pasek postępu komunikatu o kwarantannie.

  

• W centrum administracyjnym firmy Microsoft Entra przejdź do filtru Dzienniki inspekcji> monitorowania tożsamości>i kondycji>w obszarze Aktywność: kwarantanna i przejrzyj historię kwarantanny. Widok na pasku postępu, jak opisano powyżej, pokazuje, czy aprowizacja jest obecnie w kwarantannie. Dzienniki inspekcji pokazują historię kwarantanny dla aplikacji.

• Użyj żądania programu Microsoft Graph Pobierz synchronizacjęJob , aby programowo uzyskać stan zadania aprowizacji:

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

• Odbierz pocztę e-mail. Po umieszczeniu aplikacji w kwarantannie zostanie wysłana jednorazowa wiadomość e-mail z powiadomieniem. Jeśli przyczyna kwarantanny ulegnie zmianie, zostanie wysłana zaktualizowana wiadomość e-mail z nową przyczyną kwarantanny. Jeśli nie widzisz wiadomości e-mail:

  • Upewnij się, że określono prawidłową wiadomość e-mail z powiadomieniem w konfiguracji aprowizacji aplikacji.
  • Upewnij się, że w skrzynce odbiorczej wiadomości e-mail z powiadomieniem nie ma żadnego filtrowania spamu.
  • Upewnij się, że nie anulowano subskrypcji wiadomości e-mail.
  • Sprawdzanie wiadomości e-mail z azure-noreply@microsoft.com

Dlaczego moja aplikacja znajduje się w kwarantannie?

Poniżej przedstawiono typowe przyczyny, dla których aplikacja może przejść do kwarantanny

opis	Zalecana akcja
Problem ze zgodnością standardu SCIM: Odpowiedź HTTP/404 Nie znaleziono została zwrócona, a nie oczekiwana odpowiedź HTTP/200 OK. W takim przypadku usługa aprowizacji firmy Microsoft złożyła żądanie do aplikacji docelowej i otrzymała nieoczekiwaną odpowiedź.	Sprawdź sekcję poświadczenia administratora. Sprawdź, czy aplikacja wymaga określenia adresu URL dzierżawy i czy adres URL jest poprawny. Jeśli nie widzisz problemu, skontaktuj się z deweloperem aplikacji, aby upewnić się, że ich usługa jest zgodna ze standardem SCIM. https://tools.ietf.org/html/rfc7644#section-3.4.2
Nieprawidłowe poświadczenia: Podczas próby autoryzowania dostępu do aplikacji docelowej otrzymaliśmy odpowiedź od aplikacji docelowej, która wskazuje, że podane poświadczenia są nieprawidłowe.	Przejdź do sekcji poświadczenia administratora interfejsu użytkownika konfiguracji aprowizacji i ponownie autoryzuj dostęp przy użyciu prawidłowych poświadczeń. Jeśli aplikacja znajduje się w galerii, zapoznaj się z samouczkiem dotyczącym konfiguracji aplikacji, aby uzyskać więcej wymaganych kroków.
Zduplikowane role: Role importowane z niektórych aplikacji, takich jak Salesforce i Zendesk, muszą być unikatowe.	Przejdź do manifestu aplikacji w centrum administracyjnym firmy Microsoft Entra i usuń zduplikowaną rolę.

Żądanie programu Microsoft Graph w celu uzyskania stanu zadania aprowizacji pokazuje następującą przyczynę kwarantanny:

• EncounteredQuarantineException wskazuje, że podano nieprawidłowe poświadczenia. Usługa aprowizacji nie może nawiązać połączenia między systemem źródłowym a systemem docelowym.
• EncounteredEscrowProportionThreshold wskazuje, że aprowizowanie przekroczyło próg depozytu. Ten warunek występuje, gdy ponad 40% zdarzeń aprowizacji nie powiodło się. Aby uzyskać więcej informacji, zobacz szczegóły progu depozytu poniżej.
• QuarantineOnDemand oznacza, że wykryliśmy problem z aplikacją i ręcznie ustawiliśmy ją na kwarantannę.

Progi depozytu

Jeśli zostanie osiągnięty proporcjonalny próg depozytu, zadanie aprowizacji przejdzie do kwarantanny. Ta logika może ulec zmianie, ale działa mniej więcej tak, jak opisano poniżej:

Zadanie może przejść do kwarantanny niezależnie od liczby błędów dla problemów, takich jak poświadczenia administratora lub zgodność SCIM. Jednak ogólnie rzecz biorąc, 5000 niepowodzeń to minimum, aby rozpocząć ocenę, czy poddać kwarantannie ze względu na zbyt wiele awarii. Na przykład zadanie z 4000 niepowodzeniami nie zostanie poddane kwarantannie. Jednak zadanie z 5000 niepowodzeniami wyzwoli ocenę. Ocena używa następujących kryteriów:

• Jeśli ponad 40% zdarzeń aprowizacji zakończy się niepowodzeniem lub wystąpi ponad 40 000 niepowodzeń, zadanie aprowizacji przejdzie do kwarantanny. Błędy odwołań nie będą liczone jako część progu 40% ani progu 40 000. Na przykład niepowodzenie aktualizacji menedżera lub członka grupy jest błędem odwołania.
• Zadanie, w którym 45 000 użytkowników nie powiodło się, doprowadziłoby do kwarantanny, ponieważ przekracza próg 40 000.
• Zadanie, w którym 30 000 użytkowników zakończyło się niepowodzeniem, a 5000 zakończyło się powodzeniem, doprowadziłoby do kwarantanny, ponieważ przekracza próg 40% i minimum 5000.
• Zadanie z błędami 20 000 i 100 000 powodzeniem nie zostanie poddane kwarantannie, ponieważ nie przekroczy progu 40% niepowodzenia lub maksymalnej wartości 40 000 niepowodzeń.
• Istnieje bezwzględny próg 60 000 błędów, który odpowiada zarówno na błędy referencyjne, jak i niepowołane. Na przykład nie można aprowizować 40 000 użytkowników, a 21 000 aktualizacji menedżera nie powiodło się. Suma to 61 000 niepowodzeń i przekracza limit 60 000.

Czas trwania ponawiania prób

Logika udokumentowana w tym miejscu może być inna dla niektórych łączników, aby zapewnić najlepsze środowisko klienta, ale ogólnie mamy poniższe cykle ponawiania prób po awarii:

Po awarii pierwsze ponowienie próby nastąpi w ciągu 6 godzin.

• Druga ponowna próba odbywa się 12 godzin po pierwszym niepowodzeniu.
• Trzecia ponowna próba ma miejsce 24 godziny po pierwszym niepowodzeniu.

Po ponowieniu próby będą ponawiane co 24 godziny. Ponowne próby będą trwać przez 28 dni po pierwszym niepowodzeniu, po którym wpis depozytu zostanie usunięty, a zadanie zostanie wyłączone.
Jeśli którakolwiek z powyższych ponownych prób otrzyma pomyślną odpowiedź, zadanie zostanie automatycznie wycofane z kwarantanny i wznowi regularne zachowanie synchronizacji.

Jak mogę wydostać moją aplikację z kwarantanny?

Najpierw rozwiąż problem, który spowodował umieszczenie aplikacji w kwarantannie.

• Sprawdź ustawienia aprowizacji aplikacji, aby upewnić się, że wprowadzono prawidłowe poświadczenia Administracja. Identyfikator Entra firmy Microsoft musi ustanowić relację zaufania z aplikacją docelową. Upewnij się, że wprowadzono prawidłowe poświadczenia, a Twoje konto ma niezbędne uprawnienia.

• Przejrzyj dzienniki aprowizacji, aby dokładniej zbadać, jakie błędy powodują kwarantannę i usunąć błąd. Przejdź do pozycji Microsoft Entra ID>Enterprise Apps>Provisioning logs (wersja zapoznawcza) w sekcji Działanie.

Po rozwiązaniu problemu uruchom ponownie zadanie aprowizacji. Niektóre zmiany ustawień aprowizacji aplikacji, takie jak mapowania atrybutów lub filtry określania zakresu, zostaną automatycznie ponownie uruchomione aprowizowanie. Pasek postępu na stronie Aprowizacja aplikacji wskazuje, kiedy aprowizacja została ostatnio uruchomiona. Jeśli konieczne jest ręczne ponowne uruchomienie zadania aprowizacji, użyj jednej z następujących metod:

• Użyj centrum administracyjnego firmy Microsoft Entra, aby ponownie uruchomić zadanie aprowizacji. Na stronie Aprowizowanie aplikacji wybierz pozycję Uruchom ponownie aprowizację. Ta akcja w pełni uruchamia ponownie usługę aprowizacji, co może zająć trochę czasu. Zostanie ponownie uruchomiony pełny cykl początkowy, który spowoduje wyczyszczenie depozytów, usunięcie aplikacji z kwarantanny i wyczyszczenie wszelkich znaków wodnych. Następnie usługa ponownie oceni wszystkich użytkowników w systemie źródłowym i ustali, czy znajdują się w zakresie aprowizacji. Może to być przydatne, gdy aplikacja jest obecnie w kwarantannie, jak omówiono w tym artykule, lub musisz wprowadzić zmianę w mapowaniach atrybutów. Należy pamiętać, że ukończenie cyklu początkowego trwa dłużej niż typowy cykl przyrostowy ze względu na liczbę obiektów, które należy ocenić. Więcej informacji na temat wydajności cykli początkowych i przyrostowych można znaleźć tutaj.

• Użyj programu Microsoft Graph, aby ponownie uruchomić zadanie aprowizacji. Będziesz mieć pełną kontrolę nad tym, co uruchamiasz ponownie. Możesz wyczyścić deponowania (aby ponownie uruchomić licznik depozytu, który jest naliczany w kierunku stanu kwarantanny), wyczyścić kwarantannę (usunąć aplikację z kwarantanny) lub wyczyścić znaki wodne. Użyj następującego żądania:

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

Zastąp ciąg "{ID}" wartością identyfikatora aplikacji i zastąp ciąg "{jobId}" identyfikatorem zadania synchronizacji.