Cara kerja Provisi Aplikasi di ID Microsoft Entra

Artikel
10/24/2023

Provisi otomatis mengacu pada pembuatan identitas dan peran pengguna di aplikasi cloud yang perlu diakses pengguna. Selain membuat identitas pengguna, provisi otomatis mencakup pemeliharaan dan penghapusan identitas pengguna saat status atau peran berubah. Sebelum memulai penyebaran, Anda dapat meninjau artikel ini untuk mempelajari cara kerja provisi Microsoft Entra dan mendapatkan rekomendasi konfigurasi.

Layanan provisi Microsoft Entra memprovisikan pengguna ke aplikasi SaaS dan sistem lain dengan menyambungkan ke titik akhir API manajemen pengguna System for Cross-Domain Identity Management (SCIM) 2.0 yang disediakan oleh vendor aplikasi atau agen provisi lokal. Titik akhir SCIM ini memungkinkan MICROSOFT Entra ID membuat, memperbarui, dan menghapus pengguna secara terprogram. Untuk aplikasi yang dipilih, layanan provisi juga dapat membuat, memperbarui, dan menghapus objek terkait identitas tambahan, seperti grup. Saluran yang digunakan untuk provisi antara ID Microsoft Entra dan aplikasi dienkripsi menggunakan enkripsi HTTPS TLS 1.2.

Gambar 1: Layanan provisi Microsoft Entra

Alur kerja provisi pengguna keluar Gambar 2: Alur kerja provisi pengguna "Keluar" dari ID Microsoft Entra ke aplikasi SaaS populer

Alur kerja provisi pengguna masuk Gambar 3: Alur kerja provisi pengguna "Masuk" dari aplikasi Human Capital Management (HCM) populer ke ID Microsoft Entra dan Direktori Aktif Windows Server

Provisi menggunakan SCIM 2.0

Layanan provisi Microsoft Entra menggunakan protokol SCIM 2.0 untuk provisi otomatis. Layanan ini terhubung ke titik akhir SCIM untuk aplikasi, dan menggunakan skema objek pengguna SCIM dan REST API untuk mengotomatiskan provisi dan deprovisi pengguna dan grup. Konektor provisi berbasis SCIM disediakan untuk sebagian besar aplikasi di galeri Microsoft Entra. Pengembang menggunakan API manajemen pengguna SCIM 2.0 di ID Microsoft Entra untuk membangun titik akhir untuk aplikasi mereka yang terintegrasi dengan layanan provisi. Untuk mengetahui detailnya, lihat Membuat titik akhir SCIM dan mengonfigurasi provisi pengguna. Agen provisi lokal juga menerjemahkan operasi Microsoft Entra SCIM ke LDAP, SQL , REST atau SOAP, PowerShell, memanggil ke konektor ECMA kustom, atau konektor dan gateway yang dibangun oleh mitra.

Untuk meminta konektor provisi Microsoft Entra otomatis untuk aplikasi yang saat ini tidak memilikinya, lihat Permintaan Aplikasi Microsoft Entra.

Authorization

Kredensial diperlukan agar ID Microsoft Entra tersambung ke API manajemen pengguna aplikasi. Saat mengonfigurasi provisi pengguna otomatis untuk aplikasi, Anda perlu memasukkan kredensial yang valid. Untuk aplikasi galeri, Anda dapat menemukan jenis kredensial dan persyaratan untuk aplikasi dengan merujuk ke tutorial aplikasi. Untuk aplikasi non-galeri, Anda dapat merujuk ke dokumentasi SCIM untuk memahami jenis dan persyaratan info masuk. Di pusat admin Microsoft Entra, Anda dapat menguji kredensial dengan meminta Microsoft Entra ID mencoba menyambungkan ke aplikasi provisi aplikasi menggunakan kredensial yang disediakan.

Atribut pemetaan

