Apa yang baru dalam Layanan Federasi Direktori Aktif

  • Artikel

Apa yang baru dalam Layanan Federasi Direktori Aktif untuk Windows Server 2019

Artikel ini menjelaskan perubahan baru yang dilakukan pada Layanan Federasi Direktori Aktif (AD FS).

Rincian masuk yang dilindungi

Poin berikut adalah ringkasan singkat pembaruan untuk rincian masuk yang dilindungi yang tersedia di Layanan Federasi Direktori Aktif (AD FS) 2019:

  • Penyedia Autentikasi Eksternal sebagai Primer. Pelanggan sekarang dapat menggunakan produk autentikasi pihak ketiga sebagai faktor pertama dan tidak mengekspos kata sandi sebagai faktor pertama. Dalam kasus di mana penyedia autentikasi eksternal dapat membuktikan dua faktor, ia dapat mengklaim MFA.
  • Autentikasi Kata Sandi sebagai Autentikasi tambahan. Pelanggan memiliki opsi dalam kotak yang didukung penuh untuk menggunakan kata sandi hanya sebagai faktor tambahan setelah opsi tanpa kata sandi digunakan sebagai faktor pertama. Opsi ini meningkatkan pengalaman pelanggan dari Layanan Federasi Direktori Aktif 2016 di mana pelanggan harus mengunduh adaptor GitHub yang didukung apa adanya.
  • Modul Penilaian Risiko yang Dapat Dicolokkan. Pelanggan sekarang dapat membangun modul plug-in mereka sendiri untuk memblokir jenis permintaan tertentu selama tahap praauthentication. Fitur ini memudahkan pelanggan untuk menggunakan kecerdasan cloud seperti perlindungan identitas untuk memblokir masuk bagi pengguna berisiko atau transaksi berisiko. Untuk informasi selengkapnya, lihat Membangun Plug-in dengan Model Penilaian Risiko AD FS 2019.
  • Peningkatan ESL. Meningkatkan rekayasa perbaikan cepat (QFE) ESL pada tahun 2016 dengan menambahkan kemampuan berikut:
    • Memungkinkan pelanggan berada dalam mode audit saat dilindungi oleh fungsionalitas penguncian ekstranet 'klasik', tersedia sejak AD FS 2012R2. Saat ini pelanggan 2016 tidak akan memiliki perlindungan saat dalam mode audit.
    • Mengaktifkan ambang batas penguncian independen untuk lokasi yang sudah dikenal. Fitur ini memungkinkan beberapa instans aplikasi yang berjalan dengan akun layanan umum untuk menggulirkan kata sandi dengan jumlah efek paling sedikit.

Peningkatan keamanan lainnya

Peningkatan keamanan berikut tersedia di Layanan Federasi Direktori Aktif 2019:

  • PowerShell Jarak Jauh menggunakan Masuk SmartCard. Pelanggan sekarang dapat menggunakan SmartCards untuk terhubung dari jarak jauh ke Layanan Federasi Direktori Aktif melalui PowerShell dan menggunakannya untuk mengelola semua fungsi PowerShell termasuk cmdlet multi-simpul.
  • Kustomisasi Header HTTP. Pelanggan sekarang dapat mengkustomisasi header HTTP yang dipancarkan selama respons AD FS, termasuk header berikut:
    • HSTS: Header ini menyampaikan bahwa titik akhir Layanan Federasi Direktori Aktif hanya dapat digunakan pada titik akhir HTTPS untuk diberlakukan browser yang sesuai.
    • x-frame-options: Memungkinkan admin Layanan Federasi Direktori Aktif mengizinkan pihak yang mengandalkan tertentu untuk menyematkan iFrames untuk halaman masuk interaktif Ad FS. Header ini harus digunakan dengan hati-hati dan hanya pada host HTTPS.
    • Header masa depan: Header lain di masa mendatang juga dapat dikonfigurasi.

Untuk informasi selengkapnya, lihat Mengkustomisasi header respons keamanan HTTP dengan Layanan Federasi Direktori Aktif 2019.

Kemampuan Autentikasi/Kebijakan

