Cara mengimplementasikan Windows Hello for Business di domain hibrida

Jika Anda memiliki teknisi lapangan atau pengguna dengan laptop dan tablet yang terus-menerus menggunakan layar sentuh, mereka mungkin sudah bosan mengetik kata sandi mereka berulang kali. Windows Hello for Business diciptakan tepat untuk tujuan itu: untuk mengganti kata sandi dengan metode login yang lebih nyaman dan aman, seperti PIN, sidik jari, atau pengenalan wajah, sambil mempertahankan integrasi dengan domain Anda dan Microsoft Entra ID (sebelumnya Azure AD).

Masalahnya adalah ketika Anda mulai membaca dokumentasi resmi, konsep-konsep seperti model penyebaran, jenis kepercayaan, Kerberos di cloud, PKI, AD FS, MFA, sinkronisasi kunci, dan sebagainya muncul , dan mudah untuk merasa kewalahan, terutama jika Anda tidak ingin terlalu banyak berurusan dengan pengendali domain. Dalam panduan ini, kami akan menguraikannya dengan tenang, menjelaskan apa yang sebenarnya Anda butuhkan untuk mengimplementasikan Windows Hello di lingkungan domain (termasuk hybrid) dan bagian mana yang dapat Anda abaikan tergantung pada skenario Anda yang sebenarnya.

Apa itu Windows Hello for Business dan apa perbedaannya dengan Windows Hello "biasa"?

Windows Hello for Business adalah versi perusahaan dari Windows Hello yang menggantikan kata sandi dengan kredensial kunci publik yang terhubung ke perangkat . Fitur ini tidak hanya untuk membuka kunci komputer: tetapi juga digunakan untuk otentikasi dengan Active Directory dan/atau Microsoft Entra ID.

Pada praktiknya, pengguna masuk menggunakan PIN, sidik jari, atau pengenalan wajah , tetapi di baliknya, Windows menggunakan sepasang kunci asimetris yang disimpan dan dilindungi pada perangkat (sebaiknya di TPM) untuk mengautentikasi ke penyedia identitas (IdP): bisa berupa Microsoft Entra ID, lingkungan hibrida, atau lingkungan lokal murni dengan AD FS.

Kunci privat tidak pernah meninggalkan komputer; kunci publik didaftarkan ke Microsoft Entra ID atau AD FS selama pendaftaran. Dari sana, pengguna dapat melakukan SSO terhadap sumber daya cloud dan/atau on-premises, tergantung pada model penerapan yang Anda pilih.

Model penerapan Windows Hello untuk bisnis

Sebelum memodifikasi GPO atau Intune, penting untuk memahami model penyebaran mana yang paling sesuai dengan lingkungan Anda. Windows Hello for Business membedakan tiga skenario utama, tergantung pada di mana identitas dan sumber daya berada:

Hanya berbasis cloud : Organisasi yang hanya memiliki identitas Microsoft Entra ID dan tidak mengakses sumber daya lokal. Perangkat bergabung dengan Microsoft Entra (gabungan Azure AD) atau mendaftar, dan semua yang dibutuhkan pengguna (SharePoint Online, OneDrive, aplikasi SaaS, dll.) berada di cloud. Tidak ada pengendali domain lokal atau kebutuhan sertifikat untuk VPN atau layanan lokal lainnya.

Hybrid : Perusahaan yang menyinkronkan identitas antara Active Directory lokal dan Microsoft Entra ID. Mereka biasanya memiliki perangkat yang tergabung dalam domain tradisional, perangkat yang tergabung dalam Azure AD, atau perangkat hybrid, dan mereka menginginkan SSO ke sumber daya lokal (server file, aplikasi lama) dan sumber daya cloud. Ini adalah skenario yang paling umum dan menarik ketika Anda bertanya-tanya bagaimana cara mengimplementasikan Windows Hello di domain tanpa merusak apa pun.

On-premises : Organisasi tanpa identitas cloud atau aplikasi Microsoft Entra ID. Semuanya berada di Active Directory, dan aplikasi terintegrasi dengan AD atau AD FS. Namun, mereka dapat memanfaatkan Windows Hello for Business untuk pengalaman single sign-on (SSO) tanpa kata sandi di lingkungan on-premises mereka.

