Tanya jawab umum GDAP

Seseorang dengan peran agen Admin di organisasi mitra dapat membuat permintaan hubungan GDAP.

Ya. Permintaan hubungan GDAP kedaluwarsa setelah 90 hari.

Tidak. Hubungan GDAP permanen dengan pelanggan tidak dimungkinkan karena alasan keamanan. Durasi maksimum hubungan GDAP adalah dua tahun. Anda dapat mengatur perpanjangan otomatis ke Diaktifkan untuk memperpanjang hubungan admin selama enam bulan, hingga dihentikan atau diperpanjang secara otomatis diatur ke Dinonaktifkan.

Tidak. Hubungan GDAP tidak mendukung langganan yang dibeli melalui perjanjian perusahaan.

Ya. Hubungan GDAP dapat diperpanjang secara otomatis selama enam bulan hingga dihentikan atau perpanjangan otomatis diatur ke Dinonaktifkan.

• Jika hubungan GDAP dengan pelanggan Anda kedaluwarsa, meminta hubungan GDAP lagi.
• Anda dapat menggunakan analitik hubungan GDAP untuk melacak tanggal kedaluwarsa hubungan GDAP dan mempersiapkan perpanjangannya.

Untuk memperpanjang atau memperbarui hubungan GDAP, mitra atau pelanggan harus mengatur Perluasan otomatis ke Diaktifkan. Pelajari selengkapnya di Mengelola perluasan otomatis GDAP dan API .

Ya. Jika GDAP aktif, GDAP dapat diperpanjang.

Katakanlah GDAP dibuat selama 365 hari dengan perpanjangan otomatis diatur ke Diaktifkan. Pada hari ke-365, Tanggal Akhir diperbarui secara efektif oleh 180 hari.

Ya. Anda dapat memperluas GDAP aktif apa pun secara otomatis.

Tidak. Persetujuan pelanggan tidak diperlukan untuk mengatur perluasan otomatis ke Diaktifkan terhadap GDAP aktif yang ada.

Tidak. Izin terperinci yang ditetapkan ke grup keamanan berlanjut as-is.

Tidak. Anda tidak dapat memperluas hubungan admin secara otomatis dengan peran Administrator Global.

Halaman Hubungan Granular kedaluwarsa hanya tersedia untuk pengguna mitra dengan peran Administrator Global dan Agen Admin. Halaman ini membantu memfilter GDIP yang kedaluwarsa di berbagai garis waktu, dan membantu memperbarui perluasan otomatis (aktifkan/nonaktifkan) untuk satu atau beberapa GDIP.

Tidak. Tidak ada perubahan pada langganan pelanggan yang sudah ada saat hubungan GDAP kedaluwarsa.

Lihat Memecahkan masalah autentikasi multifaktor Microsoft Entra dan Tidak dapat menggunakan autentikasi multifaktor Microsoft Entra untuk masuk ke layanan cloud setelah Anda kehilangan telepon atau nomor telepon berubah untuk panduan.

Mitra harus meminta administrator autentikasi istimewa peran Microsoft Entra saat membuat GDAP pertama.

• Peran ini memungkinkan mitra untuk mengatur ulang kata sandi dan metode autentikasi untuk admin atau pengguna nonadmin. Peran administrator autentikasi Istimewa adalah bagian dari peran yang disiapkan oleh Microsoft Led Tool dan direncanakan tersedia dengan GDAP Default selama alur Buat Pelanggan (direncanakan untuk September).
• Mitra dapat meminta admin pelanggan mencoba Mengatur ulang kata sandi.
• Sebagai tindakan pencegahan, mitra harus menyiapkan SSPR (Pengaturan ulang kata sandi mandiri) untuk pelanggan mereka. Untuk informasi selengkapnya, lihat Biarkan orang mengatur ulang kata sandi mereka sendiri.

• Dalam organisasi mitra , orang dengan peran agen Admin menerima pemberitahuan penghentian.
• Dalam organisasi pelanggan , orang dengan peran admin Global menerima pemberitahuan penghentian.

Ya. Mitra dapat melihat kapan pelanggan menghapus GDAP di log aktivitas Pusat Mitra.

Tidak. GDAP adalah kemampuan opsional bagi mitra yang ingin mengelola layanan pelanggan mereka dengan cara yang lebih terperinci dan terikat waktu. Anda dapat memilih pelanggan mana yang ingin Anda buat hubungan GDAPnya.

Jawabannya tergantung pada bagaimana Anda ingin mengelola pelanggan Anda.

