Tanya jawab umum tentang Perlindungan Kata Sandi Microsoft Entra lokal

Panduan apa yang harus diberikan ke pengguna tentang cara memilih sandi yang aman?

Panduan Microsoft terkini tentang topik ini dapat ditemukan di tautan berikut:

Panduan Sandi Microsoft

Apakah Perlindungan Kata Sandi Microsoft Entra lokal didukung di cloud non-publik?

Perlindungan Kata Sandi Microsoft Entra lokal didukung di cloud Azure Global dan Azure Government.

Pusat admin Microsoft Entra memang memungkinkan modifikasi konfigurasi "Perlindungan Kata Sandi untuk Windows Server Active Directory" khusus lokal bahkan di cloud yang tidak didukung; perubahan tersebut akan dipertahankan tetapi sebaliknya tidak akan pernah berlaku. Pendaftaran forest atau agen proksi lokal tidak didukung di cloud yang tidak didukung, dan upaya pendaftaran seperti itu akan selalu gagal.

Bagaimana cara menerapkan manfaat Perlindungan Kata Sandi Microsoft Entra ke subset pengguna lokal saya?

Tidak didukung. Setelah disebarkan dan diaktifkan, Perlindungan Kata Sandi Microsoft Entra tidak mendiskriminasi - semua pengguna menerima manfaat keamanan yang sama.

Apa perbedaan antara perubahan sandi dan pengaturan (atau reset) sandi?

Perubahan kata sandi adalah ketika pengguna memilih sandi baru setelah membuktikan bahwa mereka memiliki pengetahuan tentang sandi lama. Misalnya, perubahan sandi adalah apa yang terjadi ketika pengguna masuk ke Windows dan kemudian diminta untuk memilih sandi baru.

Pengaturan sandi (terkadang disebut reset sandi) adalah ketika administrator mengganti sandi pada akun dengan sandi baru, misalnya dengan menggunakan alat manajemen Active Directory Users and Computers. Operasi ini membutuhkan tingkat hak istimewa yang tinggi (biasanya Admin Domain), dan orang yang mengoperasikan biasanya tidak memiliki pengetahuan tentang sandi lama. Skenario help-desk sering melakukan pengaturan sandi, misalnya ketika membantu pengguna yang lupa sandi mereka. Anda juga akan melihat aktivitas pengaturan sandi ketika akun pengguna baru dibuat untuk pertama kalinya dengan sandi.

Kebijakan validasi sandi berlaku sama terlepas dari apakah perubahan atau pengaturan sandi sedang dilakukan. Layanan Agen DC Perlindungan Kata Sandi Microsoft Entra melakukan log peristiwa yang berbeda untuk memberi tahu Anda apakah operasi perubahan atau pengaturan kata sandi telah dilakukan. Lihat Pemantauan dan pengelogan Perlindungan Kata Sandi Microsoft Entra.

Apakah Perlindungan Kata Sandi Microsoft Entra memvalidasi kata sandi yang ada setelah diinstal?

Tidak - Perlindungan Kata Sandi Microsoft Entra hanya dapat memberlakukan kebijakan kata sandi pada kata sandi cleartext selama operasi perubahan atau pengaturan kata sandi. Setelah sandi diterima oleh Active Directory, hanya hash spesifik protokol autentikasi dari sandi tersebut yang tetap ada. Kata sandi teks-jelas tidak pernah bertahan, oleh karena itu Perlindungan Kata Sandi Microsoft Entra tidak dapat memvalidasi kata sandi yang ada.

Setelah penyebaran awal Perlindungan Kata Sandi Microsoft Entra, semua pengguna dan akun akhirnya akan mulai menggunakan kata sandi yang divalidasi Perlindungan Kata Sandi Microsoft Entra karena kata sandi yang ada kedaluwarsa secara normal dari waktu ke waktu. Jika diinginkan, proses ini dapat dipercepat dengan kedaluwarsa manual satu kali sandi akun pengguna.

Akun yang dikonfigurasi dengan "sandi tidak pernah kedaluwarsa" tidak akan pernah dipaksa untuk mengubah sandi mereka kecuali kedaluwarsa manual dilakukan.

Mengapa aktivitas penolakan sandi duplikat dicatat ketika mencoba mengatur sandi yang lemah menggunakan snap-in manajemen Active Directory Users and Computers?