Kemampuan autentikasi/kebijakan berikut ada di Layanan Federasi Direktori Aktif 2019:

  • Tentukan metode autentikasi untuk autentikasi lain per RP. Pelanggan sekarang dapat menggunakan aturan klaim untuk memutuskan penyedia autentikasi lain mana yang akan dipanggil untuk autentikasi tambahan mereka. Fitur ini berguna untuk dua kasus penggunaan:
    • Pelanggan beralih dari satu penyedia autentikasi lainnya ke penyedia autentikasi lain. Dengan cara ini saat mereka memasukkan pengguna ke penyedia autentikasi yang lebih baru, mereka dapat menggunakan grup untuk mengontrol penyedia autentikasi tambahan mana yang dipanggil.
    • Pelanggan memiliki kebutuhan untuk penyedia autentikasi tambahan tertentu (misalnya, sertifikat) untuk aplikasi tertentu.
  • Batasi autentikasi perangkat berbasis Transport Layer Security (TLS) hanya untuk aplikasi yang memerlukannya. Pelanggan sekarang dapat membatasi autentikasi perangkat berbasis TLS klien hanya untuk aplikasi yang melakukan akses bersyarkat berbasis perangkat. Opsi ini mencegah permintaan yang tidak diinginkan untuk autentikasi perangkat (atau kegagalan jika aplikasi klien tidak dapat menangani) untuk aplikasi yang tidak memerlukan autentikasi perangkat berbasis TLS.
  • Dukungan kesegaran autentikasi multifaktor (MFA). Layanan Federasi Direktori Aktif sekarang mendukung kemampuan untuk mengulang kredensial faktor kedua berdasarkan kesegaran kredensial faktor kedua. Fitur ini memungkinkan pelanggan untuk melakukan transaksi awal dengan dua faktor dan hanya meminta faktor kedua secara berkala. Fitur ini hanya tersedia untuk aplikasi yang dapat memberikan parameter tambahan dalam permintaan dan bukan pengaturan yang dapat dikonfigurasi di Layanan Federasi Direktori Aktif. Azure AD mendukung parameter ini saat Anda mengonfigurasi "Ingat MFA saya untuk X hari" dan atur bendera 'supportsMFA' ke true pada pengaturan kepercayaan domain federasi Azure AD.

Penyempurnaan akses menyeluruh

Penyempurnaan SSO akses menyeluruh berikut telah dilakukan di Layanan Federasi Direktori Aktif 2019:

  • UX paginasi dengan Tema Terpusat. Layanan Federasi Direktori Aktif sekarang telah pindah ke alur UX paginasi yang memungkinkan Layanan Federasi Direktori Aktif memvalidasi dan memberikan pengalaman masuk yang lebih lancar. Layanan Federasi Direktori Aktif sekarang menggunakan UI terpusat (alih-alih sisi kanan layar). Anda mungkin memerlukan logo dan gambar latar belakang yang lebih baru untuk menyelaraskan dengan pengalaman ini. Perubahan ini juga mencerminkan fungsionalitas yang ditawarkan di Azure AD.
  • Perbaikan bug: Status SSO persisten untuk perangkat Win10 saat melakukan autentikasi Token Refresh Utama (PRT). Perubahan ini menyelesaikan masalah di mana status MFA tidak bertahan saat menggunakan autentikasi PRT untuk perangkat Windows 10. Hasil dari masalah ini adalah bahwa pengguna akhir akan sering dimintai kredensial faktor kedua (MFA). Perbaikan ini juga membuat pengalaman konsisten ketika autentikasi perangkat berhasil dilakukan melalui TLS klien dan melalui mekanisme PRT.

Dukungan untuk membangun aplikasi lini bisnis modern

Dukungan berikut untuk membangun aplikasi LOB lini bisnis modern telah ditambahkan ke Layanan Federasi Direktori Aktif 2019:

  • Alur/profil Perangkat Oauth. Layanan Federasi Direktori Aktif sekarang mendukung profil alur perangkat OAuth untuk masuk di perangkat yang tidak memiliki area permukaan UI untuk mendukung pengalaman masuk yang kaya. Fitur ini memungkinkan pengguna untuk menyelesaikan pengalaman masuk di perangkat yang berbeda. Fungsionalitas ini diperlukan untuk pengalaman Azure CLI di Azure Stack dan dapat digunakan dalam kasus lain.
  • Penghapusan parameter 'Sumber Daya'. Layanan Federasi Direktori Aktif sekarang telah menghapus persyaratan untuk menentukan parameter sumber daya, yang sejalan dengan spesifikasi Oauth saat ini. Klien sekarang dapat memberikan pengidentifikasi kepercayaan pihak yang mengandalkan sebagai parameter cakupan selain izin yang diminta.
  • Header berbagi sumber daya lintas asal (CORS) dalam respons Layanan Federasi Direktori Aktif. Pelanggan sekarang dapat membangun aplikasi halaman tunggal yang memungkinkan pustaka JavaScript sisi klien memvalidasi tanda tangan id_token dengan mengkueri kunci penandatanganan dari dokumen penemuan OpenID Koneksi (OIDC) di LAYANAN Federasi Direktori Aktif.
  • Dukungan Proof Key for Code Exchange (PKCE). Layanan Federasi Direktori Aktif menambahkan dukungan PKCE untuk menyediakan alur kode autentikasi yang aman dalam OAuth. Fitur ini menambahkan lapisan keamanan tambahan ke alur ini untuk mencegah pembajakan kode dan memutarnya kembali dari klien yang berbeda.
  • Perbaikan bug: Kirim klaim x5t dan anak. Perubahan ini adalah perbaikan bug kecil. Layanan Federasi Direktori Aktif sekarang juga mengirimkan klaim "kid" untuk menunjukkan petunjuk ID kunci untuk memverifikasi tanda tangan. Sebelumnya, Layanan Federasi Direktori Aktif hanya mengirim klaim "x5t".