• Jika Anda ingin pengguna mitra Anda dapat mengelola semua pelanggan, Anda dapat memasukkan semua pengguna mitra Anda ke dalam satu grup keamanan dan bahwa satu grup dapat mengelola semua pelanggan Anda.
• Jika Anda lebih suka memiliki berbagai pengguna mitra yang mengelola berbagai pelanggan, tetapkan pengguna mitra tersebut untuk memisahkan grup keamanan untuk isolasi pelanggan.

Ya. Pengecer tidak langsung (dan penyedia tidak langsung dan mitra tagihan langsung) dapat membuat permintaan hubungan GDAP di Pusat Mitra.

Sebagai bagian dari penyiapan GDAP, pastikan bahwa grup keamanan yang dibuat di penyewa mitra dengan pengguna mitra dipilih. Pastikan juga peran Microsoft Entra yang diinginkan ditetapkan ke grup keamanan. Lihat Tetapkan peran Microsoft Entra.

Pelanggan sekarang dapat mengecualikan CSP dari kebijakan akses bersyar sehingga mitra dapat bertransisi ke GDAP tanpa diblokir.

• Menyertakan pengguna - Daftar pengguna ini biasanya menyertakan semua pengguna yang ditargetkan organisasi dalam kebijakan Akses Bersyar.
• Opsi berikut ini tersedia untuk disertakan saat membuat kebijakan Akses Bersyar:
• Pilih pengguna dan grup
• Pengguna tamu atau eksternal (pratinjau)
• Pilihan ini menyediakan beberapa pilihan yang dapat digunakan untuk menargetkan kebijakan Akses Bersyar ke jenis pengguna tamu atau eksternal tertentu dan penyewa tertentu yang berisi jenis pengguna tersebut. Ada beberapa jenis pengguna tamu atau eksternal berbeda yang dapat dipilih, dan beberapa pilihan dapat dilakukan:
• Pengguna penyedia layanan, misalnya Penyedia Solusi Cloud (CSP).
• Anda dapat menentukan satu atau beberapa penyewa untuk jenis pengguna yang dipilih, atau Anda dapat menentukan semua penyewa.
• Akses mitra eksternal - Kebijakan Akses Bersyar yang menargetkan pengguna eksternal mungkin mengganggu akses penyedia layanan, misalnya hak istimewa admin yang didelegasikan secara terperinci. Untuk informasi selengkapnya, lihat Pengenalan hak istimewa admin terdelegasi terperinci (GDAP). Untuk kebijakan yang dimaksudkan untuk menargetkan penyewa penyedia layanan, gunakan pengguna penyedia layanan jenis pengguna eksternal yang tersedia di opsi pilihan Tamu atau eksternal.
• Mengecualikan pengguna - Saat organisasi menyertakan dan mengecualikan pengguna atau grup, pengguna atau grup dikecualikan dari kebijakan, karena tindakan pengecualian mengambil alih tindakan sertakan dalam kebijakan.
• Opsi berikut ini tersedia untuk dikecualikan saat membuat kebijakan Akses Bersyar:
• Pengguna tamu atau eksternal
• Pilihan ini menyediakan beberapa pilihan yang dapat digunakan untuk menargetkan kebijakan Akses Bersyar ke jenis pengguna tamu atau eksternal tertentu dan penyewa tertentu yang berisi jenis pengguna tersebut. Ada beberapa jenis pengguna tamu atau eksternal yang dapat dipilih, dan beberapa pilihan dapat dibuat:
• Pengguna penyedia layanan, misalnya Penyedia Solusi Cloud (CSP)
• Satu atau beberapa penyewa dapat ditentukan untuk jenis pengguna yang dipilih, atau Anda dapat menentukan semua penyewa. Untuk informasi selengkapnya, lihat:
• Pengalaman Graph API: BETA API dengan informasi jenis pengguna eksternal baru
• kebijakan akses bersyar
• pengguna eksternal akses bersyar

Ya. Terlepas dari paket dukungan yang Anda miliki, peran paling tidak istimewa bagi pengguna mitra untuk dapat membuat tiket dukungan bagi pelanggan mereka adalah Administrator dukungan layanan.

Tidak. Mitra saat ini tidak dapat mengakhiri GDAP dalam status Persetujuan Tertunda. Ini akan kedaluwarsa dalam 90 hari jika pelanggan tidak mengambil tindakan.

Hanya setelah 365 hari (pembersihan) setelah hubungan GDAP berakhir atau kedaluwarsa, Anda dapat menggunakan kembali nama yang sama untuk membuat hubungan GDAP baru.

Ya. Mitra dapat mengelola pelanggan mereka di seluruh wilayah tanpa membuat penyewa mitra baru per wilayah pelanggan. Ini hanya berlaku untuk peran manajemen pelanggan yang disediakan oleh GDAP (Hubungan Admin). Peran dan kemampuan transaksi masih terbatas pada wilayah resmi Anda.