Model yang Anda pilih menentukan layanan apa yang Anda butuhkan (misalnya, Microsoft Entra Connect, AD FS, PKI, Kerberos di cloud, dll.) dan jenis kepercayaan apa yang akan Anda gunakan untuk berkomunikasi dengan Active Directory.

Jenis-jenis kepercayaan: bagaimana Windows Hello melakukan autentikasi terhadap domain.

Tipe kepercayaan menentukan bagaimana klien Windows Hello for Business melakukan autentikasi ke Active Directory. Ini adalah konsep kunci ketika Anda ingin pengguna dapat menggunakan PIN atau sidik jari pada PC yang terhubung ke domain untuk mengakses sumber daya lokal.

Penting: Jenis kepercayaan ini hanya berlaku jika terdapat Active Directory lokal . Untuk melakukan autentikasi dengan Microsoft Entra ID, Windows Hello selalu menggunakan kunci (bukan sertifikat), kecuali dalam skenario kartu pintar tertentu di lingkungan terfederasi.

Tiga jenis perwalian yang dapat Anda pilih adalah:

1. Kepercayaan Kerberos Cloud
Dalam model ini, pengguna memperoleh TGT Active Directory mereka melalui Microsoft Memasuki Era KerberosMicrosoft Entra ID menerbitkan tiket yang diterima oleh pengendali domain lokal, dan pengendali domain ini kemudian terus menerbitkan tiket layanan Kerberos dan melakukan otorisasi. Ini adalah mekanisme yang sama yang digunakan untuk login dengan kunci keamanan FIDO2.

Keunggulan utama dari kepercayaan Kerberos di cloud adalah:

• Anda tidak perlu menerapkan PKI. juga tidak akan menyentuh infrastruktur sertifikat Anda yang sudah ada.
• Tidak perlu menyinkronkan kunci publik. antara Microsoft Entra ID dan Active Directory agar pengguna dapat mengakses sumber daya lokal, sehingga tidak ada penundaan antara pendaftaran Windows Hello dan kemampuan untuk melakukan autentikasi ke domain.
• Memungkinkan Masuk menggunakan kunci keamanan FIDO2 dengan konfigurasi tambahan yang sangat ringan.

Namun, kepercayaan cloud Kerberos mengharuskan Anda untuk mengimplementasikan Microsoft Enter Kerberos dan memenuhi versi minimum Windows dan Windows Server (kita akan melihat ini nanti dalam persyaratan sistem).

2. Kepercayaan utama
Dalam hal ini, pengguna melakukan autentikasi terhadap Active Directory lokal menggunakan kunci yang terhubung ke perangkat Dibuat selama pendaftaran Windows Hello. Klien meminta Kerberos TGT menggunakan kunci tersebut. Agar ini berfungsi, beberapa hal tertentu diperlukan. sertifikat ke pengendali domain, karena Kerberos akan menggunakan otentikasi berbasis sertifikat ke DC.

Model ini tidak menerbitkan sertifikat pengguna akhir: kredensial pengguna tetap berupa kunci asimetris yang dilindungi oleh perangkat, tetapi DC (Domain Controller) memerlukan sertifikat agar komputer Windows dapat mengenalinya sebagai entitas tepercaya.

3. Sertifikat kepercayaan
Mereka melangkah lebih jauh: mereka menyiarkannya. sertifikat otentikasi untuk penggunaSelama pendaftaran, pengguna meminta sertifikat menggunakan kunci yang terhubung ke perangkat (yang dihasilkan oleh Windows Hello). Setelah itu, permintaan login dan Kerberos TGT didasarkan pada sertifikat pengguna tersebut, yang didukung oleh PKI perusahaan Anda.

Model ini membutuhkan PKI perusahaan yang terkonfigurasi dengan baik dan otoritas sertifikat (CRA). Dalam penerapan terfederasi, AD FS biasanya bertindak sebagai CRA. Selain itu, dalam lingkungan hibrida, penulisan balik perangkat harus diaktifkan di Microsoft Entra Connect.

