Tentang Otentikasi Windows Terintegrasi
Otentikasi Windows Terintegrasi adalah mekanisme yang secara otomatis menyediakan informasi otentikasi pengguna ke IIS ketika IIS dan pengguna berada dalam domain Active Directory yang sama. Saat Anda membuat situs dengan C# ASP.NET, Anda dapat menentukan apakah pengguna telah diautentikasi dan mengambil informasi tentang pengguna yang telah diautentikasi.
Hal ini memungkinkan pengguna untuk mengakses aplikasi web yang dihosting (atau terintegrasi dengan) IIS tanpa memerlukan langkah login tambahan, dan memungkinkan integrasi SSO dengan server aplikasi lain.
Namun, dalam lingkungan di mana server web (IIS) ditempatkan di bawah load balancer dan komunikasi dienkripsi dengan SSL/TLS, ada kasus di mana otentikasi Windows ini tidak berfungsi dengan benar.Mengapa demikian?
Intinya adalah Mekanisme Otentikasi Windows と Pengoperasian penyeimbang beban Letaknya di sana.
NTLM adalah metode autentikasi yang melakukan tantangan/respons melalui satu koneksi TCP antara setiap klien dan server. Sama seperti Kerberos, klien memperoleh tiket berdasarkan Nama Penyedia Layanan (SPN) dan mengirimkannya ke IIS. Informasi autentikasi ini kemudian dimasukkan ke dalam header HTTP.Otorisasi: Negosiasi ... Data kemudian ditransmisikan melalui (dll.). Namun, load balancer Layer 7 menghentikan koneksi HTTPS dari klien pada perangkatnya sendiri, menganalisis konten, dan meneruskannya ke backend IIS sebagai permintaan baru.Sesi TLS ujung-ke-ujung antara klien dan IIS terputus.Selain itu, karena informasi otentikasi yang mempertahankan koneksi, seperti yang digunakan oleh NTLM, tidak diteruskan, proses otentikasi gagal.
Berdasarkan latar belakang di atas, artikel ini akan membahas 「Penyeimbang beban "Konfigurasi untuk berhasil mengimplementasikan otentikasi Windows terintegrasi IIS dalam lingkungan SSL." Kita akan meneliti hal ini. Kita akan menyajikan tiga pola konfigurasi tipikal dan menjelaskan apakah otentikasi Windows didukung untuk masing-masing pola, alasan teknisnya, serta kelebihan dan kekurangan dari setiap konfigurasi.
Verifikasi teknis setiap konfigurasi
①: Load balancer L7, terminasi SSL + penerusan ke IIS (80 atau 443)
Klien ──HTTPS──▶ Load Balancer L7 (Terminasi SSL) ──HTTP(S)──▶ IIS (80 atau 443)
Tersedianya
Autentikasi Windows dalam konfigurasi iniTidak tersediaadalah.
alasan
Karena sesi TLS antara klien dan IIS diakhiri sekali di load balancer,Transfer informasi otentikasi ujung-ke-ujung tidak dimungkinkan.Hal ini karena load balancer L7 mendekripsi HTTPS yang diterima dan mengakses IIS atas nama klien. Pada saat ini, data yang biasanya dikirim dari klien ke IIS adalah... Otorisasi: Negosiasi Header (termasuk header otentikasi seperti tiket Kerberos dan token NTLM) tidak akan sampai ke IIS dengan benar. Secara khusus, dengan NTLM, respons tantangan otentikasi yang dikirim IIS ke permintaan awal (Otentikasi WWWBerdasarkan hal ini, klien mengirimkan permintaan yang direvisi, tetapi melalui LB.Sesi TCP yang sama tidak dipertahankan.Oleh karena itu, jabat tangan NTLM tidak akan berhasil.
Bahkan, di lingkungan AWS sekalipun, autentikasi Windows tidak berfungsi dengan Application Load Balancer (ALB) atau listener HTTP, dan dikatakan bahwa load balancer tingkat TCP seperti Network Load Balancer (NLB) diperlukan.referensiSelain itu, Azure Application Gateway v2 tidak mendukung pengiriman header HTTP, termasuk otentikasi terintegrasi, ke backend.referensi]。
Fakta bahwa hal ini secara resmi tidak didukung oleh load balancer terkelola dari setiap vendor cloud menunjukkan kesulitan dalam mempertahankan otentikasi Windows pada level L7.
②: Load balancer L4 (TLS passthrough) + penerusan IIS
Klien ──HTTPS──▶ L4 Load Balancer (TLS Passthrough) ──HTTPS──▶ IIS (443)
Tersedianya
Konfigurasi ini untuk otentikasi Windows.Tersediaadalah.
alasan
Load balancer L4 (LB yang beroperasi pada Layer 4 OSI) meneruskan paket pada level TCP,Sesi TLS antara klien dan IIS dipertahankan secara ujung-ke-ujung.Hal ini karena load balancer tidak menghentikan enkripsi, tetapi hanya mendistribusikan koneksi TCP itu sendiri ke setiap server, sehingga mempertahankan "komunikasi melalui koneksi TCP yang sama" yang dibutuhkan oleh otentikasi NTLM. Demikian pula, untuk Kerberos, ia mereplikasi pengalaman klien dalam terhubung langsung ke FQDN IIS (layanan), sehingga otentikasi berbasis tiket berfungsi selama SPN dikonfigurasi dengan benar. AWS NLB dan Classic LB dalam mode listener TCP, load balancer internal Azure, dan mode L4 F5 termasuk dalam kategori ini (lainnya termasuk mode TCP HAProxy dan stream nginx), dan dapat melewati otentikasi terintegrasi Windows.
kemampuan
Karena sesi TLS tidak terputus dari klien ke server,Protokol Otentikasi Windows tetap menjalankan fungsinya sebagaimana mestinya.Ya, itu mungkin. Proses jabat tangan NTLM 3 arah diselesaikan dalam satu koneksi, dan tiket Kerberos diterima dengan benar oleh server backend. Selain itu, karena load balancer beroperasi pada L4, ia memiliki overhead yang rendah dan throughput yang tinggi dapat diharapkan.
Kekurangan
Tantangan terbesar dalam konfigurasi load balancer L4 adalah ketidakmampuan untuk melakukan routing granular berdasarkan jalur atau nama host. Misalnya, jalur URL (contoh:/api、/mengobrolMendistribusikan permintaan ke server backend yang berbeda tergantung pada permintaannya adalah fitur yang hanya dapat dicapai dengan L7 (HTTP) dan tidak mungkin dilakukan dengan L4 (TCP).
Oleh karena itu, tergantung pada persyaratan sistem, mungkin perlu untuk menyiapkan beberapa FQDN dan menetapkan server virtual yang berbeda (seperti server web dan server otentikasi Windows) ke load balancer untuk setiap tujuan, yang memiliki kelemahan yaitu meningkatkan kompleksitas konfigurasi.
Secara khusus, saat mengakses halaman otentikasi Windows menggunakan FQDN (Fully Qualified Domain Name) Pendaftaran SPN Ini cukup kompleks, jadi mohon periksa juga hal-hal berikut.
Selain itu, harap perhatikan bahwa semua pengaturan berikut yang diperlukan untuk otentikasi Windows harus diatur ke FQDN load balancer.
- Tab "Keamanan" di Opsi Internet diperlukan untuk autentikasi Windows."Situs" pada "intranet lokal" pengaturan
- Konfigurasi pengikatan situs IIS dan sertifikat SSL (tidak diperlukan instalasi sertifikat pada load balancer itu sendiri)
Proses diagram alir hingga berhasil
Jika FQDN load balancer adalah lb.example.com, alur hingga Kerberos berhasil adalah sebagai berikut:
[Client]
| 1. DNS解決: lb.example.com → LB
|
| 2. Kerberos: SPN = HTTP/lb.example.com
| → ドメインコントローラーにTGSを要求
|
| 3. TLSハンドシェイク: SNI = lb.example.com
| → IISで一致する証明書必要
|
| 4. リクエスト送信: Hostヘッダ = lb.example.com
[IIS]
→ SPN受け入れOK、証明書OK、認証成功③: Konfigurasi penghentian SSL load balancer L7 + pengalihan ke IIS
Klien ──HTTPS──▶ Load Balancer L7 (Terminasi SSL)
LB ── HTTP 302 (Respons Pengalihan) → Klien
Klien ──HTTPS──▶ IIS (akses langsung ke port 443)
Tersedianya
Konfigurasi ini untuk otentikasi Windows.Tersediaadalah.
alasan
Ide dasarnya adalah bahwa load balancer tidak meneruskan komunikasi sebenarnya, tetapi malah mengarahkan klien langsung ke backend IIS melalui respons HTTP 302. Awalnya, pengguna mengakses URL LB, tetapi load balancer L7 mengurai konten sambil mengakhiri SSL di sana, dan mengembalikan respons 302 dengan header Location yang menginstruksikan pengguna untuk terhubung melalui HTTPS ke alamat IIS yang sesuai (misalnya, nama host atau alamat IP masing-masing IIS). Browser klien menerima pengalihan ini dan secara otomatis mengirim ulang permintaan langsung ke IIS yang ditentukan melalui HTTPS.
hasil,Pada permintaan kedua, klien dan IIS terhubung langsung melalui TLS.Oleh karena itu, informasi otentikasi Kerberos/NTLM juga dipertukarkan secara ujung-ke-ujung apa adanya. Karena penyeimbang beban tidak ikut campur selama proses otentikasi, masalah kehilangan header otentikasi yang ditunjukkan pada rencana konfigurasi ① dapat dihindari.
kemampuan
Salah satu keunggulan utama adalah TLS membangun koneksi langsung dari klien ke IIS, sehingga autentikasi Windows menjadi jauh lebih mudah.adalah.
Jika otentikasi berhasil hanya dengan IIS, konfigurasi tersebut dapat digunakan apa adanya, sehingga menambahkan load balancer tidak akan meningkatkan kesulitan.
Selain itu, dengan memanfaatkan pengalihan (redirect), load balancer dapat melakukan kontrol routing yang fleksibel. Misalnya, dengan mengalihkan ke URL backend IIS yang berbeda tergantung pada jalur URL akses awal atau nama host, dimungkinkan untuk mencapai sesuatu yang mendekati distribusi berbasis jalur. Jika terdapat banyak layanan di bawah LB, dimungkinkan juga untuk mengkonsolidasikannya ke titik masuk umum pada LB dan kemudian mengarahkan pengguna ke URL sebenarnya dari setiap layanan, sehingga tampak sebagai satu entitas tunggal di permukaan.
Kekurangan
Salah satu kekurangannya adalah IIS tidak dapat diimplementasikan di belakang load balancer, sehingga memerlukan desain endpoint terpisah untuk IIS sebagai server publik, dan memerlukan penempatan sertifikat yang berbeda dari load balancer.
Kelemahan lainnya adalah pengalihan terjadi pada akses pertama, tetapi pada kenyataannya, ini hanya melibatkan koneksi ulang langsung melalui respons HTTP 302, dan dampaknya pada pengalaman pengguna praktis dapat diabaikan.
Untuk referensi mengenai kecepatan masuk ke layanan kami setelah pengalihan ke IIS dan otentikasi Windows, silakan lihat di sini.filmSilakan merujuk pada hal berikut.
Tabel perbandingan setiap konfigurasi
| komposisi | ringkasan | Autentikasi Windows | perkataan |
|---|---|---|---|
| ① | L7 LB (terminasi SSL) → IIS | ❌ Tidak mungkin | ・Pemisahan TLS, transmisi NTLM/Kerberos non-aktif |
| ② | L4 LB (TLS passthrough) → IIS | ✅ Mungkin | - Perutean berbasis jalur tidak dimungkinkan; perutean dilakukan dengan mengkonfigurasi server virtual pada load balancer menggunakan beberapa FQDN. - Konfigurasikan sertifikat di sisi IIS (tidak diperlukan sertifikat di load balancer). - Port IIS 443 hanya diperbolehkan menerima koneksi masuk dari load balancer. Secara keseluruhan, dokumentasi resmi yang tersedia sangat sedikit, sehingga menyulitkan. |
| ③ | L7 LB (terminasi SSL) → Pengalihan ke IIS | ✅ Mungkin | Perutean berbasis jalur dimungkinkan. Sertifikat diperlukan baik di sisi IIS maupun di load balancer. - Izinkan koneksi masuk pada port IIS 443 dengan ANY. - Pengujian dapat dilakukan hanya dengan menggunakan IIS, sehingga menjadi lebih mudah. |
ringkasan
Agar autentikasi Windows (NTLM/Kerberos) berfungsi dengan benar, sangat penting agar sesi TLS dipertahankan secara konsisten dari klien ke IIS.
Pada konfigurasi load balancer L4 opsi ②, autentikasi berhasil karena TLS tidak diteruskan dan lalu lintas langsung menuju IIS. Namun, ketidakmampuan untuk melakukan routing berbasis jalur yang lebih rinci dan kebutuhan untuk mengkonfigurasi beberapa server virtual di dalam load balancer membuat konfigurasi menjadi lebih sulit.
Di sisi lain, konfigurasi pengalihan pada opsi ③ ideal dari sudut pandang TLS dan otentikasi, karena menangani permintaan awal dengan load balancer L7 dan kemudian terhubung langsung ke IIS setelahnya. Dengan mengalihkan jalur tertentu ke FQDN IIS, dimungkinkan untuk mencapai kontrol aturan L7 dan otentikasi Windows. Perlu diperiksa apakah ada masalah kebijakan dengan IIS, yang tidak berada di belakang load balancer, yang mengizinkan port 443 dengan ANY.
Sebaliknya, dalam konfigurasi seperti opsi ①, di mana load balancer L7 ikut campur dalam penghentian TLS atau interpretasi HTTP, informasi autentikasi terputus, dan autentikasi Windows tidak akan berfungsi.
Kami berharap artikel ini bermanfaat dalam mempertimbangkan konfigurasi yang menyeimbangkan penyeimbangan beban dan komunikasi terenkripsi sambil mempertahankan sistem otentikasi yang kuat.