Snap-in manajemen Active Directory Users and Computers akan terlebih dahulu mencoba mengatur sandi baru menggunakan protokol Kerberos. Setelah kegagalan, snap-in akan melakukan upaya kedua untuk mengatur sandi menggunakan protokol lama (SAM RPC) (protokol khusus yang digunakan tidak penting). Jika kata sandi baru dianggap lemah oleh Perlindungan Kata Sandi Microsoft Entra, perilaku snap-in ini akan mengakibatkan dua set peristiwa penolakan pengaturan ulang kata sandi dicatat.

Mengapa peristiwa validasi kata sandi Perlindungan Kata Sandi Microsoft Entra dicatat dengan nama pengguna kosong?

Active Directory mendukung kemampuan untuk menguji sandi untuk melihat apakah sandi tersebut melewati persyaratan kompleksitas sandi domain terkini, misalnya menggunakan api NetValidatePasswordPolicy. Ketika kata sandi divalidasi dengan cara ini, pengujian juga menyertakan validasi oleh produk berbasis dll filter kata sandi seperti Perlindungan Kata Sandi Microsoft Entra - tetapi nama pengguna yang diteruskan ke dll filter kata sandi tertentu akan kosong. Dalam skenario ini, Perlindungan Kata Sandi Microsoft Entra masih akan memvalidasi kata sandi menggunakan kebijakan kata sandi yang saat ini berlaku dan akan mengeluarkan pesan log peristiwa untuk mengambil hasil, namun pesan log peristiwa akan memiliki bidang nama pengguna kosong.

Saya memiliki pengguna hibrid yang mencoba mengubah kata sandi mereka di ID Microsoft Entra dan menerima respons "Kami telah melihat kata sandi itu terlalu banyak kali sebelumnya. Pilih sesuatu yang lebih sulit untuk ditebak." Dalam hal ini, mengapa saya tidak melihat upaya validasi lokal?

Saat pengguna hibrid mengubah kata sandi mereka di ID Microsoft Entra, baik melalui Microsoft Entra SSPR, MyAccount, atau mekanisme perubahan kata sandi Microsoft Entra lainnya, kata sandi mereka dievaluasi terhadap daftar kata sandi terlarang global dan kustom di cloud. Ketika kata sandi mencapai Direktori Aktif melalui kata sandi-tulis balik, kata sandi telah divalidasi di ID Microsoft Entra.

Reset kata sandi dan perubahan yang dimulai di ID Microsoft Entra yang gagal validasi untuk pengguna hibrid dapat ditemukan di log audit Microsoft Entra. Lihat Memecahkan masalah pengaturan ulang kata sandi mandiri di ID Microsoft Entra.

Apakah didukung untuk menginstal Perlindungan Kata Sandi Microsoft Entra berdampingan dengan produk berbasis filter kata sandi lainnya?

Ya. Dukungan untuk beberapa dll filter kata sandi terdaftar adalah fitur Windows inti dan tidak khusus untuk Perlindungan Kata Sandi Microsoft Entra. Semua dll filter sandi terdaftar harus setuju sebelum sandi diterima.

Bagaimana cara menyebarkan dan mengonfigurasi Perlindungan Kata Sandi Microsoft Entra di lingkungan Direktori Aktif saya tanpa menggunakan Azure?

Tidak didukung. Perlindungan Kata Sandi Microsoft Entra adalah fitur Azure yang mendukung diperluas ke lingkungan Active Directory lokal.

Bagaimana cara mengubah konten kebijakan di tingkat Azure Active Directory?

Tidak didukung. Kebijakan hanya dapat dikelola menggunakan pusat admin Microsoft Entra. Lihat juga pertanyaan sebelumnya.

Mengapa DFSR diperlukan untuk replikasi sysvol?

FRS (teknologi pendahulu untuk DFSR) memiliki banyak masalah yang diketahui dan sama sekali tidak didukung di versi terbaru Windows Server Active Directory. Tidak ada pengujian Perlindungan Kata Sandi Microsoft Entra akan dilakukan pada domain yang dikonfigurasi FRS.

Untuk informasi selengkapnya, lihat artikel berikut ini:

Kasus migrasi replikasi sysvol ke DFSR

