Pembaruan komponen Layanan Direktori

Berlaku untuk: Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows Server 2012 R2, Windows Server 2012

Penulis: Justin Turner, Teknisi Eskalasi Dukungan Senior dengan grup Windows

Catatan

Konten ini ditulis oleh teknisi dukungan pelanggan Microsoft, dan ditujukan untuk administrator berpengalaman dan arsitek sistem yang mencari penjelasan teknis yang lebih dalam tentang fitur dan solusi di Windows Server 2012 R2 daripada topik di TechNet biasanya disediakan. Namun, itu belum mengalami lolos pengeditan yang sama, sehingga beberapa bahasa mungkin tampak kurang dipoles daripada apa yang biasanya ditemukan di TechNet.

Pelajaran ini menjelaskan pembaruan komponen Layanan Direktori di Windows Server 2012 R2.

Apa yang akan Anda Pelajari

Jelaskan pembaruan komponen Layanan Direktori baru berikut ini:

• Jelaskan pembaruan komponen Layanan Direktori baru berikut ini:

  • Tingkat Fungsi domain dan forest

  • Penghentian NTFRS

  • Perubahan Pengoptimal Kueri LDAP

  • 1644 Peningkatan peristiwa

  • Peningkatan throughput Replikasi Direktori Aktif

Tingkat Fungsi domain dan forest

Gambaran Umum

Bagian ini menyediakan pengenalan singkat untuk perubahan tingkat fungsional domain dan forest.

DFL dan FFL baru

Dengan rilis, ada tingkat fungsi domain dan forest baru:

• Tingkat Fungsi forest: Windows Server 2012 R2

• Tingkat Fungsi domain: Windows Server 2012 R2

Tingkat Fungsi domain Windows Server 2012 R2 memungkinkan dukungan untuk hal berikut:

1. Perlindungan sisi DC untuk Pengguna yang Dilindungi

   Pengguna Terproteksi yang mengautentikasi ke domain Windows Server 2012 R2 tidak dapat lagi:

   • Mengautentikasi dengan autentikasi NTLM

   • Menggunakan suite sandi DES atau RC4 dalam praauthentication Kerberos

   • Didelegasikan dengan delegasi yang tidak dibatasi atau dibatasi

   • Memperpanjang tiket pengguna (TGT) di luar masa pakai 4 jam awal

2. Kebijakan Autentikasi

   Kebijakan Direktori Aktif berbasis forest baru yang dapat diterapkan ke akun di domain Windows Server 2012 R2 untuk mengontrol host mana yang dapat masuk dari akun dan menerapkan kondisi kontrol akses untuk autentikasi ke layanan yang berjalan sebagai akun

3. Silo Kebijakan Autentikasi

   Objek Direktori Aktif berbasis forest baru yang dapat membuat hubungan antara pengguna, layanan terkelola, dan akun komputer yang akan digunakan untuk mengklasifikasikan akun untuk kebijakan autentikasi atau untuk isolasi autentikasi.

Lihat Cara Mengonfigurasi Akun yang Dilindungi untuk informasi selengkapnya.

Selain fitur di atas, tingkat fungsional domain Windows Server 2012 R2 memastikan bahwa pengontrol domain apa pun di domain menjalankan Windows Server 2012 R2. Tingkat fungsional forest Windows Server 2012 R2 tidak menyediakan fitur baru apa pun, tetapi memastikan bahwa domain baru yang dibuat di forest akan secara otomatis beroperasi di tingkat fungsional domain Windows Server 2012 R2.

DFL minimum yang diberlakukan pada pembuatan domain baru

Windows Server 2008 DFL adalah tingkat fungsional minimum yang didukung pada pembuatan domain baru.

Catatan

Penghentian FRS dilakukan dengan menghapus kemampuan untuk menginstal domain baru dengan tingkat fungsi domain yang lebih rendah dari Windows Server 2008 dengan Server Manager atau melalui Windows PowerShell.

Menurunkan tingkat fungsi forest dan domain

Tingkat fungsional forest dan domain diatur ke Windows Server 2012 R2 secara default pada domain baru dan pembuatan forest baru tetapi dapat diturunkan menggunakan Windows PowerShell.

