Akun Layanan Direktori untuk Microsoft Defender untuk Identitas

Artikel
06/06/2024

Artikel ini menjelaskan cara Microsoft Defender untuk Identitas menggunakan Akun Layanan Direktori (DSA).

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. Catatan: Kueri SAM-R untuk potensi jalur gerakan lateral tidak didukung dalam skenario ini. Kueri LDAP hanya dalam domain yang diinstal sensor. Kueri ke domain lain di forest atau lintas forest yang sama akan gagal.	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, seperti emea.contoso.com.
Sensor mencari kecocokan antara nama domain DNS domain target, seperti emea.contoso.com dan DSA entri reguler DSA, seperti emea.contoso.com
Sensor mencari kecocokan dalam nama DNS akar domain target, seperti emea.contoso.com dan nama domain entri GMSA DSA, seperti contoso.com.
Sensor mencari kecocokan dalam nama DNS akar domain target, seperti emea.contoso.com dan nama domain entri reguler DSA, seperti contoso.com.
Sensor mencari nama domain target untuk domain saudara, seperti emea.contoso.com dan nama domain entri GMSA DSA, seperti apac.contoso.com.
Sensor mencari nama domain target untuk domain saudara, seperti emea.contoso.com dan nama domain entri reguler DSA, seperti apac.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.

Langkah selanjutnya

Mengonfigurasi Akun Layanan Direktori untuk Defender for Identity dengan gMSA »

Bagikan melalui