Apa yang baru di Active Directory Federation Services

  • Artikel
  • 18 menit untuk membaca

Apa yang baru dalam Active Directory Federation Services untuk Windows Server 2019

Login Terproteksi

Berikut ini adalah ringkasan singkat pembaruan untuk login terlindungi yang tersedia di Layanan Federasi Direktori Aktif 2019:

  • Penyedia Autentikasi Eksternal sebagai Utama - 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 yang dapat diklaim MFA.
  • Autentikasi Kata Sandi sebagai Autentikasi tambahan - Pelanggan memiliki opsi dalam kotak yang didukung penuh untuk menggunakan kata sandi hanya untuk faktor tambahan setelah opsi tanpa kata sandi digunakan sebagai faktor pertama. 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 pra-autentikasi. Ini memudahkan pelanggan untuk menggunakan kecerdasan cloud seperti Perlindungan identitas untuk memblokir login bagi pengguna berisiko atau transaksi berisiko. Untuk informasi selengkapnya, lihat Membangun Plug-in dengan Model Penilaian Risiko AD FS 2019
  • Peningkatan ESL - Meningkatkan ESL QFE pada tahun 2016 dengan menambahkan kemampuan berikut
    • Memungkinkan pelanggan berada dalam mode audit saat dilindungi oleh fungsi penguncian ekstranet 'klasik' yang tersedia sejak Layanan Federasi Direktori Aktif 2012R2. Saat ini pelanggan 2016 tidak akan memiliki perlindungan saat dalam mode audit.
    • Mengaktifkan ambang batas penguncian independen untuk lokasi yang sudah tidak asing lagi. Hal ini memungkinkan beberapa instans aplikasi yang berjalan dengan akun layanan umum untuk menggulirkan kata sandi dengan jumlah dampak paling sedikit.

Peningkatan keamanan tambahan

Peningkatan keamanan tambahan berikut tersedia di Layanan Federasi Direktori Aktif 2019:

  • Remote PowerShell (PSH) menggunakan SmartCard Login - Pelanggan sekarang dapat menggunakan smartcard untuk terhubung dari jarak jauh ke Layanan Federasi Direktori Aktif melalui PSH dan menggunakannya untuk mengelola semua fungsi PSH termasuk cmdlet PSH multi-simpul.
  • Kustomisasi Header HTTP - Pelanggan sekarang dapat menyesuaikan header HTTP yang dipancarkan selama respons AD FS. Ini termasuk header berikut
    • HSTS: 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 Layanan Federasi Direktori Aktif. Ini harus digunakan dengan hati-hati dan hanya pada host HTTPS.
    • Header mendatang: Header tambahan di masa mendatang juga dapat dikonfigurasi.

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

Kapabilitas Autentikasi/Kebijakan

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

  • Tentukan metode autentikasi untuk autentikasi tambahan per RP - Pelanggan sekarang dapat menggunakan aturan klaim untuk memutuskan penyedia autentikasi tambahan mana yang akan dipanggil untuk penyedia autentikasi tambahan. Ini berguna untuk dua kasus penggunaan:
    • Pelanggan beralih dari satu penyedia autentikasi tambahan ke penyedia autentikasi lainnya. Dengan cara ini saat mereka melakukan onboarding 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 TLS hanya untuk aplikasi yang memerlukannya - Pelanggan sekarang dapat membatasi autentikasi perangkat berbasis TLS klien hanya untuk aplikasi yang melakukan akses bersyarat berbasis perangkat. 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 MFA - Layanan Federasi Direktori Aktif sekarang mendukung kemampuan untuk mengulangi kredensial faktor kedua berdasarkan kesegaran kredensial faktor kedua. Hal ini memungkinkan pelanggan untuk melakukan transaksi awal dengan dua faktor dan hanya meminta faktor kedua secara berkala. Ini hanya tersedia untuk aplikasi yang dapat memberikan parameter tambahan dalam permintaan dan bukan pengaturan yang dapat dikonfigurasi di Layanan Federasi Direktori Aktif. Parameter ini didukung oleh Azure AD ketika "Ingat MFA saya untuk X hari" dikonfigurasi dan bendera 'supportsMFA' diatur ke true pada pengaturan kepercayaan domain federasi di Azure AD.

Penyempurnaan SSO masuk

