Share via

Penyelaman mendalam teknis autentikasi berbasis sertifikat Microsoft Entra

  • Artikel

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.

Ilustrasi dengan langkah-langkah tentang cara kerja autentikasi berbasis sertifikat Microsoft Entra.

Sekarang kita akan menelusuri setiap langkah:

  1. Pengguna mencoba mengakses aplikasi, seperti portal MyApps.

  2. Jika pengguna belum masuk, pengguna dialihkan ke halaman Masuk Pengguna ID Microsoft Entra di https://login.microsoftonline.com/.

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

    Cuplikan layar portal Masuk untuk MyApps.

  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 dalam cakupan untuk CBA yang berhasil mengautentikasi terhadap aplikasi yang menggunakan ID Microsoft Entra sebagai Penyedia Identitas (IdP) mereka.

    Cuplikan layar Menggunakan sertifikat atau kartu pintar.

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

    Cuplikan layar Masuk jika FIDO2 juga diaktifkan.

  5. Setelah pengguna memilih autentikasi berbasis sertifikat, klien dialihkan ke titik akhir certauth, yang untuk https://certauth.login.microsoftonline.com ID 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 titik *.certauth.login.microsoftonline.com akhir certauth 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 pengeluar sertifikat. Jangan hardcode url 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 fitur petunjuk CA Tepercaya yang akan datang.

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

    Catatan

    Petunjuk CA tepercaya tidak didukung, sehingga daftar sertifikat tidak dapat dilingkup lebih lanjut. Kami sedang mencari untuk menambahkan fungsionalitas ini di masa mendatang.

    Cuplikan layar pemilih sertifikat.

  7. MICROSOFT Entra ID memverifikasi daftar pencabutan sertifikat untuk memastikan sertifikat tidak dicabut dan valid. ID Microsoft Entra mengidentifikasi pengguna dengan menggunakan pengikatan nama pengguna yang 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 memasukkan 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.

Autentikasi berbasis sertifikat mampu MFA

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 mungkin memerlukan lebih banyak konfigurasi untuk menyelesaikan MFA, dan membuktikan untuk mendaftarkan metode autentikasi lain ketika pengguna berada dalam cakupan untuk CBA.

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

  1. Gunakan kata sandi dan sertifikat SF.
  2. Terbitkan Kode Akses Sementara.
  3. Administrator Kebijakan Autentikasi menambahkan nomor telepon dan mengizinkan autentikasi pesan suara/teks untuk akun pengguna.

Jika pengguna berkemampuan CBA belum mengeluarkan sertifikat dan perlu menyelesaikan MFA:

  1. Terbitkan Kode Akses Sementara.
  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. Terbitkan Kode Akses Sementara.
  2. Pengguna perlu mendaftarkan metode MFA lain (ketika pengguna dapat menggunakan sertifikasi MF).
  3. Gunakan kata sandi dan sertifikasi MF (saat pengguna dapat menggunakan sertifikasi MF).
  4. Administrator Kebijakan Autentikasi menambahkan nomor telepon dan mengizinkan autentikasi pesan suara/teks untuk akun pengguna.

MFA dengan autentikasi berbasis sertifikat faktor tunggal (Pratinjau)

Microsoft Entra CBA dapat digunakan sebagai faktor kedua untuk memenuhi persyaratan MFA dengan sertifikat faktor tunggal. Beberapa kombinasi yang didukung adalah:

  1. CBA (faktor pertama) dan masuk telepon tanpa kata sandi (masuk tanpa kata sandi sebagai faktor kedua)
  2. Kunci keamanan CBA (faktor pertama) dan FIDO2 (faktor kedua)
  3. Kata sandi (faktor pertama) dan CBA (faktor kedua)

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

Penting

Pengguna dianggap mampu MFA ketika mereka 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.