The End adalah Nigh untuk FRS

Jika domain Anda belum menggunakan DFSR, Anda HARUS memigrasikannya untuk menggunakan DFSR sebelum menginstal Perlindungan Kata Sandi Microsoft Entra. Untuk mengetahui informasi selengkapnya, lihat tautan berikut:

Panduan Migrasi Replikasi SYSVOL: Replikasi FRS hingga DFS

Berapa banyak ruang disk yang diperlukan fitur pada saat berbagi sysvol domain?

Penggunaan ruang yang tepat bervariasi karena bergantung pada beberapa faktor seperti jumlah dan panjang token yang dilarang dalam daftar terlarang global Microsoft dan daftar kustom per penyewa, ditambah overhead enkripsi. Konten daftar ini kemungkinan besar akan bertambah di masa mendatang. Dengan mempertimbangkan hal ini, harapan yang wajar adalah bahwa fitur ini akan membutuhkan ruang setidaknya lima (5) megabytes pada berbagi sysvol domain.

Mengapa boot ulang diperlukan untuk menginstal atau meningkatkan perangkat lunak agen DC?

Persyaratan ini disebabkan oleh perilaku inti Windows.

Apakah ada cara untuk mengonfigurasi agen DC untuk menggunakan server proksi tertentu?

Tidak. Karena server proksi tidak bernegara, maka tidak penting server proksi khusus mana yang digunakan.

Apakah baik-baik saja untuk menyebarkan layanan Proksi Perlindungan Kata Sandi Microsoft Entra berdampingan dengan layanan lain seperti Microsoft Entra Koneksi?

Ya. Layanan Proksi Perlindungan Kata Sandi Microsoft Entra dan Microsoft Entra Koneksi tidak boleh berkonflik langsung satu sama lain.

Sayangnya, ketidaksesuaian telah ditemukan antara versi layanan Microsoft Entra Koneksi Agent Updater yang diinstal oleh perangkat lunak Proksi Perlindungan Kata Sandi Microsoft Entra dan versi layanan yang diinstal oleh perangkat lunak proksi aplikasi Microsoft Entra. Ketidakcocokan ini dapat mengakibatkan layanan Agent Updater tidak dapat menghubungi Azure untuk pembaruan perangkat lunak. Tidak disarankan untuk menginstal Proksi Perlindungan Kata Sandi Microsoft Entra dan proksi aplikasi Microsoft Entra pada komputer yang sama.

Dalam urutan apa agen DC dan proxy harus diinstal dan didaftarkan?

Setiap pemesanan penginstalan agen Proxy, penginstalan agen DC, pendaftaran forest, dan pendaftaran Proxy didukung.

Haruskah saya khawatir tentang performa hit pada pengendali domain saya karena menyebarkan fitur ini?

Layanan Agen DC Perlindungan Kata Sandi Microsoft Entra tidak boleh berdampak signifikan pada performa pengendali domain dalam penyebaran Direktori Aktif yang sehat yang ada.

Untuk sebagian besar penerapan operasi perubahan sandi Active Directory adalah sebagian kecil dari beban kerja keseluruhan pada pengontrol domain tertentu. Sebagai contoh, bayangkan domain Active Directory dengan 10000 akun pengguna dan kebijakan MaxPasswordAge diatur ke 30 hari. Rata-rata, domain ini akan melihat 10000/30 =~333 operasi perubahan sandi setiap hari, yang merupakan sejumlah kecil operasi bahkan untuk satu pengontrol domain. Pertimbangkan skenario potensial terburuk: anggaplah ~333 perubahan sandi pada satu DC dilakukan selama satu jam. Misalnya, skenario ini mungkin terjadi ketika banyak karyawan semua masuk kerja pada hari Senin pagi. Bahkan dalam hal ini, kita masih melihat ~ 333/60 menit = enam perubahan sandi per menit, yang sekali lagi bukan beban yang signifikan.

Namun jika pengendali domain Anda saat ini sudah berjalan pada tingkat terbatas performa (misalnya, dimaksimalkan sehubungan dengan CPU, ruang disk, I/O disk, dan sebagainya), disarankan untuk menambahkan pengontrol domain tambahan atau memperluas ruang disk yang tersedia, sebelum menyebarkan fitur ini. Lihat juga pertanyaan di atas tentang penggunaan ruang disk sysvol di atas.

