Penyelaman mendalam teknis autentikasi berbasis sertifikat Microsoft Entra

Artikel ini menjelaskan cara kerja autentikasi berbasis sertifikat (CBA) Microsoft Entra, dan menyelami detail teknis tentang konfigurasi Microsoft Entra CBA.

Bagaimana cara kerja autentikasi berbasis sertifikat Microsoft Entra?

Gambar berikut menjelaskan apa yang terjadi ketika pengguna mencoba masuk ke aplikasi di penyewa tempat Microsoft Entra CBA diaktifkan.

Berikut ini adalah langkah-langkah yang harus diambil:

1. Pengguna mencoba mengakses aplikasi, seperti portal MyApps.

2. Jika pengguna belum masuk, pengguna dialihkan ke halaman Masuk Pengguna Microsoft Entra ID di .

3. Pengguna memasukkan nama pengguna mereka ke halaman masuk Microsoft Entra, lalu memilih Berikutnya. Microsoft Entra ID melakukan penemuan realm asal menggunakan nama tenant, dan nama pengguna digunakan untuk mencari pengguna di dalam tenant.

   

4. MICROSOFT Entra ID memeriksa apakah CBA diaktifkan untuk penyewa. Jika CBA diaktifkan, pengguna akan melihat tautan ke Menggunakan sertifikat atau kartu pintar di halaman kata sandi. Jika pengguna tidak melihat tautan masuk, pastikan CBA diaktifkan pada penyewa. Untuk informasi selengkapnya, lihat Bagaimana cara mengaktifkan Microsoft Entra CBA?.

   Catatan

   Jika CBA diaktifkan pada penyewa, semua pengguna melihat tautan untuk Menggunakan sertifikat atau kartu pintar di halaman kata sandi. Namun, hanya pengguna yang termasuk dalam cakupan CBA yang berhasil mengotentikasi pada aplikasi yang menggunakan Microsoft Entra ID sebagai Penyedia Identitas (IdP) mereka.

   

   Jika Anda mengaktifkan metode autentikasi lain seperti Masuk telepon atau Kunci keamanan, pengguna mungkin melihat layar masuk yang berbeda.

   

5. Setelah pengguna memilih autentikasi berbasis sertifikat, klien akan diarahkan ke endpoint certauth, yaitu https://certauth.login.microsoftonline.com untuk ID Microsoft Entra publik. Untuk Azure Government, titik akhir certauth adalah https://certauth.login.microsoftonline.us.

   Titik akhir melakukan autentikasi bersama TLS, dan meminta sertifikat klien sebagai bagian dari jabat tangan TLS. Entri untuk permintaan ini muncul di log masuk.

   Catatan

   Administrator jaringan harus mengizinkan akses ke halaman masuk pengguna dan endpoint certauth *.certauth.login.microsoftonline.com untuk lingkungan cloud pelanggan. Nonaktifkan inspeksi TLS pada titik akhir certauth untuk memastikan permintaan sertifikat klien berhasil sebagai bagian dari jabat tangan TLS.

   Pastikan penonaktifan inspeksi TLS Anda juga berfungsi untuk URL baru dengan petunjuk penerbit. Jangan menetapkan URL secara permanen dengan tenantId karena mungkin berubah untuk pengguna B2B. Gunakan ekspresi reguler untuk memungkinkan URL lama dan baru berfungsi untuk penonaktifan inspeksi TLS. Misalnya, tergantung pada proksi, gunakan *.certauth.login.microsoftonline.com atau *certauth.login.microsoftonline.com. Di Azure Government, gunakan *.certauth.login.microsoftonline.us atau *certauth.login.microsoftonline.us.

   Kecuali akses diizinkan, autentikasi berbasis sertifikat gagal jika Anda mengaktifkan petunjuk pengeluar sertifikat.

6. ID Microsoft Entra meminta sertifikat klien. Pengguna memilih sertifikat klien, dan memilih Ok.

   

7. MICROSOFT Entra ID memverifikasi daftar pencabutan sertifikat untuk memastikan sertifikat tidak dicabut dan valid. Microsoft Entra ID mengidentifikasi pengguna dengan menggunakan pengikatan nama pengguna yang telah dikonfigurasi pada penyewa untuk memetakan nilai bidang sertifikat ke nilai atribut pengguna.

8. Jika pengguna unik ditemukan dengan kebijakan Akses Bersyarat yang memerlukan autentikasi multifaktor, dan aturan pengikatan autentikasi sertifikat memenuhi MFA, maka Microsoft Entra ID segera mengautentikasi pengguna. Jika MFA diperlukan tetapi sertifikat hanya memenuhi satu faktor, masuk tanpa kata sandi atau FIDO2 ditawarkan sebagai faktor kedua jika mereka sudah terdaftar.

9. MICROSOFT Entra ID menyelesaikan proses masuk dengan mengirim token refresh utama kembali untuk menunjukkan keberhasilan masuk.

10. Jika masuk pengguna berhasil, pengguna dapat mengakses aplikasi.

Memahami petunjuk penerbit (Pratinjau)

Petunjuk pengeluar sertifikat mengirim kembali Indikasi CA Tepercaya sebagai bagian dari jabat tangan TLS. Daftar CA tepercaya ditetapkan kepada subjek Penguasa Sertifikat (CA) yang diunggah oleh pengguna di toko kepercayaan Entra. Klien browser atau klien aplikasi asli dapat menggunakan petunjuk yang dikirim kembali oleh server untuk memfilter sertifikat yang ditunjukkan dalam pemilih sertifikat. Klien hanya menunjukkan sertifikat autentikasi yang dikeluarkan oleh CA di dalam daftar penyimpanan tepercaya.

Mengaktifkan petunjuk penerbit

Untuk mengaktifkan opsi pada kotak centang Petunjuk Pemberi. Administrator Kebijakan Autentikasi harus memilih saya mengakui setelah memastikan bahwa proksi dengan inspeksi TLS diaktifkan diperbarui dengan benar, dan menyimpan.

Catatan

Jika organisasi Anda memiliki firewall atau proksi dengan inspeksi TLS, pastikan bahwa Anda menonaktifkan inspeksi TLS dari endpoint certauth yang mampu mencocokkan nama apapun di bawah [*.]certauth.login.microsoftonline.com, yang telah disesuaikan sesuai dengan proksi tertentu yang digunakan.

Catatan

URL otoritas sertifikat dalam format t{tenantId}.certauth.login.microsoftonline.com setelah petunjuk pengeluar sertifikat diaktifkan.

Penyebaran pembaruan toko kepercayaan CA

Setelah Anda mengaktifkan petunjuk pengeluar sertifikat dan menambahkan, memperbarui, atau menghapus CA dari status kepercayaan, ada penundaan hingga 10 menit untuk menyebarluaskan petunjuk pengeluar sertifikat kembali ke klien. Pengguna tidak dapat mengautentikasi dengan sertifikat yang dikeluarkan oleh CA baru sampai petunjuk tersebut tersebar.

Administrator Kebijakan Otentikasi harus masuk dengan sertifikat setelah mereka mengaktifkan petunjuk penerbit untuk memulai propagasi. Pengguna melihat pesan kesalahan berikut saat pembaruan penyimpanan kepercayaan CA sedang disebarkan.

MFA dengan autentikasi berbasis sertifikat faktor tunggal

Microsoft Entra CBA didukung sebagai faktor pertama dan faktor kedua untuk autentikasi. Beberapa kombinasi yang didukung adalah:

1. CBA (faktor pertama) dan kode akses (faktor kedua)
2. CBA (faktor pertama) dan masuk dengan telepon tanpa kata sandi (faktor kedua)
3. CBA (faktor pertama) dan kunci keamanan FIDO2 (faktor kedua)
4. Kata sandi (faktor pertama) + CBA (faktor kedua) (Pratinjau)

Catatan

CBA sebagai faktor kedua pada iOS memiliki masalah yang diketahui dan diblokir di iOS. Kami sedang berupaya memperbaiki masalah dan harus didukung di iOS.

Pengguna harus memiliki cara untuk mendapatkan MFA dan mendaftarkan masuk tanpa kata sandi atau FIDO2 terlebih dahulu untuk masuk dengan Microsoft Entra CBA.

Penting

Pengguna dianggap mampu MFA saat disertakan dalam pengaturan metode CBA. Ini berarti pengguna tidak dapat menggunakan bukti sebagai bagian dari autentikasi mereka untuk mendaftarkan metode lain yang tersedia. Pastikan pengguna tanpa sertifikat yang valid tidak disertakan dalam pengaturan metode CBA. Untuk informasi selengkapnya tentang cara kerja autentikasi, lihat Autentikasi multifaktor Microsoft Entra.

Opsi untuk mendapatkan kemampuan MFA dengan Sertifikat faktor tunggal

Microsoft Entra CBA mampu melakukan autentikasi multifaktor (MFA). Microsoft Entra CBA dapat berupa faktor tunggal (SF) atau multifaktor (MF) tergantung pada konfigurasi penyewa. Mengaktifkan CBA membuat pengguna berpotensi mampu menyelesaikan MFA. Pengguna dengan sertifikat faktor tunggal memerlukan faktor lain untuk menyelesaikan MFA, itulah sebabnya kami tidak akan mengizinkan pendaftaran metode lain tanpa memuaskan MFA. Jika pengguna tidak memiliki metode autentikasi MFA lain yang terdaftar dan dimasukkan ke dalam cakupan untuk metode autentikasi CBA, pengguna tidak dapat melakukan verifikasi untuk mendaftarkan metode autentikasi lain dan mendapatkan otentikasi multi-faktor (MFA).

Jika pengguna berkemampuan CBA hanya memiliki sertifikat Single Factor (SF) dan perlu menyelesaikan MFA:

1. Menggunakan kata sandi dan sertifikat SF (OR)
2. Administrator Kebijakan Autentikasi dapat mengeluarkan Kode Akses Sementara (OR)
3. Administrator Kebijakan Autentikasi menambahkan nomor telepon dan mengizinkan autentikasi pesan suara/teks untuk akun pengguna.

Jika pengguna yang diaktifkan CBA belum diberikan sertifikat dan perlu menyelesaikan MFA:

1. Administrator Kebijakan Autentikasi dapat mengeluarkan Kode Akses Sementara (OR)
2. Administrator Kebijakan Autentikasi menambahkan nomor telepon dan mengizinkan autentikasi pesan suara/teks untuk akun pengguna.

Jika pengguna berkemampuan CBA tidak dapat menggunakan sertifikasi MF, seperti pada perangkat seluler tanpa dukungan kartu pintar, dan perlu menyelesaikan MFA:

1. Administrator Kebijakan Autentikasi dapat mengeluarkan Kode Akses Sementara (OR)
2. Pengguna perlu mendaftarkan metode MFA lain (ketika pengguna dapat menggunakan sertifikasi MF pada beberapa perangkat) (ATAU)
3. Administrator Kebijakan Autentikasi menambahkan nomor telepon dan mengizinkan autentikasi pesan suara/teks untuk akun pengguna.

Langkah-langkah untuk mengaktifkan masuk menggunakan telepon tanpa kata sandi (PSI) dengan CBA

Agar masuk tanpa kata sandi berfungsi, pengguna harus menonaktifkan pemberitahuan warisan melalui aplikasi seluler mereka.

1. Masuk ke Pusat Admin Microsoft Entra sebagai setidaknya seorang Administrator Kebijakan Autentikasi.

2. Ikuti langkah-langkah di Mengaktifkan autentikasi masuk menggunakan telepon tanpa kata sandi.

   Penting

   Dalam konfigurasi sebelumnya, pastikan Anda memilih opsi Tanpa Kata Sandi. Anda perlu mengubah mode Autentikasi untuk setiap grup yang ditambahkan untuk PSI ke mode Tanpa Kata Sandi. Jika Anda memilih Apa pun, CBA dan PSI tidak berfungsi.

3. Pilih Perlindungan>Autentikasi multifaktor>Pengaturan autentikasi multifaktor berbasis cloud tambahan.

   

4. Di bawah Opsi verifikasi, kosongkan Pemberitahuan melalui aplikasi seluler, dan pilih Simpan.

   

Alur autentikasi MFA menggunakan sertifikat faktor tunggal dan masuk tanpa kata sandi

Mari kita lihat contoh pengguna yang memiliki sertifikat faktor tunggal, dan dikonfigurasi untuk masuk tanpa kata sandi.

1. Masukkan nama prinsipal pengguna (UPN) Anda dan pilih Berikutnya.

   

2. Pilih Masuk dengan sertifikat.

   

   Jika Anda mengaktifkan metode autentikasi lain seperti Masuk melalui telepon atau kunci keamanan FIDO2, pengguna mungkin melihat layar masuk yang berbeda.

   

3. Pilih sertifikat pengguna yang benar di pemilih sertifikat klien dan pilih OK.

   

4. Karena sertifikat dikonfigurasi menjadi kekuatan autentikasi faktor tunggal, pengguna memerlukan faktor kedua untuk memenuhi persyaratan MFA. Pengguna melihat faktor kedua yang tersedia, yang dalam hal ini adalah masuk tanpa kata sandi. Pilih Setujui permintaan di aplikasi Microsoft Authenticator saya.

   

5. Anda akan mendapatkan pemberitahuan di ponsel Anda. Pilih Setujui Masuk?.

6. Masukkan nomor yang Anda lihat di layar browser atau aplikasi ke Microsoft Authenticator.

   

7. Pilih Ya dan pengguna dapat mengautentikasi dan masuk.

Memahami kebijakan pengikatan autentikasi

Kebijakan pengikatan autentikasi membantu menentukan kekuatan autentikasi sebagai faktor tunggal atau multifaktor. Administrator Kebijakan Autentikasi dapat mengubah nilai default dari faktor tunggal menjadi multifaktor, atau menyiapkan konfigurasi kebijakan kustom dengan menggunakan subjek penerbit, kebijakan OID, atau kombinasi penerbit dan OID Kebijakan dalam sertifikat.

Kekuatan sertifikat

Administrator Kebijakan Autentikasi dapat menentukan apakah sertifikat memiliki kekuatan faktor tunggal atau multifaktor. Untuk informasi selengkapnya, lihat dokumentasi yang memetakan Tingkat Jaminan Autentikasi NIST ke Metode autentikasi Microsoft Entra, yang dibangun berdasarkan NIST 800-63B SP 800-63B, Panduan Identitas Digital: Autentikasi dan Siklus Hidup Mgmt.

Autentikasi sertifikat multifaktor

Ketika pengguna memiliki sertifikat multifaktor, mereka dapat melakukan autentikasi multifaktor hanya dengan sertifikat. Namun, Administrator Kebijakan Autentikasi harus memastikan sertifikat dilindungi dengan PIN atau biometrik untuk dianggap multifaktor.

