Karantina durumunda uygulama sağlama

Microsoft Entra sağlama hizmeti yapılandırmanızın durumunu izler. Ayrıca iyi durumda olmayan uygulamaları "karantina" durumuna yerleştirir. Hedef sistemde yapılan çağrıların çoğu veya tümü tutarlı bir şekilde başarısız olursa, sağlama işi karantinada olarak işaretlenir. Hataya örnek olarak, geçersiz yönetici kimlik bilgileri nedeniyle alınan bir hata verilmiştir.

Karantinadayken:

• Artımlı döngülerin sıklığı kademeli olarak günde bir kezye indirilir.
• Sağlama işi tüm hatalar düzeltildikten ve bir sonraki eşitleme döngüsü başladıktan sonra karantinadan kaldırılır.
• Sağlama işi dört haftadan uzun süre karantinada kalırsa sağlama işi devre dışı bırakılır (çalışmayı durdurur).

Uygulamamın karantinada olup olmadığını Nasıl yaparım? biliyor musunuz?

Bir uygulamanın karantinada olup olmadığını denetlemenin üç yolu vardır:

• Microsoft Entra yönetim merkezinde Kimlik>Uygulamaları>Kurumsal uygulamalar<>uygulama adı>>Sağlama'ya gidin ve karantina iletisi için ilerleme çubuğunu gözden geçirin.

  

• Microsoft Entra yönetim merkezinde Etkinlik: Karantina'da Kimlik>İzleme ve sistem durumu>Denetim Günlükleri> filtresi'ne gidin ve karantina geçmişini gözden geçirin. Yukarıda açıklandığı gibi ilerleme çubuğundaki görünüm, sağlamanın şu anda karantinada olup olmadığını gösterir. Denetim günlükleri bir uygulamanın karantina geçmişini gösterir.

• Sağlama işinin durumunu program aracılığıyla almak için Microsoft Graph get synchronizationJob isteğini kullanın:

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

• E-postanızı denetleyin. Bir uygulama karantinaya alındığında tek seferlik bir bildirim e-postası gönderilir. Karantina nedeni değişirse, yeni karantina nedenini gösteren güncelleştirilmiş bir e-posta gönderilir. E-posta görmüyorsanız:

  • Uygulamanın sağlama yapılandırmasında geçerli bir Bildirim E-postası belirttiğinizden emin olun.
  • Bildirim e-postası gelen kutusunda istenmeyen posta filtresi olmadığından emin olun.
  • E-posta aboneliğinizi kaldırmadığınızdan emin olun.
  • E-postaları denetleme azure-noreply@microsoft.com

Uygulamam neden karantinada?

Uygulamanızın karantinaya alınmasına neden olabilecek yaygın nedenler aşağıdadır

Açıklama	Önerilen Eylem
SCIM Uyumluluğu sorunu: Beklenen HTTP/200 Tamam yanıtı yerine bir HTTP/404 Bulunamadı yanıtı döndürüldü. Bu durumda, Microsoft Entra sağlama hizmeti hedef uygulamaya bir istekte bulundu ve beklenmeyen bir yanıt aldı.	Yönetici kimlik bilgileri bölümünü denetleyin. Uygulamanın kiracı URL'sini belirtmeyi gerektirip gerektirmediğini ve URL'nin doğru olup olmadığını denetleyin. Bir sorun görmüyorsanız, hizmetlerinin SCIM uyumlu olduğundan emin olmak için uygulama geliştiricisine başvurun. https://tools.ietf.org/html/rfc7644#section-3.4.2
Geçersiz kimlik bilgileri: Yetkilendirmeye çalışırken hedef uygulamaya erişim, hedef uygulamadan sağlanan kimlik bilgilerinin geçersiz olduğunu belirten bir yanıt aldık.	Sağlama yapılandırma kullanıcı arabiriminin yönetici kimlik bilgileri bölümüne gidin ve geçerli kimlik bilgileriyle erişimi yeniden yetkileyin. Uygulama galerideyse, artık gerekli adımlar için uygulama yapılandırma öğreticisini gözden geçirin.
Yinelenen roller: Salesforce ve Zendesk gibi belirli uygulamalardan içeri aktarılan roller benzersiz olmalıdır.	Microsoft Entra yönetim merkezinde uygulama bildirimine gidin ve yinelenen rolü kaldırın.

Sağlama işinin durumunu almak için bir Microsoft Graph isteği aşağıdaki karantina nedenini gösterir:

• EncounteredQuarantineException geçersiz kimlik bilgilerinin sağlandığını gösterir. Sağlama hizmeti, kaynak sistemle hedef sistem arasında bağlantı kuramıyor.
• EncounteredEscrowProportionThreshold sağlamanın emanet eşiğini aştığını gösterir. Bu koşul, sağlama olaylarının %40'ından fazlası başarısız olduğunda oluşur. Daha fazla bilgi için aşağıdaki emanet eşiği ayrıntılarına bakın.
• QuarantineOnDemand , uygulamanızla ilgili bir sorun algıladığımız ve bunu karantinaya almak için el ile ayarladığımız anlamına gelir.

Emanet eşikleri

Orantılı emanet eşiği karşılanırsa sağlama işi karantinaya alınır. Bu mantık değiştirilebilir, ancak kabaca aşağıda açıklandığı gibi çalışır:

Bir iş, yönetici kimlik bilgileri veya SCIM uyumluluğu gibi sorunlar için hata sayılarından bağımsız olarak karantinaya alabilir. Ancak genel olarak 5.000 hata, çok fazla hata nedeniyle karantinaya alınıp alınmayacağını değerlendirmeye başlamak için en düşük değerdir. Örneğin, 4.000 başarısızlığa sahip bir iş karantinaya alınmaz. Ancak 5.000 başarısızlığa sahip bir iş değerlendirmeyi tetikleyebilir. Değerlendirme aşağıdaki ölçütleri kullanır:

• Sağlama olaylarının %40'ından fazlası başarısız olursa veya 40.000'den fazla hata olursa sağlama işi karantinaya alınır. Başvuru hataları %40 eşiğinin veya 40.000 eşiğinin parçası olarak sayılmaz. Örneğin, bir yöneticinin veya grup üyesinin güncelleştirilememesi bir başvuru hatasıdır.
• 45.000 kullanıcının başarısız şekilde sağlandığı bir iş, 40.000 eşiği aştığında karantinaya alınmasına neden olabilir.
• 30.000 kullanıcının sağlamada başarısız olduğu ve 5.000'in başarılı olduğu bir iş, %40 eşiği ve en az 5.000'i aştığı için karantinaya alınmasına neden olabilir.
• 20.000 başarısızlığa ve 100.000 başarıya sahip bir iş, %40 hata eşiğini veya en fazla 40.000 hata eşiğini aşmadığından karantinaya alınmaz.
• 60.000 hatanın mutlak eşiği vardır ve bu eşik hem başvuru hem de başvuru dışı hataları ifade eder. Örneğin, 40.000 kullanıcı sağlanamadı ve 21.000 yönetici güncelleştirmesi başarısız oldu. Toplam 61.000 hatadır ve 60.000 sınırını aşıyor.

Yeniden deneme süresi

Burada belgelenen mantık, en iyi müşteri deneyimini sağlamak için belirli bağlayıcılar için farklı olabilir, ancak genellikle bir hatadan sonra aşağıdaki yeniden deneme döngülerine sahibiz:

Hatadan sonra ilk yeniden deneme 6 saat içinde gerçekleşir.

• İkinci yeniden deneme, ilk hatadan 12 saat sonra gerçekleşir.
• Üçüncü yeniden deneme, ilk hatadan 24 saat sonra gerçekleşir.

3. yeniden denemeden sonra her 24 saatte bir yeniden denemeler yapılacaktır. Yeniden denemeler, emanet girişinin kaldırıldığı ve işin devre dışı bırakıldığı ilk hatadan sonra 28 gün devam eder.
Yukarıdaki yeniden denemelerden herhangi biri başarılı bir yanıt alırsa, iş otomatik olarak karantinadan çıkarılır ve düzenli eşitleme davranışına devam eder.

Uygulamamı karantinadan çıkarmak Nasıl yaparım??

İlk olarak, uygulamanın karantinaya alınmasına neden olan sorunu çözün.

• Geçerli Yönetici Kimlik Bilgileri girdiğinizden emin olmak için uygulamanın sağlama ayarlarını denetleyin. Microsoft Entra Id hedef uygulamayla bir güven oluşturmalıdır. Geçerli kimlik bilgileri girdiğinizden ve hesabınızın gerekli izinlere sahip olduğundan emin olun.

• Karantinaya neden olan hataları daha fazla araştırmak ve hatayı gidermek için sağlama günlüklerini gözden geçirin. Etkinlik bölümünde Microsoft Entra Id>Enterprise Apps>Sağlama günlükleri (önizleme) bölümüne gidin.

Sorunu çözdükten sonra sağlama işini yeniden başlatın. Öznitelik eşlemeleri veya kapsam filtreleri gibi uygulamanın sağlama ayarlarında yapılan bazı değişiklikler sizin için sağlamayı otomatik olarak yeniden başlatır. Uygulamanın Sağlama sayfasındaki ilerleme çubuğu, sağlamanın en son ne zaman başladığını gösterir. Sağlama işini el ile yeniden başlatmanız gerekiyorsa aşağıdaki yöntemlerden birini kullanın:

• Sağlama işini yeniden başlatmak için Microsoft Entra yönetim merkezini kullanın. Uygulamanın Sağlama sayfasında Sağlamayı yeniden başlat'ı seçin. Bu eylem, sağlama hizmetini tamamen yeniden başlatır ve bu işlem biraz zaman alabilir. Emanetleri temizleyen, uygulamayı karantinadan çıkaran ve tüm eşikleri silen tam bir başlangıç döngüsü yeniden çalıştırılır. Hizmet daha sonra kaynak sistemdeki tüm kullanıcıları yeniden değerlendirir ve sağlama kapsamında olup olmadıklarını belirler. Bu makale anlatıldığı gibi uygulamanız şu anda karantinada olduğunda veya öznitelik eşlemelerinizde bir değişiklik yapmanız gerektiğinde bu yararlı olabilir. İlk döngünün tamamlanmasının, değerlendirilmesi gereken nesne sayısından dolayı tipik artımlı döngüden daha uzun sürdüğünü unutmayın. İlk ve artımlı döngülerin performansı hakkında daha fazla bilgiyi burada bulabilirsiniz.

• Sağlama işini yeniden başlatmak için Microsoft Graph'ı kullanın. Yeniden başlattıklarınız üzerinde tam denetime sahip olursunuz. Emanetleri temizlemeyi (karantina durumuna doğru tahakkuk eden emanet sayacını yeniden başlatmak için), karantinayı temizlemeyi (uygulamayı karantinadan kaldırmak için) veya filigranları temizlemeyi seçebilirsiniz. Aşağıdaki isteği kullanın:

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

"{ID}" değerini Uygulama Kimliği değeriyle, "{jobId}" değerini de eşitleme işinin kimliğiyle değiştirin.