Poin penting: tidak satu pun dari jenis kepercayaan ini yang secara inheren lebih aman daripada yang lain; pilihannya bergantung pada infrastruktur Anda saat ini, apakah Anda sudah memiliki PKI, apakah Anda ingin menambahkan AD FS, dan seberapa besar Anda bersedia untuk mengubah pengendali domain.

Persyaratan PKI sesuai dengan model dan jenis kepercayaan.

Salah satu pertanyaan umum saat membahas Windows Hello di domain adalah apakah PKI penuh diperlukan agar fitur ini berfungsi. Jawabannya sepenuhnya bergantung pada model penerapan Anda dan jenis kepercayaan yang dipilih.

Kepercayaan Kerberos di cloud adalah satu-satunya opsi hibrida yang tidak memerlukan sertifikat . Jika Anda dapat mengadopsi model ini, Anda menghindari keharusan untuk menyebarkan CA perusahaan untuk pengendali domain dan pengguna. Hal ini membuatnya sangat menarik untuk lingkungan yang tidak ingin berurusan dengan PKI.

Namun, dalam model hibrida yang berbasis pada Key trust atau Certificate trust , serta dalam model yang sepenuhnya lokal, Anda memang membutuhkan PKI:

• Los pengontrol domain Lingkungan hybrid dan on-premises memerlukan sertifikat agar klien Windows dapat mempercayainya saat memvalidasi autentikasi berbasis sertifikat.
• Jika Anda menggunakan sertifikat kepercayaanAnda memerlukan PKI perusahaan dan otoritas pendaftaran sertifikat (CRA) untuk menerbitkan sertifikat pengguna. AD FS bertindak sebagai CRA dalam banyak implementasi.
• Di beberapa lingkungan hibrida, Anda perlu menerbitkan sertifikat VPN kepada pengguna, jika akses mereka ke sumber daya lokal melalui terowongan yang bergantung pada sertifikat.

Oleh karena itu, jika Anda ragu untuk menyentuh pengendali domain dan lingkungan Anda sudah disinkronkan dengan Microsoft Entra ID, solusi paling praktis biasanya adalah memilih Kerberos di cloud , yang sangat menyederhanakan infrastruktur.

Autentikasi dengan ID Login Microsoft

Windows Hello for Business juga digunakan untuk mengautentikasi pengguna dengan Microsoft Entra ID , terlepas dari bagaimana Anda berkomunikasi dengan Active Directory. Dua opsi utama berperan di sini: autentikasi terfederasi (misalnya, dengan AD FS) atau autentikasi cloud (PHS/PTA).

Tergantung pada model implementasi dan jenis kepercayaan, persyaratan tertentu diberlakukan:

• Hanya awanAutentikasi berbasis cloud digunakan secara default. Anda dapat memilih autentikasi terfederasi dengan IdP pihak ketiga jika diinginkan, tetapi Windows Hello bekerja dengan lancar dengan autentikasi cloud standar.
• Sistem hibrida dengan kepercayaan cloud Kerberos atau kepercayaan kunci.Anda dapat menggunakan sinkronisasi hash kata sandi (PHS), otentikasi pass-through (PTA), atau federasi (AD FS atau IdP lainnya), tergantung pada desain Anda saat ini.
• Hibrida bersertifikatMembutuhkan autentikasi terfederasi dengan AD FS; tidak mendukung PHS atau PTA. AD FS merupakan inti dari hal ini.

Jika penyewa Anda sudah diatur dengan PHS atau PTA dan Anda tidak ingin memodifikasi AD FS, kepercayaan cloud Kerberos atau model Kepercayaan Kunci adalah pilihan yang lebih tepat. Namun, jika Anda sudah menggunakan federasi AD FS untuk semuanya, kepercayaan sertifikat mungkin merupakan pilihan yang tepat.

Registrasi perangkat sesuai model

Blok kunci lainnya adalah registri perangkat , yang menentukan siapa yang mengontrol peralatan untuk menerbitkan token dan mengaktifkan SSO.

Di lingkungan lokal , server dengan peran AD FS menangani pendaftaran perangkat. Server tersebut mengelola hubungan kepercayaan dengan perangkat dan menerbitkan token yang diperlukan agar Windows Hello for Business dapat berfungsi di dalam domain lokal.