Cara ID Microsoft Entra mengatasi beberapa aturan pengikatan kebijakan autentikasi

Karena beberapa aturan kebijakan pengikatan autentikasi kustom dapat dibuat dengan bidang sertifikat yang berbeda seperti menggunakan penerbit + OID kebijakan, atau hanya OID Kebijakan atau hanya penerbit. Di bawah ini adalah langkah-langkah yang digunakan untuk menentukan tingkat perlindungan autentikasi saat aturan kustom tumpang tindih. Klaimnya sebagai berikut:

1. Aturan OID penerbit + kebijakan lebih diutamakan daripada aturan OID Kebijakan. Aturan OID kebijakan lebih diutamakan daripada aturan penerbit sertifikat.
2. Penerbit + aturan OID kebijakan dievaluasi terlebih dahulu. Jika Anda memiliki aturan kustom dengan penerbit CA1 dan OID kebijakan 1.2.3.4.5 dengan MFA, hanya sertifikat A yang memenuhi nilai penerbit dan OID kebijakan akan mendapatkan MFA.
3. Selanjutnya, aturan kustom yang menggunakan OID kebijakan dievaluasi. Jika Anda memiliki sertifikat A dengan kebijakan OID 1.2.3.4.5 dan kredensial turunan B berdasarkan sertifikat tersebut memiliki kebijakan OID 1.2.3.4.5.6, dan aturan kustom didefinisikan sebagai Policy OID dengan nilai 1.2.3.4.5 dengan MFA, hanya sertifikat A yang memenuhi MFA, dan kredensial B hanya memenuhi autentikasi faktor tunggal. Jika pengguna menggunakan kredensial turunan selama masuk dan dikonfigurasi untuk memiliki MFA, pengguna dimintai faktor kedua untuk autentikasi yang berhasil.
4. Jika ada konflik antara beberapa OID kebijakan (seperti ketika sertifikat memiliki dua OID kebijakan, di mana satu mengikat autentikasi faktor tunggal dan yang lain mengikat MFA) maka perlakukan sertifikat sebagai autentikasi faktor tunggal.
5. Selanjutnya, aturan kustom yang menggunakan CA penerbit dievaluasi.
6. Jika sertifikat memiliki aturan OID kebijakan dan aturan Penerbit yang cocok, OID kebijakan selalu diperiksa terlebih dahulu, dan jika tidak ada aturan kebijakan yang ditemukan maka pengikatan aturan penerbit diperiksa. OID kebijakan memiliki prioritas pengikatan autentikasi yang lebih tinggi daripada pengeluar sertifikat.
7. Jika satu CA mengikat MFA, semua sertifikat pengguna yang dikeluarkan CA ini memenuhi syarat sebagai MFA. Logika yang sama berlaku untuk autentikasi faktor tunggal.
8. Jika satu OID kebijakan mengikat MFA, semua sertifikat pengguna yang menyertakan OID kebijakan ini sebagai salah satu OID (Sertifikat pengguna dapat memiliki beberapa OID kebijakan) yang memenuhi syarat sebagai MFA.
9. Satu penerbit sertifikat hanya dapat memiliki satu pengikatan autentikasi yang kuat yang valid (yaitu, sertifikat tidak dapat mengikat faktor tunggal dan MFA).

Penting

Ada masalah yang sudah diketahui saat Administrator Kebijakan Autentikasi Microsoft Entra mengonfigurasi aturan kebijakan autentikasi CBA menggunakan Penerbit dan OID Kebijakan, berdampak pada skenario pendaftaran perangkat tertentu, termasuk:

• Pendaftaran Windows Hello For Business
• Pendaftaran Kunci Keamanan Fido2
• Masuk ke Windows tanpa Kata Sandi dengan Telepon

Pendaftaran perangkat dengan Workplace Join, ID Microsoft Entra, dan skenario penggabungan perangkat Microsoft Entra Hibrid tidak terpengaruh. Aturan kebijakan autentikasi CBA yang menggunakan Penerbit ATAU OID Kebijakan tidak terpengaruh. Untuk mengurangi, Administrator Kebijakan Autentikasi harus :

• Edit aturan kebijakan autentikasi berbasis sertifikat yang saat ini menggunakan opsi Penerbit dan Kebijakan OID, lalu hapus persyaratan antara Penerbit atau OID dan simpan. ATAU
• Hapus aturan kebijakan autentikasi yang saat ini menggunakan Penerbit dan OID kebijakan, lalu buat aturan yang hanya menggunakan Penerbit atau OID kebijakan.

Kami berupaya memperbaiki masalah ini.

Memahami kebijakan pengikatan nama pengguna

Kebijakan pengikatan nama pengguna membantu memvalidasi sertifikat pengguna. Secara default, Nama Utama SAN (Subject Alternate Name) dalam sertifikat dipetakan ke atribut UserPrincipalName dari objek pengguna guna menentukan pengguna.

Mencapai keamanan yang lebih tinggi dengan pengikatan sertifikat

Ada tujuh metode yang didukung untuk pengikatan sertifikat. Secara umum, jenis pemetaan dianggap afinitas tinggi jika didasarkan pada pengidentifikasi yang tidak dapat Anda gunakan kembali, seperti Pengidentifikasi Kunci Subjek atau Kunci Umum SHA1. Pengidentifikasi ini menyampaikan jaminan yang lebih tinggi bahwa hanya satu sertifikat yang dapat digunakan untuk mengautentikasi pengguna masing-masing.

Jenis pemetaan berdasarkan nama pengguna dan alamat email dianggap sebagai afinitas rendah. Microsoft Entra ID mengimplementasikan tiga pemetaan yang dianggap memiliki afinitas rendah berdasarkan pengidentifikasi yang dapat diulang. Yang lain dianggap sebagai ikatan afinitas tinggi. Untuk informasi selengkapnya, lihat certificateUserIds.

Bidang pemetaan sertifikat	Contoh nilai dalam certificateUserIds	Atribut objek pengguna	Jenis
NamaKepala	X509:<PN>bob@woodgrove.com	userPrincipalName onPremisesUserPrincipalName certificateUserIds	afinitas rendah
RFC822Name	X509:<RFC822>user@woodgrove.com	userPrincipalName onPremisesUserPrincipalName certificateUserIds	afinitas rendah
IssuerAndSubject (pratinjau)	X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<S>DC=com,DC=contoso,OU=UserAccounts,CN=mfatest	certificateUserIds	afinitas rendah
Subjek (pratinjau)	X509:<S>DC=com,DC=contoso,OU=UserAccounts,CN=mfatest	IdPenggunaSertifikat	afinitas rendah
SKI	X509:<SKI>aB1cD2eF3gH4iJ5kL6-mN7oP8qR=	ID Pengguna Sertifikat	afinitas tinggi
SHA1PublicKey	X509:<SHA1-PUKEY>aB1cD2eF3gH4iJ5kL6-mN7oP8qR	certificateUserIds	afinitas tinggi
Pemberi Dan Nomor Seri (pratinjau)	X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>cD2eF3gH4iJ5kL6mN7-oP8qR9sT Untuk mendapatkan nilai yang benar untuk nomor seri, jalankan perintah ini dan simpan nilai yang diperlihatkan di CertificateUserIds: Sintaks: Certutil –dump –v [~certificate path~] >> [~dumpFile path~] Contoh: certutil -dump -v firstusercert.cer >> firstCertDump.txt	certificateUserIds	afinitas tinggi

Tentukan pengikatan Afinitas di tingkat penyewa dan ambil alih dengan aturan kustom (Pratinjau)