Peningkatan dukungan

Peningkatan dukungan berikut sekarang menjadi bagian dari Layanan Federasi Direktori Aktif 2019:

  • Kirim detail kesalahan ke admin Layanan Federasi Direktori Aktif. Memungkinkan admin mengonfigurasi pengguna akhir untuk mengirim log debug yang berkaitan dengan kegagalan dalam autentikasi pengguna akhir untuk disimpan sebagai file zip yang diajukan agar mudah dikonsumsi. Admin juga dapat mengonfigurasi koneksi Simple Mail Transfer Protocol (SMTP) untuk mengotomatiskan file zip ke akun email triase atau untuk membuat tiket secara otomatis berdasarkan email.

Pembaruan penyebaran

Pembaruan penyebaran berikut sekarang disertakan dalam Layanan Federasi Direktori Aktif 2019:

  • Perilaku Pertanian Tingkat 2019. Seperti halnya Layanan Federasi Direktori Aktif 2016, ada versi tingkat perilaku farm baru yang diperlukan untuk mengaktifkan fungsionalitas baru yang dibahas nanti di artikel. Pembaruan ini memungkinkan mulai dari:
    • Layanan Federasi Direktori Aktif di Windows Server 2012 R2 ke Layanan Federasi Direktori Aktif di Windows Server 2016.
    • Layanan Federasi Direktori Aktif di Windows Server 2016 ke Layanan Federasi Direktori Aktif di Windows Server 2019.

Pembaruan SAML

Pembaruan Security Assertion Markup Language (SAML) berikut ini ada di Layanan Federasi Direktori Aktif 2019:

  • Perbaikan bug: Perbaiki bug dalam federasi agregat. Ada banyak perbaikan bug di sekitar dukungan federasi agregat (misalnya, InCommon). Area berikut telah menerima perbaikan:
    • Peningkatan penskalaan untuk sejumlah besar entitas dalam dokumen metadata federasi agregat. Sebelumnya, penskalakan akan gagal dengan kesalahan "ADMIN0017".
    • Kueri menggunakan parameter 'ScopeGroupID' melalui Get-AdfsRelyingPartyTrustsGroup cmdlet PowerShell.
    • Menangani kondisi kesalahan di sekitar id entitas duplikat.

Spesifikasi sumber daya gaya Azure AD dalam parameter cakupan

Sebelumnya, Layanan Federasi Direktori Aktif mengharuskan sumber daya dan cakupan yang diinginkan berada dalam parameter terpisah dalam permintaan autentikasi apa pun. Misalnya, permintaan OAuth berikut mungkin terlihat seperti yang biasanya Anda kirim:

https://fs.contoso.com/adfs/oauth2/authorize?response_type=code&client_id=claimsxrayclient&resource=urn:microsoft:adfs:claimsxray&scope=oauth&redirect_uri=https://adfshelp.microsoft.com/
ClaimsXray/TokenResponse&prompt=login

Dengan Layanan Federasi Direktori Aktif di Server 2019, Anda sekarang dapat meneruskan nilai sumber daya yang disematkan dalam parameter cakupan. Perubahan ini konsisten dengan bagaimana seseorang dapat melakukan autentikasi terhadap Azure AD juga.

Parameter cakupan sekarang dapat diatur sebagai daftar yang dipisahkan spasi di mana setiap entri adalah struktur sebagai sumber daya/cakupan.

Catatan

Hanya satu sumber daya yang dapat ditentukan dalam permintaan autentikasi. Jika lebih dari satu sumber daya disertakan dalam permintaan, Ad FS mengembalikan kesalahan dan autentikasi tidak berhasil.

Dukungan Proof Key for Code Exchange (PKCE) untuk oAuth

Klien publik OAuth yang menggunakan Pemberian Kode Otorisasi rentan terhadap serangan penyadapan kode otorisasi. Serangan ini dijelaskan dengan baik dalam RFC 7636. Untuk mengurangi serangan ini, Layanan Federasi Direktori Aktif di Server 2019 mendukung Proof Key for Code Exchange (PKCE) untuk alur Pemberian Kode Otorisasi OAuth.