Dalam lingkungan hybrid atau cloud-only , perangkat harus mendaftar dengan ID Microsoft Entra, baik sebagai:

• Microsoft Azure AD telah terhubung.
• Microsoft bergabung dengan sistem hybrid (hybrid AD join).
• Login Microsoft untuk pengguna terdaftar (umum di BYOD).

Jenis koneksi menentukan kemampuan yang Anda miliki: misalnya, perangkat hybrid memungkinkan SSO ke cloud dan on-premises tanpa pengguna harus menggunakan berbagai kredensial yang berbeda.

Autentikasi multi-faktor (MFA) dalam penyediaan

Salah satu tujuan utama Windows Hello for Business adalah untuk beralih dari kata sandi tradisional , dengan menyediakan kredensial yang kuat yang didukung oleh perangkat yang aman. Untuk mencapai hal ini, proses penyediaan memerlukan autentikasi dua faktor.

Ide dasarnya adalah kredensial yang lemah (nama pengguna dan kata sandi) hanya digunakan sebagai faktor pertama, sedangkan faktor kedua disediakan oleh solusi MFA . Windows tidak menghasilkan kredensial Windows Hello for Business hingga pengguna berhasil menyelesaikan MFA.

Dalam lingkungan hybrid dan cloud-only, Anda dapat menggunakan:

• Microsoft Memasuki Era MFA (Autentikasi Multi-Faktor) terintegrasi.
• Solusi MFA pihak ketiga, baik sebagai metode autentikasi eksternal di Microsoft Enter ID atau melalui IdP terfederasi.

Di lingkungan lokal tanpa Microsoft Entra ID, Anda memerlukan opsi MFA yang terintegrasi sebagai adaptor MFA AD FS . Microsoft dan vendor lain menawarkan adaptor khusus untuk tujuan ini.

Selain itu, di domain terfederasi Anda dapat menyesuaikan branding. FederatedIdpMfaBehaviorPengaturan ini memberi tahu Microsoft Entra ID apakah akan menerima, mewajibkan, atau menolak MFA yang berasal dari IdP terfederasi. Pengaturan ini ditinjau dan dimodifikasi menggunakan perintah PowerShell seperti... Get-MgDomainFederationConfiguration y Update-MgDomainFederationConfiguration.

Konfigurasi kebijakan: GPO vs CSP

Untuk memungkinkan pengguna menggunakan Windows Hello for Business di perangkat mereka, Anda perlu mengkonfigurasi kebijakan yang sesuai . Ada dua mekanisme utama:

• Penyedia Layanan Konfigurasi (CSP)Ideal untuk perangkat yang dikelola melalui MDM, seperti Microsoft Intune. Ini memungkinkan Anda untuk menerapkan kebijakan Windows Hello menggunakan profil konfigurasi, dan bahkan dengan paket penyediaan.
• Kebijakan Grup (GPO)Digunakan untuk komputer yang terhubung ke domain tetapi tidak dikelola oleh MDM atau jika Anda lebih memilih untuk melanjutkan dengan manajemen lokal tradisional.

Dalam model apa pun (hanya cloud, hybrid, atau on-premises), Anda dapat menggunakan CSP, GPO, atau kombinasi keduanya, tergantung pada cara Anda mengelola perangkat. Misalnya, Anda dapat mengelola laptop yang terhubung ke domain menggunakan Intune (hybrid) sambil secara bersamaan menerapkan beberapa konfigurasi dasar melalui GPO atau administrasi jarak jauh yang aman.

Dalam penerapan GPO klasik, terdapat satu kebijakan kunci wajib untuk mengaktifkan Windows Hello for Business dalam model kepercayaan kunci, dan satu kebijakan lain yang sangat direkomendasikan:

• Rute tim: Konfigurasi komputer → Templat administratif → Komponen Windows → Windows Hello untuk Bisnis → Menggunakan Windows Hello untuk Bisnis (diaktifkan).
• Jalur pengguna: Konfigurasi pengguna → Templat administratif → Komponen Windows → Windows Hello for Business → Menggunakan Windows Hello for Business (diaktifkan jika Anda ingin memaksanya per pengguna).
• Tambahan: Gunakan perangkat keamanan perangkat keras., untuk memberlakukan penggunaan TPM dan meningkatkan perlindungan kunci.

