Az alkalmazás üzembe helyezése karanténállapotban

  • Cikk

A Microsoft Entra kiépítési szolgáltatás figyeli a konfiguráció állapotát. Emellett "karantén" állapotba helyezi a nem megfelelő alkalmazásokat. Ha a célrendszeren végrehajtott hívások többsége vagy mindegyike következetesen sikertelen, akkor a kiépítési feladat karanténban van megjelölve. Hiba például az érvénytelen rendszergazdai hitelesítő adatok miatt kapott hiba.

Karanténban:

  • A növekményes ciklusok gyakorisága fokozatosan naponta egyszer csökken.
  • A kiépítési feladat az összes hiba kijavítása és a következő szinkronizálási ciklus elindítása után törlődik a karanténból.
  • Ha a kiépítési feladat négy hétnél hosszabb ideig karanténban marad, a kiépítési feladat le van tiltva (leáll).

Hogyan tudom, hogy az alkalmazás karanténban van-e?

Háromféleképpen ellenőrizheti, hogy egy alkalmazás karanténban van-e:

  • A Microsoft Entra Felügyeleti központban lépjen az Identity>Applications>Enterprise alkalmazásalkalmazás><nevére>>, és tekintse át a karanténüzenet állapotsorát.

    Provisioning status bar showing quarantine status

  • A Microsoft Entra Felügyeleti központban lépjen az Identity Monitoring & Health>Audit Logs (Tevékenység>: Karantén) szűrőre, és tekintse át a karanténelőzményeket.> A folyamatjelző sáv fent ismertetett nézete azt mutatja, hogy a kiépítés jelenleg karanténban van-e. Az auditnaplók egy alkalmazás karanténelőzményeit mutatják be.

  • A Microsoft Graph-kérelem lekérése szinkronizálási feladat használatával programozott módon lekérheti a kiépítési feladat állapotát:

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

  • Nézze meg az e-mailjeit. Ha egy alkalmazást karanténba helyeznek, a rendszer egyszeri értesítési e-mailt küld. Ha a karantén oka megváltozik, a rendszer egy frissített e-mailt küld, amely megjeleníti a karantén új okát. Ha nem lát e-mailt:

    • Győződjön meg arról, hogy érvényes értesítési e-mailt adott meg az alkalmazás kiépítési konfigurációjában.
    • Győződjön meg arról, hogy nincs levélszemétszűrés az értesítési e-mail beérkezett üzenetek között.
    • Győződjön meg arról, hogy nem iratkozott le az e-mailekről.
    • E-mailek keresése azure-noreply@microsoft.com

Miért van karanténban az alkalmazásom?

Az alábbiakban ismertetjük az alkalmazás karanténba kerülésének gyakori okait

Leírás Recommended Action
SCIM-megfelelőségi probléma: A várt HTTP/200 OK-válasz helyett HTTP/404 Nem található válasz lett visszaadva. Ebben az esetben a Microsoft Entra kiépítési szolgáltatás kérést küldött a célalkalmazásnak, és váratlan választ kapott. Ellenőrizze a rendszergazdai hitelesítő adatok szakaszt. Ellenőrizze, hogy az alkalmazásnak meg kell-e adnia a bérlő URL-címét, és hogy az URL-cím helyes-e. Ha nem látja a problémát, forduljon az alkalmazásfejlesztőhöz, és győződjön meg arról, hogy a szolgáltatás SCIM-kompatibilis. https://tools.ietf.org/html/rfc7644#section-3.4.2
Érvénytelen hitelesítő adatok: A célalkalmazáshoz való hozzáférés engedélyezésekor a célalkalmazás válasza azt jelzi, hogy a megadott hitelesítő adatok érvénytelenek. Lépjen a kiépítési konfigurációs felhasználói felület rendszergazdai hitelesítő adatok szakaszára, és engedélyezze újra a hozzáférést érvényes hitelesítő adatokkal. Ha az alkalmazás a katalógusban található, tekintse át az alkalmazáskonfigurációs oktatóanyagot a további szükséges lépésekért.
Ismétlődő szerepkörök: Egyes alkalmazásokból, például a Salesforce-ból és a Zendeskből importált szerepköröknek egyedinek kell lenniük. Lépjen az alkalmazásjegyzékre a Microsoft Entra felügyeleti központban, és távolítsa el az ismétlődő szerepkört.

A kiépítési feladat állapotának lekérésére vonatkozó Microsoft Graph-kérés a karantén következő okát mutatja:

  • EncounteredQuarantineException azt jelzi, hogy érvénytelen hitelesítő adatok lettek megadva. A kiépítési szolgáltatás nem tud kapcsolatot létesíteni a forrásrendszer és a célrendszer között.
  • EncounteredEscrowProportionThreshold azt jelzi, hogy a kiépítés túllépte a letéti küszöbértéket. Ez a feltétel akkor fordul elő, ha a kiépítési események több mint 40%-a sikertelen volt. További információkért tekintse meg a letéti küszöbérték részleteit alább.
  • QuarantineOnDemand Azt jelenti, hogy észleltük az alkalmazással kapcsolatos problémát, és manuálisan karanténba helyeztük.

Letéti küszöbértékek

Ha az arányos letéti küszöbérték teljesül, a kiépítési feladat karanténba kerül. Ez a logika változhat, de nagyjából az alábbiak szerint működik:

A feladatok karanténba helyezhetők, függetlenül a hibák számától olyan problémák esetén, mint a rendszergazdai hitelesítő adatok vagy az SCIM-megfelelőség. Általában azonban 5000 hiba a minimális ahhoz, hogy elkezdje kiértékelni, hogy túl sok hiba miatt karanténba kell-e helyezni. Egy 4000 hibával rendelkező feladat például nem kerül karanténba. Egy 5000 hibával rendelkező feladat azonban kiértékelést indítana el. A kiértékelés a következő kritériumokat használja:

  • Ha a kiépítési események több mint 40%-a sikertelen, vagy több mint 40 000 hiba történik, a kiépítési feladat karanténba kerül. A referenciahibák nem számítanak bele a 40%-os vagy 40 000 küszöbértékbe. Egy vezető vagy egy csoporttag frissítésének sikertelensége például hivatkozási hiba.
  • Ha 45 000 felhasználót nem sikerült kiépíteni, karanténba kerül, mivel az meghaladja a 40 000-et.
  • Egy olyan feladat, amelyben 30 000 felhasználó nem tudott kiépíteni, és 5000 sikeres volt, karanténba helyezéshez vezetne, mivel meghaladja a 40%-os küszöbértéket és a minimum 5000-et.
  • Egy 20 000 hibával és 100 000 sikerrel rendelkező feladat nem kerül karanténba, mert nem lépi túl a 40%-os hibaküszöböt vagy a 40 000 hiba maximumát.
  • Abszolút küszöbértéke 60 000 hiba, amely a referencia- és a nem referenciahibákat is magában magában adja. Például 40 000 felhasználót nem sikerült kiépíteni, és 21 000 kezelői frissítés nem sikerült. Az összeg 61 000 hiba, és meghaladja a 60 000 korlátot.

Újrapróbálkozás időtartama

Az itt dokumentált logika egyes összekötők esetében eltérő lehet a legjobb felhasználói élmény biztosítása érdekében, de általában az alábbi újrapróbálkozási ciklusok vannak a hiba után:

A hiba után az első újrapróbálkozás 6 órán belül megtörténik.

  • A második újrapróbálkozás az első hiba után 12 órával történik.
  • A harmadik újrapróbálkozás az első hiba után 24 órával történik.

A 3. újrapróbálkozás után 24 óránként újrapróbálkoznak. Az újrapróbálkozás az első hiba után 28 napig folytatódik, amely után a letéti bejegyzés el lesz távolítva, és a feladat le van tiltva.
Ha a fenti újrapróbálkozások bármelyike sikeres választ kap, a feladat automatikusan karanténba kerül, és folytatja a rendszeres szinkronizálási viselkedést.

Hogyan kivenni az alkalmazásom karanténból?

Először oldja meg azt a problémát, amely miatt az alkalmazás karanténba került.

  • Ellenőrizze az alkalmazás kiépítési beállításait, és győződjön meg arról, hogy érvényes Rendszergazda hitelesítő adatokat adott meg. A Microsoft Entra-azonosítónak megbízhatósági kapcsolatot kell létesítenie a célalkalmazással. Győződjön meg arról, hogy érvényes hitelesítő adatokat adott meg, és a fiókja rendelkezik a szükséges engedélyekkel.

  • Tekintse át a kiépítési naplókat a karantént okozó hibák további vizsgálatához és a hiba elhárításához. Nyissa meg a Microsoft Entra ID>Enterprise Apps>kiépítési naplóit (előzetes verzió) a Tevékenység szakaszban.

A probléma megoldása után indítsa újra a kiépítési feladatot. Az alkalmazás kiépítési beállításainak bizonyos módosításai, például az attribútumleképezések vagy a hatókörszűrők automatikusan újraindítják a kiépítést. Az alkalmazás kiépítési oldalán látható folyamatjelző sáv jelzi, hogy mikor indult el a legutóbbi üzembe helyezés. Ha manuálisan kell újraindítania a kiépítési feladatot, használja az alábbi módszerek egyikét:

  • Indítsa újra a kiépítési feladatot a Microsoft Entra felügyeleti központban. Az alkalmazás kiépítési lapján válassza a Kiépítés újraindítása lehetőséget. Ez a művelet teljesen újraindítja a kiépítési szolgáltatást, ami eltarthat egy ideig. Ismét lefut egy teljes kezdeti ciklus, amely törli a letéteket, eltávolítja az alkalmazást a karanténból, és törli a vízjeleket is. A szolgáltatás ezután újból kiértékeli a forrásrendszer összes felhasználóját, és megállapítja, hogy szerepelnek-e az átadás hatókörében. Ez akkor lehet hasznos, ha az alkalmazás jelenleg karanténban van, ahogyan a cikk ismerteti, vagy módosítania kell az attribútumleképezéseket. Vegye figyelembe, hogy a kezdeti ciklus több időt vesz igénybe, mint a tipikus növekményes ciklus a kiértékelendő objektumok száma miatt. A kezdeti és növekményes ciklusok teljesítményéről itt tudhat meg többet.

  • Indítsa újra a kiépítési feladatot a Microsoft Graph használatával. Teljes mértékben szabályozhatja az újraindítást. Dönthet úgy, hogy törli a letéteket (újraindítja a karantén állapota miatt felhalmozódó letétszámlálót), törölheti a karantént (az alkalmazás karanténból való eltávolításához), vagy törölheti a vízjeleket. Használja a következő kérést:

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

Cserélje le a(z) "{ID}" elemet az alkalmazásazonosító értékére, és cserélje le a "{jobId}" elemet a szinkronizálási feladat azonosítójára.