Siapa Boleh Dial In? Audit msNPAllowDialin Sebelum Akses VPN

Kata laluan betul, akaun berada dalam kumpulan VPN, tetapi sambungan masih ditolak dengan mesej yang tidak menyebut sebarang dasar. Apabila itu berlaku pada pelayan akses jauh Windows, tempat pertama yang saya lihat bukan peraturan NPS tetapi satu atribut Active Directory yang tiada siapa membukanya: msNPAllowDialin, nilai di sebalik tab Dial-in. Ia mempunyai tiga keadaan, dan yang ketiga menyerahkan keputusan secara senyap kepada tempat lain. Selalunya tiada siapa mengubahnya dengan sengaja: akaun itu diklon daripada templat, atau dicipta oleh skrip yang menulis penafian jelas bertahun-tahun lalu dan tidak pernah disemak semula.

Penolakan boleh berlaku sebelum dasar dibaca

Windows menyemak kebenaran dial-in akaun semasa membina keputusan kebenaran, jadi penafian jelas menamatkan perbualan lebih awal. Apa yang dilihat pada klien ialah kegagalan pengesahan umum, kadangkala selepas pertukaran sijil selesai, dan itulah sebabnya orang menghabiskan petang menguji kelayakan yang tidak pernah menjadi masalah.

Kes sebaliknya sama mengelirukan. Akaun yang benderanya tidak pernah ditetapkan boleh berjaya bersambung kerana dasar membenarkannya, kemudian akaun yang sama berhenti bersambung apabila seseorang menyunting peraturan NPS atas sebab yang tidak berkaitan. Tiada satu pun daripada kedua-dua peristiwa itu kelihatan seperti perubahan kebenaran dial-in dari luar.

Tiga keadaan, dan yang ketiga tidak kelihatan

TRUE membenarkan dial-in, FALSE menolaknya, dan NULL bermaksud akaun mewarisi jawapannya daripada dasar akses jauh atau kebenaran NPS. GUI memaparkan keadaan ketiga itu sebagai "Control access through NPS Network Policy", dan ia dibaca seperti kotak semak yang tidak ditanda dan bukannya keputusan.

Sebab itulah mengira pengguna yang dibenarkan daripada konsol hampir tidak memberitahu apa-apa. Akaun warisan boleh dibenarkan hari ini dan ditolak esok tanpa akaun itu disentuh, dan FALSE akaun masih boleh bersambung pada pelayan yang dasarnya ditetapkan untuk mengabaikan sifat dial-in pengguna. Baca atribut dan dasar bersama-sama, jika tidak anda mengaudit separuh keputusan.

Eksport bendera tanpa menggugurkan akaun warisan

Jalankan eksport daripada pengawal domain, atau daripada stesen kerja dengan modul Active Directory, dan simpan fail mentah sebagai bukti dan bukannya menaip semula ringkasan:

Get-ADUser -Filter * -Properties msNPAllowDialin, LastLogonDate |
  Select-Object SamAccountName, Enabled, msNPAllowDialin, LastLogonDate |
  Sort-Object SamAccountName |
  Export-Csv -NoTypeInformation .\dialin.csv

Satu penapis LDAP lebih mudah ditampal ke dalam rekod perubahan. Yang ini hanya memulangkan kebenaran jelas:

dsquery * -Filter "(&(objectCategory=person)(objectClass=user)(msNPAllowDialin=TRUE))" -Attr sAMAccountName

Kemudian pertimbangkan semula tanpa klausa dial-in dan cari akaun yang nilainya tiada. Itulah akaun warisan, biasanya kumpulan terbesar dalam domain, dan melangkaunya menukar audit menjadi senarai beberapa orang yang diingati seseorang untuk dikonfigurasikan secara manual.

Pisahkan bendera daripada akses kumpulan dan kesihatan akaun

Atribut menjawab satu soalan: bolehkah akaun ini dial in. Ia tidak menyatakan apa-apa tentang sama ada orang itu masih bekerja di sini, sama ada akaun itu didayakan, atau sama ada kata laluan dikongsi terletak dalam nota meja bantuan. Pasangkan eksport dengan keadaan didayakan, tarikh log masuk terakhir dan keahlian kumpulan yang memberikan akses kepada pelayan.

Gabungan itulah yang anda tindak balas. Akaun dilumpuhkan dengan TRUE hanyalah bunyi bising. Akaun didayakan dengan TRUE yang tidak log masuk selama setahun ialah calon untuk dibuang. Akaun warisan dalam kumpulan VPN yang tiada siapa dapat jelaskan ialah penemuan yang penting, kerana tiada satu tetapan pun merekodkan mengapa ia diberikan.

Bacanya daripada pengawal domain yang benar-benar digunakan oleh pelayan VPN untuk pengesahan. Ketinggalan replikasi boleh menunjukkan nilai yang sudah diganti oleh pelayan, dan audit yang memetik nilai DC lapuk akan dicabar sebaik sahaja seseorang menyemak semula.

Ubah satu akaun dan buktikan perubahan itu sampai

Untuk menarik balik akses, tetapkan atribut kepada FALSE dan bukannya mengosongkannya. Mengosongkan mengembalikan akaun kepada pewarisan dasar, yang mungkin membenarkannya semula pada sambungan seterusnya, dan perubahan itu kelihatan seperti pembetulan sedangkan sebenarnya keputusan yang berbeza:

dsmod user "CN=Jane Doe,OU=Staff,DC=corp,DC=example" -allowDialin no
Set-ADUser -Identity jdoe -Clear msNPAllowDialin

Baris kedua ialah penetapan semula warisan, sengaja diasingkan supaya tiada siapa mengelirukan kedua-dua operasi. Kemudian sahkan daripada sesi kedua, baca semula atribut, dan semak peristiwa perakaunan NPS untuk penolakan itu dan bukannya mempercayai penyegaran konsol.

Akhir sekali, catat mekanisme mana yang memiliki keputusan untuk setiap perkhidmatan akses jauh. Jika dasar mengabaikan sifat dial-in pengguna, syarat kumpulan itulah yang berautoriti dan atribut itu hanya bersifat nasihat untuk perkhidmatan tersebut. Dua perkhidmatan dalam domain yang sama boleh menjawab secara berbeza dengan sah, dan rekod semakan harus menyatakannya dalam satu baris bagi setiap perkhidmatan.

Hasil yang bertahan dalam audit adalah ringkas: siapa boleh bersambung, melalui mekanisme apa, disemak bila, oleh siapa. Bendera dial-in membekalkan dua jawapan pertama; hanya semakan dasar membekalkan selebihnya.