Jika Anda menerapkan pengaturan pada node Komputer, semua pengguna yang masuk ke perangkat tersebut akan dipaksa untuk mencoba mendaftar ke Windows Hello for Business. Jika Anda menerapkannya pada node Pengguna, hanya pengguna yang dituju yang akan melihat pengalaman pendaftaran. Jika terjadi konflik, kebijakan pengguna akan diutamakan daripada kebijakan komputer.

Objek Kebijakan Grup (GPO) dapat dihubungkan ke domain atau Unit Organisasi (OU) tertentu, difilter berdasarkan grup keamanan, atau bahkan berdasarkan filter WMI untuk secara tepat memisahkan mesin mana yang disertakan dalam penyebaran. Selain opsi dasar ini, terdapat sejumlah kebijakan Windows Hello yang lebih detail (misalnya, kompleksitas PIN, batas waktu penguncian, penggunaan biometrik) yang dapat Anda sesuaikan sesuai dengan kebijakan keamanan perusahaan Anda.

Proses pendaftaran dan pengalaman pengguna

Dari perspektif pengguna, proses pengaturan Windows Hello for Business cukup terarah. Penyediaan dimulai segera setelah profil pengguna dimuat dan sebelum mereka melihat desktop, asalkan semua prasyarat infrastruktur dan kebijakan terpenuhi.

Jika Anda ingin memeriksa apakah pemeriksaan awal telah berhasil, Anda dapat meninjau pengguna perangkat administrator log Di Event Viewer: Log Aplikasi dan Layanan → Microsoft → Windows. Pilihan lain adalah menggunakan dsregcmd.exe /status pada konsol untuk melihat status pendaftaran perangkat dan hubungannya dengan Microsoft Enter ID.

Langkah-langkah yang biasanya diikuti pengguna selama proses pendaftaran adalah:

1. Jika perangkat mendukung otentikasi biometrik (pembaca sidik jari, kamera yang kompatibel), Windows akan meminta pengguna untuk mengkonfigurasi gerakan biometrikGerakan ini akan membuka kunci perangkat dan mengautentikasi pengguna dengan sumber daya yang menerima Windows Hello for Business. Pengguna dapat melewati langkah ini jika mereka lebih memilih untuk hanya menggunakan PIN.
2. Windows memberi tahu Anda bahwa ia akan menggunakan Windows Hello dengan akun perusahaan dan pengguna harus menyetujuinya.
3. Fase dimulai otentikasi multi-faktorWindows memberi tahu pengguna bahwa sistem sedang mencoba menghubungi mereka melalui metode MFA yang telah dikonfigurasi (misalnya, aplikasi seluler, panggilan, atau SMS). Proses penyediaan tidak akan berlanjut hingga MFA selesai, gagal, atau kedaluwarsa. Jika MFA gagal atau kedaluwarsa, pengguna akan menerima pesan kesalahan dan diminta untuk mencoba lagi.
4. Setelah MFA berhasil, sistem akan meminta pengguna untuk Buat dan validasi PINPIN ini harus sesuai dengan arahan kompleksitas yang telah dikonfigurasi (panjang minimum, pembatasan angka yang berulang, dll.).
5. Terakhir, Windows meminta sebuah pasangan kunci asimetris Bagi pengguna, kunci tersebut idealnya dihasilkan dan dilindungi di dalam TPM (atau diperlukan jika ditentukan dalam kebijakan). Setelah kunci dihasilkan, Windows mendaftarkan kunci publik ke IdP (Microsoft Entra ID atau AD FS, tergantung modelnya). Setelah pendaftaran kunci selesai, wizard memberi tahu pengguna bahwa mereka sekarang dapat menggunakan PIN atau biometrik mereka untuk masuk, dan pengguna menutup aplikasi penyediaan dan mengakses desktop.

