Akun Layanan Direktori untuk Microsoft Defender untuk Identitas
Artikel ini menjelaskan cara Microsoft Defender untuk Identitas menggunakan Akun Layanan Direktori (DSA).
Catatan
Terlepas dari Akun Layanan Direktori yang dikonfigurasi, layanan sensor akan beroperasi di bawah identitas LocalService, dan layanan updater akan beroperasi di bawah identitas LocalSystem.
Meskipun DSA bersifat opsional dalam beberapa skenario, kami sarankan Anda mengonfigurasi DSA untuk Defender for Identity untuk cakupan keamanan penuh.
Misalnya, ketika Anda memiliki DSA yang dikonfigurasi, DSA digunakan untuk menyambungkan ke pengontrol domain saat startup. DSA juga dapat digunakan untuk mengkueri pengendali domain untuk data pada entitas yang terlihat dalam lalu lintas jaringan, peristiwa yang dipantau, dan aktivitas ETW yang dipantau
DSA diperlukan untuk fitur dan fungsionalitas berikut:
Saat bekerja dengan sensor yang diinstal pada server AD FS / AD CS.
Meminta daftar anggota untuk grup administrator lokal dari perangkat yang terlihat dalam lalu lintas jaringan, peristiwa, dan aktivitas ETW melalui panggilan SAM-R yang dilakukan ke perangkat. Data yang dikumpulkan digunakan untuk menghitung potensi jalur pergerakan lateral.
Mengakses kontainer DeletedObjects untuk mengumpulkan informasi tentang pengguna dan komputer yang dihapus.
Pemetaan domain dan kepercayaan, yang terjadi pada startup sensor, dan sekali lagi setiap 10 menit.
Mengkueri domain lain melalui LDAP untuk detailnya, saat mendeteksi aktivitas dari entitas di domain lain tersebut.
Saat Anda menggunakan satu DSA, DSA harus memiliki izin Baca ke semua domain di forest. Dalam lingkungan multi-forest yang tidak tepercaya, akun DSA diperlukan untuk setiap forest.
Satu sensor di setiap domain didefinisikan sebagai penyinkron domain, dan bertanggung jawab untuk melacak perubahan pada entitas di domain. Misalnya, perubahan mungkin mencakup objek yang dibuat, atribut entitas yang dilacak oleh Defender untuk Identitas, dan sebagainya.
Catatan
Secara default, Defender for Identity mendukung hingga 30 kredensial. Untuk menambahkan lebih banyak kredensial, hubungi dukungan Defender for Identity.
Opsi akun DSA yang didukung
Defender for Identity mendukung opsi DSA berikut:
Opsi | Deskripsi | Konfigurasi |
---|---|---|
Akun Layanan Terkelola Grup gMSA (Disarankan) | Menyediakan penyebaran dan manajemen kata sandi yang lebih aman. Direktori Aktif mengelola pembuatan dan rotasi kata sandi akun, sama seperti kata sandi akun komputer, dan Anda dapat mengontrol seberapa sering kata sandi akun diubah. | Untuk informasi selengkapnya, lihat Mengonfigurasi Akun Layanan Direktori untuk Defender untuk Identitas dengan gMSA. |
Akun pengguna reguler | Mudah digunakan saat memulai, dan lebih sederhana untuk mengonfigurasi izin Baca antara forest tepercaya, tetapi memerlukan overhead ekstra untuk manajemen kata sandi. Akun pengguna reguler kurang aman, karena mengharuskan Anda untuk membuat dan mengelola kata sandi, dan dapat menyebabkan waktu henti jika kata sandi kedaluwarsa dan tidak diperbarui untuk pengguna dan DSA. |
Buat akun baru di Direktori Aktif untuk digunakan sebagai DSA dengan izin Baca ke semua objek, termasuk izin ke kontainer DeletedObjects . Untuk informasi selengkapnya, lihat Memberikan izin DSA yang diperlukan. |
Akun layanan lokal | Akun layanan Lokal digunakan di luar kotak dan digunakan secara default ketika tidak ada DSA yang dikonfigurasi. Nota: |
Tidak ada |
Catatan
Meskipun akun layanan lokal digunakan dengan sensor secara default, dan DSA bersifat opsional dalam beberapa skenario, kami sarankan Anda mengonfigurasi DSA untuk Defender for Identity untuk cakupan keamanan penuh.
Penggunaan entri DSA
Bagian ini menjelaskan bagaimana entri DSA digunakan, dan bagaimana sensor memilih entri DSA dalam skenario tertentu. Upaya sensor berbeda, tergantung pada jenis entri DSA:
Tipe | Deskripsi |
---|---|
akun gMSA | Sensor mencoba mengambil kata sandi akun gMSA dari Direktori Aktif, lalu masuk ke domain. |
Akun pengguna reguler | Sensor mencoba masuk ke domain menggunakan nama pengguna dan kata sandi yang dikonfigurasi. |
Logika berikut diterapkan:
Sensor mencari entri dengan kecocokan nama domain yang tepat untuk domain target. Jika kecocokan yang tepat ditemukan, sensor mencoba mengautentikasi menggunakan kredensial dalam entri tersebut.
Jika tidak ada kecocokan yang tepat, atau jika autentikasi gagal, sensor mencari daftar untuk entri ke domain induk menggunakan DNS FQDN, dan mencoba mengautentikasi menggunakan kredensial di entri induk sebagai gantinya.
Jika tidak ada entri untuk domain induk, atau jika autentikasi gagal, sensor mencari daftar untuk entri domain saudara, menggunakan DNS FQDN, dan mencoba mengautentikasi menggunakan kredensial dalam entri saudara sebagai gantinya.
Jika tidak ada entri untuk domain saudara, atau jika autentikasi gagal, sensor meninjau daftar lagi dan mencoba mengautentikasi lagi dengan setiap entri hingga berhasil. Entri GMSA DSA memiliki prioritas yang lebih tinggi daripada entri DSA reguler.
Logika sampel dengan DSA
Bagian ini memberikan contoh bagaimana sensor mencoba seluruh DSA saat Anda memiliki beberapa akun, termasuk akun gMSA dan akun reguler.
Logika berikut diterapkan:
Sensor mencari kecocokan antara nama domain DNS domain target, seperti
emea.contoso.com
dan entri DSA gMSA, sepertiemea.contoso.com
.Sensor mencari kecocokan antara nama domain DNS domain target, seperti
emea.contoso.com
dan DSA entri reguler DSA, sepertiemea.contoso.com
Sensor mencari kecocokan dalam nama DNS akar domain target, seperti
emea.contoso.com
dan nama domain entri GMSA DSA, seperticontoso.com
.Sensor mencari kecocokan dalam nama DNS akar domain target, seperti
emea.contoso.com
dan nama domain entri reguler DSA, seperticontoso.com
.Sensor mencari nama domain target untuk domain saudara, seperti
emea.contoso.com
dan nama domain entri GMSA DSA, sepertiapac.contoso.com
.Sensor mencari nama domain target untuk domain saudara, seperti
emea.contoso.com
dan nama domain entri reguler DSA, sepertiapac.contoso.com
.Sensor menjalankan round robin dari semua entri DSA gMSA.
Sensor menjalankan round robin dari semua entri reguler DSA.
Logika yang ditampilkan dalam contoh ini diimplementasikan dengan konfigurasi berikut:
Entri DSA:
DSA1.emea.contoso.com
DSA2.fabrikam.com
Sensor dan entri DSA yang digunakan terlebih dahulu:
Pengendali domain FQDN Entri DSA yang digunakan DC01.emea.contoso.com
DSA1.emea.contoso.com
DC02.contoso.com
DSA1.emea.contoso.com
DC03.fabrikam.com
DSA2.fabrikam.com
DC04.contoso.local
Round robin
Penting
Jika sensor tidak berhasil mengautentikasi melalui LDAP ke domain Direktori Aktif saat startup, sensor tidak akan memasuki status berjalan dan masalah kesehatan dihasilkan. Untuk informasi selengkapnya, lihat Masalah kesehatan Defender for Identity.
Memberikan izin DSA yang diperlukan
DSA memerlukan izin baca saja pada semua objek di Direktori Aktif, termasuk Kontainer Objek Yang Dihapus.
Izin baca-saja pada kontainer Objek Yang Dihapus memungkinkan Defender untuk Identitas mendeteksi penghapusan pengguna dari Direktori Aktif Anda.
Gunakan sampel kode berikut untuk membantu Anda memberikan izin baca yang diperlukan pada kontainer Objek Terhapus , baik Anda menggunakan akun gMSA atau tidak.
Tip
Jika DSA yang ingin Anda berikan izinnya adalah Akun Layanan Terkelola Grup (gMSA), Anda harus terlebih dahulu membuat grup keamanan, menambahkan gMSA sebagai anggota, dan menambahkan izin ke grup tersebut. Untuk informasi selengkapnya, lihat Mengonfigurasi Akun Layanan Direktori untuk Defender untuk Identitas dengan gMSA.
# Declare the identity that you want to add read access to the deleted objects container:
$Identity = 'mdiSvc01'
# If the identity is a gMSA, first to create a group and add the gMSA to it:
$groupName = 'mdiUsr01Group'
$groupDescription = 'Members of this group are allowed to read the objects in the Deleted Objects container in AD'
if(Get-ADServiceAccount -Identity $Identity -ErrorAction SilentlyContinue) {
$groupParams = @{
Name = $groupName
SamAccountName = $groupName
DisplayName = $groupName
GroupCategory = 'Security'
GroupScope = 'Universal'
Description = $groupDescription
}
$group = New-ADGroup @groupParams -PassThru
Add-ADGroupMember -Identity $group -Members ('{0}$' -f $Identity)
$Identity = $group.Name
}
# Get the deleted objects container's distinguished name:
$distinguishedName = ([adsi]'').distinguishedName.Value
$deletedObjectsDN = 'CN=Deleted Objects,{0}' -f $distinguishedName
# Take ownership on the deleted objects container:
$params = @("$deletedObjectsDN", '/takeOwnership')
C:\Windows\System32\dsacls.exe $params
# Grant the 'List Contents' and 'Read Property' permissions to the user or group:
$params = @("$deletedObjectsDN", '/G', ('{0}\{1}:LCRP' -f ([adsi]'').name.Value, $Identity))
C:\Windows\System32\dsacls.exe $params
# To remove the permissions, uncomment the next 2 lines and run them instead of the two prior ones:
# $params = @("$deletedObjectsDN", '/R', ('{0}\{1}' -f ([adsi]'').name.Value, $Identity))
# C:\Windows\System32\dsacls.exe $params
Untuk informasi selengkapnya, lihat Mengubah izin pada kontainer objek yang dihapus.
Menguji izin dan delegasi DSA Anda melalui PowerShell
Gunakan perintah PowerShell berikut untuk memverifikasi bahwa DSA Anda tidak memiliki terlalu banyak izin, seperti izin admin yang kuat:
Test-MDIDSA [-Identity] <String> [-Detailed] [<CommonParameters>]
Misalnya, untuk memeriksa izin untuk akun mdiSvc01 dan memberikan detail lengkap, jalankan:
Test-MDIDSA -Identity "mdiSvc01" -Detailed
Untuk informasi selengkapnya, lihat referensi DefenderForIdentity PowerShell.