Untuk menggunakan dukungan PKCE, spesifikasi ini menambahkan lebih banyak parameter ke Otorisasi OAuth 2.0 dan permintaan token akses.

Diagram hubungan PKCE antara klien dan LAYANAN Federasi Direktori Aktif 2019.

A. Klien membuat dan merekam rahasia bernama "code_verifier" dan mendapatkan versi yang diubah "t(code_verifier)" (disebut sebagai "code_challenge"). Rahasia dikirim dalam Permintaan Otorisasi OAuth 2.0 bersama dengan metode transformasi "t_m".

B. Titik akhir otorisasi merespons seperti biasa tetapi merekam "t(code_verifier)" dan metode transformasi.

C. Klien kemudian mengirim kode otorisasi dalam permintaan token akses seperti biasa tetapi menyertakan rahasia "code_verifier" yang dihasilkan di (A).

D. Layanan Federasi Direktori Aktif mengubah "code_verifier" dan membandingkannya dengan "t(code_verifier)" dari (B). Akses ditolak jika tidak sama.

Cara memilih penyedia autentikasi tambahan di 2019

Layanan Federasi Direktori Aktif sudah mendukung pemicu autentikasi tambahan berdasarkan kebijakan aturan klaim. Kebijakan tersebut dapat ditetapkan pada RP tertentu atau di tingkat global. Anda dapat menetapkan kebijakan autentikasi tambahan untuk RP tertentu dengan menggunakan cmdlet Set-AdfsRelyingPartyTrust (AD FS) | Microsoft Docs dengan meneruskan parameter AdditionalAuthenticationRules atau AdditionalAuthenticationRulesFile . Untuk mengaturnya secara global, admin dapat menggunakan cmdlet Set-AdfsAdditionalAuthenticationRule (AD FS) | Microsoft Docs.

Misalnya, admin 2012 R2 dan seterusnya sudah dapat menulis aturan berikut untuk meminta autentikasi tambahan jika permintaan berasal dari ekstranet.

Set-AdfsAdditionalAuthenticationRule -AdditionalAuthenticationRules 'c:[type == "http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", value == "false"] => issue(type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", value = "http://schemas.microsoft.com/claims/multipleauthn" );'

Pada tahun 2019, pelanggan sekarang dapat menggunakan aturan klaim untuk memutuskan penyedia autentikasi lain mana yang akan dipanggil untuk autentikasi tambahan. Fitur ini berguna untuk dua skenario:

Pelanggan beralih dari satu penyedia autentikasi lainnya ke penyedia autentikasi lain. Dengan cara ini saat mereka memasukkan pengguna ke penyedia autentikasi yang lebih baru, mereka dapat menggunakan grup untuk mengontrol penyedia autentikasi tambahan mana yang dipanggil.

Pelanggan memiliki kebutuhan akan penyedia autentikasi tambahan tertentu (misalnya, sertifikat) untuk aplikasi tertentu tetapi metode yang berbeda (Azure AD Multi-Factor Authentication) untuk aplikasi lain.

Konfigurasi ini dapat dicapai dengan mengeluarkan klaim http://schemas.microsoft.com/claims/authnmethodsproviders dari kebijakan autentikasi lainnya. Nilai klaim ini harus menjadi Nama penyedia autentikasi.

Sekarang di 2019 mereka dapat memodifikasi aturan klaim sebelumnya untuk memilih penyedia autentikasi berdasarkan skenario mereka.

Transisi dari satu penyedia autentikasi lainnya ke penyedia autentikasi lain: Anda dapat mengubah aturan yang disebutkan sebelumnya untuk memilih Autentikasi Multifaktor Azure AD untuk pengguna yang berada dalam grup SID S-1-5-21-608905689-872870963-3921916988-12345. Misalnya, Anda dapat menggunakan modifikasi ini untuk grup yang Anda kelola oleh perusahaan, yang melacak pengguna yang telah mendaftar untuk Autentikasi Multifaktor Azure AD. Modifikasi ini juga berfungsi untuk pengguna lain yang ingin digunakan admin autentikasi sertifikat.

'c:[type == "http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", Value == "false"] => issue(type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", Value = "http://schemas.microsoft.com/claims/multipleauthn" ); 

 c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value == "S-1-5-21-608905689-872870963-3921916988-12345"] => issue(Type = "http://schemas.microsoft.com/claims/authnmethodsproviders", Value = "AzureMfaAuthentication"); 

not exists([Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value=="S-1-5-21-608905689-872870963-3921916988-12345"]) => issue(Type = "http://schemas.microsoft.com/claims/authnmethodsproviders", Value = "CertificateAuthentication");’

