Polling untuk Perubahan Menggunakan Kontrol DirSync
Kontrol sinkronisasi direktori Direktori Aktif (DirSync) adalah ekstensi server LDAP yang memungkinkan aplikasi mencari partisi direktori untuk objek yang telah berubah sejak status sebelumnya.
Gunakan kontrol DirSync melalui ADSI dengan menentukan preferensi pencarian ADS_SEARCHPREF_DIRSYNC saat menggunakan IDirectorySearch. Untuk informasi selengkapnya dan contoh kode, lihat Contoh Kode Menggunakan ADS_SEARCHPREF_DIRSYNC. Anda juga dapat melakukan pencarian DirSync menggunakan API LDAP. Berikut ini menjelaskan implementasi ADSI, yang sebagian besar juga berlaku untuk menggunakan LDAP secara langsung, kecuali seperti yang dibahas di akhir topik ini.
Saat Anda melakukan pencarian DirSync, Anda meneruskan elemen data khusus penyedia (cookie) yang mengidentifikasi status direktori pada saat pencarian DirSync sebelumnya. Untuk pencarian pertama, Anda meneruskan cookie null, dan pencarian mengembalikan semua objek yang cocok dengan filter. Pencarian juga mengembalikan cookie yang valid. Simpan cookie di penyimpanan yang sama dengan yang Anda sinkronkan dengan server Direktori Aktif. Pada pencarian berikutnya, dapatkan cookie dari penyimpanan dan teruskan dengan permintaan pencarian. Hasil pencarian sekarang hanya menyertakan objek dan atribut yang telah berubah sejak status sebelumnya yang diidentifikasi oleh cookie. Pencarian juga mengembalikan cookie baru untuk disimpan untuk pencarian berikutnya.
Tabel berikut mencantumkan parameter pencarian yang dapat ditentukan permintaan pencarian klien.
| Parameter | Deskripsi |
|---|---|
| Dasar pencarian | Dasar pencarian DirSync harus menjadi akar partisi direktori, yang dapat menjadi partisi domain, partisi konfigurasi, atau partisi skema. |
| Cakupan | Cakupan pencarian DirSync harus ADS_SCOPE_SUBTREE, yaitu, seluruh subtree partisi. Ketahuilah bahwa untuk pencarian partisi domain, subtree menyertakan kepala, tetapi bukan konten, dari konfigurasi dan partisi skema. Untuk melakukan polling perubahan dalam cakupan yang lebih kecil, gunakan teknik USNChanged alih-alih DirSync. |
| Filter | Anda dapat menentukan filter pencarian yang valid. Untuk pencarian awal dengan cookie null, hasilnya mencakup semua objek yang cocok dengan filter. Untuk pencarian berikutnya dengan cookie yang valid, hasil pencarian hanya menyertakan data untuk objek yang cocok dengan filter dan telah berubah sejak status yang ditunjukkan oleh cookie. Untuk informasi selengkapnya tentang filter pencarian, lihat Membuat Filter Kueri. |
| Atribut | Anda dapat menentukan daftar atribut yang akan dikembalikan saat perubahan terjadi. Untuk setiap objek, hasil awal menyertakan semua atribut yang diminta yang diatur pada objek. Hasil pencarian berikutnya hanya mencakup atribut yang ditentukan yang telah berubah. Atribut yang tidak berubah tidak disertakan dalam hasil pencarian. Dalam implementasi ADSI, hasil pencarian selalu menyertakan objectGUID dan instanceType dari setiap objek. Selain itu, daftar atribut yang ditentukan bertindak sebagai filter tambahan: hasil pencarian awal hanya menyertakan objek yang memiliki setidaknya salah satu atribut yang ditentukan yang ditetapkan; pencarian berikutnya hanya menyertakan objek di mana satu atau beberapa atribut telah berubah (nilai ditambahkan atau dihapus). |
Selain itu, ketahuilah bahwa:
Untuk pencarian inkremental, praktik terbaik adalah mengikat pengontrol domain (DC) yang sama yang digunakan dalam pencarian sebelumnya, yaitu DC yang menghasilkan cookie. Jika DC yang sama tidak tersedia, tunggu hingga, atau ikat ke DC baru dan lakukan sinkronisasi penuh. Simpan nama DNS DC di penyimpanan sekunder dengan cookie.
Anda dapat meneruskan cookie yang dihasilkan oleh satu DC ke DC yang berbeda yang menghosting replika partisi direktori yang sama. Tidak ada kemungkinan bahwa klien akan melewatkan perubahan dengan menggunakan cookie dari satu DC di DC lain. Namun, ada kemungkinan bahwa hasil pencarian dari DC baru dapat mencakup perubahan yang dilaporkan oleh DC lama; dalam beberapa kasus, DC baru dapat mengembalikan semua objek dan atribut, seperti halnya sinkronisasi penuh. Klien hanya harus membuat databasenya konsisten dengan hasil pencarian yang dilaporkan untuk setiap panggilan DirSync tertentu, yaitu, menangani semua hasil bertahap seolah-olah mereka adalah status terbaru. Tidak masalah apakah Anda telah melihat perubahan sebelum atau bahkan kembali ke status sebelumnya karena sinkronisasi inkremental berulang akan bertemu pada konsistensi.
Ada kemungkinan juga DC lain menolak cookie yang dikembalikan dari DC asli. Pencarian menghasilkan kesalahan LDAP di server seperti "0000203D: LdapErr: DSID-xxxxxxxxxx, komentar: Kontrol pemrosesan kesalahan, data 0", dan aplikasi klien dapat menghasilkan kesalahan seperti "System.DirectoryServices.Protocols.DirectoryOperationException: Kesalahan protokol terjadi." Ini mungkin terjadi, misalnya, ketika cookie lebih lama, dan konten internal cookie diperkirakan berbeda ketika diproses oleh server LDAP yang menjalankan versi Windows yang berbeda. Cookie adalah struktur buram dan tidak dijamin konsisten secara struktural di antara semua versi OS Windows. Aplikasi klien harus menangani kasus ini dan mencoba kembali dengan sinkronisasi penuh jika kesalahan ini ditemui.
Ketika objek diganti namanya atau dipindahkan, objek turunannya, jika ada, tidak disertakan dalam hasil pencarian, meskipun nama khusus objek anak telah berubah. Demikian pula, ketika ACE yang dapat diwariskan dimodifikasi dalam deskriptor keamanan objek, objek turunan objek tidak disertakan dalam hasil pencarian, meskipun deskriptor keamanan objek turunan telah berubah.
Gunakan atribut objectGUID untuk mengidentifikasi objek yang dilacak. ObjectGUID dari setiap objek tetap tidak berubah terlepas dari di mana objek dipindahkan di dalam forest.
Ketahuilah bahwa hasil pencarian pencarian DirSync menunjukkan status objek pada replika partisi direktori pada saat pencarian. Ini berarti bahwa perubahan yang dilakukan pada DC lain tidak akan disertakan jika belum direplikasi ke DC target. Ini juga berarti bahwa atribut objek mungkin telah berubah beberapa kali sejak pencarian DirSync sebelumnya, tetapi pencarian hanya akan menampilkan status akhir, bukan urutan perubahan.
Dalam implementasi ADSI, aplikasi harus menangani cookie sebagai buram dan tidak membuat asumsi tentang organisasi atau nilai internalnya.
Ketahuilah bahwa klien menyimpan cookie, panjang cookie, dan nama DNS DC dalam penyimpanan yang sama yang berisi data objek yang disinkronkan. Ini memastikan bahwa cookie dan parameter lainnya tetap sinkron dengan data objek jika penyimpanan pernah dipulihkan dari cadangan.
Untuk mengambil atribut parentGUID, yang dibangun untuk kontrol DirSync, perlu juga meminta atribut nama.
Untuk menggunakan kontrol DirSync, pemanggil harus memiliki hak "direktori dapatkan perubahan" yang ditetapkan pada akar partisi yang sedang dipantau. Secara default, hak ini ditetapkan ke akun Administrator dan LocalSystem pada pengendali domain. Pemanggil juga harus memiliki akses kontrol yang diperluas DS-Replication-Get-Changes. Untuk informasi selengkapnya tentang menerapkan mekanisme pelacakan perubahan untuk aplikasi yang harus berjalan di bawah akun yang tidak memiliki hak ini, lihat Polling untuk Perubahan Menggunakan USNChanged. Untuk informasi selengkapnya tentang hak istimewa, lihat Hak Istimewa.
Mengambil Objek yang Dihapus Dengan Pencarian DirSync
Hasil pencarian ADS_SEARCHPREF_DIRSYNC secara otomatis menyertakan objek yang dihapus (batu nisan) yang cocok dengan filter pencarian yang ditentukan. Namun, filter pencarian yang akan cocok dengan objek saat ditayangkan mungkin tidak cocok dengan objek setelah dihapus. Ini karena batu nisan hanya mempertahankan subset atribut yang ada pada objek asli. Misalnya, Anda biasanya akan menggunakan filter berikut untuk objek pengguna.
(&(objectClass=user)(objectCategory=person))
Atribut objectCategory dihapus saat objek dihapus, sehingga filter di atas tidak akan cocok dengan objek batu nisan apa pun. Sebaliknya, atribut objectClass dipertahankan pada objek batu nisan , sehingga filter "(objectClass=user)" akan cocok dengan objek pengguna yang dihapus.
Daftar atribut yang Anda tentukan dengan pencarian DirSync juga bertindak sebagai filter; hasil pencarian hanya mencakup objek di mana satu atau beberapa atribut yang ditentukan telah berubah sejak pencarian DirSync sebelumnya. Jika daftar atribut tidak menyertakan atribut apa pun yang disimpan di batu nisan, hasil pencarian tidak akan menyertakan batu nisan. Untuk menangani ini, minta semua atribut dengan menentukan daftar atribut null; atau Anda dapat meminta atribut isDeleted , diatur ke TRUE di semua batu nisan. Atribut Tombstone memiliki bit 0x8 yang diatur dalam atribut searchFlags dari definisi attributeSchema .
Untuk informasi selengkapnya, lihat Mengambil Objek yang Dihapus.
Implementasi LDAP dari Kontrol DirSync
Anda juga dapat melakukan pencarian DirSync dengan menggunakan API LDAP dengan kontrol LDAP_SERVER_DIRSYNC_OID . Jika Anda menggunakan LDAP API, tentukan juga kontrol LDAP_SERVER_EXTENDED_DN_OID dan LDAP_SERVER_SHOW_DELETED_OID . Kontrol LDAP_SERVER_EXTENDED_DN_OID menyebabkan pencarian LDAP mengembalikan bentuk yang diperluas dari nama khusus yang mencakup objectGUID dan objectSID untuk objek utama keamanan seperti pengguna, grup, dan komputer. Kontrol LDAP_SERVER_SHOW_DELETED_OID menyebabkan hasil pencarian menyertakan data untuk objek yang dihapus. Ketahuilah bahwa kontrol ini secara otomatis disertakan dalam implementasi ADSI.
Saran dan Komentar
Segera hadir: Sepanjang tahun 2024 kami akan menghentikan penggunaan GitHub Issues sebagai mekanisme umpan balik untuk konten dan menggantinya dengan sistem umpan balik baru. Untuk mengetahui informasi selengkapnya, lihat: https://aka.ms/ContentUserFeedback.
Kirim dan lihat umpan balik untuk