Saat Anda mengaktifkan provisi pengguna untuk aplikasi SaaS pihak ketiga, pusat admin Microsoft Entra mengontrol nilai atributnya melalui pemetaan atribut. Pemetaan menentukan atribut pengguna yang mengalir antara ID Microsoft Entra dan aplikasi target saat akun pengguna disediakan atau diperbarui.

Ada serangkaian atribut dan pemetaan atribut yang telah dikonfigurasi sebelumnya antara objek pengguna Microsoft Entra dan setiap objek pengguna aplikasi SaaS. Beberapa aplikasi mengelola jenis objek lain bersama dengan Pengguna, seperti Grup.

Saat menyiapkan provisi, penting untuk meninjau dan mengonfigurasi pemetaan atribut dan alur kerja yang menentukan properti pengguna (atau grup) mana yang mengalir dari ID Microsoft Entra ke aplikasi. Tinjau dan konfigurasikan properti yang cocok(Cocokkan objek menggunakan atribut ini) yang digunakan untuk mengidentifikasi dan mencocokkan pengguna/grup secara unik di antara kedua sistem.

Anda dapat menyesuaikan pemetaan atribut default sesuai dengan kebutuhan bisnis Anda. Jadi, Anda dapat mengubah atau menghapus pemetaan atribut yang ada, atau membuat pemetaan atribut baru. Untuk mengethaui detailnya, lihat Menyesuaikan pemetaan atribut provisi pengguna untuk aplikasi SaaS.

Saat Anda mengonfigurasi provisi ke aplikasi SaaS, salah satu jenis pemetaan atribut yang dapat Anda tentukan adalah pemetaan ekspresi. Untuk pemetaan ini, Anda harus menulis ekspresi seperti skrip yang memungkinkan Anda mengubah data pengguna menjadi format yang lebih dapat diterima untuk aplikasi SaaS. Untuk mengetahui detailnya, lihat Menulis ekspresi untuk pemetaan atribut.

Cakupan

Cakupan berbasis penetapan

Untuk provisi keluar dari ID Microsoft Entra ke aplikasi SaaS, mengandalkan penetapan pengguna atau grup adalah cara paling umum untuk menentukan pengguna mana yang berada dalam cakupan provisi. Karena penetapan pengguna juga digunakan untuk mengaktifkan akses menyeluruh, metode yang sama dapat digunakan untuk mengelola akses dan provisi. Cakupan berbasis penetapan tidak berlaku untuk skenario provisi masuk seperti Workday dan Successfactors.

Grup. Dengan paket lisensi Microsoft Entra ID P1 atau P2, Anda dapat menggunakan grup untuk menetapkan akses ke aplikasi SaaS. Kemudian, ketika cakupan provisi diatur ke Sinkronkan hanya pengguna dan grup yang ditetapkan, layanan provisi Microsoft Entra menyediakan atau mencabut provisi pengguna berdasarkan apakah mereka anggota grup yang ditetapkan ke aplikasi. Objek grup itu sendiri tidak disediakan kecuali aplikasi mendukung objek grup. Pastikan bahwa grup yang ditetapkan ke aplikasi Anda memiliki properti "SecurityEnabled" yang diatur ke "True".
Grup dinamis. Layanan provisi pengguna Microsoft Entra dapat membaca dan memprovisikan pengguna dalam grup dinamis. Ingatlah peringatan dan rekomendasi ini:
- Grup dinamis dapat memengaruhi performa provisi end-to-end dari ID Microsoft Entra ke aplikasi SaaS.
- Seberapa cepat pengguna dalam grup dinamis disediakan atau dideprovisi dalam aplikasi SaaS tergantung pada seberapa cepat grup dinamis dapat mengevaluasi perubahan keanggotaan. Untuk mengetahui informasi tentang cara memeriksa status pemrosesan grup dinamis, lihat Memeriksa status pemrosesan untuk aturan keanggotaan.
- Saat pengguna kehilangan keanggotaan dalam grup dinamis, itu dianggap sebagai peristiwa deprovisi. Pertimbangkan skenario ini saat membuat aturan untuk grup dinamis.
Grup berlapis. Layanan provisi pengguna Microsoft Entra tidak dapat membaca atau memprovisikan pengguna dalam grup berlapis. Layanan ini hanya dapat membaca dan menyediakan pengguna yang merupakan anggota langsung dari grup yang ditetapkan secara eksplisit. Batasan "penetapan berbasis grup ke aplikasi" ini juga memengaruhi akses menyeluruh (lihat Menggunakan grup untuk mengelola akses ke aplikasi SaaS). Sebagai gantinya, langsung tetapkan atau cakup dalam grup yang berisi pengguna yang perlu disediakan.

