Provisi aplikasi dalam status karantina

  • Artikel

Layanan provisi Microsoft Entra memantau kesehatan konfigurasi Anda. Ini juga menempatkan aplikasi yang tidak sehat dalam status "karantina". Jika sebagian besar atau semua panggilan yang dilakukan pada sistem target terus gagal, pekerjaan provisi akan ditandai seperti dalam karantina. Contoh kegagalan adalah kesalahan yang diterima karena info masuk admin tidak valid.

Selama di karantina:

  • Frekuensi siklus bertahap secara bertahap dikurangi menjadi sekali per hari.
  • Pekerjaan provisi dihapus dari karantina setelah semua kesalahan diperbaiki dan siklus sinkronisasi berikutnya dimulai.
  • Jika pekerjaan provisi tetap berada dalam karantina selama lebih dari empat minggu, pekerjaan provisi dinonaktifkan (berhenti berjalan).

Bagaimana cara mengetahui apakah aplikasi saya berada dalam karantina?

Ada tiga cara untuk memeriksa apakah aplikasi berada di karantina:

  • Di pusat admin Microsoft Entra, navigasikan ke nama aplikasi<>Identity>Applications>Enterprise Provisi>> dan tinjau bilah kemajuan untuk pesan karantina.

    Provisioning status bar showing quarantine status

  • Di pusat admin Microsoft Entra, navigasikan ke filter Pemantauan Identitas>& Log> Audit kesehatan>pada Aktivitas: Karantina dan tinjau riwayat karantina. Tampilan di bilah kemajuan seperti yang dijelaskan di atas menunjukkan apakah provisi saat ini berada di karantina. Log audit menampilkan riwayat karantina untuk aplikasi.

  • Gunakan permintaan Microsoft Graph Get synchronizationJob untuk mendapatkan status pekerjaan provisi secara terprogram:

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

  • Periksa email Anda. Saat aplikasi ditempatkan di karantina, email notifikasi satu kali akan dikirim. Jika alasan karantina berubah, email yang diperbarui dikirim yang menunjukkan alasan baru untuk karantina. Jika Anda tidak melihat email:

    • Pastikan Anda telah menentukan Email Pemberitahuan yang valid dalam konfigurasi provisi untuk aplikasi.
    • Pastikan tidak ada pemfilteran spam di kotak masuk email pemberitahuan.
    • Pastikan Anda belum berhenti berlangganan dari email.
    • Periksa email dari azure-noreply@microsoft.com

Mengapa aplikasi saya berada di karantina?

Berikut adalah alasan umum aplikasi Anda mungkin masuk ke karantina

Deskripsi Tindakan yang Direkomendasikan
Masalah Kepatuhan SCIM: Respons HTTP/404 Tidak Ditemukan ditampilkan, bukan respons HTTP/200 OK yang diharapkan. Dalam hal ini, layanan provisi Microsoft Entra telah membuat permintaan ke aplikasi target dan menerima respons yang tidak terduga. Periksa bagian info masuk admin. Lihat apakah aplikasi mewajibkan penentuan URL penyewa dan URL tersebut sudah benar. Jika Anda tidak melihat masalah, hubungi pengembang aplikasi untuk memastikan bahwa layanannya mematuhi SCIM. https://tools.ietf.org/html/rfc7644#section-3.4.2
Info masuk tidak valid: Ketika mencoba mengotorisasi, akses ke aplikasi target, kami menerima respons dari aplikasi target yang memperlihatkan info masuk yang diberikan tidak valid. Buka bagian info masuk admin dari UI konfigurasi provisi dan izinkan akses lagi dengan info masuk yang valid. Jika aplikasi berada di galeri, tinjau tutorial konfigurasi aplikasi untuk mengetahui langkah-langkah yang diperlukan lainnya.
Peran duplikat: Peran yang diimpor dari aplikasi tertentu seperti Salesforce dan Zendesk harus unik. Navigasikan ke manifes aplikasi di pusat admin Microsoft Entra dan hapus peran duplikat.

Permintaan Microsoft Graph untuk mendapatkan status pekerjaan provisi menunjukkan alasan berikut untuk karantina:

  • EncounteredQuarantineException menunjukkan bahwa info masuk yang tidak valid disediakan. Layanan provisi tidak dapat membuat koneksi antara sistem sumber dan sistem target.
  • EncounteredEscrowProportionThreshold menunjukkan bahwa provisi melebihi ambang escrow. Kondisi ini terjadi jika lebih dari 40% peristiwa provisi gagal. Untuk informasi selengkapnya, lihat detail ambang batas escrow di bawah.
  • QuarantineOnDemand berarti bahwa kami telah mendeteksi masalah dengan aplikasi Anda dan telah mengaturnya secara manual ke karantina.

Ambang batas escrow

Jika ambang batas escrow yang proporsional terpenuhi, pekerjaan provisi akan dimasukkan ke karantina. Logika ini dapat berubah, tetapi bekerja secara kasar seperti yang dijelaskan di bawah:

