Cara mengonfigurasi Autentikasi Windows Terintegrasi IIS agar berhasil di lingkungan penyeimbang beban + SSL

31 Maret 2025

Daftar isi

Tentang Autentikasi Windows Terintegrasi

Autentikasi Windows Terpadu adalah mekanisme yang secara otomatis menyediakan informasi autentikasi pengguna ke IIS ketika IIS dan pengguna berada dalam domain Direktori Aktif yang sama. Saat Anda membuat situs menggunakan ASP.NET C#, Anda dapat menentukan apakah pengguna telah diautentikasi dan memperoleh informasi tentang pengguna yang diautentikasi.

Hal ini memungkinkan pengguna untuk mengakses aplikasi web yang dihosting (atau ditautkan) oleh IIS tanpa operasi login tambahan, dan memungkinkan integrasi SSO dengan server aplikasi lain.

Namun, dalam lingkungan di mana server web (IIS) berada di bawah penyeimbang beban dan komunikasi dienkripsi dengan SSL/TLS, autentikasi Windows ini mungkin tidak berfungsi dengan baik.Mengapa demikian?

Jika autentikasi Windows berhasil, Anda akan dapat mengakses situs autentikasi dengan lancar, tetapi jika gagal, tombol masuk akan ditampilkan. Jika Anda tidak mengautentikasi dengan benar, Anda akan mendapatkan Kesalahan HTTP 401.1 – Tidak Resmi.

Intinya adalah Cara kerja autentikasi Windows dan Operasi penyeimbang beban berada.

NTLM adalah metode autentikasi tantangan/respons melalui koneksi TCP tunggal antara setiap klien dan server. Dengan Kerberos, klien juga memperoleh tiket berdasarkan pengenal layanan (SPN) dan mengirimkannya ke IIS. Kredensial ini dikirim melalui header HTTP (Otorisasi: Negosiasikan ... Transaksi dilakukan dengan metode demikian. Namun, penyeimbang beban Lapisan 7 mengakhiri koneksi HTTPS dari klien pada perangkatnya sendiri, menganalisis konten, dan meneruskannya ke IIS backend sebagai permintaan baru. Selama proses iniSesi TLS ujung ke ujung antara klien dan IIS diakhiri.Lebih jauh lagi, informasi autentikasi persisten seperti NTLM tidak terbawa, yang menyebabkan proses autentikasi gagal.

Mengingat latar belakang di atas, artikel ini "Penyeimbang beban + Mengonfigurasi Autentikasi Windows Terintegrasi IIS untuk berhasil dalam lingkungan SSL Kami akan mempertimbangkan hal berikut ini. Kami akan mencantumkan tiga pola konfigurasi umum dan menjelaskan untuk masing-masing pola apakah autentikasi Windows didukung, alasan teknis untuk ini, serta kelebihan dan kekurangan konfigurasi tersebut.

Verifikasi teknis setiap rencana konfigurasi

①: Penghentian SSL penyeimbang beban L7 + IIS (80 atau 443)

Klien ──HTTPS──▶ L7 Load Balancer (penghentian SSL) ──HTTP(S)──▶ IIS (80 atau 443)

Tersedianya

Autentikasi Windows tidak didukung dalam konfigurasi ini.Tidak tersediaadalah.

alasan

Karena sesi TLS antara klien dan IIS diakhiri sekali pada penyeimbang beban,Transfer kredensial menyeluruh tidak dimungkinkanItulah sebabnya. Penyeimbang beban L7 mendekripsi lalu lintas HTTPS yang diterima dan mengakses IIS atas nama klien. Pada saat ini, klien harus mengirim Otorisasi: Negosiasi Header (header autentikasi termasuk tiket Kerberos dan token NTLM) tidak akan mencapai IIS dengan benar. Secara khusus, dengan NTLM, respons tantangan otentikasi yang dikirim IIS ke permintaan awal (WWW-Otentikasi) klien mengirimkan permintaan ulang, tetapi melalui LBSesi TCP yang sama tidak dipertahankanOleh karena itu, jabat tangan NTLM tidak berhasil.

Faktanya, bahkan dalam lingkungan AWS, autentikasi Windows tidak berfungsi dengan Application Load Balancer (ALB) atau pendengar HTTP, dan LB tingkat TCP seperti Network Load Balancer (NLB) diperlukan.referensi]. Selain itu, Azure Application Gateway v2 tidak mendukung penerusan header HTTP termasuk autentikasi terintegrasi ke backend.referensi].