Cakupan berbasis atribut

Anda dapat menggunakan filter cakupan untuk menentukan aturan berbasis atribut yang menentukan pengguna mana yang disediakan untuk aplikasi. Metode ini umumnya digunakan untuk provisi masuk dari aplikasi HCM ke ID Microsoft Entra dan Direktori Aktif. Filter cakupan dikonfigurasi sebagai bagian dari pemetaan atribut untuk setiap konektor provisi pengguna Microsoft Entra. Untuk mengetahui detail tentang mengonfigurasi filter cakupan berbasis atribut, lihat Provisi aplikasi berbasis atribut dengan filter cakupan.

Pengguna B2B (tamu)

Dimungkinkan untuk menggunakan layanan provisi pengguna Microsoft Entra untuk memprovisikan pengguna B2B (tamu) di ID Microsoft Entra ke aplikasi SaaS. Namun, bagi pengguna B2B untuk masuk ke aplikasi SaaS menggunakan MICROSOFT Entra ID, Anda harus mengonfigurasi aplikasi SaaS secara manual untuk menggunakan ID Microsoft Entra sebagai Id identitas Security Assertion Markup Language (SAML).

Ikuti panduan umum ini saat mengonfigurasi aplikasi SaaS untuk pengguna B2B (tamu):

Untuk sebagian besar aplikasi, penyiapan pengguna perlu dilakukan secara manual. Pengguna juga harus dibuat secara manual di aplikasi.
Untuk aplikasi yang mendukung penyiapan otomatis, seperti Dropbox, undangan terpisah dibuat dari aplikasi. Pengguna harus yakin untuk menerima setiap undangan.
Dalam atribut pengguna, untuk mengurangi masalah apa pun dengan disk profil pengguna (UPD) yang rusak di pengguna tamu, selalu atur pengidentifikasi pengguna ke user.mail.

Catatan

UserPrincipalName untuk pengguna kolaborasi B2B mewakili alamat email pengguna eksternal alias@theirdomain sebagai "alias_theirdomain#EXT#@yourdomain". Saat atribut userPrincipalName disertakan dalam pemetaan atribut Anda sebagai atribut sumber, dan pengguna B2B sedang disediakan, #EXT# dan domain Anda dihapus dari userPrincipalName, jadi hanya alias@domainmereka yang asli yang digunakan untuk pencocokan atau provisi. Jika Anda memerlukan nama prinsipal pengguna lengkap termasuk #EXT# dan domain Anda untuk ada, ganti namaUserPrincipalName dengan originalUserPrincipalName sebagai atribut sumber.
userPrincipalName = alias@theirdomain
originalUserPrincipalName = alias_theirdomain#EXT#@yourdomain

Siklus provisi: Awal dan bertahap

Saat MICROSOFT Entra ID adalah sistem sumber, layanan provisi menggunakan kueri delta untuk melacak perubahan dalam data Microsoft Graph untuk memantau pengguna dan grup. Layanan provisi menjalankan siklus awal terhadap sistem sumber dan sistem target, diikuti oleh siklus bertahap berkala.

Siklus awal

Saat layanan provisi dimulai, siklus pertama akan:

Membuat kueri semua pengguna dan grup dari sistem sumber, mengambil semua atribut yang ditentukan dalam pemetaan atribut.
Memfilter pengguna dan grup yang ditampilkan, menggunakan penetapan atau filter cakupan berbasis atribut yang konfigurasi.
Saat pengguna ditetapkan atau dalam cakupan untuk provisi, layanan membuat kueri sistem target untuk pengguna yang cocok menggunakan atribut pencocokan yang ditentukan. Contoh: Jika nama userPrincipal dalam sistem sumber adalah atribut dan peta yang cocok dengan userName dalam sistem target, layanan provisi membuat kueri sistem target untuk userNames yang cocok dengan nilai nama userPrincipal dalam sistem sumber.
Jika pengguna yang cocok tidak ditemukan dalam sistem target, pengguna akan dibuat menggunakan atribut yang ditampilkan dari sistem sumber. Setelah akun pengguna dibuat, layanan provisi mendeteksi dan menyimpan cache ID sistem target untuk pengguna baru. ID ini digunakan untuk menjalankan semua operasi di masa mendatang pada pengguna tersebut.
Jika pengguna yang cocok ditemukan, pengguna akan diperbarui menggunakan atribut yang disediakan oleh sistem sumber. Setelah akun pengguna dicocokkan, layanan provisi mendeteksi dan menyimpan cache ID sistem target untuk pengguna baru. ID ini digunakan untuk menjalankan semua operasi di masa mendatang pada pengguna tersebut.
Jika pemetaan atribut berisi atribut "referensi", layanan melakukan lebih banyak pembaruan pada sistem target untuk membuat dan menautkan objek yang dirujuk. Misalnya, pengguna mungkin memiliki atribut "Pengelola" dalam sistem target, yang ditautkan ke pengguna lain yang dibuat di sistem target.
Pertahankan marka air di akhir siklus awal, yang menyediakan titik awal untuk siklus bertahap selanjutnya.

Beberapa aplikasi seperti dukungan ServiceNow, G Suite, dan Box tidak hanya menyediakan pengguna, tetapi juga menyediakan grup dan anggotanya. Dalam kasus tersebut, jika provisi grup diaktifkan di pemetaan, layanan provisi menyinkronkan pengguna dan grup, lalu menyinkronkan keanggotaan grup.

Siklus bertahap

Setelah siklus awal, semua siklus lainnya akan:

Membuat kueri sistem sumber untuk setiap pengguna dan grup yang diperbarui sejak marka air terakhir disimpan.
Memfilter pengguna dan grup yang ditampilkan, menggunakan penetapan atau filter cakupan berbasis atribut yang konfigurasi.
Saat pengguna ditetapkan atau dalam cakupan untuk provisi, layanan membuat kueri sistem target untuk pengguna yang cocok menggunakan atribut pencocokan yang ditentukan.
Jika pengguna yang cocok tidak ditemukan dalam sistem target, pengguna akan dibuat menggunakan atribut yang ditampilkan dari sistem sumber. Setelah akun pengguna dibuat, layanan provisi mendeteksi dan menyimpan cache ID sistem target untuk pengguna baru. ID ini digunakan untuk menjalankan semua operasi di masa mendatang pada pengguna tersebut.
Jika pengguna yang cocok ditemukan, pengguna akan diperbarui menggunakan atribut yang disediakan oleh sistem sumber. Jika itu adalah akun yang baru ditetapkan yang cocok, layanan provisi mendeteksi dan menyimpan cache ID sistem target untuk pengguna baru. ID ini digunakan untuk menjalankan semua operasi di masa mendatang pada pengguna tersebut.
Jika pemetaan atribut berisi atribut "referensi", layanan melakukan lebih banyak pembaruan pada sistem target untuk membuat dan menautkan objek yang dirujuk. Misalnya, pengguna mungkin memiliki atribut "Pengelola" dalam sistem target, yang ditautkan ke pengguna lain yang dibuat di sistem target.
Jika pengguna yang sebelumnya berada dalam cakupan untuk provisi dihapus dari cakupan, termasuk tidak ditetapkan, layanan akan menonaktifkan pengguna dalam sistem target melalui pembaruan.
Jika pengguna yang sebelumnya berada dalam cakupan untuk provisi dinonaktifkan atau dihapus sementara dalam sistem sumber, layanan akan menonaktifkan pengguna dalam sistem target melalui pembaruan.
Jika pengguna yang sebelumnya berada dalam cakupan untuk provisi dihapus permanen dalam sistem sumber, layanan akan menghapus pengguna dalam sistem target. Di ID Microsoft Entra, pengguna dihapus secara permanen 30 hari setelah dihapus sementara.
Pertahankan marka air baru di akhir siklus bertahap, yang menyediakan titik awal untuk siklus bertahap selanjutnya.