Tidak. Penyedia layanan tidak dapat menjadi bagian dari organisasi multipenyewa, mereka saling eksklusif.

1. Pastikan bahwa GDAP disiapkan dengan benar, termasuk cara Anda memberikan izin untuk kelompok keamanan.
2. Pastikan izin grup keamanan granular Anda sudah benar.
3. Lihat tanya jawab umum Security Copilot untuk bantuan.

Untuk informasi selengkapnya tentang API dan GDAP, lihat dokumentasi pengembang Pusat Mitra .

Ya. Sebaiknya mitra menggunakan API GDAP beta untuk produksi dan kemudian beralih ke API v.1 saat tersedia. Meskipun ada peringatan, "Penggunaan API ini dalam aplikasi produksi tidak didukung," panduan umum tersebut adalah untuk API beta apa pun di bawah Grafik dan tidak berlaku untuk API Grafik GDAP beta.

Ya. Anda dapat membuat hubungan GDAP dengan menggunakan API, yang memungkinkan mitra untuk menskalakan proses ini. Tetapi membuat beberapa hubungan GDAP tidak tersedia di Pusat Mitra. Untuk informasi tentang API dan GDAP, lihat dokumentasi pengembang Pusat Mitra .

API berfungsi untuk satu grup keamanan pada satu waktu, tetapi Anda dapat memetakan beberapa grup keamanan ke beberapa peran di Pusat Mitra.

Lakukan panggilan individual untuk setiap sumber daya. Saat membuat satu permintaan POST, hanya berikan satu sumber daya dan cakupan yang sesuai. Misalnya, untuk meminta izin untuk https://graph.microsoft.com/Directory.AccessAsUser.All dan https://graph.microsoft.com/Organization.Read.All, buat dua permintaan berbeda, satu untuk masing-masing.

Gunakan tautan yang disediakan untuk mencari Nama sumber daya: Memverifikasi aplikasi Microsoft pihak pertama dalam laporan masuk - Direktori Aktif. Misalnya, untuk menemukan ID Sumber Daya 00000003-0000-0000-c000-0000000000000 untuk graph.microsoft.com:

Kesalahan ini biasanya terjadi ketika pengidentifikasi yang salah digunakan dalam filter kueri. Untuk mengatasinya, pastikan Anda menggunakan properti enterpriseApplicationId dengan ID sumber daya yang benar, bukan nama sumber daya.

• Permintaan yang salah UntukenterpriseApplicationId , jangan gunakan nama sumber daya seperti graph.microsoft.com.
• Koreksi permintaan Sebagai gantinya, untukenterpriseApplicationId , gunakan ID sumber daya, seperti 00000003-0000-0000-c000-000000000000.

Misalnya, Sebelumnya dalam sumber daya graph.microsoft.com hanya cakupan "profil" yang disetujui. Sekarang kita perlu menambahkan profil dan user.read juga. Untuk menambahkan cakupan baru ke aplikasi yang disetujui sebelumnya:

1. Gunakan metode DELETE untuk mencabut persetujuan aplikasi yang ada dari penyewa pelanggan.
2. Gunakan metode POST untuk membuat persetujuan aplikasi baru dengan cakupan tambahan.

Menggabungkan cakupan yang diperlukan menggunakan koma diikuti dengan spasi. Misalnya, "cakupan": "profile, User.Read"

1. Konfirmasikan bahwa properti 'displayName' dan 'applicationId' dalam isi permintaan akurat dan cocok dengan aplikasi yang ingin Anda setujui ke penyewa pelanggan.
2. Pastikan Anda menggunakan aplikasi yang sama untuk menghasilkan token akses yang Anda coba setujui ke penyewa pelanggan. Misalnya: Jika ID aplikasi adalah "12341234-1234-1234-12341234," klaim "appId" dalam token akses juga harus "12341234-1234-1234-1234-12341234."
3. Verifikasi bahwa salah satu kondisi berikut terpenuhi:

• Anda memiliki Hak Istimewa Admin (DAP) Yang Didelegasikan aktif, dan pengguna juga merupakan anggota grup Keamanan Agen Admin di penyewa mitra.
• Anda memiliki hubungan Granular Delegated Admin Privilege (GDAP) aktif dengan penyewa Pelanggan dengan setidaknya salah satu dari tiga peran GDAP berikut, dan Anda menyelesaikan Penetapan Akses:
  • Administrator Global, Administrator Aplikasi, atau Peran Administrator Aplikasi Cloud.
  • Pengguna mitra adalah anggota Grup Keamanan yang ditentukan dalam Penetapan Akses.