Saya ingin menguji Perlindungan Kata Sandi Microsoft Entra hanya pada beberapa DC di domain saya. Apakah mungkin untuk memaksa perubahan sandi pengguna menggunakan DC tertentu?

Tidak. OS klien Windows mengontrol pengontrol domain mana yang digunakan saat pengguna mengubah sandi mereka. Pengontrol domain dipilih berdasarkan faktor-faktor seperti situs Direktori Aktif dan penetapan subnet, konfigurasi jaringan khusus lingkungan, dan sebagainya. Perlindungan Kata Sandi Microsoft Entra tidak mengontrol faktor-faktor ini dan tidak dapat memengaruhi pengontrol domain mana yang dipilih untuk mengubah kata sandi pengguna.

Salah satu cara untuk mencapai sebagian tujuan ini adalah dengan menyebarkan Perlindungan Kata Sandi Microsoft Entra pada semua pengendali domain di situs Direktori Aktif tertentu. Pendekatan ini akan memberikan cakupan yang wajar untuk klien Windows yang ditetapkan ke situs tersebut, dan oleh karena itu juga untuk pengguna yang masuk ke klien tersebut dan mengubah sandi mereka.

Jika saya menginstal layanan Agen DC Perlindungan Kata Sandi Microsoft Entra hanya pada Pengendali Domain Utama (PDC), apakah semua pengontrol domain lain di domain juga akan dilindungi?

Tidak. Ketika sandi pengguna diubah pada pengontrol domain non-PDC tertentu, sandi teks biasa tidak pernah dikirim ke PDC (ide ini adalah kesalahan persepsi yang umum). Setelah sandi baru diterima di DC tertentu, DC tersebut menggunakan sandi tersebut untuk membuat berbagai hash khusus protokol autentikasi dari sandi tersebut dan kemudian mempertahankan hash tersebut di direktori. Sandi teks biasa tidak bertahan. Hash yang diperbarui kemudian direplikasi ke PDC. Sandi pengguna mungkin dalam beberapa kasus diubah langsung pada PDC, sekali lagi tergantung pada berbagai faktor seperti topologi jaringan dan desain situs Active Directory. (Lihat pertanyaan sebelumnya.)

Singkatnya, penyebaran layanan Agen DC Perlindungan Kata Sandi Microsoft Entra pada PDC diperlukan untuk mencapai cakupan keamanan 100% fitur di seluruh domain. Menyebarkan fitur pada PDC hanya tidak memberikan manfaat keamanan Perlindungan Kata Sandi Microsoft Entra untuk DC lain di domain.

Mengapa penguncian pintar kustom tidak berfungsi bahkan setelah agen diinstal di lingkungan Azure Active Directory lokal saya?

Penguncian cerdas kustom hanya didukung di ID Microsoft Entra. Perubahan pada pengaturan penguncian cerdas kustom di pusat admin Microsoft Entra tidak berpengaruh pada lingkungan Active Directory lokal, bahkan dengan agen yang diinstal.

Apakah paket manajemen Manajer Operasi Pusat Sistem tersedia untuk Perlindungan Kata Sandi Microsoft Entra?

Tidak.

Mengapa MICROSOFT Entra ID masih menolak kata sandi yang lemah meskipun saya telah mengonfigurasi kebijakan untuk berada dalam mode Audit?

Mode audit hanya didukung di lingkungan Active Directory lokal. ID Microsoft Entra secara implisit selalu dalam mode "terapkan" saat mengevaluasi kata sandi.

Pengguna saya melihat pesan kesalahan Windows tradisional saat kata sandi ditolak oleh Perlindungan Kata Sandi Microsoft Entra. Apakah mungkin untuk mengkustomisasi pesan kesalahan ini sehingga pengguna tahu apa yang sebenarnya terjadi?

Tidak. Pesan kesalahan yang dilihat oleh pengguna ketika sandi ditolak oleh pengontrol domain dikendalikan oleh mesin klien, bukan oleh pengontrol domain. Perilaku ini terjadi apakah kata sandi ditolak oleh kebijakan kata sandi Direktori Aktif default atau oleh solusi berbasis filter kata sandi seperti Perlindungan Kata Sandi Microsoft Entra.