Catatan

Anda dapat secara opsional menonaktifkan operasi Buat, Perbarui, atau Hapus dengan menggunakan kotak centang Tindakan objek target di bagian Pemetaan. Logika untuk menonaktifkan pengguna selama pembaruan juga dikontrol melalui pemetaan atribut dari bidang seperti accountEnabled.

Layanan provisi terus menjalankan siklus bertahap back-to-back tanpa batas waktu, pada interval yang ditentukan dalam tutorial khusus untuk setiap aplikasi. Siklus bertahap berlanjut hingga salah satu peristiwa terjadi:

Layanan dihentikan secara manual menggunakan pusat admin Microsoft Entra, atau menggunakan perintah Microsoft Graph API yang sesuai.
Siklus awal baru dipicu menggunakan opsi Mulai ulang provisi di pusat admin Microsoft Entra, atau menggunakan perintah Microsoft Graph API yang sesuai. Tindakan menghapus marka air yang disimpan dan menyebabkan semua objek sumber dievaluasi lagi. Selain itu, tindakan tidak memutus tautan antara objek sumber dan target. Untuk memutuskan tautan, gunakan Hidupkan ulang sinkronisasiJob dengan permintaan:

POST https://graph.microsoft.com/beta/servicePrincipals/{id}/synchronization/jobs/{jobId}/restart
Authorization: Bearer <token>
Content-type: application/json
{
   "criteria": {
       "resetScope": "Full"
   }
}

Siklus awal baru dipicu karena perubahan pemetaan atribut atau filter cakupan. Tindakan ini juga menghapus marka air tersimpan dan menyebabkan semua objek sumber dievaluasi lagi.
Proses provisi masuk ke karantina (lihat contoh) karena tingkat kesalahan yang tinggi, dan tetap berada di karantina selama lebih dari empat minggu. Dalam kejadian ini, layanan secara otomatis dinonaktifkan.

Kesalahan dan upaya ulang

Jika kesalahan di sistem target mencegah pengguna individu ditambahkan, diperbarui, atau dihapus di sistem target, operasi akan dicoba ulang di siklus sinkronisasi berikutnya. Kesalahan terus-menerus dicoba ulang, secara bertahap mengurangi frekuensi percobaan ulang. Untuk mengatasi kegagalan tersebut, administrator harus memeriksa log provisi untuk menentukan akar masalahnya dan melakukan tindakan yang sesuai. Kegagalan umum dapat mencakup:

Pengguna tidak memiliki atribut yang diisi di sistem sumber yang diperlukan di sistem target
Pengguna memiliki nilai atribut dalam sistem sumber yang ada batasan unik dalam sistem targetnya, dan nilai yang sama ada di catatan pengguna lain

Atasi kegagalan ini dengan menyesuaikan nilai atribut untuk pengguna terpengaruh di sistem sumber, atau dengan menyesuaikan pemetaan atribut agar tidak menimbulkan konflik.

Karantina

Jika sebagian besar atau semua panggilan yang dilakukan terhadap sistem target secara konsisten gagal karena kesalahan (misalnya info masuk admin yang tidak valid), pekerjaan provisi masuk ke status "karantina". Status ini ditunjukkan dalam laporan ringkasan provisi dan melalui email jika pemberitahuan email dikonfigurasi di pusat admin Microsoft Entra.