Contoh ini menunjukkan cara mengatur dua penyedia autentikasi yang berbeda untuk dua aplikasi yang berbeda:

Atur Aplikasi A untuk menggunakan Autentikasi Multifaktor Azure AD sebagai penyedia autentikasi tambahan:

Set-AdfsRelyingPartyTrust -TargetName AppA -AdditionalAuthenticationRules 'c:[type == "http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", Value == "false"] => issue(type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", Value = "http://schemas.microsoft.com/claims/multipleauthn" ); 

c:[] => issue(Type = "http://schemas.microsoft.com/claims/authnmethodsproviders", Value = "AzureMfaAuthentication");'

Atur Aplikasi B untuk menggunakan Sertifikat sebagai penyedia autentikasi tambahan:

Set-AdfsRelyingPartyTrust -TargetName AppB -AdditionalAuthenticationRules 'c:[type == "http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", Value == "false"] => issue(type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", Value = "http://schemas.microsoft.com/claims/multipleauthn" ); 

c:[] => issue(Type = "http://schemas.microsoft.com/claims/authnmethodsproviders", Value = "CertificateAuthentication");'

Admin juga dapat membuat aturan untuk mengizinkan lebih dari satu penyedia autentikasi tambahan. Dalam hal ini Layanan Federasi Direktori Aktif menunjukkan penyedia metode autentikasi yang dikeluarkan, dan pengguna dapat memilih salah satunya. Untuk mengizinkan beberapa penyedia autentikasi tambahan, mereka harus mengeluarkan beberapa klaim http://schemas.microsoft.com/claims/authnmethodsproviders.

Jika evaluasi klaim tidak mengembalikan penyedia autentikasi, LAYANAN Federasi Direktori Aktif akan kembali menampilkan semua penyedia autentikasi tambahan yang dikonfigurasi oleh admin di Layanan Federasi Direktori Aktif. Pengguna kemudian perlu memilih penyedia autentikasi yang sesuai.

Untuk mengizinkan semua penyedia autentikasi lainnya, admin dapat menggunakan cmdlet (Get-AdfsGlobalAuthenticationPolicy). AdditionalAuthenticationProvider. Nilai http://schemas.microsoft.com/claims/authnmethodsproviders klaim harus menjadi salah satu nama penyedia yang dikembalikan oleh cmdlet yang disebutkan sebelumnya.

Tidak ada dukungan untuk memicu penyedia autentikasi tambahan tertentu jika RP menggunakan Kebijakan Kontrol Akses di Layanan Federasi Direktori Aktif Windows Server 2016 | Microsoft Docs. Saat Anda memindahkan aplikasi dari kebijakan kontrol Akses, Layanan Federasi Direktori Aktif menyalin kebijakan yang sesuai dari Kebijakan Kontrol Akses ke AdditionalAuthenticationRules dan IssuanceAuthorizationRules. Jadi jika admin ingin menggunakan penyedia autentikasi tertentu, mereka dapat menjauh dari tidak menggunakan kebijakan kontrol akses dan kemudian memodifikasi AdditionalAuthenticationRules untuk memicu penyedia autentikasi tertentu.

FAQ

Bagaimana cara mengatasi kesalahan log peristiwa Admin Layanan Federasi Direktori Aktif, "Menerima permintaan Oauth yang tidak valid. Klien 'NAME' dilarang mengakses sumber daya dengan cakupan 'ugs'."?

Ikuti langkah-langkah berikut untuk memulihkan masalah:

  1. Luncurkan konsol manajemen Layanan Federasi Direktori Aktif. Buka Deskripsi Cakupan Layanan>.
  2. Pilih opsi lainnya tentang "Deskripsi Cakupan, dan pilih Tambahkan Deskripsi Cakupan.
  3. Di bawah nama, masukkan "ugs" dan Pilih Terapkan > OK.
  4. Luncurkan PowerShell sebagai Administrator.
  5. Jalankan perintah Get-AdfsApplicationPermission. Cari yang ScopeNames :{openid, aza} memiliki ClientRoleIdentifier. Buat catatan dari ObjectIdentifier.
  6. Jalankan perintah Set-AdfsApplicationPermission -TargetIdentifier <ObjectIdentifier from step 5> -AddScope 'ugs'.
  7. Mulai ulang layanan AD FS.
  8. Pada klien, mulai ulang klien. Anda harus diminta untuk mengonfigurasi Windows Hello untuk Bisnis (WHFB).
  9. Jika jendela konfigurasi tidak muncul, Maka Anda perlu mengumpulkan log jejak dan memecahkan masalah lebih lanjut.

Bisakah saya meneruskan nilai sumber daya sebagai bagian dari nilai cakupan seperti bagaimana permintaan dilakukan terhadap Azure AD?