• Untuk mengelola Azure dengan partisi akses per pelanggan (yang merupakan praktik terbaik yang direkomendasikan), buat grup keamanan (seperti Azure Managers ) dan menumpuknya di bawah Agen admin.
• Untuk mengakses langganan Azure sebagai pemilik bagi pelanggan, Anda dapat menetapkan peran bawaan Microsoft Entra (seperti pembaca Direktori , peran paling tidak istimewa) ke grup keamanan Azure Managers. Untuk langkah-langkah menyiapkan Azure GDAP, lihat Beban Kerja yang didukung oleh hak istimewa admin terdelegasi terperinci (GDAP).

Ya. Untuk informasi tentang cara membatasi izin administrator pengguna dengan menetapkan peran dengan hak istimewa paling sedikit di Microsoft Entra, lihat Peran dengan hak istimewa paling sedikit berdasarkan tugas di Microsoft Entra.

Sebaiknya tetapkan peran administrator dukungan Layanan . Untuk mempelajari selengkapnya, lihat Peran dengan hak istimewa paling sedikit berdasarkan tugas di Microsoft Entra.

• Untuk mengurangi kesenjangan antara peran Microsoft Entra yang tersedia di API Pusat Mitra versus UI, daftar sembilan peran tersedia di UI Pusat Mitra pada Juli 2024.
• Di bawah Kolaborasi:
  • Microsoft Edge Administrator
  • Administrator Kunjungan Virtual
  • Administrator Tujuan Viva
  • Viva Pulse Administrator
  • Yammer Administrator
• Di bawah Identitas:
  • Administrator Manajemen Izin
  • Administrator Alur Kerja Siklus Hidup
• Di bawah Lainnya:
  • Administrator Branding Organisasi
  • Pemberi Persetujuan Pesan Organisasi

• Untuk mengurangi kesenjangan antara peran Microsoft Entra yang tersedia di API Pusat Mitra versus UI, daftar 17 peran tersedia di UI Pusat Mitra pada Desember 2024.
• Di bawah Kolaborasi:
  • Analis Wawasan
  • Administrator Migrasi Microsoft 365
  • Penulis Pesan Organisasi
  • SharePoint Embedded Administrator
  • Administrator Telepon Teams
  • Manajer Keberhasilan Pengalaman Pengguna
• Di bawah Perangkat:
  • Administrator Garansi Perangkat Keras Microsoft
  • Microsoft Hardware Warranty Specialist
• Di bawah Identitas:
  • Administrator Penugasan Atribut
  • Pembaca Penugasan Atribut
  • Administrator Definisi Atribut
  • Pembaca Definisi Atribut
  • Administrator Log Atribut
  • Pembaca Log Atribut
  • Administrator Ekstensibilitas Autentikasi
  • Administrator Akses Aman Global
  • Pembuat Penyewa

Tidak. Peran paling tidak istimewa bagi pengguna mitra untuk dapat membuat tiket dukungan untuk pelanggan mereka adalah administrator dukungan Layanan . Oleh karena itu, untuk dapat membuat tiket dukungan bagi pelanggan, pengguna mitra harus berada dalam kelompok keamanan dan ditugaskan kepada pelanggan tersebut dengan peran tersebut.

Untuk informasi tentang semua peran, lihat peran bawaan Microsoft Entra. Untuk informasi tentang beban kerja, lihat beban kerja yang didukung oleh hak istimewa admin terdelegasi terperinci (GDAP).

Banyak peran digunakan untuk Pusat Admin Microsoft 365. Untuk informasi selengkapnya, lihat Peran pusat admin Microsoft 365 yang umum digunakan.

Ya. Buat grup keamanan, tetapkan peran yang disetujui, lalu tetapkan pengguna penyewa mitra ke grup keamanan tersebut.

Akses baca-saja ke langganan pelanggan disediakan oleh pembaca Global , pembaca Direktori , dan peran dukungan Mitra tingkat 2.

Kami sarankan Anda menghapus agen mitra dari peran agen Admin dan menambahkannya ke grup keamanan GDAP saja. Dengan demikian, mereka dapat mengelola layanan (manajemen layanan dan permintaan layanan log, misalnya), tetapi mereka tidak dapat membeli dan mengelola langganan (mengubah kuantitas, membatalkan, menjadwalkan perubahan, dan sebagainya).

Kelompok keamanan yang ditetapkan ke hubungan kehilangan akses ke pelanggan tersebut. Hal yang sama terjadi jika pelanggan mengakhiri hubungan DAP.

Ya. Menghapus hubungan GDAP dengan pelanggan tidak mengakhiri hubungan penjual mitra dengan pelanggan. Mitra masih dapat membeli produk untuk pelanggan dan mengelola anggaran Azure dan aktivitas terkait lainnya.

Tidak. Semua peran dalam hubungan GDAP memiliki waktu yang sama untuk kedaluwarsa: durasi yang dipilih saat hubungan dibuat.