Saat dalam karantina, frekuensi siklus bertahap secara bertahap dikurangi menjadi sekali per hari.

Pekerjaan provisi keluar dari karantina setelah semua kesalahan yang melanggar diperbaiki dan siklus sinkronisasi berikutnya dimulai. Jika pekerjaan provisi tetap dalam karantina selama lebih dari empat minggu, pekerjaan provisi dinonaktifkan. Pelajari lebih lanjut di sini tentang status karantina di sini.

Berapa lama provisi berlangsung

Performa tergantung pada apakah pekerjaan provisi Anda menjalankan siklus provisi awal atau siklus bertahap. Untuk mengetahui detail tentang berapa lama provisi berlangsung dan cara memantau status layanan provisi, lihat Memeriksa status provisi pengguna.

Cara mengetahui apakah pengguna disediakan dengan benar

Semua operasi yang dijalankan oleh layanan provisi pengguna dicatat dalam log Provisi Microsoft Entra (pratinjau). Log mencakup semua operasi baca dan tulis yang dibuat ke sistem sumber dan target, dan data pengguna yang dibaca atau ditulis selama setiap operasi. Untuk informasi tentang cara membaca log provisi di pusat admin Microsoft Entra, lihat panduan pelaporan provisi.

Pencabutan Akses

Layanan provisi Microsoft Entra menjaga sistem sumber dan target tetap sinkron dengan mendeprovisi akun saat akses pengguna dihapus.

Layanan provisi mendukung menghapus dan menonaktifkan (terkadang disebut sebagai penghapusan sementara) pengguna. Definisi yang tepat dari menonaktifkan dan menghapus bervariasi berdasarkan penerapan aplikasi target, tetapi umumnya menonaktifkan menunjukkan bahwa pengguna tidak dapat masuk. Penghapusan menunjukkan bahwa pengguna telah dihapus sepenuhnya dari aplikasi. Untuk aplikasi SCIM, menonaktifkan adalah permintaan untuk mengatur properti aktif ke false pada pengguna.

Mengonfigurasi aplikasi Anda untuk menonaktifkan pengguna

Konfirmasikan kotak centang untuk pembaruan dipilih.

Konfirmasikan pemetaan untuk aktif untuk aplikasi Anda. Jika Anda menggunakan aplikasi dari galeri aplikasi, pemetaannya mungkin sedikit berbeda. Dalam hal ini, gunakan pemetaan default untuk aplikasi galeri.

Mengonfigurasi aplikasi Anda untuk menghapus pengguna

Skenario ini memicu penonaktifan atau penghapusan:

Pengguna dihapus sementara di ID Microsoft Entra (dikirim ke keranjang sampah / properti AccountEnabled diatur ke false). Tiga puluh hari setelah pengguna dihapus di ID Microsoft Entra, mereka dihapus secara permanen dari penyewa. Pada titik ini, layanan provisi mengirimkan permintaan DELETE untuk menghapus pengguna secara permanen dalam aplikasi. Kapan saja selama jendela 30 hari, Anda dapat menghapus pengguna secara manual, yang mengirim permintaan penghapusan ke aplikasi.
Pengguna dihapus / dihapus secara permanen dari keranjang sampah di ID Microsoft Entra.
Pengguna tidak ditetapkan dari aplikasi.
Pengguna beralih dari dalam cakupan ke luar cakupan (tidak meneruskan filter cakupan lagi).

Secara default, layanan provisi Microsoft Entra menghapus sementara atau menonaktifkan pengguna yang keluar dari cakupan. Jika Anda ingin mengambil alih perilaku default ini, Anda dapat mengatur bendera untuk melewati penghapusan di luar cakupan.

Ketika salah satu dari empat peristiwa terjadi dan aplikasi target tidak mendukung penghapusan sementara, layanan provisi mengirimkan permintaan DELETE untuk menghapus pengguna secara permanen dari aplikasi.