Dokumentasi resmi biasanya mencakup diagram urutan dan video yang menggambarkan langkah-langkah ini, termasuk contoh dengan adaptor MFA khusus untuk AD FS. Ini bermanfaat untuk memahami panggilan antara klien, IdP, DC, dan layanan MFA.

Pencatatan penekanan tombol dan sinkronisasi direktori

Inti dari Windows Hello untuk bisnis adalah pembuatan dan pendaftaran pasangan kunci asimetris . Proses penyediaan menghasilkan kunci privat yang terhubung ke perangkat (biasanya disimpan di TPM) dan mendaftarkan kunci publik dengan penyedia identitas yang sesuai.

• Model khusus cloudKunci publik terdaftar di Microsoft Login ID.
• Model hibridaSelain itu, sistem ini juga terdaftar di Microsoft Entra ID; kemudian, Microsoft Entra Connect Sync akan menangani sinkronisasi kunci publik dengan Active Directory.
• Model lokalKunci publik terdaftar di AD FS, yang bertindak sebagai penyedia identitas untuk lingkungan lokal.

Dalam model hibrida, Microsoft Entra Connect tidak hanya menyinkronkan pengguna dan perangkat, tetapi juga kredensial publik Windows Hello , memungkinkan pengguna untuk mendapatkan SSO terhadap sumber daya lokal menggunakan kredensial yang kuat tersebut, tanpa perlu menggunakan kata sandi lagi.

Dalam model lokal murni yang menggunakan Azure MFA sebagai solusi multi-faktor, sinkronisasi direktori dapat digunakan untuk mengimpor pengguna dari Active Directory ke server Azure MFA, yang kemudian berkomunikasi dengan layanan cloud MFA untuk memvalidasi faktor kedua.

persyaratan sistem operasi

Terkait versi Windows, semua versi klien yang secara resmi didukung oleh Microsoft dapat menggunakan Windows Hello for Business . Namun, kepercayaan Kerberos di cloud memiliki persyaratan minimum tertentu:

• Windows 10 21H2 dengan pembaruan KB5010415 atau yang lebih baru.
• Windows 11 21H2 dengan pembaruan KB5010414 atau yang lebih baru.

Untuk jenis kepercayaan lainnya (Kunci dan Sertifikat) dalam model hibrida atau lokal, semua versi klien Windows yang didukung valid, asalkan menerima pembaruan keamanan.

Terkait pengendali domain, Windows Hello untuk bisnis berfungsi dengan semua versi Windows Server yang didukung, tetapi kepercayaan Kerberos di cloud kembali memiliki persyaratan minimum:

• Windows Server 2016 dengan KB4534307 atau versi yang lebih baru.
• Windows Server 2019 dengan KB4534321 atau versi yang lebih baru.
• Windows Server 2022
• Windows Server 2025

Bagaimanapun, level fungsional minimum forest dan domain harus Windows Server 2008 R2 untuk semua model penerapan. Jika Anda masih memiliki domain dengan level fungsional yang lebih lama, Anda perlu memperbarui domain tersebut sebelum mempertimbangkan penerapan Windows Hello for Business secara serius.

Persyaratan lisensi dan layanan cloud

Dari segi lisensi, Windows Hello for Business sendiri tidak secara langsung memerlukan Microsoft Entra ID P1 atau P2 . Namun, beberapa fitur terkait (seperti pendaftaran MDM otomatis, kebijakan akses bersyarat tertentu, atau penulisan balik perangkat) mungkin memerlukan level P1/P2.

Beberapa poin penting terkait perizinan adalah:

• Anda dapat menerapkan Windows Hello untuk bisnis dengan cara berikut: tingkat gratis ID Masuk Microsoft. Semua akun gratis dapat menggunakan MFA Masuk Microsoft untuk fitur Windows tanpa kata sandi.
• Perangkat yang dikelola melalui MDM (Intune atau lainnya) tidak memerlukan P1/P2 karena menggunakan Windows Hello; namun, tanpa P1/P2, pendaftaran MDM mungkin tidak otomatis dan pengguna perlu melakukan hal tersebut. mendaftar secara manual dalam solusi MDM.
• Jika Anda menggunakan model sertifikat kepercayaan Dalam konfigurasi hybrid, Anda memerlukan setidaknya Microsoft Enter ID P1 untuk mengaktifkan fitur-fitur seperti penulisan balik perangkat dan pendaftaran sertifikat melalui otoritas registri AD FS.
• Di lingkungan lokal, jika Anda memutuskan untuk menggunakan Azure MFA sebagai solusi otentikasi multifaktor, Anda perlu memiliki lisensi atau paket Azure MFA yang sesuai yang menyertakannya.