Dengan Layanan Federasi Direktori Aktif di Server 2019, Anda sekarang dapat meneruskan nilai sumber daya yang disematkan dalam parameter cakupan. Parameter cakupan sekarang dapat diatur sebagai daftar yang dipisahkan spasi di mana setiap entri adalah struktur sebagai sumber daya/cakupan. Misalnya: <create a valid sample request>

Apakah Layanan Federasi Direktori Aktif mendukung ekstensi PKCE?

Layanan Federasi Direktori Aktif di Server 2019 mendukung Proof Key for Code Exchange (PKCE) untuk alur Pemberian Kode Otorisasi OAuth.

Apa yang baru dalam Layanan Federasi Direktori Aktif untuk Windows Server 2016

Jika Anda mencari informasi tentang versi AD FS sebelumnya, lihat artikel berikut ini: Layanan Federasi Direktori Aktif di Windows Server 2012 atau 2012 R2 dan AD FS 2.0.

Layanan Federasi Direktori Aktif menyediakan kontrol akses dan akses menyeluruh di berbagai aplikasi termasuk Office 365, aplikasi SaaS berbasis cloud, dan aplikasi di jaringan perusahaan.

  • Untuk organisasi TI, ini memungkinkan Anda untuk memberikan kontrol akses dan masuk ke aplikasi modern dan warisan pada komputer apa pun, berdasarkan serangkaian kredensial dan kebijakan yang sama.
  • Untuk pengguna, ini menyediakan masuk tanpa hambatan menggunakan kredensial akun yang sama dan familier.
  • Bagi pengembang, ini menyediakan cara mudah untuk mengautentikasi pengguna yang identitasnya tinggal di direktori organisasi sehingga Anda dapat memfokuskan upaya Anda pada aplikasi Anda, bukan autentikasi atau identitas.

Menghilangkan Kata Sandi dari ekstranet

Layanan Federasi Direktori Aktif 2016 memungkinkan tiga opsi baru untuk masuk tanpa kata sandi, memungkinkan organisasi untuk menghindari risiko kompromi jaringan dari kata sandi phished, bocor, atau dicuri.

Masuk dengan autentikasi multifaktor Azure Active Directory

Layanan Federasi Direktori Aktif 2016 dibangun berdasarkan kemampuan autentikasi multifaktor (MFA) Ad FS di Windows Server 2012 R2. Anda sekarang dapat mengizinkan masuk hanya dengan menggunakan kode Autentikasi Multifaktor Azure AD, tanpa terlebih dahulu memasukkan nama pengguna dan kata sandi.

  • Dengan Autentikasi Multifaktor Azure AD sebagai metode autentikasi utama, pengguna diminta untuk nama pengguna dan kode OTP dari aplikasi Azure Authenticator.
  • Dengan Autentikasi Multifaktor Azure AD sebagai metode autentikasi sekunder atau tambahan, pengguna menyediakan kredensial autentikasi utama. Mereka dapat masuk dengan menggunakan Autentikasi Terintegrasi Windows, dengan nama pengguna dan kata sandi, kartu pintar, atau sertifikat pengguna atau perangkat. Kemudian mereka melihat permintaan untuk masuk teks, suara, atau Autentikasi Multifaktor Azure AD berbasis OTP.
  • Dengan adaptor Autentikasi Multifaktor Azure ACTIVE Directory bawaan, penyiapan dan konfigurasi untuk Autentikasi Multifaktor Microsoft Azure AD dengan Layanan Federasi Direktori Aktif tidak pernah lebih sederhana.
  • Organisasi dapat memanfaatkan Autentikasi Multifaktor Azure AD tanpa perlu server Autentikasi Multifaktor Azure AD lokal.
  • Autentikasi Multifaktor Azure AD dapat dikonfigurasi untuk intranet atau ekstranet, atau sebagai bagian dari kebijakan kontrol akses apa pun.

Untuk informasi selengkapnya tentang Autentikasi Multifaktor Azure ACTIVE Directory dengan Layanan Federasi Direktori Aktif, lihat Mengonfigurasi Ad FS 2016 dan Autentikasi Multifaktor Azure AD.

Akses tanpa kata sandi dari perangkat yang sesuai

LAYANAN Federasi Direktori Aktif 2016 dibangun pada kemampuan pendaftaran perangkat sebelumnya untuk mengaktifkan kontrol akses dan masuk berdasarkan status kepatuhan perangkat. Pengguna dapat masuk menggunakan kredensial perangkat, dan kepatuhan dievaluasi kembali saat atribut perangkat berubah sehingga Anda selalu dapat memastikan kebijakan diberlakukan. Fitur ini memungkinkan kebijakan seperti:

  • Aktifkan Akses hanya dari perangkat yang dikelola dan/atau sesuai.
  • Aktifkan Akses Ekstranet hanya dari perangkat yang dikelola dan/atau sesuai.
  • Memerlukan autentikasi multifaktor untuk komputer yang tidak dikelola atau tidak sesuai.