Tidak. Anda tidak memerlukan GDAP untuk memenuhi pesanan untuk pelanggan baru dan yang sudah ada. Anda dapat terus menggunakan proses yang sama untuk memenuhi pesanan pelanggan di Pusat Mitra.

Hubungan GDAP adalah per pelanggan. Anda dapat memiliki beberapa hubungan per pelanggan. Setiap hubungan GDAP dapat memiliki peran yang berbeda dan menggunakan grup Microsoft Entra yang berbeda dalam Penyewa CSP Anda. Di Pusat Mitra, penetapan peran berfungsi pada tingkat hubungan pelanggan-ke-GDAP. Jika Anda ingin menetapkan peran multikustomer, Anda dapat mengotomatiskan menggunakan API.

Tidak. Akun tamu tidak berfungsi dengan GDAP. Pelanggan harus menghapus akun tamu apa pun agar GDAP berfungsi.

Admin tamu GDAP tidak dapat mengelola informasi keamanan mereka sendiri di My Security-Info. Sebagai gantinya, mereka memerlukan bantuan admin penyewa tempat mereka menjadi tamu untuk setiap pendaftaran, pembaruan, atau penghapusan info keamanan. Organisasi dapat mengonfigurasi kebijakan akses lintas penyewa untuk mempercayai MFA dari penyewa CSP tepercaya. Jika tidak, admin tamu GDAP hanya terbatas pada metode yang dapat didaftarkan oleh admin penyewa (yaitu SMS atau Voice). Untuk mempelajari selengkapnya, lihat kebijakan akses lintas penyewa .

Sejajarkan dengan prinsip Panduan Zero Trust: Gunakan akses hak istimewa paling sedikit:

• Sebaiknya gunakan peran yang paling tidak istimewa oleh tugas dan tugas beban kerja Beban Kerja yang didukung oleh hak istimewa admin terdelegasi terperinci (GDAP) didukung oleh GDAP.
• Ketika perlu untuk mengatasi masalah yang diketahui yang tercantum, bekerja samalah dengan pelanggan Anda untuk meminta peran Administrator Global yang terikat waktu.
• Kami tidak merekomendasikan untuk mengganti peran Administrator Global dengan semua kemungkinan peran Microsoft Entra.

Ya. Selama periode transisi, DAP dan GDAP akan hidup berdampingan, dengan izin GDAP lebih diutamakan daripada izin DAP untuk Microsoft 365, Dynamics 365, dan beban kerja Azure.

DAP dan GDAP berdampingan selama periode transisi. Namun, akhirnya GDAP menggantiKAN DAP untuk memastikan bahwa kami memberikan solusi yang lebih aman bagi mitra dan pelanggan kami. Kami menyarankan agar Anda mentransisikan pelanggan Anda ke GDAP sesegera mungkin untuk memastikan kelangsungan.

Tidak ada perubahan pada alur hubungan DAP yang ada sementara DAP dan GDAP berdampingan.

DAP saat ini diberikan ketika penyewa pelanggan baru dibuat. Pada 25 September 2023, Microsoft tidak lagi memberikan DAP untuk pembuatan pelanggan baru dan sebaliknya memberikan GDAP Default dengan peran tertentu. Peran default bervariasi menurut jenis mitra, seperti yang diperlihatkan dalam tabel berikut:

Mitra dapat menerapkan Privileged Identity Management (PIM) pada grup keamanan GDAP di penyewa mitra untuk meningkatkan akses beberapa pengguna hak istimewa tinggi, tepat pada waktunya (JIT) untuk memberi mereka peran hak istimewa tinggi seperti admin Kata Sandi dengan penghapusan akses otomatis. Hingga Januari 2023, diperlukan bahwa setiap Grup Akses Istimewa (nama sebelumnya untuk fitur PIM for Groups) harus berada dalam grup yang dapat ditetapkan peran . Pembatasan ini sekarang dihapus. Mengingat perubahan ini, dimungkinkan untuk mengaktifkan lebih dari 500 grup per penyewa di PIM, tetapi hanya hingga 500 grup yang dapat ditetapkan peran. Ringkasan:

• Mitra dapat menggunakan yang dapat ditetapkan peran dan grup yang tidak dapat ditetapkan peran di PIM. Opsi ini secara efektif menghapus batas pada 500 grup/penyewa di PIM.
• Dengan pembaruan terbaru, ada dua cara untuk melakukan onboarding grup ke PIM (UX-wise): dari menu PIM atau dari menu Grup . Terlepas dari cara yang Anda pilih, hasil bersihnya sama.
  • Kemampuan untuk melakukan onboarding grup yang dapat ditetapkan peran/tidak dapat ditetapkan peran melalui menu PIM sudah tersedia.
  • Kemampuan untuk melakukan onboarding grup yang dapat ditetapkan peran/tidak dapat ditetapkan peran melalui menu Grup sudah tersedia.
