Apa yang menyebabkan Kontroler Domain saya mencatat lusinan upaya otentikasi yang berhasil per detik?

Kami memiliki domain dengan sekitar 15 server dan sekitar 30 workstation. Server sebagian besar 2008r2 dan workstation kebanyakan Windows 7. Kedua DCs adalah 2012r2. Setiap beberapa minggu, salah satu akun admin kami dikunci. Saya mencoba untuk mempersempit penyebabnya dan saya telah menemui jalan buntu.

Inilah yang saya miliki.

Log peristiwa di PDC menunjukkan acara 4776 - keberhasilan audit:

Authentication Package: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0
Logon Account:  username
Source Workstation: 
Error Code: 0x0

Semua untuk nama pengguna yang sama dan berulang beberapa kali dalam satu detik.

Berdasarkan ID peristiwa, ini adalah login NTLM daripada Kerberos. Meskipun jenis otentikasi yang digunakan kurang mengkhawatirkan bagi saya daripada jumlah geser. Ini terjadi beberapa kali per detik dan berulang setiap beberapa detik tanpa batas, sepanjang jam, malam, atau akhir pekan.

Log peristiwa juga menunjukkan audit event ID 4624 (masuk) dan 4634 (masuk) untuk nama pengguna ini, tetapi seperti dalam kejadian di atas bidang "workstation" kosong.

Saya mengaktifkan logging log netlogon dan menunjukkan netlogon.log

02/28 17:11:03 [LOGON] [2044] domain: SamLogon: Transitive Network logon of domain\username from  (via workstation1) Entered
02/28 17:11:03 [LOGON] [2044] domain: SamLogon: Transitive Network logon of domain\username from  (via workstation1) Returns 0x0
02/28 17:11:04 [LOGON] [2044] domain: SamLogon: Transitive Network logon of domain\username from  (via workstation2) Entered
02/28 17:11:04 [LOGON] [2044] domain: SamLogon: Transitive Network logon of domain\username from  (via workstation2) Returns 0x0
02/28 17:11:19 [LOGON] [8468] domain: SamLogon: Transitive Network logon of domain\username from  (via server1) Entered
02/28 17:11:19 [LOGON] [8468] domain: SamLogon: Transitive Network logon of domain\username from  (via server1) Returns 0x0
02/28 17:11:19 [LOGON] [8468] domain: SamLogon: Transitive Network logon of domain\username from  (via server2) Entered
02/28 17:11:19 [LOGON] [8468] domain: SamLogon: Transitive Network logon of domain\username from  (via server2) Returns 0x0
02/28 17:11:19 [LOGON] [2044] domain: SamLogon: Transitive Network logon of domain\username from  (via workstation3) Entered
02/28 17:11:19 [LOGON] [2044] domain: SamLogon: Transitive Network logon of domain\username from  (via workstation3) Returns 0x0
02/28 17:11:19 [LOGON] [2044] domain: SamLogon: Transitive Network logon of domain\username from  (via workstation2) Entered
02/28 17:11:19 [LOGON] [2044] domain: SamLogon: Transitive Network logon of domain\username from  (via workstation2) Returns 0x0
02/28 17:11:19 [LOGON] [5476] domain: SamLogon: Transitive Network logon of domain\username from  (via workstation4) Entered
02/28 17:11:19 [LOGON] [8468] domain: SamLogon: Transitive Network logon of domain\username from  (via workstation5) Entered
02/28 17:11:19 [LOGON] [5476] domain: SamLogon: Transitive Network logon of domain\username from  (via workstation4) Returns 0x0
02/28 17:11:19 [LOGON] [8468] domain: SamLogon: Transitive Network logon of domain\username from  (via workstation5) Returns 0x0
02/28 17:11:20 [LOGON] [5476] domain: SamLogon: Transitive Network logon of domain\username from  (via server3) Entered
02/28 17:11:20 [LOGON] [5476] domain: SamLogon: Transitive Network logon of domain\username from  (via server3) Returns 0x0
02/28 17:11:20 [LOGON] [5476] domain: SamLogon: Transitive Network logon of domain\username from  (via server4) Entered
02/28 17:11:20 [LOGON] [5476] domain: SamLogon: Transitive Network logon of domain\username from  (via server4) Returns 0x0

Dan seterusnya dan seterusnya. Sumber yang jelas dari login ini (melalui XYZ) dapat mencakup workstation dan server dari seluruh jaringan.

Jelas ini terlihat seperti otomatisasi atau skrip. Karena proses masuk secara umum semuanya berhasil, saya tidak percaya ini merupakan upaya intrusi. Namun, beberapa login gagal dari waktu ke waktu, tetapi saya belum mengidentifikasi pola kegagalan tersebut dan jarang terjadi sehingga (hampir setiap hari) mereka tidak mengunci akun. Kode kegagalan ketika ada biasanya 0xc0000022 (Akses Ditolak)

Saya telah menonaktifkan dan menghapus agen pemantauan jarak jauh kami (saat ini Kaseya, tapi kami akhirnya pindah ke LabTech) dari salah satu server, tetapi masih melihat peristiwa baru yang berasal dari server itu, jadi ini mengesampingkan tugas otomatisasi. Saya juga telah memeriksa penjadwal tugas pada beberapa server dan tidak menemukan yang luar biasa. Saya telah memeriksa layanan untuk memverifikasi akun masuk dan akun ini tidak digunakan dalam layanan apa pun.