Anda mungkin ingin melakukan beberapa pengujian dasar berbagai sandi untuk memvalidasi operasi perangkat lunak yang tepat dan untuk mendapatkan pemahaman yang lebih baik tentang algoritma evaluasi sandi. Bagian ini menguraikan metode untuk pengujian semacam itu yang didesain untuk menghasilkan hasil yang dapat diulang.

Mengapa perlu mengikuti langkah seperti itu? Ada beberapa faktor yang menyulitkan kontrol, pengujian sandi yang dan berulang di lingkungan Active Directory lokal:

• Kebijakan sandi dikonfigurasi dan disimpan di Azure, dan salinan kebijakan disinkronkan secara berkala oleh agen DC lokal menggunakan mekanisme pemungutan suara. Latensi yang melekat dalam siklus pemungutan suara ini dapat menyebabkan kebingungan. Misalnya, jika Anda mengonfigurasi kebijakan di Azure tetapi lupa menyinkronkannya ke agen DC, maka pengujian Anda mungkin tidak menghasilkan hasil yang diharapkan. Interval polling saat ini di-hardcode menjadi sekali per jam, tetapi menunggu satu jam antara perubahan kebijakan tidak ideal untuk skenario pengujian interaktif.
• Setelah kebijakan sandi baru disinkronkan ke pengontrol domain, lebih banyak latensi akan terjadi saat direplikasikan ke pengontrol domain lainnya. Penundaan ini dapat menyebabkan hasil yang tidak terduga jika Anda menguji perubahan sandi terhadap pengontrol domain yang belum menerima kebijakan versi terbaru.
• Menguji perubahan sandi melalui antarmuka pengguna membuatnya sulit untuk memiliki kepercayaan pada hasil Anda. Misalnya, mudah untuk salah mengetik sandi yang tidak valid ke antarmuka pengguna, terutama karena sebagian besar antarmuka pengguna sandi menyembunyikan input pengguna (misalnya, seperti UI Windows Ctrl-Alt-Delete -> Ubah sandi UI).
• Tidak dimungkinkan untuk semata mata mengontrol pengontrol domain mana yang digunakan saat menguji perubahan sandi dari klien yang bergabung dengan domain. OS klien Windows memilih pengontrol domain berdasarkan faktor-faktor seperti situs Direktori Aktif dan penetapan subnet, konfigurasi jaringan khusus lingkungan, dan sebagainya.

Untuk menghindari masalah ini, beberapa langkah di bawah ini didasarkan pada pengujian baris perintah reset sandi saat masuk ke pengontrol domain.

Langkah-langkah berikut ini mengasumsikan bahwa Anda telah menginstal agen DC pada setidaknya satu pengontrol domain, telah menginstal setidaknya satu proksi, dan telah mendaftarkan proksi dan forest.

1. Masuk ke pengontrol domain menggunakan info masuk Admin Domain (atau info masuk lain yang memiliki hak istimewa yang memadai untuk membuat akun pengguna pengujian dan mereset sandi), yang telah menginstal perangkat lunak agen DC dan telah di-boot ulang.

2. Buka Pemantau Aktivitas dan navigasi ke log aktivitas Admin Agen DC.

3. Buka jendela prompt perintah yang ditinggikan.

4. Membuat akun pengujian untuk melakukan pengujian sandi

   Ada banyak cara untuk membuat akun pengguna, tetapi opsi baris perintah ditawarkan di sini sebagai cara untuk mempermudah selama siklus pengujian berulang:

   net.exe user <testuseraccountname> /add <password>
   

   Untuk tujuan diskusi di bawah ini, asumsikan bahwa kami telah membuat akun pengujian bernama "ContosoUser", misalnya:

   net.exe user ContosoUser /add <password>
   

5. Masuk ke pusat admin Microsoft Entra sebagai setidaknya Administrator Autentikasi.

6. Telusuri perlindungan kata sandi metode > Autentikasi Perlindungan>.

7. Ubah kebijakan Perlindungan Kata Sandi Microsoft Entra sesuai kebutuhan untuk pengujian yang ingin Anda lakukan. Misalnya, Anda dapat memutuskan untuk mengonfigurasi Mode Diterapkan atau Audit, atau Anda dapat memutuskan untuk mengubah daftar istilah yang dilarang dalam daftar sandi kustom yang dilarang milik Anda.