• Untuk informasi selengkapnya, lihat Privileged Identity Management (PIM) untuk Grup (pratinjau) - Microsoft Entra.

GDAP umumnya tersedia dengan dukungan untuk semua layanan cloud komersial Microsoft (Microsoft 365, Dynamics 365, beban kerja Microsoft Azure, dan Microsoft Power Platform). Untuk informasi selengkapnya tentang bagaimana DAP dan GDAP dapat hidup berdampingan dan bagaimana GDAP lebih diutamakan, cari FAQ ini untuk Bagaimana izin GDAP lebih diutamakan daripada izin DAP sementara DAP dan GDAP hidup berdampingan? pertanyaan.

Anda dapat melakukan tindakan ini dengan API.

Tidak. Penghasilan PEC Anda tidak terpengaruh saat Anda beralih ke GDAP. Tidak ada perubahan pada PAL dengan transisi, memastikan bahwa Anda terus mendapatkan PEC.

• Jika pelanggan mitra hanya memiliki DAP dan DAP dihapus, PEC tidak hilang.
• Jika pelanggan mitra memiliki DAP, dan mereka pindah ke GDAP untuk Microsoft 365 dan Azure secara bersamaan, dan DAP dihapus, PEC tidak hilang.
• Jika pelanggan mitra memiliki DAP, dan mereka pindah ke GDAP untuk Microsoft 365 tetapi mempertahankan Azure as-is (mereka tidak pindah ke GDAP) dan DAP dihapus, PEC tidak hilang, tetapi akses ke langganan Azure hilang.
• Jika peran RBAC dihapus, PEC hilang, tetapi menghapus GDAP tidak menghapus RBAC.

Ketika pengguna adalah bagian dari grup keamanan GDAP dan grup agen Admin DAP dan pelanggan memiliki hubungan DAP dan GDAP, akses GDAP lebih diutamakan pada tingkat mitra, pelanggan, dan beban kerja.

Misalnya, jika pengguna mitra masuk untuk beban kerja dan ada DAP untuk peran admin Global dan GDAP untuk peran Pembaca global, pengguna mitra hanya mendapatkan izin pembaca Global.

Jika ada tiga pelanggan dengan penetapan peran GDAP hanya untuk grup keamanan GDAP (bukan agen Admin):

Tabel berikut ini menjelaskan apa yang terjadi saat pengguna masuk ke penyewa pelanggan yang berbeda.

DAP dan GDAP bukan jenis asosiasi yang memenuhi syarat untuk penunjukan Mitra Solusi. menonaktifkan atau beralih dari DAP ke GDAP tidak memengaruhi pencapaian penunjukan Mitra Solusi Anda. Selain itu, perpanjangan manfaat kompetensi warisan atau manfaat Mitra Solusi tidak terpengaruh. Untuk melihat jenis asosiasi mitra lain yang memenuhi syarat untuk penunjukan Mitra Solusi, lihat penunjukan Mitra Solusi Pusat Mitra.

Mengenai hubungan antara Azure Lighthouse dan DAP/GDAP, anggap saja sebagai jalur paralel yang dipisahkan ke sumber daya Azure. Memisahkan satu tidak boleh mempengaruhi yang lain.

• Dalam skenario Azure Lighthouse, pengguna dari penyewa mitra tidak pernah masuk ke penyewa pelanggan dan tidak memiliki izin Microsoft Entra di penyewa pelanggan. Penetapan peran Azure RBAC mereka juga disimpan di penyewa mitra.
• Dalam skenario GDAP, pengguna dari penyewa mitra masuk ke penyewa pelanggan. Penetapan peran Azure RBAC ke grup Agen admin juga ada di penyewa pelanggan. Anda dapat memblokir jalur GDAP (pengguna tidak dapat lagi masuk) saat jalur Azure Lighthouse tidak terpengaruh. Sebaliknya, Anda dapat memisahkan hubungan Lighthouse (proyeksi) tanpa memengaruhi GDAP. Untuk informasi selengkapnya, lihat dokumentasi Azure Lighthouse.

