RouterOS OpenVPN dan NPS: setel user-auth-method, bukan auth

RouterOS dapat menjangkau NPS dengan login OpenVPN dan tetap ditolak, dan penyebab umumnya adalah dua pengaturan yang namanya sama-sama terdengar seperti autentikasi. Satu memilih digest kriptografis untuk tunnel; yang lain menentukan bagaimana kredensial pengguna disajikan ke RADIUS. Mengubah digest tidak akan pernah mengubah permintaan PAP menjadi MS-CHAPv2, sebanyak apa pun layanan dimulai ulang. Daftar periksa di bawah memisahkan keduanya, lalu menelusuri satu login yang gagal melalui kebijakan NPS yang menilainya.

Langkah 1: baca kedua pengaturan sebelum mengubah salah satunya

Cetak konfigurasi server OpenVPN yang berlaku pada router yang mengakhiri tunnel, bukan dari cadangan atau posting forum yang disalin. Dua bidang yang Anda pedulikan biasanya berada di menu yang sama dan terbaca seolah-olah keduanya alternatif. Keduanya bukan: satu tentang kanal data, yang lain tentang pertukaran kredensial.

/interface ovpn-server server print
/interface ovpn-server server export

Bidang auth mencantumkan digest seperti sha1 dan sha256 dan mengendalikan HMAC yang mengautentikasi paket tunnel. Bidang user-auth-method memilih pap atau mschap2 dan menentukan bagaimana router menyajikan kredensial pengguna ke RADIUS. Perubahan digest tidak dapat mengubah perilaku kedua, dan karena itu penolakan yang sama bertahan pada setiap penyesuaian yang pertama.

Berhenti di sini jika rilis Anda tidak mengekspos user-auth-method sama sekali. Build RouterOS yang lebih lama mungkin tidak menawarkannya di server OpenVPN, dan perbaikan itu termasuk dalam rilis yang dapat Anda dukung, bukan dalam perintah yang disalin dari versi yang lebih baru.

Langkah 2: temukan kebijakan yang benar-benar menolak login

Di sisi NPS, permintaan koneksi dievaluasi terhadap kebijakan jaringan, dan metode autentikasi yang disebutkan dalam kebijakan yang cocok harus salah satu yang benar-benar ditawarkan klien. Kaitkan satu login yang gagal berdasarkan waktu dan pengguna alih-alih membaca jumlah ringkasan. Log keamanan mencatat permintaan yang diberikan dan ditolak dengan kode alasan, yang memberi tahu Anda jauh lebih banyak daripada baris kegagalan umum router.

Get-WinEvent -LogName Security -MaxEvents 200 |
  Where-Object { $_.Id -in 6272,6273 } |
  Format-List TimeCreated,Id,Message

Baca tiga hal dalam peristiwa: nama kebijakan yang cocok, metode autentikasi, dan kode alasan. Kebijakan yang memerlukan MS-CHAPv2 menolak permintaan PAP bahkan ketika kata sandinya benar, dan kebijakan yang memerlukan akun domain menolak akun lokal. Entri klien RADIUS juga harus cocok dengan alamat sumber router, atau permintaan dijatuhkan sebelum kebijakan mana pun diperiksa. Tidak ada satu pun dari itu yang muncul di log OpenVPN.

Berhenti di sini jika permintaan tidak pernah mencapai NPS. Itu masalah rahasia bersama, alamat klien, atau UDP 1812, dan mengubah metode autentikasi tidak akan memperbaikinya.

Langkah 3: ubah satu metode, di kedua sisi

Jika desain yang disetujui adalah MS-CHAPv2, setel di router dan pastikan kebijakan yang cocok menerimanya. Ubah satu sisi, uji ulang, lalu ubah sisi lainnya; mengubah keduanya sekaligus membuat Anda tidak bisa mengatakan mana yang penting.

/interface ovpn-server server set user-auth-method=mschap2
/interface ovpn-server server print
/log print where topics~"radius"

Jangan aktifkan setiap metode yang lebih lemah di NPS agar kesalahan hilang. Backend harus memiliki materi yang dapat diverifikasi metode yang dipilih: MS-CHAPv2 memerlukan akses ke kata sandi atau domain, dan kebijakan tidak dapat mengarang materi itu. Memperluas kebijakan juga memperluas apa yang dapat dicoba penyerang terhadap akun yang sama. Catat metode, nama kebijakan, dan referensi perubahan bersama-sama, agar orang berikutnya mewarisi keputusan, bukan dugaan.

Biarkan validasi sertifikat tunnel persis seperti sebelumnya. Metode kredensial bukan pengganti identitas server, dan menurunkan pemeriksaan TLS agar pengujian lulus menukar satu masalah dengan masalah yang lebih buruk.

Langkah 4: uji tiga login dan satu izin

Uji pengguna yang diizinkan, kata sandi yang salah, dan pengguna yang dikecualikan, masing-masing dalam sesi baru. Yang pertama membuktikan jalurnya, yang kedua membuktikan pemeriksaan kredensial itu nyata, dan yang ketiga membuktikan kebijakan masih mengecualikan siapa yang seharusnya. Sesi yang di-cache dapat menyembunyikan ketiganya, jadi putuskan koneksi di antara percobaan.

/log print where topics~"ovpn"
/radius monitor 0

Keberhasilan autentikasi bukan akhir dari daftar periksa. Periksa alamat yang diterima klien dan sumber daya yang dapat dijangkau alamat itu, karena pengguna dapat mengautentikasi dengan benar dan tetap mendarat di kumpulan yang salah. Jika alamat yang ditetapkan salah, masalahnya ada di profil atau atribut balasan RADIUS, bukan di metode. Konfirmasikan keduanya sebelum menutup tiket.

Daftar periksa selesai ketika pengaturan router dan kebijakan NPS menyebut metode yang sama, satu pengguna yang diizinkan terhubung dengan sesi baru, satu kata sandi yang salah ditolak, satu pengguna yang dikecualikan tetap dikecualikan, dan alamat yang ditetapkan cocok dengan kumpulan yang dimaksud. Apa pun yang kurang dari itu menyerahkan login berikutnya pada kebetulan.