Dengan fitur ini, Administrator Kebijakan Autentikasi dapat mengonfigurasi apakah pengguna dapat diautentikasi dengan menggunakan pemetaan pengikatan nama pengguna afinitas rendah atau afinitas tinggi. Anda dapat mengatur Pengikatan afinitas yang diperlukan untuk penyewa, yang berlaku untuk semua pengguna. Anda juga dapat mengubah nilai default tenant secara menyeluruh dengan membuat aturan khusus berdasarkan Penerbit dan OID Kebijakan, atau hanya OID Kebijakan, atau hanya Penerbit.

Cara ID Microsoft Entra mengatasi beberapa aturan pengikatan kebijakan nama pengguna

Gunakan pengikatan prioritas tertinggi (angka terendah).

1. Cari objek pengguna dengan menggunakan nama pengguna atau Nama Prinsipal Pengguna.
2. Dapatkan daftar semua pengikatan nama pengguna yang disiapkan oleh Administrator Kebijakan Autentikasi dalam konfigurasi metode autentikasi CBA yang diurutkan berdasarkan atribut 'prioritas'. Saat ini konsep prioritas tidak diekspos di UX Portal. Grafik mengembalikan atribut prioritas untuk setiap pengikatan dan digunakan dalam proses evaluasi.
3. Jika penyewa memiliki pengikatan afinitas tinggi diaktifkan atau jika nilai sertifikat cocok dengan aturan kustom yang memerlukan pengikatan afinitas tinggi, hapus semua pengikatan afinitas rendah dari daftar.
4. Evaluasi setiap pengikatan dalam daftar hingga autentikasi berhasil terjadi.
5. Jika bidang sertifikat X.509 dari pengikatan yang dikonfigurasi terdapat pada sertifikat yang disajikan, Microsoft Entra ID mencocokkan nilai di bidang sertifikat tersebut dengan nilai atribut objek pengguna.
   1. Jika kecocokan ditemukan, autentikasi pengguna berhasil.
   2. Jika kecocokan tidak ditemukan, lanjutkan ke pengikatan prioritas berikutnya.
6. Jika bidang sertifikat X.509 tidak ada di sertifikat yang disajikan, pindahkan ke pengikatan prioritas berikutnya.
7. Validasi semua pengikatan nama pengguna yang dikonfigurasi hingga salah satunya menghasilkan kecocokan dan autentikasi pengguna berhasil.
8. Jika kecocokan tidak ditemukan pada salah satu pengikatan nama pengguna yang dikonfigurasi, autentikasi pengguna gagal.

Mengamankan konfigurasi Microsoft Entra dengan beberapa pengikatan nama pengguna

Setiap atribut objek pengguna Microsoft Entra (userPrincipalName, onPremiseUserPrincipalName, certificateUserIds) tersedia untuk mengikat sertifikat ke akun pengguna Microsoft Entra memiliki batasan unik untuk memastikan sertifikat hanya cocok dengan satu akun pengguna Microsoft Entra. Namun, Microsoft Entra CBA mendukung beberapa metode pengikatan dalam kebijakan pengikatan nama pengguna yang memungkinkan Administrator Kebijakan Autentikasi untuk mengakomodasi satu sertifikat ke beberapa konfigurasi akun pengguna Microsoft Entra.

Penting

Jika Anda mengonfigurasi beberapa pengikatan, autentikasi Microsoft Entra CBA hanya seaman pengikatan afinitas terendah Anda karena CBA memvalidasi setiap pengikatan untuk mengautentikasi pengguna. Untuk mencegah skenario di mana satu sertifikat cocok dengan beberapa akun Microsoft Entra, Administrator Kebijakan Autentikasi dapat:

• Konfigurasikan satu metode pengikatan dalam kebijakan pengikatan nama pengguna.
• Jika penyewa memiliki beberapa metode pengikatan yang dikonfigurasi dan tidak ingin mengizinkan satu sertifikat untuk memetakan ke beberapa akun, Administrator Kebijakan Autentikasi harus memastikan semua metode yang diizinkan dikonfigurasi dalam peta kebijakan ke akun Microsoft Entra yang sama. Semua akun pengguna harus memiliki nilai yang cocok dengan semua pengikatan.
• Jika penyewa memiliki beberapa metode pengikatan yang dikonfigurasi, Administrator Kebijakan Autentikasi harus memastikan bahwa mereka tidak memiliki lebih dari satu pengikatan afinitas rendah.

Misalnya, misalkan Anda memiliki dua pengikatan nama pengguna pada PrincipalName yang dipetakan ke UPN dan SubjectKeyIdentifier (SKI) yang dipetakan ke certificateUserIds. Jika Anda ingin sertifikat hanya digunakan untuk satu akun, Administrator Kebijakan Autentikasi harus memastikan bahwa akun memiliki UPN yang ada dalam sertifikat, dan menerapkan pemetaan SKI di atribut certificateUserId dari akun yang sama.

Dukungan untuk beberapa sertifikat dengan satu akun pengguna Microsoft Entra (M:1)

Ada skenario di mana organisasi mengeluarkan beberapa sertifikat untuk satu identitas. Paling umum ini bisa menjadi kredensial turunan untuk perangkat seluler atau juga dapat untuk smartcard sekunder atau perangkat berkemampuan pemegang kredensial x509 seperti Yubikey.

Akun khusus cloud Untuk akun khusus cloud, Anda dapat memetakan beberapa sertifikat (hingga 5) untuk digunakan dengan mengisi bidang certificateUserIds (Info otorisasi di Portal Pengguna) dengan nilai unik yang mengidentifikasi setiap sertifikat. Jika organisasi menggunakan pengikatan afinitas tinggi, misalnya Penerbit + SerialNumber, nilai dalam CertificateUserIds mungkin terlihat seperti berikut ini:

X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>cD2eF3gH4iJ5kL6mN7-oP8qR9sT
X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>eF3gH4iJ5kL6mN7oP8-qR9sT0uV

Dalam contoh ini, nilai pertama mewakili X509Certificate1 dan nilai kedua mewakili X509Certificate2. Pengguna dapat menunjukkan salah satu sertifikat saat melakukan masuk, dan selama Pengikatan Nama Pengguna CBA diatur untuk menunjuk ke bidang certificateUserIds untuk mencari jenis pengikatan tertentu (yaitu, Issuer+SerialNumber dalam contoh ini), maka pengguna berhasil masuk.

Akun Yang Disinkronkan Hibrid Untuk akun yang disinkronkan, Anda dapat memetakan beberapa sertifikat untuk digunakan dengan mengisi bidang altSecurityIdentities di AD, nilai yang mengidentifikasi setiap sertifikat. Jika organisasi menggunakan pengikatan afinitas tinggi (yaitu, autentikasi yang kuat) seperti Penerbit + SerialNumber, ini bisa terlihat seperti berikut:

X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>cD2eF3gH4iJ5kL6mN7-oP8qR9sT
X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>eF3gH4iJ5kL6mN7oP8-qR9sT0uV

Dalam contoh ini, nilai pertama mewakili X509Certificate1 dan nilai kedua mewakili X509Certificate2. Nilai-nilai ini kemudian harus disinkronkan ke bidang certificateUserIds di ID Microsoft Entra.

Dukungan untuk satu sertifikat dengan beberapa akun pengguna Microsoft Entra (1:M)