Langkah-langkah untuk menyiapkan masuk 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 Administrator Kebijakan Autentikasi.

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

    Penting

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

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

    Cuplikan layar cara mengonfigurasi pengaturan autentikasi multifaktor.

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

    Cuplikan layar cara menghapus pemberitahuan melalui aplikasi seluler.

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.

    Cuplikan layar cara memasukkan nama prinsipal pengguna.

  2. Pilih Masuk dengan sertifikat.

    Cuplikan layar cara masuk dengan sertifikat.

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

    Cuplikan layar cara alternatif untuk masuk dengan sertifikat.

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

    Cuplikan layar cara memilih sertifikat.

  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.

    Cuplikan layar permintaan faktor kedua.

  5. Anda akan mendapatkan pemberitahuan di ponsel Anda. Pilih Setujui Masuk?. Cuplikan layar permintaan persetujuan.

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

    Cuplikan layar kecocokan angka.

  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 dapat mengubah nilai default dari faktor tunggal ke multifaktor, atau menyiapkan konfigurasi kebijakan kustom baik dengan menggunakan subjek penerbit atau kebijakan OID atau penerbit dan bidang OID Kebijakan dalam sertifikat.

Kekuatan sertifikat

Admin 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. Pengeluar sertifikat + aturan OID kebijakan dievaluasi terlebih dahulu. Jika Anda memiliki aturan kustom dengan penerbit CA1 dan kebijakan OID 1.2.3.4.5 dengan MFA, hanya sertifikat A yang memenuhi nilai penerbit dan OID kebijakan yang akan diberikan 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 Pengeluar sertifikat yang cocok, OID kebijakan selalu diperiksa terlebih dahulu, dan jika tidak ada aturan kebijakan yang ditemukan maka pengikatan 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 diketahui di mana admin penyewa Entra mengonfigurasi aturan kebijakan autentikasi CBA menggunakan Penerbit dan OID Kebijakan berdampak pada beberapa skenario pendaftaran perangkat termasuk:

  • Pendaftaran Windows Hello For Business
  • Pendaftaran Kunci Keamanan Fido2
  • Masuk Telepon Tanpa Kata Sandi Windows

Pendaftaran perangkat dengan skenario gabungan perangkat Workplace Join, Entra ID, dan Hybrid Entra ID tidak terpengaruh. Aturan kebijakan autentikasi CBA yang menggunakan Penerbit ATAU OID Kebijakan tidak terpengaruh. Untuk mengurangi, admin harus :

  • Edit aturan kebijakan autentikasi berbasis sertifikat yang saat ini menggunakan opsi Pengeluar Sertifikat dan OID Kebijakan dan hapus persyaratan Penerbit atau OID dan simpan. ATAU
  • Hapus aturan kebijakan autentikasi yang saat ini menggunakan Penerbit dan OID Kebijakan dan buat aturan hanya menggunakan pengeluar sertifikat 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 Nama Alternatif Subjek (SAN) dalam sertifikat dipetakan ke atribut UserPrincipalName objek pengguna untuk 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 menerapkan tiga pemetaan yang dianggap afinitas rendah berdasarkan pengidentifikasi yang dapat digunakan kembali. Yang lain dianggap pengikatan afinitas tinggi. Untuk informasi selengkapnya, lihat certificateUserIds.

Bidang pemetaan sertifikat Contoh nilai dalam certificateUserIds Atribut objek pengguna Jenis
PrincipalName 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 certificateUserIds afinitas rendah
SKI X509:<SKI>123456789abcdef certificateUserIds afinitas tinggi
SHA1PublicKey X509:<SHA1-PUKEY>123456789abcdef certificateUserIds afinitas tinggi
IssuerAndSerialNumber (pratinjau) X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>b24134139f069b49997212a86ba0ef48
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 mengambil alih nilai default di seluruh penyewa dengan membuat aturan kustom berdasarkan Penerbit dan OID Kebijakan, atau OID Kebijakan, atau 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 penyiapan pengikatan nama pengguna oleh admin penyewa dalam konfigurasi metode autentikasi CBA yang diurutkan oleh atribut 'prioritas'. Saat ini konsep prioritas tidak diekspos di UX Portal. Grafik akan 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 ada pada sertifikat yang disajikan, ID Microsoft Entra cocok dengan nilai di bidang sertifikat dengan nilai atribut objek pengguna.
    1. Jika kecocokan ditemukan, autentikasi pengguna berhasil.
    2. Jika kecocokan tidak ditemukan, pindahkan 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 untuk mengakomodasi satu sertifikat ke beberapa konfigurasi akun pengguna 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, Anda memiliki dua pengikatan nama pengguna pada PrincipalName yang dipetakan ke UPN dan SubjectKeyIdentifier (SKI) 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 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 hanya 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>b24134139f069b49997212a86ba0ef48