Layanan Federasi Direktori Aktif menyediakan komponen lokal kebijakan akses bersyariah dalam skenario hibrid. Saat Anda mendaftarkan perangkat dengan Microsoft Azure AD untuk akses bersyarah ke sumber daya cloud, identitas perangkat juga dapat digunakan untuk kebijakan Layanan Federasi Direktori Aktif.

Diagram solusi hibrid dan hubungan antara pengguna dan direktori aktif lokal.

Untuk informasi selengkapnya tentang menggunakan akses bersyarah berbasis perangkat di cloud, lihat Akses Bersyar Azure Active Directory.

Untuk informasi selengkapnya tentang menggunakan akses bersyarkat berbasis perangkat dengan Layanan Federasi Direktori Aktif

Masuk dengan Windows Hello untuk Bisnis

Catatan

Saat ini, Google Chrome dan Microsoft Edge baru yang dibangun di browser proyek Chromium sumber terbuka tidak didukung untuk akses menyeluruh (SSO) berbasis browser dengan Windows Hello untuk Bisnis. Gunakan Internet Explorer atau versi Microsoft Edge yang lebih lama.

Perangkat Windows 10 memperkenalkan Windows Hello dan Windows Hello untuk Bisnis, mengganti kata sandi pengguna dengan kredensial pengguna yang terikat perangkat yang kuat yang dilindungi oleh gerakan pengguna (PIN, gerakan biometrik seperti sidik jari, atau pengenalan wajah). Layanan Federasi Direktori Aktif 2016 mendukung kemampuan Windows 10 baru ini sehingga pengguna dapat masuk ke aplikasi Layanan Federasi Direktori Aktif dari intranet atau ekstranet tanpa memberikan kata sandi.

Untuk informasi selengkapnya tentang menggunakan Windows Hello untuk Bisnis di organisasi Anda, lihat Mengaktifkan Windows Hello untuk Bisnis di organisasi Anda.

Akses aman ke aplikasi

Perubahan berikut memengaruhi akses aman ke aplikasi di Layanan Federasi Direktori Aktif.

Autentikasi modern

LAYANAN Federasi Direktori Aktif 2016 mendukung protokol modern terbaru yang memberikan pengalaman pengguna yang lebih baik untuk Windows 10 dan perangkat dan aplikasi iOS dan Android terbaru.

Untuk informasi selengkapnya, lihat Skenario Layanan Federasi Direktori Aktif untuk Pengembang.

Mengonfigurasi kebijakan kontrol akses tanpa harus mengetahui bahasa aturan klaim

Sebelumnya, administrator Layanan Federasi Direktori Aktif harus mengonfigurasi kebijakan dengan menggunakan bahasa aturan klaim Layanan Federasi Direktori Aktif, sehingga sulit untuk mengonfigurasi dan memelihara kebijakan. Dengan kebijakan kontrol akses, administrator dapat menggunakan templat bawaan untuk menerapkan kebijakan umum seperti

  • Izinkan akses intranet saja.
  • Izinkan semua orang dan wajibkan MFA dari Extranet.
  • Izinkan semua orang dan wajibkan MFA dari grup tertentu.

Templat mudah disesuaikan dengan menggunakan proses yang digerakkan wizard untuk menambahkan pengecualian atau aturan kebijakan tambahan dan dapat diterapkan ke satu atau banyak aplikasi untuk penegakan kebijakan yang konsisten.

Untuk informasi selengkapnya, lihat Kebijakan kontrol akses di Layanan Federasi Direktori Aktif.

Mengaktifkan masuk dengan direktori LDAP non-AD

Banyak organisasi memiliki kombinasi Direktori Aktif dan direktori pihak ketiga. Dengan penambahan dukungan Layanan Federasi Direktori Aktif untuk mengautentikasi pengguna yang disimpan dalam direktori yang mematuhi Lightweight Directory Access Protocol (LDAP) v3, Layanan Federasi Direktori Aktif sekarang dapat digunakan untuk:

  • Pengguna di pihak ketiga, direktori yang mematuhi LDAP v3.
  • Pengguna di forest Direktori Aktif tempat kepercayaan dua arah Direktori Aktif tidak dikonfigurasi.
  • Pengguna di Active Directory Lightweight Directory Services (AD LDS).

Untuk informasi selengkapnya, lihat Mengonfigurasi Layanan Federasi Direktori Aktif untuk mengautentikasi pengguna yang disimpan di direktori LDAP.