Ada skenario di mana organisasi memerlukan pengguna untuk menggunakan sertifikat yang sama untuk mengautentikasi ke beberapa identitas. Paling umum ini untuk akun administratif. Ini juga dapat untuk akun pengembang atau akun tugas sementara. Dalam AD tradisional, bidang altSecurityIdentities digunakan untuk mengisi nilai sertifikat dan Petunjuk digunakan selama masuk untuk mengarahkan AD ke akun yang diinginkan untuk memverifikasi masuk. Dengan Microsoft Entra CBA ini berbeda dan tidak ada Petunjuk. Sebagai gantinya, Home Realm Discovery mengidentifikasi akun yang diinginkan untuk memeriksa nilai sertifikat. Perbedaan utama lainnya adalah bahwa Microsoft Entra CBA memberlakukan keunikan di bidang certificateUserIds. Ini berarti bahwa dua akun tidak dapat mengisi nilai sertifikat yang sama.

Penting

Ini bukan konfigurasi yang sangat aman untuk menggunakan kredensial yang sama untuk mengautentikasi ke akun Microsoft Entra yang berbeda dan disarankan untuk tidak mengizinkan satu sertifikat untuk beberapa akun pengguna Microsoft Entra.

Akun yang hanya ada di cloud Untuk akun yang hanya ada di cloud, Anda perlu membuat beberapa pengikatan nama pengguna dan memetakan nilai unik ke setiap akun pengguna yang akan menggunakan sertifikat. Setiap akun diautentikasi menggunakan pengikatan nama pengguna yang berbeda. Ini berlaku dalam batas direktori/penyewa tunggal (yaitu, Administrator Kebijakan Autentikasi dapat memetakan sertifikat untuk digunakan di direktori/penyewa lain juga, selama nilai tetap unik per akun juga).

Isi bidang certificateUserIds (Info otorisasi di Portal Pengguna) dengan nilai unik yang mengidentifikasi sertifikat yang diinginkan. Jika organisasi menggunakan pengikatan afinitas tinggi (yaitu, autentikasi yang kuat) seperti Penerbit + SerialNumber dan SKI, ini dapat terlihat sebagai berikut:

Pengikatan nama pengguna:

• Penerbit + Nomor Seri -> CertificateUserIds
• SKI -> CertificateUserIds

Nilai-nilai CertificateUserIds pada akun pengguna.
X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>aB1cD2eF3gH4iJ5kL6-mN7oP8qR
X509:<SKI>cD2eF3gH4iJ5kL6mN7-oP8qR9sT

Sekarang, ketika salah satu pengguna menyajikan sertifikat yang sama saat masuk, pengguna berhasil masuk karena akun mereka cocok dengan nilai unik pada sertifikat tersebut. Satu akun diautentikasi menggunakan Issuer+SerialNumber dan akun lainnya menggunakan pengikatan SKI.

Catatan

Jumlah akun yang dapat digunakan dengan cara ini dibatasi oleh jumlah pengikatan nama pengguna yang dikonfigurasi pada penyewa. Jika organisasi hanya menggunakan pengikatan Afinitas Tinggi, jumlah akun yang didukung dibatasi hingga 3. Jika organisasi juga menggunakan pengikatan afinitas rendah, jumlah ini meningkat menjadi 7 akun (1 PrincipalName, 1 RFC822Name, 1 SubjectKeyIdentifier, 1 SHA1PublicKey, 1 Issuer+Subject, 1 Issuer+SerialNumber, 1 Subject).

Akun Synchronized Hibrida Untuk akun yang disinkronkan, pendekatannya berbeda. Meskipun Administrator Kebijakan Autentikasi dapat memetakan nilai unik ke setiap akun pengguna yang menggunakan sertifikat, praktik umum mengisi semua nilai ke setiap akun di ID Microsoft Entra menyulitkan ini. Sebagai gantinya, Microsoft Entra Connect harus memfilter nilai yang diinginkan per akun ke nilai unik yang diisi ke akun di ID Microsoft Entra. Aturan keunikan berlaku dalam batas direktori/penyewa tunggal (yaitu, Administrator Kebijakan Autentikasi dapat memetakan sertifikat untuk digunakan di direktori/penyewa lain juga, selama nilai tetap unik per akun juga). Selanjutnya, organisasi mungkin memiliki beberapa hutan AD yang menyatukan pengguna ke dalam satu penyewa Microsoft Entra. Dalam hal ini, Microsoft Entra Connect menerapkan filter ke masing-masing forest AD ini dengan tujuan yang sama untuk mengisi hanya nilai unik yang diinginkan ke akun cloud.

Isi bidang altSecurityIdentities di AD dengan nilai yang mengidentifikasi sertifikat yang diinginkan dan untuk menyertakan nilai sertifikat yang diinginkan untuk jenis akun pengguna tersebut (seperti detailee, admin, pengembang, dan sebagainya). Pilih atribut kunci di AD yang memberi tahu sinkronisasi jenis akun pengguna mana yang dievaluasi pengguna (seperti msDS-cloudExtensionAttribute1). Isi atribut ini dengan nilai jenis pengguna yang Anda inginkan seperti detailee, admin, atau pengembang. Jika ini adalah akun utama pengguna, nilainya dapat dibiarkan kosong/null.

Akun bisa terlihat seperti berikut ini:

Forest 1 - Account1 (bob@woodgrove.com):
X509:<SKI>aB1cD2eF3gH4iJ5kL6mN7oP8qR
X509:<SHA1-PUKEY>cD2eF3gH4iJ5kL6mN7oP8qR9sT
X509:<PN>bob@woodgrove.com

Hutan 1 - Akun2 (bob-admin@woodgrove.com):
X509:<SKI>aB1cD2eF3gH4iJ5kL6mN7oP8qR
X509:<SHA1-PUKEY>>cD2eF3gH4iJ5kL6mN7oP8qR9sT
X509:<PN>bob@woodgrove.com

Forest 2 – ADAccount1 (bob-tdy@woodgrove.com):
X509:<SKI>aB1cD2eF3gH4iJ5kL6mN7oP8qR
X509:<SHA1-PUKEY>>cD2eF3gH4iJ5kL6mN7oP8qR9sT
X509:<PN>bob@woodgrove.com

Nilai-nilai ini kemudian harus disinkronkan ke bidang certificateUserIds di ID Microsoft Entra.

Langkah-langkah untuk menyinkronkan ke certificateUserIds

1. Mengonfigurasi Microsoft Entra Connect untuk menambahkan bidang alternativeSecurityIds ke Metaverse
2. Untuk setiap Forest AD, konfigurasikan aturan masuk kustom baru dengan prioritas tinggi (angka rendah di bawah 100). Tambahkan transformasi Ekspresi dengan bidang altSecurityIdentities sebagai sumbernya. Ekspresi target memanfaatkan Atribut Kunci yang telah Anda pilih dan telah Anda isi, serta pemetaan ke Jenis Pengguna yang Anda tentukan.
3. Contohnya:

IIF((IsPresent([msDS-cloudExtensionAttribute1]) && IsPresent([altSecurityIdentities])), 
    IIF((InStr(LCase([msDS-cloudExtensionAttribute1]),LCase("detailee"))>0), 
    Where($item,[altSecurityIdentities],(InStr($item, "X509:<SHA1-PUKEY>")>0)), 
        IIF((InStr(LCase([msDS-cloudExtensionAttribute1]),LCase("developer"))>0), 
        Where($item,[altSecurityIdentities],(InStr($item, "X509:<SKI>")>0)), NULL) ), 
    IIF(IsPresent([altSecurityIdentities]), 
    Where($item,[altSecurityIdentities],(BitAnd(InStr($item, "X509:<I>"),InStrRev($item, "<SR>"))>0)), NULL) 
)