Pekerjaan dapat dimasukkan ke karantina terlepas dari jumlah kegagalan masalah seperti info masuk admin atau kepatuhan SCIM. Namun, secara umum, 5.000 kegagalan adalah jumlah minimum untuk mulai mengevaluasi apakah harus dikarantina karena terlalu banyak kegagalan. Misalnya, pekerjaan dengan 4.000 kegagalan tidak akan dimasukkan ke karantina. Tapi, pekerjaan dengan 5.000 kegagalan akan memicu evaluasi. Evaluasi menggunakan kriteria berikut:

  • Jika lebih dari 40% peristiwa provisi gagal, atau ada lebih dari 40.000 kegagalan, pekerjaan provisi akan dimasukkan ke karantina. Kegagalan referensi tidak akan dihitung sebagai bagian dari ambang batas 40% atau ambang batas 40.000. Misalnya, kegagalan untuk memperbarui pengelola atau anggota grup adalah kegagalan referensi.
  • Pekerjaan saat 45.000 pengguna tidak berhasil diprovisikan akan menyebabkan karantina karena melebihi ambang batas 40.000.
  • Pekerjaan saat provisi 30.000 pengguna gagal dan 5.000 berhasil akan menyebabkan karantina karena melebihi ambang batas 40% dan minimum 5.000.
  • Pekerjaan dengan 20.000 kegagalan dan 100.000 keberhasilan tidak akan dikarantina karena tidak melebihi ambang batas kegagalan 40% atau maksimal 40.000 kegagalan.
  • Ada ambang batas mutlak dari 60.000 kegagalan yang menyumbang kegagalan referensi dan non-referensi. Misalnya, 40.000 pengguna gagal diprovisikan dan 21.000 pembaruan pengelola gagal. Totalnya adalah 61.000 kegagalan dan melebihi batas 60.000.

Durasi coba lagi

Logika yang di dokumentasikan di sini mungkin berbeda untuk konektor tertentu untuk memastikan pengalaman pelanggan terbaik, tetapi kami umumnya memiliki siklus coba lagi di bawah ini setelah kegagalan:

Setelah kegagalan, percobaan ulang pertama akan terjadi dalam 6 jam.

  • Percobaan ulang kedua terjadi 12 jam setelah kegagalan pertama.
  • Percobaan ulang ketiga terjadi 24 jam setelah kegagalan pertama.

Akan ada percobaan ulang setiap 24 jam setelah percobaan ulang ke-3. Percobaan ulang akan berlangsung selama 28 hari setelah kegagalan pertama setelah entri escrow dihapus dan pekerjaan dinonaktifkan.
Jika salah satu percobaan ulang di atas mendapatkan respons yang berhasil, pekerjaan secara otomatis dihentikan dari karantina dan akan melanjutkan perilaku sinkronisasi reguler.

Bagaimana cara mengeluarkan aplikasi saya dari karantina?

Pertama, selesaikan masalah yang menyebabkan aplikasi ditempatkan di karantina.

  • Periksa pengaturan provisi aplikasi untuk memastikan Anda telah memasukkan Info Masuk Admin yang valid. ID Microsoft Entra harus membangun kepercayaan dengan aplikasi target. Pastikan Anda telah memasukkan info masuk yang valid dan akun Anda memiliki izin yang diperlukan.

  • Tinjau log provisi untuk menyelidiki lebih lanjut kesalahan apa yang menyebabkan karantina dan mengatasi kesalahan. Buka log Provisi Aplikasi>Perusahaan Microsoft Entra ID>(pratinjau) di bagian Aktivitas.

Setelah Anda menyelesaikan masalah, mulai ulang pekerjaan provisi. Perubahan tertentu pada pengaturan provisi aplikasi, seperti pemetaan atribut atau filter cakupan, akan otomatis memulai ulang provisi untuk Anda. Bilah kemajuan di halaman Provisi aplikasi menunjukkan kapan provisi terakhir dimulai. Jika Anda perlu memulai ulang pekerjaan provisi secara manual, gunakan salah satu metode berikut:

  • Gunakan pusat admin Microsoft Entra untuk memulai ulang pekerjaan provisi. Di halaman Provisi aplikasi, pilih Mulai ulang provisi. Tindakan ini sepenuhnya memulai ulang layanan provisi, yang dapat memakan waktu. Siklus awal penuh akan berjalan lagi, yang akan membersihkan escrow, menghapus aplikasi dari karantina, dan membersihkan semua tanda air. Layanan kemudian akan mengevaluasi semua pengguna dalam sistem sumber lagi dan menentukan apakah mereka berada dalam cakupan provisi. Ini dapat berguna ketika aplikasi Anda saat ini berada di karantina, seperti yang dibahas dalam artikel ini membahas, atau Anda perlu membuat perubahan pada pemetaan atribut Anda. Perhatikan bahwa siklus awal membutuhkan waktu lebih lama untuk diselesaikan daripada siklus bertahap umum karena jumlah objek yang perlu dievaluasi. Anda dapat mempelajari lebih lanjut performa siklus awal dan bertahap di sini.

  • Gunakan Microsoft Graph untuk memulai ulang pekerjaan provisi. Anda akan memiliki kontrol penuh atas apa yang Anda mulai ulang. Anda dapat memilih untuk membersihkan escrow (untuk memulai ulang penghitung escrow yang bertambah ke status karantina), membersihkan karantina (untuk menghapus aplikasi dari karantina), atau menghapus tanda air. Gunakan permintaan berikut:

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

Ganti "{ID}" dengan nilai ID Aplikasi, dan ganti "{jobId}" dengan ID pekerjaan sinkronisasi.