Programetablering i karantänstatus

Azure AD-etableringstjänsten övervakar konfigurationens hälsotillstånd. Det placerar även appar med feltillstånd i "karantäntillstånd". Om de flesta, eller alla, av anropen som görs mot målsystemet konsekvent misslyckas markeras etableringsjobbet som i karantän. Ett exempel på ett fel är ett fel som tas emot på grund av ogiltiga administratörsautentiseringsuppgifter.

I karantän:

  • Frekvensen för inkrementella cykler minskas gradvis till en gång per dag.
  • Etableringsjobbet tas bort från karantänen när alla fel har åtgärdats och nästa synkroniseringscykel startar.
  • Om etableringsjobbet finns kvar i karantän i mer än fyra veckor inaktiveras etableringsjobbet (körs inte längre).

Hur gör jag för att om mitt program är i karantän?

Det finns tre sätt att kontrollera om ett program är i karantän:

  • I Azure Portal navigerar du till Azure Active DirectoryEnterprise-programnamnEtablering och <<>>> granskar förloppsfältet för ett karantänmeddelande.

    Provisioning status bar showing quarantine status

  • I Azure Portal navigerar du till Azure Active Directoryfiltrerar granskningsloggarAktivitet: Karantän och granskar karantänhistoriken. Vyn i förloppsfältet enligt beskrivningen ovan visar om etableringen för närvarande är i karantän. Granskningsloggarna visar karantänhistoriken för ett program.

  • Använd Microsoft Graph hämta synkroniseringsjobb för att programmatiskt hämta status för etableringsjobbet:

        GET https://graph.microsoft.com/beta/servicePrincipals/{id}/synchronization/jobs/{jobId}/
  • Gå igenom din e-post. När ett program placeras i karantän skickas ett e-postmeddelande med ett enda meddelande. Om karantänorsaken ändras skickas ett uppdaterat e-postmeddelande som visar den nya orsaken till karantänen. Om du inte ser något e-postmeddelande:

    • Kontrollera att du har angett ett giltigt e-postmeddelande i etableringskonfigurationen för programmet.
    • Kontrollera att det inte finns någon skräppostfiltrering i inkorgen för e-postmeddelanden.
    • Kontrollera att du inte har avslutat prenumerationen på e-postmeddelanden.
    • Sök efter e-postmeddelanden från azure-noreply@microsoft.com

Varför är mitt program i karantän?

Beskrivning Rekommenderad åtgärd
SCIM-efterlevnadsproblem: Svaret HTTP/404 Hittades inte returnerades i stället för det förväntade HTTP/200 OK-svaret. I det här fallet har Azure AD-etableringstjänsten gjort en begäran till målprogrammet och fått ett oväntat svar. Läs avsnittet om administratörsautentiseringsuppgifter. Se om programmet kräver att klient-URL:en anges och att URL:en är korrekt. Om du inte ser något problem kontaktar du programutvecklaren för att säkerställa att deras tjänst är SCIM-kompatibel. https://tools.ietf.org/html/rfc7644#section-3.4.2
Ogiltiga autentiseringsuppgifter: Vid försök att auktorisera åtkomst till målprogrammet fick vi ett svar från målprogrammet som anger att de angivna autentiseringsuppgifterna är ogiltiga. Gå till avsnittet administratörsautentiseringsuppgifter i användargränssnittet för etableringskonfiguration och auktorisera åtkomst igen med giltiga autentiseringsuppgifter. Om programmet finns i galleriet kan du gå igenom självstudien om programkonfiguration för att se om det finns nödvändiga steg längre.
Dubblettroller: Roller som importerats från vissa program som Salesforce och Zendesk måste vara unika. Gå till programmanifestet i Azure Portal och ta bort dubblettrollen.

En Microsoft Graph-begäran om att hämta status för etableringsjobbet visar följande orsak till karantänen:

  • EncounteredQuarantineException anger att ogiltiga autentiseringsuppgifter har angetts. Etableringstjänsten kan inte upprätta en anslutning mellan källsystemet och målsystemet.
  • EncounteredEscrowProportionThreshold anger att etableringen överskred tröskelvärdet för deposition. Det här tillståndet inträffar när mer än 40 % av etableringshändelserna misslyckades. Mer information finns i informationen om tröskelvärde för deposition nedan.
  • QuarantineOnDemand innebär att vi har identifierat ett problem med ditt program och har ställt in det manuellt på karantän.

