Provisi aplikasi dalam status karantina

Layanan provisi Azure Active Directory 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 portal Microsoft Azure, buka Azure Active Directory>Aplikasi perusahaan><nama aplikasi>>Provisi dan tinjau bilah kemajuan untuk pesan karantina.

    Bilah status provisi memperlihatkan status karantina

  • Di portal Microsoft Azure, buka Azure Active Directory>Log Audit> filter di 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 Azure Active Directory telah mengajukan 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. Buka manifes aplikasi di portal Microsoft Azure 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 pertama, coba lagi pertama terjadi dalam 2 jam ke depan (biasanya dalam siklus sinkronisasi berikutnya).

  • Percobaan ulang kedua terjadi 6 jam setelah kegagalan pertama.
  • Percobaan ulang ketiga terjadi 12 jam setelah kegagalan pertama.
  • Percobaan ulang keempat terjadi 24 jam setelah kegagalan pertama.
  • Percobaan ulang kelima terjadi 48 jam setelah kegagalan pertama.
  • Percobaan ulang keenam terjadi 72 jam setelah kegagalan pertama.
  • Percobaan ulang ketujuh terjadi 96 jam setelah kegagalan pertama.
  • Percobaan ulang kedelapan terjadi 120 jam setelah kegagalan pertama.

Siklus ini diulang setiap 24 jam hingga hari ke-30 saat percobaan ulang dihentikan dan pekerjaan dinonaktifkan.

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. Azure Active Directory 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 Azure Active Directory>Aplikasi Enterprise>Log provisi (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 portal Microsoft Azure 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.