Untuk menaikkan atau menurunkan tingkat fungsional forest menggunakan Windows PowerShell, gunakan cmdlet Set-ADForestMode .

Untuk mengatur contoso.com FFL ke mode Windows Server 2008:

Set-ADForestMode -ForestMode Windows2008Forest -Identity contoso.com

Untuk menaikkan atau menurunkan tingkat fungsional domain menggunakan Windows PowerShell, gunakan cmdlet Set-ADDomainMode.

Untuk mengatur contoso.com DFL ke mode Windows Server 2008:

Set-ADDomainMode -DomainMode Windows2008Domain -Identity contoso.com

Promosi DC yang menjalankan Windows Server 2012 R2 sebagai replika tambahan ke domain yang ada yang menjalankan pekerjaan DFL 2003.

Pembuatan domain baru di forest yang sudah ada

ADPREP

Tidak ada operasi forest atau domain baru dalam rilis ini.

File .ldf ini berisi perubahan skema untuk Layanan Pendaftaran Perangkat.

1. Sch59

2. Sch61

3. Sch62

4. Sch63

5. Sch64

6. Sch65

7. Sch67

Folder Kerja:

1. Sch66

MSODS:

1. Sch60

Kebijakan dan Silo Autentikasi

1. Sch68

2. Sch69

Penghentian NTFRS

Gambaran Umum

FRS tidak digunakan lagi di Windows Server 2012 R2. Penghentian FRS dilakukan dengan memberlakukan tingkat fungsi domain minimum (DFL) Windows Server 2008. Penerapan ini hanya ada jika domain baru dibuat menggunakan Manajer Server atau Windows PowerShell.

Anda menggunakan parameter -DomainMode dengan cmdlet Install-ADDSForest atau Install-ADDSDomain untuk menentukan tingkat fungsional domain. Nilai yang didukung untuk parameter ini dapat berupa bilangan bulat yang valid atau nilai string enumerasi yang sesuai. Misalnya, untuk mengatur tingkat mode domain ke Windows Server 2008 R2, Anda dapat menentukan nilai 4 atau "Win2008R2". Saat menjalankan cmdlet ini dari nilai yang valid Server 2012 R2 termasuk yang untuk Windows Server 2008 (3, Win2008) Windows Server 2008 R2 (4, Win2008R2) Windows Server 2012 (5, Win2012) dan Windows Server 2012 R2 (6, Win2012R2). Tingkat fungsi domain tidak boleh lebih rendah dari tingkat fungsi forest, tetapi bisa lebih tinggi. Karena FRS tidak digunakan lagi dalam rilis ini, Windows Server 2003 (2, Win2003) bukan parameter yang dikenali dengan cmdlet ini ketika dijalankan dari Windows Server 2012 R2.

Perubahan Pengoptimal Kueri LDAP

Gambaran Umum

Algoritma pengoptimal kueri LDAP dievaluasi ulang dan dioptimalkan lebih lanjut. Hasilnya adalah peningkatan performa dalam efisiensi pencarian LDAP dan waktu pencarian LDAP dari kueri yang kompleks.

Catatan

Dari Developer:improvements dalam performa pencarian melalui peningkatan dalam pemetaan dari kueri LDAP ke kueri ESE. Filter LDAP di luar tingkat kompleksitas tertentu mencegah pemilihan indeks yang dioptimalkan, yang mengakibatkan penurunan performa secara drastis (1000x atau lebih). Perubahan ini mengubah cara kami memilih indeks untuk kueri LDAP untuk menghindari masalah ini.

Catatan

Perombakan lengkap algoritma pengoptimal kueri LDAP, menghasilkan:

• Waktu pencarian yang lebih cepat
• Keuntungan efisiensi memungkinkan DC untuk melakukan lebih banyak
• Panggilan dukungan yang lebih sedikit mengenai masalah Performa AD
• Kembali di-port ke Windows Server 2008 R2 (KB 2862304)

Latar belakang