Tröskelvärden för deposition

Om tröskelvärdet för proportionell deposition uppfylls förs etableringsjobbet i karantän. Den här logiken kan ändras, men fungerar ungefär så som beskrivs nedan:

Ett jobb kan förts i karantän oavsett antal fel för problem som administratörsautentiseringsuppgifter eller SCIM-efterlevnad. I allmänhet är dock 5 000 fel minimikravet för att börja utvärdera om du ska sätta i karantän på grund av för många fel. Ett jobb med 4 000 fel skulle till exempel inte förs i karantän. Men ett jobb med 5 000 fel skulle utlösa en utvärdering. En utvärdering använder följande kriterier:

  • Om mer än 40 % av etableringshändelserna misslyckas, eller om det finns fler än 40 000 fel, förs etableringsjobbet i karantän. Referensfel räknas inte som en del av tröskelvärdet på 40 % eller 40 000. Till exempel är fel vid uppdatering av en chef eller gruppmedlem ett referensfel.
  • Ett jobb där 45 000 användare inte kunde etableras skulle leda till karantän eftersom det överskrider tröskelvärdet på 40 000.
  • Ett jobb där 30 000 användare misslyckades med etableringen och 5 000 lyckades skulle leda till karantän eftersom det överskrider tröskelvärdet på 40 % och 5 000 minimum.
  • Ett jobb med 20 000 fel och 100 000 lyckade fel skulle inte föra i karantän eftersom det inte överskrider tröskelvärdet på 40 % eller maxgränsen på 40 000 fel.
  • Det finns ett absolut tröskelvärde på 60 000 fel som står för både referens- och icke-referensfel. Till exempel kunde 40 000 användare inte etableras och 21 000 manager-uppdateringar misslyckades. Summan är 61 000 fel och överskrider gränsen på 60 000.

Hur gör jag för att kan du få ut mitt program från karantänen?

Lös först problemet som gjorde att programmet placerades i karantän.

  • Kontrollera programmets etableringsinställningar för att kontrollera att du har angett giltiga administratörsautentiseringsuppgifter. Azure AD måste upprätta ett förtroende med målprogrammet. Kontrollera att du har angett giltiga autentiseringsuppgifter och att ditt konto har de behörigheter som krävs.

  • Granska etableringsloggarna för att undersöka vilka fel som orsakar karantänen och åtgärda felet. Gå till Azure Active DirectoryEnterpriseApps-etableringsloggar (förhandsversion) i avsnittet Aktivitet.

När du har löst problemet startar du om etableringsjobbet. Vissa ändringar av programmets etableringsinställningar, till exempel attributmappningar eller omfångsfilter, startar automatiskt om etableringen åt dig. Förloppsfältet på programmets etableringssida visar när etableringen senast startades. Om du behöver starta om etableringsjobbet manuellt använder du någon av följande metoder:

  • Använd Azure Portal för att starta om etableringsjobbet. På programmets etableringssida väljer du Starta om etableringen. Den här åtgärden startar om etableringstjänsten helt, vilket kan ta lite tid. En fullständig inledande cykel körs igen, vilket rensar depositioner, tar bort appen från karantänen och rensar eventuella vattenstämplar. Tjänsten utvärderar sedan alla användare i källsystemet igen och avgör om de omfattas av etableringen. Detta kan vara användbart när ditt program för närvarande är i karantän, som beskrivs i den här artikeln, eller om du behöver göra en ändring i attributmappningarna. Observera att den inledande cykeln tar längre tid att slutföra än den typiska inkrementella cykeln på grund av antalet objekt som behöver utvärderas. Du kan lära dig mer om prestanda för inledande och inkrementella cykler här.

  • Använd Microsoft Graph för att starta om etableringsjobbet. Du har fullständig kontroll över vad du startar om. Du kan välja att rensa depositioner (för att starta om depositionsräknaren som ackumuleras mot karantänstatus), rensa karantän (för att ta bort programmet från karantänen) eller rensa vattenstämplar. Använd följande begäran:

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

Ersätt "{ID}" med värdet för program-ID:t och ersätt "{jobId}" med ID:t för synkroniseringsjobbet.