Bagaimana Login VPN Sampai ke RADIUS dan Penyedia Identitas Anda

Pekan lalu seorang pengguna bisa masuk ke VPN dan tetap mendarat di jaringan yang tidak bisa meresolusi apa pun. Klien menyatakan terhubung, log gateway menyatakan Access-Accept, dan tim identitas menyatakan akunnya baik-baik saja. Login-nya berhasil; otorisasi di belakangnya tidak. Saat login VPN gagal, saya menelusuri jalur yang benar-benar ditempuh permintaan — klien, gateway, server RADIUS, penyedia identitas — dan berhenti pada hop pertama yang jawabannya tidak cocok dengan hop berikutnya.

Klien tidak pernah berbicara RADIUS

Apa pun yang ditampilkan aplikasi di laptop, hop pertamanya adalah protokol VPN: IKEv2, OpenVPN, WireGuard, atau klien berbasis TLS. RADIUS tidak muncul dalam pertukaran itu. Klien melakukan autentikasi ke gateway dengan sertifikat, nama pengguna dan kata sandi, atau metode EAP yang dibawa di dalam penyiapan terowongan.

Itu penting saat membaca log, karena galat autentikasi umum yang dilihat pengguna dihasilkan oleh gateway setelah gateway berbicara dengan hal lain. Jika klien tidak pernah mencapai gateway, tidak ada permintaan RADIUS untuk di-debug, dan satu jam di server RADIUS terbuang. Pastikan terowongannya benar-benar terbentuk sebelum menyentuh backend.

Gateway adalah klien RADIUS

Begitu penyiapan terowongan mencapai titik di mana kredensial harus diperiksa, gateway menjadi server akses jaringan. Ia membangun Access-Request: User-Name, kata sandi atau payload EAP, NAS-IP-Address atau NAS-Identifier, dan Message-Authenticator bila metode memintanya. Permintaan dikirim ke UDP 1812 secara default, dan akuntansi ke 1813. Penerapan lama masih memakai 1645 dan 1646, jadi aturan firewall yang ditulis untuk satu pasangan menjelaskan banyak kegagalan senyap.

Kedua sisi berbagi rahasia, dan itu bukan kredensial pengguna. Rahasia itu menandatangani pertukaran, dan setiap balasan diverifikasi terhadapnya. Konfigurasikan rahasianya berbeda di kedua sisi dan server tidak menjawab dengan rahasia salah — ia menjatuhkan permintaan atau balasannya gagal verifikasi, sehingga gateway melaporkan timeout. Rahasia yang salah dan server yang mati terlihat identik dari gateway, karena itu saya menguji hop dengan alat klien sebelum menyalahkan direktori.

Protokolnya kecil dan tua — RFC 2865 mendefinisikan pertukaran autentikasi — tetapi atribut yang dibawanya adalah dasar sebagian besar kebijakan VPN.

# ask the RADIUS server directly, from the gateway host
radtest alice 'test-password' 127.0.0.1 0 testing123

# watch the exchange the gateway actually sends
tcpdump -ni any -c 20 'udp port 1812'

Server RADIUS mungkin hanya menjadi etalase penyedia identitas

Orang menyebut RADIUS dan penyedia identitas seolah-olah keduanya kotak yang sama. Sering kali bukan. Server RADIUS menerima Access-Request lalu menanyakan hal lain — Active Directory lewat LDAP atau Kerberos, berkas pengguna lokal, atau layanan eksternal — sebelum menjawab. FreeRADIUS dengan modul LDAP atau krb5, Windows NPS, dan Cisco ISE semuanya berada di posisi ini.

Perbedaan itu menentukan ke mana Anda melihat. Kata sandi yang ditolak adalah jawaban penyedia identitas yang diteruskan RADIUS. Timeout biasanya bagian RADIUS-ke-direktori: akun bind kedaluwarsa, direktori tak terjangkau, atau permintaan yang dirutekan ke backend salah. Jika nama pengguna membawa sufiks domain, server dapat merutekan berdasarkan itu, dan akun yang sama yang dikirim sebagai CORP\alice dan [email protected] bisa mendarat di tempat berbeda. Di Windows NPS, log Security mencatat 6272 untuk pemberian dan 6273 untuk penolakan, yang memberi tahu apakah keputusannya berasal dari NPS.

Baca kegagalan pada hop yang menghasilkannya

Satu pesan tidak-bisa-terhubung mencakup empat kegagalan berbeda. Sebelum mengubah apa pun, cocokkan gejalanya dengan hop yang menghasilkannya.

Baris terakhir itulah yang mengirim orang ke tim yang salah. Access-Accept berarti kredensial diterima; bukan berarti gateway telah menempatkan pengguna di pool yang benar atau mendorong rute. Atribut grup hanya penting jika kebijakan gateway membacanya. Saya pernah melihat login yang benar mendarat di pool tamu karena pemetaan grup di sisi RADIUS dikonfigurasi untuk atribut yang berbeda dari yang diperiksa gateway.

Telusuri satu login dari awal sampai akhir

Pilih satu akun uji dan satu gateway, lalu amati percobaan yang sama di keempat titik. Mulai proses debug di sisi RADIUS — freeradius -X mencetak permintaan dan setiap modul yang disentuhnya — ikuti log autentikasi gateway, dan jalankan tcpdump untuk pertukaran UDP. Hubungkan sekali dan baca keempat jejak secara berurutan.

Yang ingin Anda lihat adalah kesepakatan: gateway menanyakan pengguna yang Anda harapkan, server RADIUS memilih backend yang Anda harapkan, backend itu mengembalikan keputusan, dan atribut dalam balasan cocok dengan kebijakan yang diterapkan gateway. Tempat pertama jejak tidak sepakat adalah garis kesalahan Anda. Jika balasan tidak membawa atribut grup, masalahnya di sisi RADIUS, bukan di profil VPN; jika atributnya ada dan gateway mengabaikannya, kebijakan gateway adalah masalahnya.

Satu catatan keamanan selagi Anda di sana. Rahasia bersama melindungi pertukaran, tetapi tidak mengenkripsi sebagian besar atribut. Jika gateway dan server RADIUS berada di segmen berbeda, letakkan hop itu pada RADIUS melalui TLS atau jalur privat. Terowongan pengguna yang terenkripsi tidak mengatakan apa pun tentang tautan backend.

Sebelum menutup tiket, pastikan empat hal. Gateway dapat mencapai server RADIUS pada port yang benar-benar dikonfigurasi. Rahasia bersama cocok di kedua sisi. Server RADIUS meresolusi bentuk nama pengguna persis yang dikirim gateway. Accept membawa atribut yang dibutuhkan kebijakan gateway. Bila keempatnya terpenuhi, login yang masih gagal adalah masalah kebijakan gateway, bukan autentikasi.