8. Sinkronkan kebijakan baru dengan menghentikan dan memulai ulang layanan agen DC.

   Langkah ini dapat dicapai dengan berbagai cara. Salah satu caranya adalah dengan menggunakan konsol administratif Manajemen Layanan, dengan mengklik kanan pada layanan Agen DC Perlindungan Kata Sandi Microsoft Entra dan memilih "Hidupkan ulang". Cara lain dapat dilakukan dari jendela prompt perintah seperti:

   net stop AzureADPasswordProtectionDCAgent && net start AzureADPasswordProtectionDCAgent
   

9. Periksa Penampil Aktivitas untuk memverifikasi bahwa kebijakan baru telah diunduh.

   Setiap kali layanan agen DC dihentikan dan dimulai, Anda akan melihat dua aktivitas 30006 dikeluarkan secara berurutan. Aktivitas 30006 pertama akan mencerminkan kebijakan yang di-cache pada disk di berbagi sysvol. Aktivitas 30006 kedua (jika ada) harus memiliki tanggal kebijakan Penyewa yang diperbarui, dan jika demikian akan mencerminkan kebijakan yang diunduh dari Azure. Nilai tanggal kebijakan penyewa saat ini dikodekan untuk menampilkan perkiraan stempel waktu kebijakan yang diunduh dari Azure.

   Jika aktivitas 30006 kedua tidak muncul, Anda harus memecahkan masalah sebelum melanjutkan.

   Aktivitas 30006 akan terlihat mirip dengan contoh ini:

   The service is now enforcing the following Azure password policy.
   
   Enabled: 1
   AuditOnly: 0
   Global policy date: ‎2018‎-‎05‎-‎15T00:00:00.000000000Z
   Tenant policy date: ‎2018‎-‎06‎-‎10T20:15:24.432457600Z
   Enforce tenant policy: 1
   

   Misalnya, perubahan antara Mode Diterapkan dan Audit akan mengakibatkan bendera AuditOnly dimodifikasi (kebijakan di atas dengan AuditOnly=0 berada dalam mode Diterapkan); perubahan pada daftar sandi khusus yang dilarang tidak secara langsung tercermin dalam aktivitas 30006 di atas (dan tidak dicatat di tempat lain karena alasan keamanan). Berhasil mengunduh kebijakan dari Azure setelah perubahan tersebut juga akan menyertakan daftar sandi kustom yang dilarang yang dimodifikasi.