Kemampuan untuk mencari Direktori Aktif adalah layanan inti yang disediakan oleh pengendali domain. Layanan dan lini aplikasi bisnis lainnya mengandalkan pencarian Direktori Aktif. Operasi bisnis dapat berhenti jika fitur ini tidak tersedia. Sebagai layanan inti dan sangat digunakan, sangat penting bahwa pengendali domain menangani lalu lintas pencarian LDAP secara efisien. Algoritma pengoptimal kueri LDAP mencoba membuat pencarian LDAP seefisien mungkin dengan memetakan filter pencarian LDAP ke kumpulan hasil yang dapat dipenuhi melalui rekaman yang sudah diindeks dalam database. Algoritma ini dievaluasi kembali dan dioptimalkan lebih lanjut. Hasilnya adalah peningkatan performa dalam efisiensi pencarian LDAP dan waktu pencarian LDAP dari kueri yang kompleks.

Detail perubahan

Pencarian LDAP berisi:

• Lokasi (kepala NC, OU, Objek) dalam hierarki untuk memulai pencarian

• Filter pencarian

• Daftar atribut yang akan dikembalikan

Proses pencarian dapat diringkas sebagai berikut:

1. Sederhanakan filter pencarian jika memungkinkan.

2. Pilih sekumpulan Kunci Indeks yang akan mengembalikan set terkecil yang tercakup.

3. Lakukan satu atau beberapa persimpangan Kunci Indeks, untuk mengurangi set yang tercakup.

4. Untuk setiap rekaman dalam set yang tercakup, evaluasi ekspresi filter serta keamanan. Jika filter mengevaluasi ke TRUE dan akses diberikan, maka kembalikan rekaman ini ke klien.

Pekerjaan pengoptimalan kueri LDAP memodifikasi langkah 2 dan 3, untuk mengurangi ukuran set yang tercakup. Lebih khusus lagi, implementasi saat ini memilih Kunci Indeks duplikat dan melakukan persimpangan redundan.

Perbandingan antara algoritma lama dan baru

Target pencarian LDAP yang tidak efisien dalam contoh ini adalah pengontrol domain Windows Server 2012. Pencarian selesai dalam waktu sekitar 44 detik sebagai akibat dari gagal menemukan indeks yang lebih efisien.

adfind -b dc=blue,dc=contoso,dc=com -f "(| (& (|(cn=justintu) (postalcode=80304) (userprincipalname=justintu@blue.contoso.com)) (|(objectclass=person) (cn=justintu)) ) (&(cn=justintu)(objectclass=person)))" -stats >>adfind.txt

Using server: WINSRV-DC1.blue.contoso.com:389

<removed search results>

Statistics
=====
Elapsed Time: 44640 (ms)
Returned 324 entries of 553896 visited - (0.06%)

Used Filter:
 ( |  ( &  ( |  (cn=justintu)  (postalCode=80304)  (userPrincipalName=justintu@blue.contoso.com) )  ( |  (objectClass=person)  (cn=justintu) ) )  ( &  (cn=justintu)  (objectClass=person) ) )

Used Indices:
 DNT_index:516615:N

Pages Referenced          : 4619650
Pages Read From Disk      : 973
Pages Pre-read From Disk  : 180898
Pages Dirtied             : 0
Pages Re-Dirtied          : 0
Log Records Generated     : 0
Log Record Bytes Generated: 0

Sampel hasil menggunakan algoritma baru

Contoh ini mengulangi pencarian yang sama persis seperti di atas tetapi menargetkan pengontrol domain Windows Server 2012 R2. Pencarian yang sama selesai dalam waktu kurang dari satu detik karena peningkatan dalam algoritma pengoptimal kueri LDAP.

adfind -b dc=blue,dc=contoso,dc=com -f "(| (& (|(cn=justintu) (postalcode=80304) (userprincipalname=dhunt@blue.contoso.com)) (|(objectclass=person) (cn=justintu)) ) (&(cn=justintu)(objectclass=person)))" -stats >>adfindBLUE.txt

Using server: winblueDC1.blue.contoso.com:389

.<removed search results>

Statistics
=====
Elapsed Time: 672 (ms)
Returned 324 entries of 648 visited - (50.00%)

Used Filter:
 ( |  ( &  ( |  (cn=justintu)  (postalCode=80304)  (userPrincipalName=justintu@blue.contoso.com) )  ( |  (objectClass=person)  (cn=justintu) ) )  ( &  (cn=justintu)  (objectClass=person) ) )

Used Indices:
 idx_userPrincipalName:648:N
 idx_postalCode:323:N
 idx_cn:1:N