Fakta bahwa hal ini tidak didukung secara resmi oleh LB yang dikelola masing-masing vendor cloud menunjukkan kesulitan dalam mempertahankan autentikasi Windows di tingkat L7.

②: Penyeimbang beban L4 (TLS pass-through)

Klien ──HTTPS──▶ Penyeimbang Beban L4 (TLS pass-through) ──HTTPS──▶ IIS (443)

Tersedianya

Konfigurasi ini menggunakan autentikasi Windows.Kompatibeladalah.

alasan

Karena penyeimbang beban L4 (LB yang beroperasi pada OSI Layer 4) menyampaikan paket pada tingkat TCP,Sesi TLS antara klien dan IIS dipertahankan secara menyeluruhakan dilakukan. Penyeimbang beban tidak menghentikan enkripsi, tetapi hanya mendistribusikan koneksi TCP itu sendiri ke setiap server, sehingga "komunikasi pada koneksi TCP yang sama" yang dibutuhkan oleh autentikasi NTLM tetap terjaga. Mengenai Kerberos, dari perspektif klien, hal itu dapat direproduksi seolah-olah klien terhubung langsung ke FQDN IIS (layanan), jadi selama SPN ditetapkan dengan tepat, autentikasi berbasis tiket akan berjalan sebagaimana mestinya. Mode pendengar AWS NLB dan LB TCP klasik, penyeimbang beban internal Azure, mode F5 L4, dsb. termasuk dalam kategori ini (yang lainnya termasuk mode TCP HAProxy dan aliran nginx), dan dapat melewati autentikasi terintegrasi Windows.

kemampuan

Sesi TLS tidak terputus dari klien ke server.Protokol otentikasi Windows terus berfungsi sebagaimana mestinyaBisa. Jabat tangan tiga arah NTLM juga diselesaikan dalam satu koneksi, dan tiket Kerberos diterima dengan benar oleh server back-end. Selain itu, karena LB merupakan operasi L4, overhead-nya rendah dan dapat diharapkan mencapai throughput tinggi.

Kekurangan