X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>c11154138u089b48767212a86cd0ef76

Dalam contoh ini, nilai pertama mewakili X509Certificate1 dan nilai kedua mewakili X509Certificate2. Pengguna dapat menunjukkan sertifikat saat 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 akan 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) mengatakan Penerbit + SerialNumber, ini bisa terlihat seperti berikut:

X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>b24134139f069b49997212a86ba0ef48
X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>c11154138u089b48767212a86cd0ef76

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

Dukungan untuk satu sertifikat dengan beberapa akun pengguna 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 memeriksa login. 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 ID Entra yang berbeda dan disarankan untuk tidak mengizinkan satu sertifikat untuk beberapa akun pengguna Entra.

Akun cloud hanya Untuk akun khusus cloud, Anda perlu membuat beberapa pengikatan nama pengguna dan perlu memetakan nilai unik ke setiap akun pengguna yang akan menggunakan sertifikat. Setiap akun akan diautentikasi menggunakan pengikatan nama pengguna yang berbeda. Ini berlaku dalam batas direktori/penyewa tunggal (yaitu admin Penyewa 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) mengatakan Penerbit + SerialNumber dan SKI, ini bisa terlihat seperti berikut:

Pengikatan nama pengguna:

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

Nilai CertificateUserIds akun pengguna:
X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>b24134139f069b49997212a86ba0ef48
X509:<SKI>82b287a25c48af0918ea088d5293712324dfd523