Singkatnya: untuk banyak penerapan hybrid dengan Kerberos di cloud atau Key trust, langganan P1/P2 tidak wajib, tetapi jika Anda ingin memanfaatkan sepenuhnya manajemen modern, akses bersyarat tingkat lanjut, dan penulisan balik perangkat, langganan ini menjadi relevan.

Bagaimana semua ini sesuai dengan skenario dunia nyata: tablet yang terhubung secara hibrida

Dalam lingkungan teknisi lapangan yang menggunakan tablet Windows yang terhubung secara hibrida, biasanya yang terjadi adalah sebagai berikut:

• Perangkat-perangkat tersebut adalah Bergabung ke domain dan terdaftar dengan ID Login Microsoft. (gabungan AD hibrida).
• Konfigurasi dikelola dengan Intune, GPO, atau kombinasi keduanya.
• Anda ingin mengaktifkan Masuk menggunakan sidik jari atau PIN. untuk menghindari pengetikan kata sandi di layar sentuh.

Dalam konteks ini, biasanya lebih disarankan untuk memilih Kerberos di cloud daripada model yang membutuhkan PKI penuh. Anda tidak perlu "merusak" apa pun pada pengendali domain selain menginstal patch yang diperlukan dan mengkonfigurasi Microsoft Entra Kerberos, dan Anda menghindari kerumitan sertifikat pengguna dan CRA.

Jika Anda sudah membuat profil konfigurasi di Intune untuk mengaktifkan Windows Hello dan Anda melihat sistem menawarkan untuk mengkonfigurasi PIN atau biometrik, tetapi kemudian Anda mendapatkan kesalahan "Kredensial Anda tidak dapat diverifikasi" saat mencoba menggunakan Windows Hello, kemungkinan besar karena:

• Tidak punya Backend tepercaya telah selesai. (Kerberos di cloud/Kunci/Sertifikat) untuk berkomunikasi dengan domain.
• Atau konfigurasi tidak berfungsi dengan benar. model implementasi hibrida mengikuti pedoman resmi (misalnya, panduan khusus untuk kepercayaan Kerberos cloud hibrida).

Konfigurasi global di bawah “Daftarkan perangkat → Pendaftaran Windows” di Intune mengaktifkan Windows Hello di tingkat penyewa, tetapi tidak menggantikan persyaratan infrastruktur yang mendasarinya (tipe kepercayaan, Microsoft Entra Kerberos, sinkronisasi direktori, dll.). Itulah mengapa Anda melihat wizard di klien, tetapi autentikasi sisi server gagal saat memvalidasi kredensial.

Hal yang bijaksana untuk dilakukan dalam kasus ini adalah meninjau langkah demi langkah dokumentasi penerapan Windows Hello for Business dan hibridisasinya dengan Kerberos di cloud, memastikan bahwa perangkat tampak terdaftar dengan benar (melalui dsregcmd /status), bahwa Microsoft Entra Kerberos telah dikonfigurasi di forest yang benar dan bahwa kebijakan (CSP/GPO) diterapkan kepada pengguna dan komputer yang sesuai.

Dengan semua elemen ini tersusun dengan benar—model penerapan yang jelas, jenis kepercayaan yang tepat, MFA yang berfungsi, registrasi perangkat dan kunci yang benar, serta kebijakan yang diterapkan dengan baik—Windows Hello for Business tidak lagi menjadi "hal yang merepotkan untuk disiapkan" dan menjadi cara yang cukup nyaman bagi pengguna Anda untuk masuk ke domain dengan PIN, sidik jari, atau wajah, alih-alih berjuang dengan kata sandi yang tak ada habisnya pada keyboard sentuh.