Saya menjalankan Netstat untuk waktu yang lama dan terutama melihat koneksi ke PDC dari "System" dan "System Idle Process". Saya memang melihat koneksi sesekali dari spoolsrv dan lsass dan ismserv (server yang saya uji adalah server Citrix XenApp, tetapi server "sumber" lainnya tidak ada di farm XenApp, dan tentu saja workstation "sumber" juga tidak ada). Saya menghentikan layanan spooler cetak hanya untuk menguji dan tidak berdampak pada peristiwa masuk.

Saya bekerja di MSP dan ini adalah akun admin dom teknisi utama kami, jadi ini prioritas tinggi agar berfungsi dan aman. Gagasan terakhir yang saya miliki adalah mengubah kata sandi dan melihat apa yang rusak, tetapi tanpa mengetahui akun apa yang sedang digunakan untuk hal ini dapat memiliki konsekuensi yang berpotensi menimbulkan bencana. Namun, kecurigaan saya adalah bahwa ini mungkin hanya AD yang salah konfigurasi.

Adakah yang pernah mengalami hal seperti ini sebelumnya dan dapat mengidentifikasi sumbernya?

active-directory windows-server-2008-r2 windows-server-2012-r2

— Thomas
sumber

Bagi siapa pun yang ingin tahu tentang tingginya jumlah server, mereka memiliki server XenApp dengan SharePoint menghadap publik untuk tenaga kerja yang sangat mobile dengan BYOD. Mereka juga memiliki staf TI sebelumnya yang sedikit berlebihan dalam infrastruktur mereka untuk ukuran bisnis mereka. Karena mereka mengontrak kami, kami telah berusaha sedikit merampingkannya menjadi sesuatu yang lebih sesuai dengan kebutuhan mereka.

— Thomas

Sesuatu yang mungkin Anda coba adalah menginstal Microsoft Network Monitor di salah satu server, mulai menangkap, menunggu entri dari server untuk masuk ke log netlogon dan kemudian melihat menangkap dan melihat apakah Anda dapat menemukan percakapan di Monitor Jaringan . Monitor Jaringan harus menunjukkan kepada Anda proses yang bertanggung jawab untuk percakapan. Jika itu tidak mempersempitnya, Anda dapat menggunakan Monitor Jaringan bersama dengan Monitor Proses untuk mengidentifikasi proses yang bertanggung jawab.

— joeqwerty

Microsoft Network Monitor sudah usang dan diganti oleh Microsoft Message Analyzer. Kesepakatan yang sama seperti Wireshark. Saya menjalankan paket capture dan sama sekali tidak menemukan hal yang membantu. Satu-satunya peristiwa yang berkorelasi erat dengan peristiwa NetLogon adalah koneksi WMI dan RPC.

— Thomas

Benar, NetMon sudah usang tetapi masih merupakan alat yang bagus. Jika Anda belum pernah menggunakan Message Analyzer sebelum itu bisa sedikit berlebihan. NetMon cukup sederhana dan intuitif. Saya biasanya menggunakannya sebelum hal lain. - Mengenai penangkapan Anda, lalu lintas RPC mungkin menyimpan beberapa petunjuk.

— joeqwerty

Ya tidak apa-apa. Ada satu MSRPC Bind yang dikirim dan Ack diterima untuk membangun sesi terenkripsi diikuti oleh paket NRPC yang dikirim dan diterima yang berisi Permintaan dan Respons NetrLogonSamLogonEx, dua yang terakhir dienkripsi. Proses panggilan pada komputer sumber adalah LSASS, yang menjalankan layanan Netlogon. Tidak ada detail yang berguna sama sekali dalam data paket lalu lintas Bind dan tentu saja paket yang dienkripsi tidak berguna bagi saya.

— Thomas

Saya merekomendasikan lebih lanjut mengaktifkan audit NTLM di DC Anda. Menggunakan Kebijakan Pengontrol Domain Default, aktifkan pengaturan kebijakan berikut:

Keamanan jaringan: Batasi NTLM: Audit Lalu Lintas Masuk = Aktifkan audit untuk semua akun Keamanan jaringan: Batasi NTLM: Audit otentikasi NTLM dalam domain ini = Aktifkan semua Keamanan jaringan: Batasi NTLM: Lalu lintas NTLM yang keluar ke server jauh = Audit Semua

https://support.symantec.com/en_US/article.HOWTO79508.html

https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/jj865682(v=ws.10)

Setelah diaktifkan, Arahkan di penampil acara Anda ke: Aplikasi dan Log Layanan> Microsoft> Windows> NTLM> Operasional

Akan ada acara dengan cap waktu yang cocok dengan cap waktu acara netlogon Anda. Log ini akan mengungkapkan Nama Workstation yang sebenarnya.

Dan khusus untuk membantu Anda mengidentifikasi lebih jauh sumbernya, Nama Saluran Aman di log ini akan membantu mempersempit proses awal.

— Homebrew Hops
sumber

Terima kasih atas jawabannya. Sayangnya klien khusus ini bukan lagi pelanggan kami, jadi saya tidak dapat mencoba instruksi Anda. Saya telah maju dan menerima jawaban Anda, karena pemahaman saya sendiri tentang AD memberi tahu saya bahwa harus memberi saya perincian yang saya butuhkan. (Tidak yakin mengapa saya tidak berpikir untuk menyesuaikan kebijakan audit, tetapi Anda beralasan untuk menyarankannya.)

— Thomas