Penyempurnaan SSO masuk 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 untuk memvalidasi dan memberikan pengalaman masuk yang lebih lancar. Layanan Federasi Direktori Aktif sekarang menggunakan UI terpusat (bukan di sisi kanan layar). Anda mungkin memerlukan logo dan gambar latar belakang yang lebih baru untuk menyelaraskan dengan pengalaman ini. Ini juga mencerminkan fungsionalitas yang ditawarkan dalam Azure AD.
  • Perbaikan bug: Status SSO persisten untuk perangkat Win10 saat melakukan autentikasi PRT 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 modern telah ditambahkan ke Layanan Federasi Direktori Aktif 2019:

  • Alur/profil Perangkat Oauth - Layanan Federasi Direktori Aktif sekarang mendukung profil alur perangkat OAuth untuk melakukan login pada perangkat yang tidak memiliki area permukaan UI untuk mendukung pengalaman masuk yang kaya. 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 CORS dalam respons LAYANAN Federasi Direktori Aktif - Pelanggan sekarang dapat membuat Aplikasi Halaman Tunggal yang memungkinkan pustaka JS sisi klien memvalidasi tanda tangan id_token dengan mengkueri kunci penandatanganan dari dokumen penemuan OIDC di LAYANAN Federasi Direktori Aktif.
  • Dukungan PKCE - Layanan Federasi Direktori Aktif menambahkan dukungan PKCE untuk menyediakan alur kode autentikasi yang aman dalam OAuth. Ini menambahkan lapisan keamanan tambahan ke alur ini untuk mencegah pembajakan kode dan memutar ulang dari klien yang berbeda.
  • Perbaikan bug: Kirim klaim x5t dan kid - Ini adalah perbaikan bug kecil. Layanan Federasi Direktori Aktif sekarang juga mengirimkan klaim 'anak' untuk menunjukkan petunjuk id kunci untuk memverifikasi tanda tangan. Sebelumnya Layanan Federasi Direktori Aktif hanya mengirim ini sebagai 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 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:

  • Tingkat Perilaku Farm 2019 - Seperti halnya Layanan Federasi Direktori Aktif 2016, ada versi Tingkat Perilaku Farm baru yang diperlukan untuk mengaktifkan fungsionalitas baru yang dibahas di atas. Hal ini memungkinkan terjadi dari:
    • 2012 R2-> 2019
    • 2016 -> 2019

Pembaruan SAML

Pembaruan SAML berikut 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). Perbaikan telah ada di sekitar hal-hal berikut:
    • Peningkatan penskalaan untuk # entitas besar dalam dokumen metadata federasi agregat. Sebelumnya, ini akan gagal dengan kesalahan "ADMIN0017".
    • Kueri menggunakan parameter 'ScopeGroupID' melalui cmdlet Get-AdfsRelyingPartyTrustsGroup PSH (PowerShell).
    • Menangani kondisi kesalahan di sekitar id entitas duplikat

Azure AD spesifikasi sumber daya gaya 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 umum akan terlihat seperti di bawah ini: 7 https://fs.contoso.com/adfs/oauth2/authorize?
response_type=code& client_id=claimsxrayclientresource&=urn:microsoft:
adfs:claimsxrayscope&=oauth& redirect_uri=https://adfshelp.microsoft.com/
ClaimsXray/TokenResponseprompt&=login

Dengan Layanan Federasi Direktori Aktif di Server 2019, Anda sekarang dapat meneruskan nilai sumber daya yang disematkan dalam parameter cakupan. 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, Layanan Federasi Direktori Aktif akan mengembalikan kesalahan dan autentikasi tidak akan 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 parameter tambahan ke Otorisasi OAuth 2.0 dan Permintaan Token Akses.

Proofkey

J. Klien membuat dan merekam rahasia bernama "code_verifier" dan memperoleh versi yang diubah "t(code_verifier)" (disebut sebagai "code_challenge"), yang 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. Kebijakan autentikasi tambahan untuk RP tertentu dapat ditetapkan menggunakan cmdlet Set-AdfsRelyingPartyTrust (AD FS) | Microsoft Docs dengan melewati 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 == "https://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", value == "false"] => issue(type = "https://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", value = "https://schemas.microsoft.com/claims/multipleauthn" );'

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

Pelanggan beralih dari satu penyedia autentikasi tambahan ke penyedia autentikasi lainnya. Dengan cara ini saat mereka melakukan onboarding 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 (AzureMFA) untuk aplikasi lain.

Ini dapat dicapai dengan mengeluarkan klaim https://schemas.microsoft.com/claims/authnmethodsproviders dari kebijakan autentikasi tambahan. Nilai klaim ini haruslah Nama penyedia autentikasi.

Sekarang pada tahun 2019 mereka dapat memodifikasi aturan klaim di atas untuk memilih penyedia autentikasi berdasarkan skenario mereka.

Transisi dari satu penyedia autentikasi tambahan ke penyedia autentikasi lainnya: Kami akan memodifikasi aturan di atas untuk memilih AzureMFA untuk pengguna yang berada di grup SID S-1-5-21-608905689-872870963-3921916988-12345 (misalnya grup yang dikelola oleh perusahaan, yang melacak pengguna yang telah mendaftar untuk AzureMFA) dan untuk pengguna lainnya, admin ingin menggunakan autentikasi sertifikat.

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

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

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