Pengalaman Masuk yang Lebih Baik

Perubahan berikut meningkatkan pengalaman masuk untuk Layanan Federasi Direktori Aktif.

Menyesuaikan pengalaman masuk untuk aplikasi Layanan Federasi Direktori Aktif

Sebelumnya, Layanan Federasi Direktori Aktif di Windows Server 2012 R2 memberikan pengalaman masuk umum untuk semua aplikasi pihak yang mengandalkan, dengan kemampuan untuk menyesuaikan subset konten berbasis teks per aplikasi. Dengan Windows Server 2016, Anda dapat menyesuaikan tidak hanya pesan, tetapi gambar, logo, dan tema web per aplikasi. Selain itu, Anda dapat membuat tema web kustom baru dan menerapkan tema ini per pihak yang mengandalkan.

Untuk informasi selengkapnya, lihat Kustomisasi masuk pengguna Layanan Federasi Direktori Aktif.

Pengelolaan dan peningkatan operasional

Bagian berikut menjelaskan skenario operasional yang ditingkatkan yang diperkenalkan dengan Layanan Federasi Direktori Aktif di Windows Server 2016.

Audit yang disederhanakan untuk manajemen administratif yang lebih mudah

Di Layanan Federasi Direktori Aktif untuk Windows Server 2012 R2, ada banyak peristiwa audit yang dihasilkan untuk satu permintaan, dan informasi yang relevan tentang aktivitas penerbitan masuk atau token tidak ada atau tersebar di beberapa peristiwa audit. Secara default peristiwa audit Layanan Federasi Direktori Aktif dimatikan karena sifat verbosenya. Dengan rilis Ad FS 2016, audit menjadi lebih efisien dan kurang verbose.

Untuk informasi selengkapnya, lihat Mengaudit penyempurnaan layanan federasi direktori aktif di Windows Server 2016.

Peningkatan interoperabilitas dengan SAML 2.0 untuk partisipasi dalam konfederasi

Layanan Federasi Direktori Aktif 2016 berisi lebih banyak dukungan protokol SAML, termasuk dukungan untuk mengimpor kepercayaan berdasarkan metadata yang berisi beberapa entitas. Perubahan ini memungkinkan Anda mengonfigurasi Layanan Federasi Direktori Aktif untuk berpartisipasi dalam konfederasi seperti InCommon Federation dan implementasi lain yang sesuai dengan standar eGov 2.0.

Untuk informasi selengkapnya, lihat Meningkatkan interoperabilitas dengan SAML 2.0.

Manajemen kata sandi yang disederhanakan untuk pengguna Microsoft 365 federasi

Anda dapat mengonfigurasi Layanan Federasi Direktori Aktif (AD FS) untuk mengirim klaim kedaluwarsa kata sandi ke kepercayaan pihak yang mengandalkan (aplikasi) yang dilindungi oleh Layanan Federasi Direktori Aktif. Bagaimana klaim ini digunakan tergantung pada aplikasi. Misalnya, dengan Office 365 sebagai pihak yang mengandalkan Anda, pembaruan telah diterapkan ke Exchange dan Outlook untuk memberi tahu pengguna federasi tentang kata sandi mereka yang akan segera kedaluwarsa.

Untuk informasi selengkapnya, lihat Mengonfigurasi Layanan Federasi Direktori Aktif untuk mengirim klaim kedaluwarsa kata sandi.

Berpindah dari Layanan Federasi Direktori Aktif di Windows Server 2012 R2 ke Layanan Federasi Direktori Aktif di Windows Server 2016 lebih mudah

Sebelumnya, migrasi ke versi baru Ad FS memerlukan konfigurasi ekspor dari farm lama dan mengimpor ke farm paralel baru.

Sekarang, berpindah dari Layanan Federasi Direktori Aktif pada Windows Server 2012 R2 ke Layanan Federasi Direktori Aktif di Windows Server 2016 menjadi lebih mudah. Tambahkan server Windows Server 2016 baru ke farm Windows Server 2012 R2, dan farm bertindak di tingkat perilaku farm Windows Server 2012 R2. Server Anda sekarang terlihat dan bereaksi seperti farm Windows Server 2012 R2.

Kemudian, tambahkan server Windows Server 2016 baru ke farm, verifikasi fungsionalitas dan hapus server yang lebih lama dari load balancer. Setelah semua simpul farm menjalankan Windows Server 2016, Anda siap untuk meningkatkan tingkat perilaku farm ke 2016 dan mulai menggunakan fitur baru.

Untuk informasi selengkapnya, lihat Memutakhirkan ke Layanan Federasi Direktori Aktif di Windows Server 2016.