Pages Referenced          : 15350
Pages Read From Disk      : 176
Pages Pre-read From Disk  : 2
Pages Dirtied             : 0
Pages Re-Dirtied          : 0
Log Records Generated     : 0
Log Record Bytes Generated: 0

• Jika tidak dapat mengoptimalkan pohon:

  • Misalnya: ekspresi di pohon melebihi kolom yang tidak diindeks

  • Merekam daftar indeks yang mencegah pengoptimalan

  • Diekspos melalui pelacakan ETW dan ID peristiwa 1644

    

Untuk mengaktifkan kontrol Statistik di LDP

1. Buka LDP.exe, dan sambungkan dan ikat ke pengendali domain.

2. Pada menu Opsi , pilih Kontrol.

3. Pada kotak dialog Kontrol, perluas menu tarik-turun Muat yang telah ditentukan sebelumnya, pilih Statistik Pencarian lalu pilih OK.

   

4. Pada menu Telusuri , pilih Cari

5. Dalam kotak dialog Pencarian, pilih tombol Opsi .

6. Pastikan kotak centang Diperluas dipilih pada kotak dialog Opsi Pencarian dan pilih OK.

   

Coba Ini: Gunakan LDP untuk mengembalikan statistik kueri

Lakukan hal berikut pada pengontrol domain, atau dari klien atau server yang bergabung dengan domain yang menginstal alat AD DS. Ulangi hal berikut yang menargetkan DC Windows Server 2012 dan DC Windows Server 2012 R2 Anda.

1. Tinjau artikel "Membuat Aplikasi berkemampuan Microsoft AD yang Lebih Efisien" dan rujuk kembali sesuai kebutuhan.

2. Menggunakan LDP, aktifkan statistik pencarian (lihat Untuk mengaktifkan kontrol Statistik di LDP)

3. Lakukan beberapa pencarian LDAP dan amati informasi statistik di bagian atas hasil. Anda akan mengulangi pencarian yang sama di aktivitas lain sehingga dokumentasikan dalam file teks notepad.

4. Melakukan pencarian LDAP yang harus dapat dioptimalkan oleh pengoptimal kueri karena indeks atribut

5. Coba buat pencarian yang membutuhkan waktu lama untuk diselesaikan (Anda mungkin ingin meningkatkan opsi Batas waktu sehingga pencarian tidak habis).

Sumber Daya Tambahan

Apa itu Pencarian Direktori Aktif?

Cara Kerja Pencarian Direktori Aktif

Membuat Aplikasi berkemampuan Microsoft Active Directory yang Lebih Efisien

951581 kueri LDAP dijalankan lebih lambat dari yang diharapkan dalam layanan direktori AD atau LDS/ADAM dan ID Peristiwa 1644 dapat dicatat

1644 Peningkatan peristiwa

Gambaran Umum

Pembaruan ini menambahkan statistik hasil pencarian LDAP tambahan ke ID peristiwa 1644 untuk membantu dalam tujuan pemecahan masalah. Selain itu, ada nilai registri baru yang dapat digunakan untuk mengaktifkan pengelogan pada ambang batas berbasis waktu. Peningkatan ini tersedia di Windows Server 2012 dan Windows Server 2008 R2 SP1 melalui KB 2800945 dan akan tersedia untuk Windows Server 2008 SP2.

Catatan

• Statistik pencarian LDAP tambahan ditambahkan ke ID peristiwa 1644 untuk membantu pemecahan masalah pencarian LDAP yang tidak efisien atau mahal
• Sekarang Anda dapat menentukan Ambang Waktu Pencarian (misalnya. Peristiwa log 1644 untuk pencarian membutuhkan waktu lebih dari 100ms) alih-alih menentukan nilai ambang hasil pencarian Mahal dan Tidak Efisien

Latar belakang

Saat memecahkan masalah performa Direktori Aktif, menjadi jelas bahwa aktivitas pencarian LDAP mungkin berkontribusi pada masalah tersebut. Anda memutuskan untuk mengaktifkan pengelogan sehingga Anda dapat melihat kueri LDAP yang mahal atau tidak efisien yang diproses oleh pengendali domain. Untuk mengaktifkan pengelogan, Anda harus mengatur nilai diagnostik Rekayasa Bidang dan dapat secara opsional menentukan nilai ambang batas hasil pencarian yang mahal/tidak efisien. Setelah mengaktifkan tingkat pengelogan Rekayasa Bidang ke nilai 5, setiap pencarian yang memenuhi kriteria ini dicatat dalam log peristiwa Layanan Direktori dengan ID peristiwa 1644.

