Bagaimana Log Masuk VPN Sampai ke RADIUS dan Penyedia Identiti Anda

Minggu lepas seorang pengguna berjaya log masuk ke VPN dan tetap mendarat di rangkaian yang tiada apa-apa diselesaikan. Klien berkata bersambung, log gateway berkata Access-Accept, dan pasukan identiti berkata akaun itu elok. Log masuk telah berjaya; kebenaran di belakangnya tidak. Apabila log masuk VPN gagal, saya menjejaki laluan yang sebenarnya dilalui permintaan — klien, gateway, pelayan RADIUS, penyedia identiti — dan berhenti pada hop pertama yang jawapannya tidak sepadan dengan hop seterusnya.

Klien tidak pernah bercakap RADIUS

Apa pun yang dipaparkan aplikasi pada komputer riba, hop pertamanya ialah protokol VPN: IKEv2, OpenVPN, WireGuard atau klien berasaskan TLS. RADIUS tidak muncul dalam pertukaran itu. Klien mengesahkan dirinya kepada gateway dengan sijil, nama pengguna dan kata laluan, atau kaedah EAP yang dibawa dalam persediaan terowong.

Itu penting apabila membaca log, kerana ralat pengesahan umum yang dilihat pengguna dihasilkan oleh gateway selepas ia sudah bercakap dengan sesuatu yang lain. Jika klien tidak pernah sampai ke gateway, tiada permintaan RADIUS untuk dinyahpepijat, dan sejam di pelayan RADIUS terbuang. Sahkan terowong itu naik sebelum menyentuh backend.

Gateway ialah klien RADIUS

Sebaik sahaja persediaan terowong mencapai titik di mana kelayakan mesti diperiksa, gateway menjadi pelayan akses rangkaian. Ia membina Access-Request: User-Name, kata laluan atau muatan EAP, NAS-IP-Address atau NAS-Identifier, dan Message-Authenticator apabila kaedah memerlukannya. Permintaan pergi ke UDP 1812 secara lalai, dan perakaunan ke 1813. Pelaksanaan lama masih menggunakan 1645 dan 1646, jadi peraturan firewall yang ditulis untuk satu pasangan menjelaskan banyak kegagalan senyap.

Kedua-dua pihak berkongsi rahsia, dan ia bukan kelayakan pengguna. Ia menandatangani pertukaran itu, dan setiap balasan disahkan terhadapnya. Konfigurasikan rahsia secara berbeza pada kedua-dua pihak dan pelayan tidak menjawab dengan rahsia salah — ia menggugurkan permintaan atau balasan gagal pengesahan, jadi gateway melaporkan tamat masa. Rahsia salah dan pelayan mati kelihatan sama dari gateway, sebab itu saya menguji hop itu dengan alat klien sebelum menyalahkan direktori.

Protokol itu kecil dan lama — RFC 2865 mentakrifkan pertukaran pengesahan — tetapi atribut yang dibawanya ialah asas kepada sebahagian besar dasar 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'

Pelayan RADIUS mungkin hanya bahagian hadapan penyedia identiti

Orang bercakap tentang RADIUS dan penyedia identiti seolah-olah kedua-duanya kotak yang sama. Selalunya bukan. Pelayan RADIUS menerima Access-Request dan kemudian bertanya sesuatu yang lain — Active Directory melalui LDAP atau Kerberos, fail pengguna tempatan atau perkhidmatan luaran — sebelum menjawab. FreeRADIUS dengan modul LDAP atau krb5, Windows NPS dan Cisco ISE semuanya berdiri di kedudukan ini.

Perbezaan itu menentukan ke mana anda melihat. Kata laluan yang ditolak ialah jawapan penyedia identiti yang disampaikan oleh RADIUS. Tamat masa biasanya bahagian RADIUS-ke-direktori: akaun bind yang luput, direktori yang tidak dapat dicapai, atau permintaan yang dihalakan ke backend yang salah. Jika nama pengguna membawa akhiran domain, pelayan boleh menghalakan berdasarkannya, dan akaun yang sama dihantar sebagai CORP\alice dan [email protected] boleh mendarat di tempat berbeza. Dalam Windows NPS, log Security merekodkan 6272 untuk pemberian dan 6273 untuk penolakan, yang memberitahu sama ada keputusan itu datang dari NPS.

Baca kegagalan pada hop yang menghasilkannya

Satu mesej tidak-boleh-sambung meliputi empat kegagalan berbeza. Sebelum mengubah apa-apa, padankan simptom dengan hop yang menghasilkannya.

Baris terakhir itulah yang menghantar orang kepada pasukan yang salah. Access-Accept bermaksud kelayakan diterima; ia tidak bermaksud gateway telah meletakkan pengguna dalam kumpulan yang betul atau menolak laluan. Atribut kumpulan hanya penting jika dasar gateway membacanya. Saya pernah melihat log masuk yang betul mendarat dalam kumpulan tetamu kerana pemetaan kumpulan di sebelah RADIUS dikonfigurasikan untuk atribut yang berbeza daripada yang diperiksa gateway.

Jejaki satu log masuk dari awal hingga akhir

Pilih satu akaun ujian dan satu gateway, kemudian perhatikan percubaan yang sama pada keempat-empat titik. Mulakan larian nyahpepijat di sebelah RADIUS — freeradius -X mencetak permintaan dan setiap modul yang disentuhnya — ikuti log pengesahan gateway, dan jalankan tcpdump untuk pertukaran UDP. Sambung sekali dan baca keempat-empat jejak mengikut urutan.

Apa yang anda mahu lihat ialah persetujuan: gateway bertanya tentang pengguna yang anda jangkakan, pelayan RADIUS memilih backend yang anda jangkakan, backend itu mengembalikan keputusan, dan atribut dalam balasan sepadan dengan dasar yang digunakan gateway. Tempat pertama jejak tidak bersetuju ialah garis kesalahan anda. Jika balasan tidak membawa atribut kumpulan, masalahnya di sebelah RADIUS, bukan dalam profil VPN; jika atribut itu ada dan gateway mengabaikannya, dasar gateway ialah masalahnya.

Satu nota keselamatan semasa anda di sana. Rahsia kongsi melindungi pertukaran itu, tetapi ia tidak menyulitkan sebahagian besar atribut. Jika gateway dan pelayan RADIUS berada pada segmen berbeza, letakkan hop itu pada RADIUS melalui TLS atau laluan peribadi. Terowong pengguna yang disulitkan tidak berkata apa-apa tentang pautan backend.

Sebelum menutup tiket, sahkan empat perkara. Gateway boleh mencapai pelayan RADIUS pada port yang benar-benar dikonfigurasikan. Rahsia kongsi sepadan pada kedua-dua pihak. Pelayan RADIUS menyelesaikan bentuk nama pengguna tepat yang dihantar gateway. Penerimaan membawa atribut yang diperlukan oleh dasar gateway. Apabila keempat-empatnya benar, log masuk yang masih gagal ialah masalah dasar gateway, bukan pengesahan.