Mengapa menyunting berkas .ovpn tidak bisa mengaktifkan MFA di server

Anda menambahkan auth-user-pass ke profil, menyambung ulang, dan klien meminta nama pengguna dan kata sandi. Tampaknya MFA aktif. Lalu Anda mengetik kode dari akun yang salah, atau kode yang kedaluwarsa sepuluh menit lalu, dan terowongan tetap naik. Itulah gejalanya: klien berubah, server tidak. Kata sandi sekali pakai hanya menjadi faktor ketika pemverifikasi di server memutuskan apakah kode itu sah untuk identitas yang mengklaimnya.

Permintaan itu hanya membuktikan bahwa klien bertanya, tidak lebih

Berkas .ovpn adalah dokumen di sisi klien. Ia dapat memberi tahu klien untuk meminta kredensial, menyimpannya di cache, atau berhenti melakukannya. Ia tidak dapat mendaftarkan pengguna, memasang modul PAM, atau membuat server mewajibkan faktor kedua yang tidak diperiksanya saat ini.

Memasang aplikasi autentikator di ponsel juga tidak menciptakan hubungan itu. Proyek Google Authenticator PAM adalah komponen verifikasi OTP yang dapat berada di belakang OpenVPN; itu bukan cara menempelkan login akun Google ke profil yang diimpor.

Pendaftaran adalah bagian yang tidak bisa dilakukan profil

TOTP memerlukan materi pendaftaran yang dibagi antara aplikasi autentikator dan pemverifikasinya. Enam digit di ponsel adalah keluaran; benih di baliknya adalah rahasianya, dan itu milik satu identitas.

Jadi operator memerlukan proses pendaftaran yang mengikat benih yang tepat ke identitas VPN yang tepat, ditambah jalur penggantian terverifikasi untuk ponsel yang hilang. Membiarkan pengguna mengunggah berkas yang dinamai menurut nama mereka mengubah pendaftaran menjadi peluang pengambilalihan akun, dan mengenkripsi unggahan tidak mengubahnya.

Desain berbasis PAM tidak harus membuat akun Unix terpisah untuk setiap pengguna VPN. Dokumentasi modul mendukung jalur rahasia alternatif dan akun khusus untuk akses berkas, yang merupakan identitas sistem berkas, bukan identitas login yang diverifikasi.

Kesalahan umum adalah jalur rahasia tetap yang berakhir dengan satu nama pengguna, disalin dari contoh satu pengguna. Itu demonstrasi satu identitas, bukan pencarian per pengguna, dan memakainya untuk setiap permintaan tidak memberi siapa pun aplikasi autentikator yang terdaftar secara independen. Tuliskan pemetaan identitas, lindungi berkas benih, dan pertahankan pemeriksaan kata sandi, sertifikat, dan akun dalam tumpukan autentikasi yang sama.

Baca tumpukan PAM untuk melihat apa yang sebenarnya diwajibkan

Baris seperti account required pam_permit.so tidak menerapkan kelayakan akun dan tidak menambahkan faktor. Ia mengizinkan tahap pengelolaan akun PAM itu, yang merupakan pernyataan tentang tahap, bukan tentang pengguna Anda.

Hal yang sama berlaku untuk opsi pendaftaran yang permisif. Menerima pengguna tanpa rahasia terdaftar bisa menjadi pilihan peluncuran yang disengaja, tetapi itu bukan bukti bahwa MFA wajib, dan itu harus dicatat sebagai pengecualian sementara dengan tanggal berakhir.

Sesuaikan interaksi klien dengan desain server

auth-user-pass

Direktif itu meminta masukan nama pengguna dan kata sandi. Ia tidak mengonfigurasi PAM, tidak membuat catatan pendaftaran, dan tidak memberi tahu server bahwa bidang kata sandi berisi nilai TOTP. Integrasi server dan klien harus menyepakati interaksi yang benar-benar didukung penerapan: tantangan, format kredensial gabungan yang terdokumentasi, atau alur khusus produk.

Jangan menambahkan kode ke kata sandi hanya karena klien menampilkan satu bidang. Itu hanya berfungsi di tempat plugin server mengharapkan persis format itu, dan gagal secara membingungkan di tempat lain.

Jauhkan benih dan materi QR dari profil bersama dan log diagnostik rutin. Kode yang dikirim melalui kanal login terautentikasi bukan objek yang sama dengan benih yang diberikan selama pendaftaran terkontrol, dan mencampurnya dalam tiket dukungan adalah cara rahasia bocor.

Sambungan ulang, token, dan uji yang menyelesaikannya

Rencanakan apa yang terjadi setelah login pertama yang berhasil. Kode yang sebelumnya diterima mungkin kedaluwarsa atau ditolak sebagai pengulangan pada autentikasi berikutnya. auth-nocache mengendalikan penyimpanan kredensial dan tidak memasang MFA, dan reneg-sec 0 bukan definisi dukungan TOTP, sesering apa pun ia muncul di utas forum.

Beberapa penerapan menerbitkan token autentikasi setelah pemeriksaan awal agar sambungan ulang tidak bertanya lagi. Itu keputusan desain dengan jendela validitas dan kisah pencabutannya sendiri, bukan default yang Anda warisi.

Lalu uji kebijakan penerimaan dengan klien yang benar-benar dipakai orang. Pengguna terdaftar dengan kata sandi, sertifikat, dan kode saat ini yang benar seharusnya dapat terhubung. Kode yang salah, pengguna tanpa pendaftaran, dan akun yang dilarang masing-masing harus gagal, dan alasannya harus terlihat di log server. Sampai Anda melihat penolakan itu, Anda punya permintaan, bukan kebijakan.