Cara kerja Provisi Aplikasi di ID Microsoft Entra

Artikel
10/15/2024

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 detailnya, lihat Membangun 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.

Otorisasi

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 dan persyaratan kredensial untuk aplikasi dengan merujuk ke tutorial aplikasi. Untuk aplikasi non-galeri, Anda dapat merujuk ke dokumentasi SCIM untuk memahami jenis dan persyaratan kredensial. 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 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 Anda menjadi format yang lebih dapat diterima untuk aplikasi SaaS. Untuk detailnya, lihat Menulis ekspresi untuk pemetaan atribut.

Scoping

Pencakupan berbasis penugasan

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. Pencakupan berbasis penugasan tidak berlaku untuk skenario provisi masuk seperti Workday dan Successfactors.

Kelompok. 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 keanggotaan 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 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 keanggotaan dinamis.
Grup berlapis. Layanan provisi pengguna Microsoft Entra tidak dapat membaca atau memprovisikan pengguna dalam grup berlapis. Layanan ini hanya dapat membaca dan memprovisikan pengguna yang merupakan anggota langsung dari grup yang ditetapkan secara eksplisit. Batasan "penugasan berbasis grup untuk aplikasi" ini juga memengaruhi akses menyeluruh (lihat Menggunakan grup untuk mengelola akses ke aplikasi SaaS). Sebagai gantinya , secara langsung tetapkan atau lingkup dalam grup yang berisi pengguna yang perlu disediakan.

Pencakupan berbasis atribut

Anda dapat menggunakan filter cakupan untuk menentukan aturan berbasis atribut yang menentukan pengguna mana yang diprovisikan ke 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 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.

Nota

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 dilucuti dari userPrincipalName, jadi hanya alias@theirdomain asli mereka yang digunakan untuk pencocokan atau provisi. Jika Anda memerlukan nama prinsipal pengguna lengkap termasuk #EXT# dan domain Anda untuk hadir, ganti userPrincipalName 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

Ketika layanan provisi dimulai, siklus pertama akan:

Kueri semua pengguna dan grup dari sistem sumber, mengambil semua atribut yang ditentukan dalam pemetaan atribut.
Filter pengguna dan grup yang dikembalikan, menggunakan penugasan yang dikonfigurasi atau filter cakupan berbasis atribut.
Saat pengguna ditetapkan atau dalam cakupan provisi, layanan meminta sistem target untuk pengguna yang cocok menggunakan atribut pencocokan yang ditentukan. Contoh: Jika nama userPrincipal dalam sistem sumber adalah atribut yang cocok dan memetakan ke userName dalam sistem target, maka layanan provisi meminta sistem target untuk userNames yang cocok dengan nilai nama userPrincipal dalam sistem sumber.
Jika pengguna yang cocok tidak ditemukan di sistem target, pengguna dibuat menggunakan atribut yang dikembalikan 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 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 "Manajer" dalam sistem target, yang ditautkan ke pengguna lain yang dibuat dalam sistem target.
Pertahankan marka air di akhir siklus awal, yang menyediakan titik awal untuk siklus bertahap selanjutnya.

Beberapa aplikasi seperti ServiceNow, G Suite, dan Box tidak hanya mendukung provisi pengguna, tetapi juga memprovisikan grup dan anggota mereka. Dalam kasus tersebut, jika provisi grup diaktifkan dalam pemetaan, layanan provisi menyinkronkan pengguna dan grup, lalu menyinkronkan grup keanggotaan dinamis.

Siklus bertahap

Setelah siklus awal, semua siklus lainnya akan:

Kueri sistem sumber untuk setiap pengguna dan grup yang diperbarui sejak marka air terakhir disimpan.
Filter pengguna dan grup yang dikembalikan, menggunakan penugasan yang dikonfigurasi atau filter cakupan berbasis atribut.
Saat pengguna ditetapkan atau dalam cakupan provisi, layanan meminta sistem target untuk pengguna yang cocok menggunakan atribut pencocokan yang ditentukan.
Jika pengguna yang cocok tidak ditemukan di sistem target, pengguna dibuat menggunakan atribut yang dikembalikan 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 ini 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 "Manajer" dalam sistem target, yang ditautkan ke pengguna lain yang dibuat dalam sistem target.
Jika pengguna yang sebelumnya berada dalam cakupan provisi dihapus dari cakupan, termasuk tidak ditetapkan, layanan akan menonaktifkan pengguna dalam sistem target melalui pembaruan.
Jika pengguna yang sebelumnya berada dalam cakupan provisi dinonaktifkan atau dihapus sementara dalam sistem sumber, layanan akan menonaktifkan pengguna dalam sistem target melalui pembaruan.
Jika pengguna yang sebelumnya berada dalam cakupan provisi dihapus secara 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 inkremental, yang menyediakan titik awal untuk siklus bertahap selanjutnya.

Nota

Anda dapat menonaktifkan operasi Buat, Perbarui, atau Hapus secara opsional 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 inkremental 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 yang disimpan 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 percobaan ulang

Jika kesalahan dalam sistem target mencegah pengguna individual ditambahkan, diperbarui, atau dihapus dalam sistem target, operasi akan dicoba kembali dalam siklus sinkronisasi berikutnya. Kesalahan terus dicoba kembali, secara bertahap menskalakan kembali frekuensi percobaan ulang. Untuk mengatasi kegagalan, administrator harus memeriksa log provisi untuk menentukan akar penyebabnya dan mengambil tindakan yang sesuai. Kegagalan umum dapat mencakup:

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

Atasi kegagalan ini dengan menyesuaikan nilai atribut untuk pengguna yang terpengaruh dalam sistem sumber, atau dengan menyesuaikan pemetaan atribut sehingga tidak menyebabkan konflik.

Karantina

Jika sebagian besar atau semua panggilan yang dilakukan terhadap sistem target secara konsisten gagal karena kesalahan (misalnya kredensial 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.

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

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

Berapa lama provisi diperlukan

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

Cara mengetahui apakah pengguna diprovisikan dengan benar

Semua operasi yang dijalankan oleh layanan provisi pengguna dicatat dalam log Provisi Microsoft Entra. 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.

Deprovisi

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

Layanan provisi mendukung penghapusan dan pennonaktifkan (terkadang disebut sebagai penghapusan sementara) pengguna. Definisi pasti penonaktifan dan penghapusan bervariasi berdasarkan implementasi aplikasi target, tetapi umumnya nonaktifkan menunjukkan bahwa pengguna tidak dapat masuk. Penghapusan menunjukkan bahwa pengguna telah dihapus sepenuhnya dari aplikasi. Untuk aplikasi SCIM, nonaktifkan 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 secara permanen, 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.

Membatalkan provisi peristiwa

Tabel ini menjelaskan cara mengonfigurasi tindakan deprovisi dengan layanan provisi Microsoft Entra. Aturan ini ditulis dengan mengingat 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.	Ini saat ini didukung untuk serangkaian aplikasi galeri terbatas di mana fungsionalitas diperlukan. 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 Bahwa 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 sementara dari direktori.
Provisi pengguna yang dinonaktifkan di ID Microsoft Entra tidak didukung. Mereka harus aktif di ID Microsoft Entra sebelum disediakan.
Ketika pengguna beralih dari dihapus sementara ke aktif, layanan provisi Microsoft Entra mengaktifkan pengguna di aplikasi target, tetapi tidak secara otomatis memulihkan grup keanggotaan dinamis. Aplikasi target harus mempertahankan grup keanggotaan dinamis untuk pengguna dalam status tidak aktif. Jika aplikasi target tidak mendukung pemeliharaan status tidak aktif, Anda dapat memulai ulang provisi untuk memperbarui grup keanggotaan dinamis.

Rekomendasi

Saat mengembangkan aplikasi, selalu dukung penghapusan sementara dan penghapusan permanen. Ini memungkinkan pelanggan untuk pulih ketika pengguna secara tidak sengaja dinonaktifkan.

Langkah Berikutnya

Merencanakan penyebaran provisi pengguna otomatis

Mengonfigurasi provisi untuk aplikasi galeri

Membangun titik akhir SCIM dan mengonfigurasi provisi saat membuat aplikasi Anda sendiri

Memecahkan masalah dengan mengonfigurasi dan memprovisikan pengguna ke aplikasi.

Bagikan melalui