Penyedia Layanan Terkelola (MSP) yang terdaftar dalam program Penyedia Solusi Cloud (CSP) sebagai pengecer tidak langsung atau tagihan langsung mitra sekarang dapat menggunakan Microsoft 365 Lighthouse untuk menyiapkan GDAP untuk penyewa pelanggan mana pun. Karena ada beberapa cara mitra mengelola transisi mereka ke GDAP, wizard ini memungkinkan mitra Lighthouse mengadopsi rekomendasi peran khusus untuk kebutuhan bisnis mereka. Ini juga memungkinkan mereka mengadopsi langkah-langkah keamanan seperti akses just-in-time (JIT). MSP juga dapat membuat templat GDAP melalui Lighthouse untuk dengan mudah menyimpan dan menerapkan kembali pengaturan yang memungkinkan akses pelanggan yang paling tidak istimewa. Untuk informasi selengkapnya, dan untuk melihat demo, lihat wizard penyiapan GDAP Lighthouse . MSP dapat menyiapkan GDAP untuk penyewa pelanggan mana pun di Lighthouse. Untuk mengakses data beban kerja pelanggan di Lighthouse, diperlukan hubungan GDAP atau DAP. Jika GDAP dan DAP berdampingan di penyewa pelanggan, izin GDAP lebih diutamakan untuk teknisi MSP di grup keamanan berkemampuan GDAP. Untuk informasi selengkapnya tentang persyaratan untuk Microsoft 365 Lighthouse, lihat Persyaratan untuk Microsoft 365 Lighthouse.

Urutan yang benar untuk diikuti untuk skenario ini adalah:

1. Buat hubungan GDAP untuk Microsoft 365 dan Azure.
2. Tetapkan peran Microsoft Entra ke grup keamanan untuk Microsoft 365 dan Azure.
3. Konfigurasikan GDAP untuk lebih diutamakan daripada DAP.
4. Hapus DAP.

Urutan berikut dapat mengakibatkan kehilangan akses ke langganan Azure:

1. Hapus DAP. Anda tidak selalu kehilangan akses ke langganan Azure dengan menghapus DAP. Tetapi saat ini, Anda tidak dapat menelusuri direktori pelanggan untuk melakukan penetapan peran Azure RBAC apa pun (seperti menetapkan pengguna pelanggan baru sebagai kontributor RBAC langganan).
2. Buat hubungan GDAP untuk Microsoft 365 dan Azure bersama-sama. Anda mungkin kehilangan akses ke langganan Azure pada langkah ini segera setelah GDAP disiapkan.
3. Menetapkan peran Microsoft Entra ke grup keamanan untuk Microsoft 365 dan Azure

Anda mendapatkan kembali akses ke langganan Azure setelah penyiapan Azure GDAP selesai.

Jika Anda memiliki langganan Azure tanpa DAP yang Anda kelola sebagai pemilik, saat menambahkan GDAP untuk Microsoft 365 ke pelanggan tersebut, Anda mungkin kehilangan akses ke langganan Azure. Untuk menghindari kehilangan akses, pindahkan pelanggan ke Azure GDAP secara bersamaan bahwa Anda memindahkan pelanggan ke Microsoft 365 GDAP.

Tidak. Hubungan, setelah diterima, tidak dapat digunakan kembali.

Jika Anda memiliki hubungan penjual yang sudah ada dengan pelanggan, Anda masih perlu membuat hubungan GDAP untuk mengelola langganan Azure mereka.

1. Buat grup keamanan (misalnya, Azure Managers) di Microsoft Entra.
2. Buat hubungan GDAP dengan peran pembaca direktori .
3. Jadikan grup keamanan sebagai anggota grup Agen Admin . Setelah melakukan langkah-langkah ini, Anda dapat mengelola langganan Azure pelanggan dengan cara AOBO. Anda tidak dapat mengelola langganan melalui CLI/Powershell.

Ya. Anda dapat membuat paket Azure meskipun tidak ada DAP atau GDAP dengan hubungan penjual yang ada. Tetapi untuk mengelola langganan tersebut, Anda memerlukan DAP atau GDAP.

Saat mitra beralih dari DAP ke GDAP, mereka harus memastikan hal-hal berikut tersedia untuk melihat detail Perusahaan:

• Hubungan GDAP aktif.
• Salah satu peran Microsoft Entra berikut ditetapkan: Administrator Global, Pembaca Direktori, Pembaca Global. Lihat memberikan izin terperinci kepada kelompok keamanan.

Ketika CSP masuk ke portal Microsoft Azure pelanggan mereka (portal.azure.come) menggunakan kredensial CSP mereka dan hubungan GDAP ada, CSP melihat bahwa nama pengguna mereka "user_" diikuti oleh beberapa angka. Ini tidak menampilkan nama pengguna mereka yang sebenarnya seperti di DAP. Ini sudah didesain.

Mitra harus secara eksplisit memberikan izin terperinci kepada grup keamanan di GDAP Default.
Mulai 10 Oktober 2023, DAP tidak lagi tersedia dengan hubungan penjual. Tautan Hubungan Reseller Permintaan yang diperbarui tersedia di UI Pusat Mitra, dan URL properti kontrak API "/v1/pelanggan/permintaan hubungan" mengembalikan URL undangan untuk dikirim ke admin penyewa pelanggan.