Sekarang, ketika salah satu pengguna menyajikan sertifikat yang sama saat masuk, pengguna akan berhasil masuk karena akun mereka cocok dengan nilai unik pada sertifikat tersebut. Satu akun akan diautentikasi ke dalam menggunakan Issuer+SerialNumber dan yang 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 akan 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 Yang Disinkronkan Hibrid Untuk akun yang disinkronkan, pendekatan akan berbeda. Meskipun admin penyewa dapat memetakan nilai unik ke setiap akun pengguna yang akan menggunakan sertifikat, praktik umum mengisi semua nilai ke setiap akun di ID Entra akan menyulitkan ini. Sebagai gantinya, Azure AD Koneksi harus memfilter nilai yang diinginkan per akun ke nilai unik yang diisi ke akun di ID Entra. Aturan keunikan berlaku dalam batas direktori/penyewa tunggal (yaitu admin Penyewa dapat memetakan sertifikat untuk digunakan di direktori/penyewa lain juga, selama nilai tetap unik per akun juga). Selanjutnya, organisasi mungkin memiliki beberapa forest AD yang berkontribusi pengguna ke dalam satu penyewa ID Entra. Dalam hal ini Azure AD Koneksi akan 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 (misalnya detailee, admin, pengembang, dll.). Pilih atribut kunci di AD yang akan memberi tahu sinkronisasi jenis akun pengguna mana yang dievaluasi pengguna (misalnya 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>82b287a25c48af0918ea088d5293712324dfd523
X509:<SHA1-PUKEY>123456789abcdef
X509:<PN>bob@woodgrove.com

Forest 1 - Account2 (bob-admin@woodgrove.com):
X509:<SKI>82b287a25c48af0918ea088d5293712324dfd523
X509:<SHA1-PUKEY>123456789abcdef
X509:<PN>bob@woodgrove.com

Forest 2 – ADAccount1 (bob-tdy@woodgrove.com):
X509:<SKI>82b287a25c48af0918ea088d5293712324dfd523
X509:<SHA1-PUKEY>123456789abcdef
X509:<PN>bob@woodgrove.com

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

Langkah-langkah untuk menyinkronkan ke certificateUserIds

  1. Mengonfigurasi azure AD 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 akan menggunakan Atribut Kunci yang Anda pilih dan 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, altSecurityIdentities diperiksa untuk melihat apakah identitas tersebut diisi. Jika kosong maka kita atur ke NULL. Jika tidak, akun termasuk dalam kasus default dan dalam contoh ini kami hanya memfilter 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 akan mendapatkan semua nilai dan disinkronkan ke Id Entra - bukan hanya yang pertama yang ditemukannya.

  1. Contoh kedua yang menunjukkan cara mendorong nilai kosong jika atribut kontrol kosong ada di bawah ini.
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 kosong dalam ID Entra.

  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 dalam ID 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 akan berhasil masuk.

Memahami proses pencabutan sertifikat

Proses pencabutan sertifikat memungkinkan admin untuk mencabut sertifikat yang dikeluarkan 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.

Admin 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 ID Microsoft Entra agar berhasil diunduh pada masuk interaktif dan cache adalah 20 MB di ID Entra 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 masuk interaktif dengan sertifikat, dan CRL melebihi batas interaktif untuk cloud, masuk awal mereka gagal dengan 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 yang tunduk pada batas sisi layanan (45 MB di ID Entra publik dan 150 MB di cloud Azure US Government).

Penting

Jika admin 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 mengunduh CRL di setiap koneksi oleh browser klien untuk OCSP, MICROSOFT Entra ID mengunduh sekali pada rincian masuk pertama dan menyimpannya, sehingga meningkatkan performa dan keandalan verifikasi CRL. Kami juga mengindeks cache sehingga pencarian harus lebih cepat setiap saat. Pelanggan harus menerbitkan CRM 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 penerbit tepercaya atau otoritas sertifikat yang sesuai.
  2. Microsoft Entra ID menyimpan cache dan menggunakan kembali CRL untuk penggunaan berikutnya. Ini menghormati 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 telah 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.

      Cuplikan layar sertifikat pengguna yang dicabut di CRL.

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

Catatan

MICROSOFT Entra ID memeriksa CRL CA penerbit dan CA lain dalam rantai kepercayaan PKI hingga CA akar. Kami memiliki batas hingga 10 CA dari sertifikat klien daun 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 PKI penyewa memiliki lebih dari 5 CA dan jika terjadi kompromi CA, administrator harus menghapus penerbit tepercaya yang disusupi dari konfigurasi penyewa Microsoft Entra.

Penting

Karena sifat siklus penembolokan dan penerbitan CRL, sangat disarankan jika pencabutan sertifikat juga mencabut semua sesi pengguna yang terpengaruh di ID Microsoft Entra.

Sampai sekarang, tidak ada cara untuk memaksa atau mengambil kembali unduhan CRL secara manual.

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 autorisasi, atur bidang StsRefreshTokenValidFrom untuk pengguna tertentu ini menggunakan Windows PowerShell. Anda harus memperbarui bidang StsRefreshTokenValidFrom untuk setiap pengguna yang aksesnya ingin Anda cabut.

Untuk memastikan pencabutan tetap berlangsung, Anda harus mengatur Tanggal Efektif CRL ke tanggal setelah nilai yang diatur oleh StsRefreshTokenValidFrom dan memastikan bahwa sertifikat tersebut ada dalam CRL.

Catatan

Modul Azure ACTIVE Directory dan MSOnline PowerShell tidak digunakan lagi per 30 Maret 2024. Untuk mempelajari lebih lanjut, baca pembaruan penghentian. Setelah tanggal ini, dukungan untuk modul ini terbatas pada bantuan migrasi ke Microsoft Graph PowerShell SDK dan perbaikan keamanan. Modul yang tidak digunakan lagi akan terus berfungsi hingga Maret, 30 2025.

Sebaiknya migrasi ke Microsoft Graph PowerShell untuk berinteraksi dengan ID Microsoft Entra (sebelumnya Microsoft Azure AD). Untuk pertanyaan umum tentang migrasi, lihat Tanya Jawab Umum Migrasi. Catatan: MSOnline versi 1.0.x mungkin mengalami gangguan setelah 30 Juni 2024.

Langkah berikut menggarisbawahi proses pembaruan dan pembatalan token otorisasi dengan mengatur bidang StsRefreshTokenValidFrom.

  1. Koneksi ke PowerShell:

    Connect-MgGraph

  2. Ambil nilai StsRefreshTokensValidFrom saat ini untuk pengguna:

            $user = Get-MsolUser -UserPrincipalName test@yourdomain.com`
        $user.StsRefreshTokensValidFrom

  3. Konfigurasikan nilai StsRefreshTokensValidFrom baru untuk pengguna yang sama dengan tanda waktu saat ini:

            Set-MsolUser -UserPrincipalName test@yourdomain.com -StsRefreshTokensValidFrom ("03/05/2021")

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

Cara kerja CBA dengan kebijakan kekuatan autentikasi Akses Bersyar

Pelanggan dapat membuat kebijakan kekuatan autentikasi Akses Bersyar 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 autentikasi Akses Bersyar.

Kekuatan autentikasi CBA dengan opsi tingkat lanjut

Dalam kebijakan metode Autentikasi CBA, admin 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 Bersyar.

Memahami log Masuk

Log kredensial masuk menyediakan Informasi tentang kredensial masuk dan bagaimana sumber daya Anda digunakan oleh pengguna. 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:

Cuplikan layar sertifikat pengguna.

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 menampilkan sesuatu seperti "Daftar Pencabutan Sertifikat (CRL) validasi tanda tangan yang gagal. Pengidentifikasi Kunci Subjek yang Diharapkan {expectedSKI} tidak cocok dengan Kunci Otoritas CRL {crlAK}. Harap minta administrator penyewa Anda untuk memeriksa konfigurasi CRL." di mana {expectedSKI} dan {crlAKI} tidak diisi dengan nilai yang benar.

Saat pengguna masuk dengan CBA gagal, salin detail log dari tautan 'Detail Selengkapnya' di 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.

Cuplikan layar konfigurasi kebijakan Autentikasi memperlihatkan autentikasi faktor tunggal yang diperlukan.

  1. Masuk ke pusat admin Microsoft Entra sebagai pengguna uji dengan menggunakan CBA. Kebijakan autentikasi diatur di mana aturan subjek Penerbit memenuhi autentikasi faktor tunggal.

  2. Cari dan pilih Log masuk.

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

    Entri pertama meminta sertifikat X.509 dari pengguna. Status Terganggu berarti ID Microsoft Entra memvalidasi bahwa CBA diaktifkan di penyewa dan sertifikat diminta untuk autentikasi.

    Cuplikan layar entri autentikasi faktor tunggal di log masuk.

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

    Cuplikan layar detail aktivitas dalam log masuk.

    Detail Tambahan menampilkan informasi sertifikat.

    Cuplikan layar detail tambahan multifaktor dalam log masuk.

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

    Cuplikan layar entri token refresh di log masuk.

Uji autentikasi multifaktor

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

Cuplikan layar konfigurasi kebijakan Autentikasi yang menunjukkan autentikasi multifaktor diperlukan.

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

  2. Cari dan pilih Masuk.

    Anda akan melihat beberapa entri dalam log Masuk, termasuk entri dengan status Terganggu .

    Cuplikan layar beberapa entri dalam log masuk.

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

    Cuplikan layar detail masuk faktor kedua dalam log masuk.

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

    Cuplikan layar detail upaya terganggu dalam log masuk.

    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 merupakan 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:

Cuplikan layar kesalahan validasi sertifikat.

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, yang pada gilirannya bisa mendapatkan informasi selengkapnya dari log Masuk.

Cuplikan layar detail kesalahan.

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

Catatan

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

Cuplikan layar upaya masuk baru.

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

Identitas eksternal tidak dapat melakukan autentikasi multifaktor ke penyewa sumber daya dengan Microsoft Entra CBA. Sebagai gantinya, minta pengguna melakukan MFA menggunakan CBA di penyewa rumah, dan menyiapkan pengaturan lintas penyewa untuk penyewa sumber daya untuk mempercayai MFA dari penyewa rumah.

Untuk informasi selengkapnya tentang cara mengaktifkan autentikasi multifaktor Kepercayaan dari penyewa Microsoft Entra, lihat Mengonfigurasi akses lintas penyewa kolaborasi B2B.

Langkah berikutnya