Contoh untuk mengatur dua penyedia autentikasi yang berbeda untuk dua aplikasi yang berbeda.

Aplikasi A untuk menggunakan Azure MFA sebagai penyedia autentikasi tambahan:

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

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

Aplikasi B untuk menggunakan Sertifikat sebagai penyedia autentikasi tambahan:

Set- 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 akan menampilkan semua penyedia metode autentikasi yang dikeluarkan dan pengguna dapat memilih salah satunya. Untuk mengizinkan beberapa penyedia autentikasi tambahan, mereka harus mengeluarkan beberapa klaim https://schemas.microsoft.com/claims/authnmethodsproviders

Jika tidak ada penyedia autentikasi yang dikembalikan oleh evaluasi klaim, Layanan Federasi Direktori Aktif akan kembali untuk menampilkan semua penyedia autentikasi tambahan yang dikonfigurasi oleh Admin di Layanan Federasi Direktori Aktif dan pengguna harus memilih penyedia autentikasi yang sesuai.

Untuk mendapatkan semua penyedia autentikasi tambahan yang diizinkan, admin dapat menggunakan cmdlet (Get-AdfsGlobalAuthenticationPolicy). AdditionalAuthenticationProvider. Nilai https://schemas.microsoft.com/claims/authnmethodsproviders klaim harus menjadi salah satu nama penyedia yang dikembalikan oleh cmdlet di atas.

Tidak ada dukungan untuk memicu penyedia autentikasi tambahan tertentu jika RP menggunakan Kebijakan Access Control di Layanan Federasi Direktori Aktif Windows Server 2016 | Microsoft Docs. Saat memindahkan Aplikasi dari kebijakan kontrol Akses, LAYANAN Federasi Direktori Aktif menyalin kebijakan yang sesuai dari Kebijakan Access Control 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 tambahan tertentu.

FAQ

Catatan

Anda mungkin mengalami kesalahan ini di log peristiwa Admin Layanan Federasi Direktori Aktif: Menerima permintaan Oauth yang tidak valid. Klien 'NAME' dilarang mengakses sumber daya dengan cakupan 'ugs'. Untuk memulihkan kesalahan ini:

  1. Luncurkan konsol manajemen Layanan Federasi Direktori Aktif. Telusuri ke "Deskripsi Cakupan Layanan > "
  2. Klik kanan "Deskripsi Cakupan" dan pilih "Tambahkan Deskripsi Cakupan"
  3. Di bawah nama ketik "ugs" dan Klik Terapkan > OK
  4. Luncurkan PowerShell sebagai Administrator
  5. Jalankan perintah "Get-AdfsApplicationPermission". Cari ScopeNames :{openid, aza} yang memiliki ClientRoleIdentifier. Catat ObjectIdentifier.
  6. Jalankan perintah "Set-AdfsApplicationPermission -TargetIdentifier <ObjectIdentifier dari langkah 5> -AddScope 'ugs'
  7. Mulai ulang layanan AD FS.
  8. Pada klien: Mulai ulang klien. Pengguna harus diminta untuk menyediakan WHFB.
  9. Jika jendela provisi tidak muncul, maka perlu mengumpulkan log jejak NGC dan memecahkan masalah lebih lanjut.

T. Dapatkah saya meneruskan nilai sumber daya sebagai bagian dari nilai cakupan seperti bagaimana permintaan dilakukan terhadap Azure AD?
J. 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: < membuat permintaan> sampel yang valid

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

Apa yang baru dalam Active Directory Federation Services untuk Windows Server 2016

Jika Anda mencari informasi tentang versi LAYANAN Federasi Direktori Aktif yang lebih lama, lihat artikel berikut ini: Layanan Federasi Direktori Aktif di Windows Server 2012 atau 2012 R2 dan Layanan Federasi Direktori Aktif 2.0

Active Directory Federation Services 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 masuk dan akses ke aplikasi modern dan warisan, lokal dan di cloud, 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 berada di direktori organisasi sehingga Anda dapat memfokuskan upaya Anda pada aplikasi Anda, bukan autentikasi atau identitas.

Artikel ini menjelaskan apa yang baru dalam Layanan Federasi Direktori Aktif di Windows Server 2016 (Layanan Federasi Direktori Aktif 2016).

Menghilangkan Kata Sandi dari Ekstranet

Layanan Federasi Direktori Aktif 2016 memungkinkan tiga opsi baru untuk masuk tanpa kata sandi, memungkinkan organisasi menghindari risiko penyusupan jaringan dari kata sandi yang di-phish, bocor, atau dicuri.