Tantangan terbesar dalam mengonfigurasi penyeimbang beban L4 adalah ketidakmampuan untuk melakukan perutean terperinci berbasis jalur atau berbasis nama host. Misalnya, di jalur URL (misalnya/api,,/mengobrolMendistribusikan setiap permintaan (atau beberapa permintaan) ke server backend yang berbeda adalah fitur yang hanya dapat dicapai dengan L7 (HTTP) dan tidak dimungkinkan dengan L4 (TCP).

Oleh karena itu, bergantung pada persyaratan sistem, mungkin perlu menyiapkan beberapa FQDN dan menetapkan server virtual yang berbeda untuk tujuan yang berbeda (server web, server untuk autentikasi Windows, dll.) dalam penyeimbang beban, yang memiliki kelemahan yaitu membuat konfigurasi lebih sulit.

Perlu diperhatikan juga bahwa pengaturan berikut yang diperlukan untuk autentikasi Windows semuanya mengatur FQDN penyeimbang beban.

Otentikasi Windows diperlukan di tab "Keamanan" Opsi Internet."Intranet Lokal" "Situs" pengaturan
Saat mengakses halaman autentikasi Windows menggunakan FQDN (nama domain berkualifikasi lengkap) Registrasi SPN
Sertifikat SSL dalam pengaturan pengikatan situs IIS

* Jika FQDN penyeimbang beban 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、認証成功

③: Penghentian SSL penyeimbang beban L7 + konfigurasi pengalihan

Klien ──HTTPS──▶ Penyeimbang beban L7 (penghentian SSL)
LB ──HTTP 302 (Respon pengalihan) → Klien
Klien ──HTTPS──▶ IIS (akses langsung ke 443)

Tersedianya

Konfigurasi ini menggunakan autentikasi Windows.Kompatibeladalah.

alasan

Idenya adalah bahwa penyeimbang beban tidak menyampaikan komunikasi sebenarnya, tetapi malah mengarahkan klien langsung ke IIS backend (respons HTTP 302). Saat pertama kali pengguna mengakses URL LB, penyeimbang beban L7 mengakhiri SSL di sana, menganalisis konten, dan mengembalikan respons 302 dengan header Lokasi untuk menyambungkan ke alamat IIS yang sesuai (misalnya, nama host atau alamat IP individual untuk setiap IIS) melalui HTTPS. Peramban klien menerima pengalihan ini dan secara otomatis mengirimkan ulang permintaan melalui HTTPS langsung ke IIS yang ditentukan.

hasil,Untuk permintaan kedua, klien dan IIS terhubung langsung melalui TLSOleh karena itu, informasi autentikasi Kerberos/NTLM diteruskan ujung ke ujung sebagaimana adanya. Karena penyeimbang beban tidak terlibat dalam proses autentikasi, maka masalah hilangnya header autentikasi seperti yang terlihat pada konfigurasi 1 dapat dihindari.

kemampuan

Keuntungan utamanya adalah TLS terhubung langsung dari klien ke IIS, sehingga autentikasi Windows mudah berhasil.adalah.
Jika autentikasi berhasil menggunakan IIS saja, konfigurasi dapat digunakan sebagaimana adanya, jadi tidak ada peningkatan kesulitan meskipun penyeimbang beban digunakan sebagai perantara.

Selain itu, dengan memanfaatkan pengalihan, tingkat kontrol perutean yang fleksibel tertentu dimungkinkan di sisi penyeimbang beban. Misalnya, Anda dapat mencapai sesuatu yang mendekati distribusi berbasis jalur dengan mengalihkan ke URL IIS backend yang berbeda tergantung pada jalur URL akses awal atau nama host. Jika ada banyak layanan di bawah LB, dimungkinkan untuk menggabungkan semuanya terlebih dahulu ke dalam LB sebagai titik masuk umum, lalu mengarahkan pengguna ke URL sebenarnya dari setiap layanan dari sana, sehingga semuanya tampak sebagai satu kesatuan di permukaan.

Kekurangan

Kerugiannya adalah IIS tidak dapat diterapkan di belakang LB, dan titik akhir terpisah harus dirancang untuk IIS sebagai server publik, dan sertifikat yang berbeda harus ditempatkan untuk LB.

Kerugian lainnya adalah pengalihan terjadi pada akses pertama, tetapi pada kenyataannya, penyambungan kembali segera dilakukan melalui respons HTTP 302, sehingga dampaknya pada pengalaman pengguna hampir dapat diabaikan.

Untuk referensi kecepatan login ke layanan kami setelah dialihkan ke IIS dan melalui otentikasi Windows, lihat di sinifilmSilakan merujuk ke.

Tabel perbandingan setiap konfigurasi

komposisi	ringkasan	Otentikasi Windows	perkataan
①	Penghentian SSL di L7 LB → IIS	❌ Tidak	- Pemisahan TLS, NTLM/Kerberos non-transparan
②	TLS melewati L4 LB	✅ Ya	- Perutean berbasis jalur tidak memungkinkan, jadi beberapa server virtual dikonsolidasikan menjadi satu LB ・Tidak ada dokumentasi resmi yang akurat, jadi sulit untuk ・Siapkan sertifikat untuk penyeimbang beban
③	Arahkan halaman autentikasi langsung ke IIS	✅ Ya	- IIS tidak dapat digunakan di belakang LB - Desain titik akhir terpisah untuk IIS dan sertifikat berbeda dari LB diperlukan ・Penyeimbang beban L7 memungkinkan alokasi berbasis jalur

Tabel perbandingan setiap konfigurasi

ringkasan

Agar autentikasi Windows (NTLM/Kerberos) berfungsi dengan baik, sangat penting bahwa sesi TLS dipertahankan mulai dari klien hingga IIS.

Dalam konfigurasi penyeimbang beban L4 opsi 2, TLS tidak diteruskan dan mencapai IIS secara langsung, sehingga autentikasi berhasil. Namun, konfigurasinya rumit karena tidak memungkinkan perutean berbasis jalur yang terperinci dan memerlukan konfigurasi beberapa server virtual dalam penyeimbang beban.

Di sisi lain, konfigurasi pengalihan pada Opsi 3 diproses oleh penyeimbang beban L7 hanya untuk pertama kalinya, lalu terhubung langsung ke IIS, yang merupakan alur ideal dari perspektif TLS dan autentikasi. Dengan mengarahkan jalur tertentu ke IIS FQDN, Anda dapat memperoleh kontrol aturan L7 dan autentikasi Windows. Perlu diperiksa apakah ada masalah kebijakan terkait ketidakmampuan menerapkan IIS di belakang LB.

Di sisi lain, dalam konfigurasi seperti Opsi 1, di mana penyeimbang beban L7 melakukan penghentian TLS atau interpretasi HTTP, informasi autentikasi terganggu dan autentikasi Windows tidak berfungsi.

Kami berharap artikel ini bermanfaat dalam mempertimbangkan konfigurasi yang mencapai penyeimbangan beban dan komunikasi terenkripsi dengan tetap mempertahankan sistem autentikasi yang kuat.

URLをコピーしました！