Memindahkan backend autentikasi VPN tanpa memakai ulang hash lama

Nama pengguna muncul di direktori baru, migrasi dinyatakan selesai, dan login tetap gagal. Gateway masih membutuhkan jalur autentikasi yang didukung dan hasil otorisasi yang benar, dan keduanya tidak mengikuti dari direktori yang kini memuat akun. Pemindahan backend adalah pemotongan dengan siklus hidup, bukan pekerjaan menyalin. Gejala di bawah ini adalah yang biasanya mengungkap perbedaannya.

Gejalanya: akun ada, sesi tidak

Direktori baru memuat setiap nama pengguna, pengikatan uji berhasil, dan klien VPN tetap mengembalikan kegagalan autentikasi. Kombinasi itu berarti identitas ada, tetapi jalur verifikasi yang dipakai gateway tidak menjangkaunya, atau menjangkaunya dengan metode yang tidak dapat dipenuhinya. Keduanya konfigurasi, dan keduanya masalah berbeda.

Yang pertama adalah pemasangan kabel: gateway menunjuk backend yang tidak menjawab, memakai rahasia bersama yang tidak diharapkan pihak lain, atau meminta atribut yang tidak dikembalikan layanan baru. Yang kedua bersifat kriptografis: metode menuntut rahasia asli, dan penyimpanan baru hanya menyimpan hash-nya. Teks galat terlihat mirip pada kedua kasus, karena itu keduanya diperlakukan sebagai satu masalah.

Memisahkan keduanya sebelum menyentuh akun menghemat satu minggu. Satu adalah soal perutean dan kepercayaan, yang lain keputusan tentang penyetelan ulang kredensial, dan mencampurnya menghasilkan perubahan yang tidak dapat dilacak siapa pun.

Petakan rantai sebelum memindahkan siapa pun

Tuliskan enam hal untuk setiap profil klien: metode autentikasi luar, metode dalam bila ada, identitas server yang diharapkan klien, antarmuka antara gateway dan backend, atribut yang dipetakan gateway ke keanggotaan grup, dan kebijakan sumber daya yang dihasilkan. Membacanya berurutan menunjukkan mata rantai mana yang tidak punya pemilik. Setiap butir punya penanggung jawab, dan pemotongan gagal pada butir yang tidak diperiksa siapa pun.

Login direktori biasa hampir tidak melewati apa pun dari rantai itu. Itu membuktikan akun ada dan kata sandi berfungsi, yaitu bagian yang tidak pernah diragukan.

Hash tidak berpindah antarmetode

Kompatibilitas kredensial harus diperiksa sekali, sebelum kelompok mana pun pindah. FreeRADIUS mendokumentasikan pemisahannya dengan jelas: pemeriksaan CHAP yang dilakukan server sendiri membutuhkan kata sandi sebenarnya, dan MS-CHAP menerima kata sandi itu atau materi NT yang sesuai. Hash yang dibuat untuk tujuan lain tidak cocok pada kedua kasus, sekuat apa pun.

Perbedaannya ada pada siapa yang menghitung bukti. Metode yang memverifikasi dengan mengikat ke direktori membiarkan direktori memeriksa apa yang bisa diperiksanya. Metode yang memverifikasi dengan menghitung ulang respons tantangan membutuhkan rahasia itu sendiri, karena server harus melakukan perhitungan yang sama.

Ketika materi tidak ada, pilihan jujurnya adalah penyetelan ulang yang didukung, pendaftaran ulang, layanan verifikasi eksternal, atau perubahan metode. Ekspor sementara kata sandi yang dapat dipulihkan tidak ada dalam daftar itu. Itu menciptakan penyimpanan kredensial teks polos pada minggu paling kacau dalam proyek, dan biasanya bertahan lebih lama dari migrasi.

Kelompok percontohan, lalu perubahan siklus hidup

Pindahkan kelompok kecil identitas yang disetujui dengan klien sungguhan, dan uji empat hal: login baru, kredensial yang sengaja salah, sumber daya yang boleh dijangkau sesi, dan sumber daya yang tidak boleh. Periksa juga identitas server yang diterima klien, karena ketidakcocokan nama sertifikat tidak terlihat sampai seseorang membaca log klien.

Lalu latih perubahan yang benar-benar menjadi tumpuan penerapan. Ubah kata sandi, perbarui atau daftarkan ulang sertifikat, dan cabut akses dari satu akun percontohan. Setelah masing-masing, konfirmasi verifikator mana yang menangani percobaan itu, karena sesi yang dibuat sebelum pemotongan bisa terus bekerja dan tidak membuktikan apa pun tentang login berikutnya.

Pisahkan pengiriman profil dari peralihan identitas. Setiap kelompok membutuhkan profil yang dimaksudkan, status kredensial atau pendaftarannya, layanan autentikasi yang harus dipakai, dan kontak dukungan, dan tidak satu pun catatan itu boleh memuat rahasia.

Jika jalur lama dan baru hidup berdampingan, batasi dengan tanggal berakhir. Kemunduran otomatis dapat meloloskan akun lewat kredensial lama setelah pemilik baru mencabut akses, dan itu regresi keamanan yang menyamar sebagai ketersediaan.

Pengembalian tidak dapat memulihkan kredensial

Membalikkan pemotongan meninggalkan direktori persis seperti keadaannya sekarang. Kata sandi yang disetel ulang tetap disetel ulang, sertifikat yang dicabut tetap dicabut, dan format kredensial yang diubah tetap berubah. Itu peristiwa di direktori, dan gateway tidak pernah menjadi sumbernya. Pemulihan harus didefinisikan per peristiwa, dan tidak ada bagiannya yang boleh bergantung pada rekonstruksi rahasia dari hash yang tidak kompatibel.

Pertahankan jalur administratif yang tidak memakai koneksi yang sedang dimigrasikan. Ketika autentikasi baru gagal, hentikan kelompok dan pakai jalur pemulihannya yang terdokumentasi, alih-alih melemahkan autentikasi untuk semua orang demi memenuhi tenggat.

Setelah kelompok tercakup, pensiunkan kredensial, profil, dan hubungan kepercayaan backend lama melalui pemiliknya. Pastikan jalur lama tidak lagi meloloskan pengguna, dan pertahankan pemetaan identitas ke kebijakan tanpa rahasia yang masih dibutuhkan dukungan. Migrasi selesai ketika siklus hidup baru bekerja dan tidak ada lagi yang masuk lewat jalur lama, bukan ketika daftar akun tampak lengkap.