Masuk dengan Azure Multi-Factor Authentication

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

  • Dengan Azure MFA sebagai metode autentikasi utama, pengguna dimintai nama pengguna dan kode OTP dari aplikasi Azure Authenticator.
  • Dengan Azure MFA sebagai metode autentikasi sekunder atau tambahan, pengguna menyediakan kredensial autentikasi utama (menggunakan Autentikasi Terpadu Windows, nama pengguna dan kata sandi, kartu pintar, atau sertifikat pengguna atau perangkat), lalu melihat permintaan untuk masuk teks, suara, atau MFA Azure berbasis OTP.
  • Dengan adaptor Azure MFA bawaan baru, penyiapan dan konfigurasi untuk Azure MFA dengan Layanan Federasi Direktori Aktif tidak pernah lebih sederhana.
  • Organisasi dapat memanfaatkan Azure MFA tanpa perlu server Azure MFA lokal.
  • Azure MFA dapat dikonfigurasi untuk intranet atau ekstranet, atau sebagai bagian dari kebijakan kontrol akses apa pun.

Untuk informasi selengkapnya tentang Azure MFA dengan Layanan Federasi Direktori Aktif

Akses Tanpa Kata Sandi dari Perangkat yang Sesuai

Layanan Federasi Direktori Aktif 2016 dibangun pada kemampuan pendaftaran perangkat sebelumnya untuk mengaktifkan kontrol masuk dan akses 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. 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 dari kebijakan akses bersyariah dalam skenario hibrid. Saat Anda mendaftarkan perangkat dengan Azure AD untuk akses bersuhidan ke sumber daya cloud, identitas perangkat juga dapat digunakan untuk kebijakan Layanan Federasi Direktori Aktif.

whats new

Untuk informasi selengkapnya tentang menggunakan akses bersyarkala berbasis perangkat di cloud

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 Chromium sumber terbuka browser proyek tidak didukung untuk akses menyeluruh (SSO) berbasis browser dengan Windows Hello untuk Bisnis. Gunakan Internet Explorer atau versi Microsoft Edge yang lebih lama.

Windows 10 perangkat memperkenalkan Windows Hello dan Windows Hello untuk Bisnis, mengganti kata sandi pengguna dengan info masuk 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 perlu memberikan kata sandi.

Untuk informasi selengkapnya tentang menggunakan Windows Hello untuk Bisnis di organisasi Anda

Akses Aman ke Aplikasi

Autentikasi Modern

Layanan Federasi Direktori Aktif 2016 mendukung protokol modern terbaru yang memberikan pengalaman pengguna yang lebih baik untuk Windows 10 serta 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 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
  • Mengizinkan semua orang dan memerlukan MFA dari Ekstranet
  • Mengizinkan semua orang dan mewajibkan MFA dari grup tertentu

Templat mudah disesuaikan menggunakan proses berbasis 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 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 Active Directory 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

Menyesuaikan pengalaman masuk untuk aplikasi Layanan Federasi Direktori Aktif

Kami mendengar dari Anda bahwa kemampuan untuk menyesuaikan pengalaman masuk untuk setiap aplikasi akan menjadi peningkatan kegunaan yang bagus, terutama bagi organisasi yang menyediakan masuk untuk aplikasi yang mewakili beberapa perusahaan atau merek yang berbeda.

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 tidak hanya dapat menyesuaikan pesan, tetapi juga gambar, logo, dan tema web per aplikasi. Selain itu, Anda dapat membuat tema web kustom baru dan menerapkannya 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 Active Directory Federation Services di Windows Server 2016.

Audit yang disederhanakan untuk manajemen administratif yang lebih mudah

Dalam 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 (dalam beberapa versi AD FS) atau tersebar di beberapa peristiwa audit. Secara default, peristiwa audit Layanan Federasi Direktori Aktif dimatikan karena sifat verbose-nya. Dengan dirilisnya Layanan Federasi Direktori Aktif 2016, audit menjadi lebih efisien dan kurang verbose.

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

Peningkatan interoperabilitas dengan SAML 2.0 untuk partisipasi dalam konfederasi

Layanan Federasi Direktori Aktif 2016 berisi dukungan protokol SAML tambahan, termasuk dukungan untuk mengimpor kepercayaan berdasarkan metadata yang berisi beberapa entitas. Ini memungkinkan Anda mengonfigurasi Layanan Federasi Direktori Aktif untuk berpartisipasi dalam konfederasi seperti Federasi InCommon 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 O365 federasi

Anda dapat mengonfigurasi Active Directory Federation Services (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 di Windows Server 2012 R2 ke Layanan Federasi Direktori Aktif di Windows Server 2016 menjadi jauh lebih mudah. Cukup tambahkan server Windows Server 2016 baru ke farm Windows Server 2012 R2, dan farm akan bertindak di tingkat perilaku farm Windows Server 2012 R2, sehingga terlihat dan berperilaku 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 berjalan 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.