Peristiwa berisi:

• IP klien dan port

• Node Awal

• Filter

• Cakupan pencarian

• Pemilihan atribut

• Kontrol server

• Entri yang dikunjungi

• Entri yang dikembalikan

Namun, data kunci hilang dari peristiwa seperti jumlah waktu yang dihabiskan untuk operasi pencarian dan indeks apa (jika ada) yang digunakan.

Statistik pencarian tambahan ditambahkan ke peristiwa 1644

• Indeks yang digunakan

• Halaman yang dirujuk

• Halaman yang dibaca dari disk

• Halaman yang telah dibaca sebelumnya dari disk

• Bersihkan halaman yang dimodifikasi

• Halaman kotor dimodifikasi

• Waktu pencarian

• Atribut Mencegah Pengoptimalan

Nilai registri ambang batas berbasis waktu baru untuk pengelogan peristiwa 1644

Alih-alih menentukan nilai ambang batas hasil pencarian Yang Mahal dan Tidak Efisien, Anda dapat menentukan Ambang Waktu Pencarian. Jika Anda ingin mencatat semua hasil pencarian yang membutuhkan waktu 50 mdtk atau lebih besar, Anda akan menentukan 50 desimal/32 heksa (selain mengatur nilai Rekayasa Bidang).

Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters]
"Search Time Threshold (msecs)"=dword:00000032

Perbandingan ID peristiwa lama dan baru 1644

OLD

BARU

Coba Ini: Gunakan log peristiwa untuk mengembalikan statistik kueri

1. Ulangi hal berikut yang menargetkan DC Windows Server 2012 dan DC Windows Server 2012 R2 Anda. Amati ID peristiwa 1644 di kedua DC setelah setiap pencarian.

2. Menggunakan regedit, aktifkan pengelogan ID peristiwa 1644 menggunakan ambang batas berbasis waktu pada Windows Server 2012 R2 DC dan metode lama pada Windows Server 2012 DC.

3. Lakukan beberapa pencarian LDAP yang melebihi ambang batas dan amati informasi statistik di bagian atas hasil. Gunakan kueri LDAP yang Anda dokumentasikan sebelumnya dan ulangi pencarian yang sama.

4. Lakukan pencarian LDAP yang tidak dapat dioptimalkan oleh pengoptimal kueri karena satu atau beberapa atribut tidak diindeks.

Peningkatan throughput Replikasi Direktori Aktif

Gambaran Umum

Replikasi AD menggunakan RPC untuk transportasi replikasinya. Secara default, RPC menggunakan buffer transmisi 8K dan ukuran paket 5K. Ini memiliki efek bersih di mana instans pengiriman akan mengirimkan tiga paket (sekitar 15K data) dan kemudian harus menunggu perjalanan pulang pergi jaringan sebelum mengirim lebih banyak. Dengan asumsi waktu pulang pergi 3ms, throughput tertinggi akan sekitar 40Mbps, bahkan pada jaringan 1Gbps atau 10 Gbps.

Catatan

• Pembaruan ini menyesuaikan throughput Replikasi AD maksimum dari 40Mbps menjadi sekitar 600 Mbps.

  • Ini meningkatkan ukuran buffer pengiriman RPC yang mengurangi jumlah perjalanan pulang pergi jaringan

• Efeknya akan paling terlihat pada jaringan kecepatan tinggi dan latensi tinggi.

Pembaruan ini meningkatkan throughput maksimum menjadi sekitar 600 Mbps dengan mengubah ukuran buffer pengiriman RPC dari 8K menjadi 256KB. Perubahan ini memungkinkan ukuran jendela TCP tumbuh melebihi 8K, mengurangi jumlah perjalanan pulang pergi jaringan.

Catatan

Tidak ada pengaturan yang dapat dikonfigurasi untuk mengubah perilaku ini.

Sumber Daya Tambahan

Cara Kerja Model Replikasi Direktori Aktif