10. Jalankan pengujian dengan mencoba mereset sandi baru pada akun pengguna pengujian.

    Langkah ini dapat dilakukan dari jendela prompt perintah seperti:

    net.exe user ContosoUser <password>
    

    Setelah menjalankan perintah, Anda bisa mendapatkan informasi lebih lanjut tentang hasil perintah dengan melihat di penampil aktivitas. Aktivitas hasil validasi sandi didokumentasikan dalam topik log aktivitas Admin Agen DC; Anda akan menggunakan aktivitas tersebut untuk memvalidasi hasil pengujian Anda selain output interaktif dari perintah net.exe.

    Mari kita coba contoh: mencoba mengatur sandi yang dilarang oleh daftar global Microsoft (perhatikan bahwa daftar tidak didokumentasikan tetapi kita dapat mengujinya di sini terhadap istilah terlarang yang diketahui). Contoh ini mengasumsikan bahwa Anda telah mengonfigurasi kebijakan untuk berada dalam mode Diterapkan, dan telah menambahkan nol istilah ke daftar sandi kustom yang dilarang.

    net.exe user ContosoUser PassWord
    The password does not meet the password policy requirements. Check the minimum password length, password complexity and password history requirements.
    
    More help is available by typing NET HELPMSG 2245.
    

    Sesuai dokumentasi, karena pengujian kami adalah operasi pengaturan ulang sandi Anda akan melihat aktivitas 10017 dan 30005 untuk pengguna ContosoUser.

    Aktivitas 10017 akan terlihat seperti contoh ini:

    The reset password for the specified user was rejected because it did not comply with the current Azure password policy. Please see the correlated event log message for more details.
    
    UserName: ContosoUser
    FullName: 
    

    Aktivitas 30005 akan terlihat seperti contoh ini:

    The reset password for the specified user was rejected because it matched at least one of the tokens present in the Microsoft global banned password list of the current Azure password policy.
    
    UserName: ContosoUser
    FullName: 
    

    Menyenangkan - mari kita coba contoh lain! Kali ini kami akan mencoba mengatur sandi yang dilarang oleh daftar terlarang kustom saat kebijakan dalam mode Audit. Contoh ini mengasumsikan bahwa Anda telah melakukan langkah berikut: mengonfigurasi kebijakan untuk berada dalam mode Audit, menambahkan istilah "lachrymose" ke daftar sandi kustom yang dilarang, dan menyinkronkan kebijakan baru yang dihasilkan ke pengontrol domain dengan mengulangi layanan agen DC seperti yang dijelaskan di atas.

    Ok, mengatur variasi sandi yang dilarang:

    net.exe user ContosoUser LaChRymoSE!1
    The command completed successfully.
    

    Ingat, kali ini berhasil karena kebijakan tersebut dalam mode Audit. Anda akan melihat aktivitas 10025 dan 30007 untuk pengguna ContosoUser.

    Aktivitas 10025 akan terlihat seperti contoh ini:

    The reset password for the specified user would normally have been rejected because it did not comply with the current Azure password policy. The current Azure password policy is configured for audit-only mode so the password was accepted. Please see the correlated event log message for more details.
    
    UserName: ContosoUser
    FullName: 
    

    Aktivitas 30007 akan terlihat seperti contoh ini:

    The reset password for the specified user would normally have been rejected because it matches at least one of the tokens present in the per-tenant banned password list of the current Azure password policy. The current Azure password policy is configured for audit-only mode so the password was accepted.
    
    UserName: ContosoUser
    FullName: 
    

11. Lanjutkan pengujian berbagai sandi pilihan Anda dan periksa hasilnya di penampil aktivitas menggunakan prosedur yang diuraikan dalam langkah sebelumnya. Jika Anda perlu mengubah kebijakan di pusat admin Microsoft Entra, jangan lupa untuk menyinkronkan kebijakan baru ke agen DC seperti yang dijelaskan sebelumnya.

Kami telah membahas prosedur yang memungkinkan Anda melakukan pengujian terkontrol perilaku validasi kata sandi Perlindungan Kata Sandi Microsoft Entra. Menyetel ulang sandi pengguna dari baris perintah langsung pada pengontrol domain mungkin tampak sebagai cara yang aneh untuk melakukan pengujian semacam itu, tetapi seperti yang dijelaskan sebelumnya, ini dirancang untuk menghasilkan hasil yang dapat diulang. Saat Anda menguji berbagai sandi, ingatlah algoritma evaluasi sandi karena dapat membantu menjelaskan hasil yang tidak Anda harapkan.

Tautan berikut bukan bagian dari dokumentasi inti Perlindungan Kata Sandi Microsoft Entra tetapi mungkin merupakan sumber informasi tambahan yang berguna pada fitur tersebut.

Perlindungan Kata Sandi Microsoft Entra sekarang tersedia secara umum!

Panduan Perlindungan Pengelabuan Email – Bagian 15: Terapkan Layanan Perlindungan Kata Sandi Microsoft Entra (untuk Lokal juga!)

Perlindungan Kata Sandi Microsoft Entra dan Penguncian Cerdas sekarang berada di Pratinjau Umum!

Jika Anda tertarik untuk mempelajari selengkapnya tentang Perlindungan Kata Sandi Microsoft Entra dan menyebarkannya di lingkungan Anda, Anda dapat memanfaatkan layanan proaktif Microsoft yang tersedia untuk pelanggan tersebut dengan kontrak dukungan Premier atau Terpadu. Layanan ini disebut ID Microsoft Entra: Perlindungan Kata Sandi. Hubungi Manajer Akun Keberhasilan Pelanggan Anda untuk informasi lebih lanjut.

Langkah berikutnya

Jika Anda memiliki pertanyaan Perlindungan Kata Sandi Microsoft Entra lokal yang tidak dijawab di sini, kirimkan item Umpan Balik di bawah ini - terima kasih!

Menyebarkan perlindungan kata sandi Microsoft Entra