Karantina durumunda uygulama sağlama

Azure AD sağlama hizmeti, yapılandırmanın durumunu izler. Ayrıca iyi durumda olmayan uygulamaları "karantina" durumuna da yertir. Hedef sisteme yapılan çağrıların çoğu veya hepsi tutarlı bir şekilde başarısız olursa sağlama işi karantinada olarak işaretlenir. Geçersiz yönetici kimlik bilgileri nedeniyle alınan bir hata hataya örnek olarak bir örnektir.

Karantinadayken:

  • Artımlı döngülerin sıklığı kademeli olarak günde bir kezye indir indirildi.
  • Tüm hatalar düzeltildikten ve sonraki eşitleme döngüsü başladıktan sonra sağlama işi 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).

Nasıl yaparım? karantinada mı olduğunu biliyor musunuz?

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

  • Aşağıdaki Azure portal Kurumsal uygulamalar Azure Active Directory Adı Sağlama'ya gidin ve karantina > > < > > iletisi için ilerleme çubuğunu gözden geçirebilirsiniz.

    Karantina durumunu gösteren sağlama durumu çubuğu

  • Aşağıdaki Azure portal Etkinlik: Karantinaya Azure Active Directory için > Denetim Günlükleri'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 Microsoft Graph durumunu program aracılığıyla almak için Get synchronizationJob isteğinde Microsoft Graph kullanın:

        GET https://graph.microsoft.com/beta/servicePrincipals/{id}/synchronization/jobs/{jobId}/
  • E-postanızı kontrol edin. Bir uygulama karantinada yerleştirildiğinde, bir kerelik bildirim e-postası gönderilir. Karantina nedeni değişirse, karantinanın yeni 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 filtrelemesi bulunmadığından emin olun.
    • E-postalardan aboneliği kaldırmadığınızdan emin olun.
    • E-postaları denetle azure-noreply@microsoft.com

Uygulamamın neden karantinaya alınsın?

Description Önerilen Eylem
SCIM uyumluluk sorunu: Beklenen HTTP/200 Tamam yanıtı yerine bir HTTP/404 bulunamadı yanıtı döndürüldü. Bu durumda, Azure AD sağlama hizmeti hedef uygulamaya bir istek yaptı ve beklenmeyen bir yanıt aldı. Yönetici kimlik bilgileri bölümünü denetleyin. Uygulamanın kiracı URL 'sini belirtmesini gerektirip gerektirmediğini ve URL 'nin doğru olup olmadığını görün. Bir sorun görmüyorsanız, hizmetinin SCıM 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: Hedef uygulamaya erişim izni verirken, hedef uygulamadan, belirtilen 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 Yetkilendir. Uygulama Galeri 'de ise, 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. Azure portal uygulama bildirimine gidin ve yinelenen rolü kaldırın.

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

  • EncounteredQuarantineException geçersiz kimlik bilgilerinin sağlandığını belirtir. Sağlama hizmeti, kaynak sistemle hedef sistem arasında bağlantı kuramıyor.
  • EncounteredEscrowProportionThreshold sağlamanın escrow eşiğini aşmış olduğunu gösterir. Sağlama olaylarının %40'dan fazlası başarısız olduğunda bu durum oluşur. Daha fazla bilgi için aşağıdaki escrow eşik ayrıntılarına bakın.
  • QuarantineOnDemand , uygulamanıza ilişkin bir sorun algıladık ve el ile karantinaya alınmış olduğu anlamına gelir.

Escrow eşikleri

Orantılı escrow eşiğine uyulsa sağlama işi karantinaya alınır. Bu mantık değişebilir, ancak aşağıda açıklandığı gibi kabaca çalışır:

Bir iş, yönetici kimlik bilgileri veya SCIM uyumluluğu gibi sorunlar için hata sayılarına bakılmaksızın karantinaya gidebilir. Ancak genel olarak 5.000 hata, çok fazla hata nedeniyle karantinaya alınıp alınama Örneğin, 4.000 hatası olan bir iş karantinaya alınamaz. Ancak 5.000 hataya sahip bir iş değerlendirmeyi tetikler. Değerlendirme aşağıdaki ölçütleri kullanır:

  • Sağlama olaylarının %40'dan fazlası başarısız olursa veya 40.000'den fazla hata varsa, sağlama işi karantinaya alınır. Başvuru hataları % 40 eşiğinin veya 40.000 eşiğin parçası olarak sayılmaz. Örneğin, bir yöneticiyi veya grup üyesini güncelleştirme hatası bir başvuru hatasıdır.
  • 45.000 kullanıcının başarısız bir şekilde sağlandı olduğu bir iş, 40.000 eşiği aştıklarında karantinaya alınmasını sağlar.
  • 30.000 kullanıcının sağlamayı başarısız olduğu ve 5.000'in başarılı olduğu bir iş, %40 eşiğini ve en az 5.000'i aştıklarında karantinaya alınmasını sağlar.
  • %40 hata eşiğini veya maksimum 40.000 hata eşiğini aşmayarak 20.000 hataya ve 100.000 başarıya sahip bir iş karantinaya alınamaz.
  • Hem başvuru hem de başvuru dışı hataları hesaba alan 60.000 hatanın mutlak eşiği vardır. Ö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 limitini aşıyor.

Uygulamamı karantinaya alma Nasıl yaparım??

İlk olarak, uygulamanın karantinada yerleştirilmesine neden olan sorunu çözün.

  • Geçerli yönetici kimlik bilgilerini girdiğinizdenemin olmak için uygulamanın sağlama ayarlarını kontrol edin. Azure AD, hedef uygulamayla bir güven sağlamalıdır. Geçerli kimlik bilgilerini girdiğinizden ve hesabınızda gerekli izinlere sahip olduğunuzdan emin olun.

  • Hangi hataların karantinaya neden olduğunu araştırmak ve hatayı gidermek için sağlama günlüklerini gözden geçirin. Etkinlik bölümünde Azure Active Directory > Kurumsal uygulamalar > sağlama günlükleri (Önizleme) bölümüne gidin .

Sorunu çözdükten sonra, sağlama işini yeniden başlatın. Uygulamanın sağlama ayarlarında öznitelik eşlemeleri veya kapsam filtreleri gibi bazı değişiklikler, sağlamayı sizin için otomatik olarak yeniden başlatacak. Uygulamanın sağlama sayfasındaki ilerleme çubuğu, sağlamanın en son ne zaman başlatıldığı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 Azure portal 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. Tam bir başlangıç döngüsünün yeniden çalışması için, escrows 'yi temizler, uygulamayı karantinadan kaldırır ve tüm filigranları temizler. Daha sonra hizmet, kaynak sistemdeki tüm kullanıcıları yeniden değerlendirir ve sağlama kapsamında olup olmadıklarını saptacaktır. Bu makalede açıklandığı gibi, uygulamanız Şu anda karantinaya alınır veya öznitelik eşlemelerinizde bir değişiklik yapmanız gerekiyorsa, bu yararlı olabilir. İlk döngüsünün değerlendirilmesi gereken nesne sayısı nedeniyle, tipik artımlı döngüden daha uzun sürdüğüne göz önünde unutmayın. İlk ve artımlı döngülerin performansı hakkında daha fazla bilgi için buraya bakabilirsiniz.

  • Sağlama Microsoft Graph yeniden başlatmak için Microsoft Graph kullanın. Yeniden başlatma işlemi üzerinde tam denetime sahip oluruz. Escrow'ları temizlemeyi (karantina durumuna doğru tahakkuk eden escrow 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 ise eşitleme işinin kimliğiyle değiştirin.