Jika Anda melihat IsSoftDeleted dalam pemetaan atribut Anda, pemetaan tersebut digunakan untuk menentukan status pengguna dan apakah akan mengirim permintaan pembaruan dengan active = false untuk menghapus sementara pengguna.

Peristiwa pencabutan akses

Tabel ini menjelaskan cara mengonfigurasi tindakan deprovisi dengan layanan provisi Microsoft Entra. Aturan ini ditulis dengan mempertimbangkan aplikasi non-galeri / kustom, tetapi umumnya berlaku untuk aplikasi di galeri. Namun, perilaku untuk aplikasi galeri dapat berbeda karena telah dioptimalkan untuk memenuhi kebutuhan aplikasi. Misalnya, jika aplikasi target tidak mendukung penghapusan sementara, layanan provisi Microsoft Entra mungkin mengirim permintaan penghapusan permanen untuk menghapus pengguna daripada mengirim penghapusan sementara.

Skenario	Cara mengonfigurasi di MICROSOFT Entra ID
Pengguna tidak ditetapkan dari aplikasi, dihapus sementara di ID Microsoft Entra, atau diblokir dari masuk. Anda tidak ingin apa-apa dilakukan.	Hapus `isSoftDeleted` dari pemetaan atribut dan / atau atur properti lombah keluar dari penghapusan cakupan ke true.
Pengguna tidak ditetapkan dari aplikasi, dihapus sementara di ID Microsoft Entra, atau diblokir dari masuk. Anda ingin mengatur atribut tertentu ke `true` atau `false`.	Petakan `isSoftDeleted` ke atribut yang ingin Anda atur ke false.
Pengguna dinonaktifkan di ID Microsoft Entra, tidak ditetapkan dari aplikasi, dihapus sementara di ID Microsoft Entra, atau diblokir dari masuk. Anda ingin mengirim permintaan DELETE ke aplikasi target.	Tindakan ini saat ini didukung untuk set aplikasi galeri terbatas yang memerlukan fungsionalitas. Ini tidak dapat dikonfigurasi oleh pelanggan.
Pengguna dihapus di ID Microsoft Entra. Anda tidak ingin apa pun dilakukan dalam aplikasi target.	Pastikan bahwa "Hapus" tidak dipilih sebagai salah satu tindakan objek target dalam pengalaman konfigurasi atribut.
Pengguna dihapus di ID Microsoft Entra. Anda ingin mengatur nilai atribut di aplikasi target.	Tidak didukung.
Pengguna dihapus di ID Microsoft Entra. Anda ingin menghapus pengguna di aplikasi target	Pastikan Hapus dipilih sebagai salah satu tindakan objek target dalam pengalaman konfigurasi atribut.

Batasan yang Diketahui

Saat pengguna atau grup tidak ditetapkan dari aplikasi dan tidak lagi dikelola dengan layanan provisi, permintaan penonaktifan dikirim. Pada saat itu, layanan tidak mengelola pengguna dan permintaan penghapusan tidak dikirim saat pengguna dihapus dari direktori.
Provisi pengguna yang dinonaktifkan di ID Microsoft Entra tidak didukung. Mereka harus aktif di ID Microsoft Entra sebelum disediakan.
Saat pengguna beralih dari penghapusan sementara ke aktif, layanan provisi Microsoft Entra mengaktifkan pengguna di aplikasi target, tetapi tidak secara otomatis memulihkan keanggotaan grup. Aplikasi target harus mempertahankan keanggotaan grup untuk pengguna dalam status tidak aktif. Jika aplikasi target tidak mendukung pemeliharaan status tidak aktif, Anda dapat memulai ulang provisi untuk memperbarui keanggotaan grup.

Rekomendasi

Saat mengembangkan aplikasi, selalu dukung penghapusan sementara dan penghapusan permanen. Ini memungkinkan pelanggan untuk dipulihkan saat pengguna tidak sengaja dinonaktifkan.