Dalam contoh di atas, altSecurityIdentities dan atribut kunci msDS-cloudExtensionAttribute1is pertama kali diperiksa untuk melihat apakah mereka diisi. Jika tidak, akan diperiksa apakah altSecurityIdentities sudah terisi. Jika kosong maka kita atur ke NULL. Jika tidak, akun akan masuk ke dalam kasus default, dan dalam contoh ini kami memfilter hanya untuk pemetaan Issuer+SerialNumber. Jika atribut kunci diisi, maka nilai diperiksa untuk melihat apakah itu sama dengan salah satu jenis pengguna yang ditentukan. Dalam contoh ini jika nilai tersebut adalah detailee, maka kita memfilter ke nilai SHA1PublicKey dari altSecurityIdentities. Jika nilainya adalah pengembang, maka kita memfilter ke nilai SubjectKeyIssuer dari altSecurityIdentities. Mungkin ada beberapa nilai sertifikat dari jenis tertentu. Misalnya, beberapa nilai PrincipalName atau beberapa nilai SKI atau SHA1-PUKEY. Filter mendapatkan semua nilai dan mengintegrasikannya ke dalam Microsoft Entra ID – bukan hanya yang pertama yang ditemukannya.

1. Contoh kedua yang menunjukkan cara memasukkan nilai kosong jika atribut kontrol kosong adalah sebagai berikut:

IIF((IsPresent([msDS-cloudExtensionAttribute1]) && IsPresent([altSecurityIdentities])), 
    IIF((InStr(LCase([msDS-cloudExtensionAttribute1]),LCase("detailee"))>0), 
    Where($item,[altSecurityIdentities],(InStr($item, "X509:<SHA1-PUKEY>")>0)), 
        IIF((InStr(LCase([msDS-cloudExtensionAttribute1]),LCase("developer")>0), 
        Where($item,[altSecurityIdentities],(InStr($item, "X509:<SKI>")>0)), NULL) ), 
    IIF(IsPresent([altSecurityIdentities]), 
    AuthoritativeNull, NULL) 
) 

Jika nilai dalam altSecurityIdentities tidak cocok dengan salah satu nilai pencarian di atribut kontrol, maka AuthoritativeNull diteruskan. Ini memastikan bahwa aturan sebelumnya atau berikutnya yang mengisi alternativeSecurityId diabaikan dan hasilnya menjadi kosong di Microsoft Entra ID.

1. Konfigurasikan aturan keluar kustom baru dengan prioritas rendah (angka tinggi di atas 160 – bagian bawah daftar).
2. Tambahkan transformasi langsung dengan bidang alternativeSecurityIds sebagai sumber dan bidang certificateUserIds sebagai target.
3. Jalankan siklus sinkronisasi untuk menyelesaikan populasi data di ID Microsoft Entra.

Pastikan bahwa CBA di setiap penyewa dikonfigurasi dengan Pengikatan Nama Pengguna yang menunjuk ke bidang certificateUserIds untuk jenis bidang yang telah Anda petakan dari sertifikat. Sekarang salah satu pengguna ini dapat menunjukkan sertifikat saat masuk dan setelah nilai unik dari sertifikat divalidasi terhadap bidang certificateUserIds, pengguna tersebut berhasil masuk.

Memahami proses pencabutan sertifikat

Proses pencabutan sertifikat memungkinkan Administrator Kebijakan Autentikasi mencabut sertifikat yang diterbitkan sebelumnya agar tidak digunakan untuk autentikasi di masa mendatang. Pencabutan sertifikat tidak akan mencabut token pengguna yang sudah diterbitkan. Ikuti langkah-langkah untuk mencabut token secara manual di Mengonfigurasi pencabutan.

MICROSOFT Entra ID mengunduh dan menyimpan daftar pencabutan sertifikat pelanggan (CRL) dari otoritas sertifikat mereka untuk memeriksa apakah sertifikat dicabut selama autentikasi pengguna.

Administrator Kebijakan Autentikasi dapat mengonfigurasi titik distribusi CRL selama proses penyiapan penerbit tepercaya di penyewa Microsoft Entra. Setiap penerbit tepercaya harus memiliki CRL yang dapat direferensikan dengan menggunakan URL yang terhubung ke internet.

Penting

Ukuran maksimum CRL untuk Microsoft Entra ID agar berhasil diunduh pada masuk interaktif dan cache adalah 20 MB di Microsoft Entra ID publik dan 45 MB di cloud Azure US Government, dan waktu yang diperlukan untuk mengunduh CRL tidak boleh melebihi 10 detik. Jika MICROSOFT Entra ID tidak dapat mengunduh CRL, autentikasi berbasis sertifikat menggunakan sertifikat yang dikeluarkan oleh CA terkait gagal. Sebagai praktik terbaik untuk menyimpan file CRL dalam batas ukuran, jaga masa pakai sertifikat dalam batas yang wajar dan untuk membersihkan sertifikat yang kedaluwarsa. Untuk informasi selengkapnya, lihat Apakah ada batasan untuk ukuran CRL?.

Saat pengguna melakukan log masuk interaktif dengan sertifikat, dan CRL melebihi batas interaktif untuk awan, log masuk awal mereka mengalami kegagalan dengan pesan kesalahan berikut:

"Daftar Pencabutan Sertifikat (CRL) yang diunduh dari {uri} telah melebihi ukuran maksimum yang diizinkan ({size} byte) untuk CRL di ID Microsoft Entra. Coba lagi dalam beberapa menit. Jika masalah berlanjut, hubungi administrator penyewa Anda."

Setelah kesalahan, Microsoft Entra ID mencoba mengunduh CRL sesuai dengan batasan layanan (45 MB di Microsoft Entra ID publik dan 150 MB di Azure US Government cloud).

Penting

Jika Administrator Kebijakan Autentikasi melewati konfigurasi CRL, ID Microsoft Entra tidak melakukan pemeriksaan CRL selama autentikasi pengguna berbasis sertifikat. Ini dapat membantu untuk pemecahan masalah awal, tetapi tidak boleh dipertimbangkan untuk penggunaan produksi.

Mulai sekarang, kami tidak mendukung Online Certificate Status Protocol (OCSP) karena alasan performa dan keandalan. Alih-alih browser klien mengunduh CRL setiap kali terhubung untuk OCSP, Microsoft Entra ID mengunduhnya sekali saat masuk pertama dan menyimpannya di cache. Tindakan ini meningkatkan performa dan keandalan verifikasi CRL. Kami juga mengindeks cache sehingga pencarian harus lebih cepat setiap saat. Pelanggan harus menerbitkan CRL untuk pencabutan sertifikat.

Langkah-langkah berikut adalah alur khas pemeriksaan CRL:

1. Microsoft Entra ID mencoba mengunduh CRL pada peristiwa masuk pertama setiap pengguna dengan sertifikat dari penerbit tepercaya atau otoritas sertifikat yang bersangkutan.
2. Microsoft Entra ID menyimpan cache dan menggunakan kembali CRL untuk penggunaan berikutnya. Ini sesuai dengan Tanggal Pembaruan Berikutnya dan, jika tersedia, Tanggal Penerbitan CRL Berikutnya (digunakan oleh CA Windows Server) dalam dokumen CRL.
3. Autentikasi berbasis sertifikat pengguna gagal jika:

   • CRL dikonfigurasi untuk penerbit tepercaya dan ID Microsoft Entra tidak dapat mengunduh CRL, karena kendala ketersediaan, ukuran, atau latensi.

   • Sertifikat pengguna terdaftar sebagai dicabut pada CRL.

     

   • MICROSOFT Entra ID mencoba mengunduh CRL baru dari titik distribusi jika dokumen CRL yang di-cache kedaluwarsa.

Catatan

Microsoft Entra ID memeriksa CRL dari CA penerbit dan CA lainnya pada rantai kepercayaan PKI hingga CA akar. Kami memiliki batas hingga 10 CA dari sertifikat klien leaf untuk validasi CRL dalam rantai PKI. Batasannya adalah memastikan aktor jahat tidak menurunkan layanan dengan mengunggah rantai PKI dengan sejumlah besar CA dengan ukuran CRL yang lebih besar. Jika rantai sertifikat PKI penyewa memiliki lebih dari 5 CA, dan jika ada kompromi CA, Administrator Kebijakan Autentikasi sebaiknya menghapus penerbit tepercaya yang telah dikompromikan dari konfigurasi penyewa Microsoft Entra.

Penting

Karena sifat siklus penyimpanan dalam cache dan penerbitan CRL, sangat disarankan bahwa jika terjadi pencabutan sertifikat, untuk juga mencabut semua sesi pengguna yang terpengaruh di Microsoft Entra ID.

Sampai sekarang, tidak ada cara untuk secara manual memaksa atau memicu ulang pengunduhan CRL.

Cara mengonfigurasi pencabutan

Untuk mencabut sertifikat klien, MICROSOFT Entra ID mengambil daftar pencabutan sertifikat (CRL) dari URL yang diunggah sebagai bagian dari informasi otoritas sertifikat dan menyimpannya di cache. Tanda waktu penerbitan terakhir (properti Tanggal Efektif) pada CRL digunakan untuk memastikan CRL masih valid. CRL dirujuk secara berkala untuk mencabut akses pada sertifikat yang merupakan bagian dari daftar tersebut.

Jika diperlukan pencabutan yang lebih instan (contohnya, jika pengguna kehilangan perangkatnya), token autorisasi pengguna dapat dibatalkan. Untuk membatalkan token otorisasi, atur bidang StsRefreshTokensValidFrom untuk pengguna tertentu ini menggunakan Windows PowerShell. Anda harus memperbarui bidang StsRefreshTokensValidFrom untuk setiap pengguna yang ingin Anda cabut aksesnya.

Untuk memastikan bahwa pencabutan berlanjut, Anda harus mengatur Tanggal Efektif dari CRL ke tanggal setelah nilai yang ditetapkan oleh StsRefreshTokensValidFrom dan memastikan sertifikat yang dimaksud ada di CRL.

Langkah-langkah berikut menguraikan proses untuk memperbarui dan membatalkan token otorisasi dengan mengatur bidang StsRefreshTokensValidFrom.

# Authenticate to Microsoft Graph
Connect-MgGraph -Scopes "User.Read.All"

# Get the user
$user = Get-MgUser -UserPrincipalName "test@yourdomain.com"

# Get the StsRefreshTokensValidFrom property
$user.StsRefreshTokensValidFrom

Tanggal yang Anda atur harus berada di masa depan. Jika tanggal tidak berada di masa depan, properti StsRefreshTokensValidFrom tidak disetel. Jika tanggal berada di masa depan, StsRefreshTokensValidFrom diatur ke waktu saat ini (bukan tanggal yang ditunjukkan oleh perintah Set-MsolUser).

Memahami validasi CRL (Pratinjau)

CRL adalah catatan sertifikat digital yang telah dicabut sebelum akhir periode validitasnya oleh otoritas sertifikat (CA). Saat CA diunggah ke penyimpanan kepercayaan Microsoft Entra, CRL, atau lebih khusus atribut CrlDistributionPoint, tidak diperlukan. CA dapat diunggah tanpa titik akhir CRL, dan autentikasi berbasis sertifikat tidak akan gagal jika CA penerbit tidak memiliki CRL yang ditentukan.

Untuk memperkuat keamanan dan menghindari kesalahan konfigurasi, Administrator Kebijakan Autentikasi dapat memastikan autentikasi CBA akan gagal jika tidak ada CRL yang dikonfigurasi dari CA yang mengeluarkan sertifikat bagi pengguna akhir.

Mengaktifkan validasi CRL

Untuk mengaktifkan validasi CRL, pilih Memerlukan validasi CRL (disarankan).

Setelah diaktifkan, setiap kegagalan CBA disebabkan oleh sertifikat pengguna akhir yang dikeluarkan oleh CA tanpa CRL yang dikonfigurasi dengan benar.

Administrator Kebijakan Autentikasi dapat membebaskan CA jika CRL-nya memiliki masalah yang harus diperbaiki. Pilih Tambahkan Pengecualian dan pilih CA mana pun yang akan dikecualikan.

CA dalam daftar yang dikecualikan tidak diharuskan untuk mengonfigurasi CRL dan sertifikat pengguna akhir yang dikeluarkan tidak gagal autentikasi.

Catatan

Ada masalah yang diketahui dengan pemilih objek di mana item yang dipilih tidak ditampilkan dengan benar. Gunakan tab Otoritas Sertifikasi untuk memilih atau menghapus Otoritas Sertifikasi.

Cara kerja CBA dengan kebijakan kekuatan autentikasi Akses Bersyarat

Pelanggan dapat membuat kebijakan kekuatan autentikasi Akses Bersyarat untuk menentukan bahwa CBA digunakan untuk mengakses sumber daya.

Anda dapat menggunakan kekuatan autentikasi MFA tahan Phishing bawaan. Kebijakan itu hanya memungkinkan metode autentikasi yang tahan phishing seperti CBA, kunci keamanan FIDO2, dan Windows Hello untuk Bisnis.

Anda juga dapat membuat kekuatan autentikasi kustom untuk memungkinkan hanya CBA mengakses sumber daya sensitif. Anda dapat mengizinkan CBA sebagai faktor tunggal, multifaktor, atau keduanya. Untuk informasi selengkapnya, lihat Kekuatan Otentikasi Akses Bersyarat.

Kekuatan autentikasi CBA dengan opsi tingkat lanjut

Dalam kebijakan metode Autentikasi CBA, Administrator Kebijakan Autentikasi dapat menentukan kekuatan sertifikat dengan menggunakan kebijakan pengikatan autentikasi pada metode CBA. Sekarang Anda dapat mengonfigurasi opsi Tingkat Lanjut saat membuat kekuatan autentikasi kustom untuk mengharuskan sertifikat tertentu digunakan, berdasarkan pengeluar sertifikat dan OID kebijakan, saat pengguna melakukan CBA untuk mengakses sumber daya sensitif tertentu. Fitur ini menyediakan konfigurasi yang lebih tepat untuk menentukan sertifikat dan pengguna yang dapat mengakses sumber daya. Untuk informasi selengkapnya, lihat Opsi tingkat lanjut untuk kekuatan autentikasi Akses Bersyarat.

Memahami log masuk

Log masuk menyediakan informasi tentang proses masuk dan bagaimana sumber daya Anda digunakan oleh pengguna Anda. Untuk informasi selengkapnya tentang log masuk, lihat Log masuk di ID Microsoft Entra.

Mari kita telusuri melalui dua skenario, satu di mana sertifikat memenuhi autentikasi faktor tunggal dan satu lagi di mana sertifikat memenuhi MFA.

Untuk skenario pengujian, pilih pengguna dengan kebijakan Akses Bersyarat yang memerlukan MFA. Konfigurasikan kebijakan pengikatan pengguna dengan memetakan Nama Prinsipal SAN ke UserPrincipalName.

Sertifikat pengguna harus dikonfigurasi seperti tangkapan layar ini:

Memecahkan masalah masuk dengan variabel dinamis dalam log masuk

Meskipun log masuk menyediakan semua informasi untuk men-debug masalah masuk pengguna, ada kalanya nilai tertentu diperlukan dan karena log masuk tidak mendukung variabel dinamis, log masuk akan memiliki informasi yang hilang. Misalnya: Alasan kegagalan dalam log masuk akan menunjukkan sesuatu seperti "Daftar Pencabutan Sertifikat (CRL) gagal dalam validasi tanda tangan." Pengidentifikasi Kunci Subjek yang diharapkan {expectedSKI} tidak cocok dengan Kunci Pengotoritas CRL {crlAK}. Minta administrator penyewa Anda untuk memeriksa konfigurasi CRL." di mana {expectedSKI} dan {crlAKI} tidak diisi dengan nilai yang benar.

Jika pengguna masuk dengan CBA gagal, salin detail log dari tautan 'Detail Selengkapnya' pada halaman kesalahan. Untuk informasi lebih rinci, lihat memahami halaman kesalahan CBA

Uji autentikasi faktor tunggal

Untuk skenario pengujian pertama, konfigurasikan kebijakan autentikasi di mana aturan subjek pengeluar sertifikat memenuhi autentikasi faktor tunggal.

1. Masuk ke pusat admin Microsoft Entra sebagai pengguna uji dengan menggunakan CBA. Kebijakan autentikasi ditetapkan ketika aturan subjek Penerbitan memenuhi autentikasi faktor tunggal.

2. Cari dan pilih Log Masuk.

   Mari kita lihat lebih dekat beberapa entri yang dapat Anda temukan di Log Masuk.

   Entri pertama meminta sertifikat X.509 dari pengguna. Status Terputus berarti ID Microsoft Entra memverifikasi bahwa CBA diaktifkan pada penyewa dan sertifikat diminta untuk autentikasi.

   

   Detail Aktivitas menunjukkan ini hanyalah bagian dari proses masuk yang diharapkan di mana pengguna memilih sertifikat.

   

   Detail Tambahan menampilkan informasi sertifikat.

   

   Entri tambahan ini menunjukkan bahwa autentikasi selesai, token refresh utama dikirim kembali ke browser, dan pengguna diberi akses ke sumber daya.

   

Uji autentikasi multifaktor

Untuk skenario pengujian berikutnya, konfigurasikan kebijakan autentikasi di mana aturan policyOID memenuhi autentikasi multifaktor.

1. Masuk ke pusat administrasi Microsoft Entra menggunakan CBA. Karena kebijakan diatur untuk memenuhi autentikasi multifaktor, proses masuk pengguna berhasil tanpa faktor kedua.

2. Cari dan pilih Riwayat Masuk.

   Anda akan melihat beberapa entri pada log masuk, termasuk entri dengan status Terganggu.

   

   Detail Aktivitas menunjukkan ini hanyalah bagian dari proses masuk yang diharapkan di mana pengguna memilih sertifikat.

   

   Entri dengan status Terganggu menyediakan info diagnostik lebih lanjut di tab Detail Tambahan.

   

   Tabel berikut memiliki deskripsi setiap bidang.

   Bidang	Deskripsi
   Nama subjek sertifikat pengguna	Mengacu pada bidang nama subjek dalam sertifikat.
   Pengikatan sertifikat pengguna	Sertifikat: Nama Prinsipal; Atribut Pengguna: userPrincipalName; Pangkat: 1 Ini menunjukkan bidang sertifikat PrincipalName SAN mana yang dipetakan ke atribut pengguna userPrincipalName dan memiliki prioritas 1.
   Tingkat autentikasi sertifikat pengguna	multiFactorAuthentication
   Jenis tingkat autentikasi sertifikat pengguna	PolicyId Ini menunjukkan OID kebijakan digunakan untuk menentukan kekuatan autentikasi.
   Pengidentifikasi tingkat autentikasi sertifikat pengguna	1.2.3.4 Ini menunjukkan nilai kebijakan pengidentifikasi OID dari sertifikat.

Memahami halaman kesalahan autentikasi berbasis sertifikat

Autentikasi berbasis sertifikat dapat gagal karena alasan seperti sertifikat tidak valid, atau pengguna memilih sertifikat yang salah atau sertifikat kedaluwarsa, atau karena masalah Daftar Pencabutan Sertifikat (CRL). Ketika validasi sertifikat gagal, pengguna melihat kesalahan ini:

Jika CBA gagal di browser, bahkan jika kegagalannya adalah karena Anda membatalkan pemilih sertifikat, Anda perlu menutup sesi browser dan membuka sesi baru untuk mencoba CBA lagi. Sesi baru diperlukan karena browser menyimpan sertifikat. Ketika CBA dicoba kembali, browser mengirim sertifikat yang di-cache selama tantangan TLS, yang menyebabkan kegagalan masuk dan kesalahan validasi.

Pilih Detail selengkapnya untuk mendapatkan informasi pengelogan yang dapat dikirim ke Administrator Kebijakan Autentikasi, yang pada gilirannya bisa mendapatkan informasi selengkapnya dari log Masuk.

Pilih Cara lain untuk masuk untuk mencoba metode lain yang tersedia untuk pengguna untuk masuk.

Catatan

Jika Anda mencoba kembali CBA di browser, prosesnya akan terus gagal karena masalah cache pada browser. Pengguna perlu membuka sesi browser baru dan masuk lagi.

Autentikasi berbasis sertifikat dalam metode MostRecentlyUsed (MRU)

Setelah pengguna berhasil mengautentikasi menggunakan CBA, metode autentikasi MostRecentlyUsed (MRU) pengguna diatur ke CBA. Lain kali, ketika pengguna memasukkan UPN mereka dan memilih Berikutnya, pengguna dibawa ke metode CBA secara langsung, dan tidak perlu memilih Gunakan sertifikat atau kartu pintar.

Untuk mengatur ulang metode MRU, pengguna perlu membatalkan pemilih sertifikat, pilih Cara lain untuk masuk, dan memilih metode lain yang tersedia untuk pengguna dan berhasil mengautentikasi.

Dukungan identitas eksternal

Pengguna tamu B2B dengan identitas eksternal dapat menggunakan CBA pada penyewa asal, dan jika pengaturan lintas penyewa untuk penyewa sumber daya disiapkan untuk mempercayai MFA dari penyewa asal, autentikasi CBA pengguna pada penyewa asal akan dihormati. Untuk informasi selengkapnya tentang cara mengaktifkan autentikasi multifaktor Kepercayaan dari penyewa di Microsoft Entra, lihat Konfigurasi akses kolaborasi B2B lintas penyewa. Dukungan CBA (Certificate-Based Authentication) untuk penyewa sumber belum tersedia.

Langkah berikutnya

• Gambaran umum Microsoft Entra CBA
• Cara mengonfigurasi Microsoft Entra CBA
• Microsoft Entra CBA di perangkat iOS
• Microsoft Entra CBA di perangkat Android
• Masuk kartu pintar Windows menggunakan Microsoft Entra CBA
• ID pengguna sertifikat
• Cara memigrasikan pengguna federasi
• FAQ
• Memecahkan masalah Microsoft Entra CBA