Ya, mitra harus secara eksplisit memberikan izin terperinci kepada kelompok keamanan di GDAP Default untuk mengelola pelanggan.

Bermitra dengan hubungan penjual hanya tanpa DAP atau GDAP dapat membuat pelanggan, melakukan dan mengelola pesanan, mengunduh kunci perangkat lunak, mengelola Azure RI. Mereka tidak dapat melihat detail perusahaan pelanggan, tidak dapat melihat pengguna atau menetapkan lisensi kepada pengguna, tidak dapat mencatat tiket atas nama pelanggan, dan tidak dapat mengakses dan mengelola pusat admin khusus produk (Misalnya, pusat admin Teams.)

Agar mitra atau CPV dapat mengakses dan mengelola penyewa pelanggan, perwakilan layanan aplikasi mereka harus disetujui di penyewa pelanggan. Saat DAP aktif, mereka harus menambahkan perwakilan layanan aplikasi ke Admin Agents SG di penyewa mitra. Dengan GDAP, mitra harus memastikan aplikasi mereka disetujui di penyewa pelanggan. Jika aplikasi menggunakan izin yang didelegasikan (Aplikasi + Pengguna) dan GDAP aktif ada dengan salah satu dari tiga peran (Administrator Aplikasi Cloud, Administrator Aplikasi, Administrator Global) API persetujuan dapat digunakan. Jika aplikasi hanya menggunakan izin aplikasi, aplikasi harus disetujui secara manual, baik oleh mitra atau pelanggan yang memiliki salah satu dari tiga peran (Administrator Aplikasi Cloud, Administrator Aplikasi, Administrator Global), menggunakan URL persetujuan admin seluruh penyewa .

Jika Anda melihat kesalahan berikut:

"Kami tidak dapat memvalidasi permintaan 'Buat hubungan GDAP baru' Anda saat ini. Perhatikan bahwa koneksi anonim tidak diizinkan untuk layanan ini. Jika Anda yakin menerima pesan ini dalam kesalahan, coba permintaan Anda lagi. Pilih untuk mempelajari tentang tindakan yang dapat Anda lakukan. Jika masalah berlanjut, hubungi dukungan dan kode pesan referensi 715-123220 dan ID Transaksi: panduan."

Ubah cara Anda menyambungkan ke Microsoft untuk memungkinkan layanan verifikasi identitas berjalan dengan benar. Ini membantu memastikan bahwa akun Anda tidak disusupi dan mematuhi peraturan yang harus dipatuhi Microsoft.

Hal-hal yang dapat Anda lakukan:

• Hapus cache browser Anda.
• Nonaktifkan pencegahan pelacakan di browser Anda atau tambahkan situs kami ke daftar pengecualian/aman Anda.
• Matikan program atau layanan Virtual Private Network (VPN) apa pun yang mungkin Anda gunakan.
• Sambungkan langsung dari perangkat lokal Anda daripada melalui komputer virtual (VM).

Jika setelah mencoba langkah-langkah sebelumnya, Anda masih tidak dapat tersambung, kami sarankan untuk berkonsultasi dengan Staf Dukungan TI Anda untuk memeriksa pengaturan Anda untuk melihat apakah mereka dapat membantu mengidentifikasi apa yang menyebabkan masalah. Terkadang, masalahnya ada di pengaturan jaringan perusahaan Anda. Administrator TI Anda perlu mengatasi masalah, misalnya, dengan mencantumkan situs kami dengan aman atau membuat penyesuaian pengaturan jaringan lainnya.

• Dibatasi (Tagihan Langsung): GDAP Baru (Hubungan Admin) TIDAK DAPAT dibuat. GDIP yang ada dan penetapan perannya DAPAT diperbarui.
• Ditangguhkan (Tagihan Langsung/Penyedia Tidak Langsung/Reseller Tidak Langsung): GDAP Baru TIDAK DAPAT dibuat. GDIP yang ada dan penetapan perannya TIDAK DAPAT diperbarui.
• Dibatasi (Tagihan Langsung) + Aktif (Reseller Tidak Langsung): Untuk Tagihan Langsung Terbatas: GDAP Baru (Hubungan Admin) TIDAK DAPAT dibuat. GDIP yang ada dan penetapan perannya DAPAT diperbarui. Untuk Active Indirect Reseller: GDAP Baru DAPAT dibuat, GDIP yang ada dan penetapan perannya DAPAT diperbarui. Ketika GDAP baru yang di-offboarding tidak dapat dibuat, GDAP yang ada dan penetapan perannya tidak dapat diperbarui.

Ya. Rilis GDAP saat ini mendukung semua produk: Microsoft 365, Dynamics 365, Microsoft Power Platform, dan Microsoft Azure.