Mengatasi masalah masalah Otentikasi Windows (tidak ada tantangan) di IIS 7.5?

Saya tahu bahwa ada ribuan laporan tentang orang yang mengalami kesulitan mendapatkan Otentikasi Windows Terpadu untuk bekerja dengan IIS, tetapi semuanya tampaknya mengarah ke halaman web yang tidak berlaku atau solusi yang sudah saya coba. Saya telah menyebarkan lusinan situs seperti ini sebelumnya, jadi entah ada sesuatu yang aneh terjadi dengan server / konfigurasi, atau saya telah melihat ini terlalu lama dan tidak melihat yang jelas.

Sederhananya, semuanya bekerja dengan baik pada mesin lokal saya, tetapi berantakan pada server produksi, yang sejauh yang saya tahu memiliki konfigurasi yang sama persis .

Di mesin lokal:

Mesin ini menjalankan Windows 7 Ultimate, Service Pack 1, IIS 7.5.
Situs ini telah diuji dengan sukses, menggunakan IIS dan Server Pengembangan Web VS.
Konfigurasi situs IIS menonaktifkan semua metode otentikasi kecuali Otentikasi Windows.
Mesin lokal tidak ada di domain mana pun.
Penyiapan Penyedia adalah Negosiasi dan NTLM (bukan Negosiasi: Kerberos).
Extended Protection Off.
Semua browser yang diuji (IE, Firefox, Chrome) menunjukkan prompt tantangan dan memungkinkan saya untuk masuk ke domain host lokal dengan akun Windows (lokal) saya.
Semua browser yang diuji juga berfungsi menggunakan alamat IP lokal yang tidak jelas - sehingga browser itu sendiri sepertinya tidak peduli apakah situs tersebut tampak "lokal" atau "jauh".
Saya telah menambahkan baris tampilan ke halaman web yang menunjukkan pengguna yang saat ini masuk dan menunjukkan apa yang saya harapkan (pengguna lokal mana pun yang saya gunakan untuk masuk).

Pada mesin jarak jauh:

Server menjalankan Windows Server 2008 R2, IIS 7.5.
Memuat halaman web mengakibatkan kesalahan langsung 401.2: Anda tidak berwenang melihat halaman ini karena tajuk otentikasi tidak valid. Tidak ada tantangan yang muncul.
Konfigurasi situs IIS menonaktifkan semua metode otentikasi kecuali Otentikasi Windows.
Mesin jarak jauh tidak ada di domain mana pun.
Penyiapan Penyedia adalah Negosiasi dan NTLM (bukan Negosiasi: Kerberos).
Extended Protection Off.
Pada mesin jarak jauh (sesi desktop jarak jauh), kesalahan yang sama muncul di Internet Explorer terlepas dari apakah domain tersebut adalah localhost atau alamat IP eksternal.
Jika saya mencoba melihat situs web jarak jauh dari mesin lokal saya , kesalahannya masih 401, tetapi 401 sedikit berbeda. Tidak ada subkode, dengan teks: Akses ditolak karena kredensial tidak valid.
The Windows Authentication fitur peran IIS yang diinstal.
The WindowsAuthentication Modul ini ditambahkan (di tingkat Server).
Kesalahan yang sama persis terjadi jika saya mematikan Otentikasi Windows dan mengaktifkan Otentikasi Dasar.
Situs ini memuat jika saya mematikan Otentikasi Windows dan mengaktifkan Anonim (jelas).
Saya sudah mengikuti semua langkah pemecahan masalah di Dukungan Microsoft: Mengatasi masalah kesalahan HTTP 401 di IIS
Saya sudah mencoba solusi yang ditunjukkan pada halaman dukungan Microsoft lainnya (seharusnya untuk memaksa NTLM sebagai satu-satunya metode).

Terakhir tetapi tidak kalah pentingnya, saya mencoba menyalakan FREB untuk kesalahan 401.2 dan hasilnya sepertinya tidak memberi tahu saya apa pun yang berguna, yang saya lihat adalah peringatan berikut:

MODULE_SET_RESPONSE_ERROR_STATUS

ModuleName IIS Web Core
Notification 2
HttpStatus 401
HttpReason
HttpSubStatus 2 Tidak ResmiCode
2147942405
ConfigExceptionInfo
Notification AUTHENTICATE_REQUEST
Akses ErrorCode ditolak. (0x80070005)

... ini sepertinya hanya memberi tahu saya apa yang sudah saya ketahui (bahwa itu hanya menolak permintaan alih-alih menegosiasikan kredensial).

Jejak tidak menunjukkan bahwa modul WindowsAuthentication dimuat dengan benar karena ada NOTIFY_MODULE_STARTgaris dengan ModuleName= WindowsAuthentication(dan berbagai peristiwa tindak lanjut ASP.NET lainnya - [un] untungnya, tidak ada kesalahan atau peringatan yang menarik di sini).

Adakah yang bisa memberi tahu saya apa yang mungkin saya lewatkan di sini?

Pembaruan Cepat:

Saya sedikit tidak nyaman mengirim seluruh pembuangan Wireshark karena akan mengungkapkan IP, URL, dan hal-hal lain, tapi saya melakukan perbandingan tanggapan HTTP dari localhost dan server jarak jauh di Fiddler, dan tampaknya cukup mandiri -jelas apa masalahnya:

Localhost:

HTTP / 1.1 401 Tidak Sah
Kontrol Cache: pribadi
Jenis-Konten: teks / html; charset = utf-8
Server: Microsoft-IIS / 7.5
Otentikasi WWW: Bernegosiasi
Otentikasi WWW: NTLM
X-Didukung-Oleh: ASP.NET
Tanggal: Sabtu, 17 Des 2011 23:42:34 GMT
Panjang Konten: 6399
Dukungan Proxy: Sesi-Berbasis-Otentikasi

Terpencil:

HTTP / 1.1 401 Tidak Sah
Jenis-Konten: teks / html
Server: Microsoft-IIS / 7.5
X-Didukung-Oleh: ASP.NET
Tanggal: Sabtu, 17 Des 2011 23:43:13 GMT
Panjang Konten: 1293

Selain beberapa perbedaan yang tampaknya tidak penting seperti kontrol cache, perbedaan utamanya adalah server jarak jauh tidak mengirim header WWW-Authenticate kembali ke klien.

Jadi, saya kira itu mempersempit pertanyaan menjadi: Mengapa IIS tidak mengirim header WWW-Authenticate ketika Windows Authentication tampaknya diinstal, dimuat, dan diaktifkan secara eksklusif?

— Aaronaught
sumber

Pikiran menangkap wireshark plaintext dari upaya otentikasi (ubah kata sandi Anda menjadi sesuatu yang dibuang terlebih dahulu - kami tidak ingin hash kata sandi asli Anda ada di internet)? Sekitar 18 bulan kembali sebuah tambalan Windows membuat beberapa perubahan pada negosiasi HTTP NTLM (omong-omong, apakah sistem ditambal sepanjang jalan?) Yang meledakkan aplikasi vendor dan memberi saya pengalaman yang jauh lebih banyak daripada yang saya akui dengan menganalisis dengan menganalisis percakapan negosiasi.

— Shane Madden

@ShaneMadden: Saya agak keberatan dengan berbagai bit informasi yang akan saya paparkan, tapi saya bisa melakukan sesi Fiddler yang seharusnya hampir sama, dan kemudian setidaknya saya bisa menganonimkan IP dan sebagainya - dan sebenarnya saya sudah melakukannya, hasilnya harus cukup jelas (klien tidak menunjukkan prompt kredensial karena server tidak meminta apa pun).

— Aaronaught

Oh, menarik, seseorang sepertinya telah melaporkan masalah ini pada Stack Overflow juga - tidak ada jawaban di sana, sedihnya.

— Aaronaught

@Aaronaught Bagaimana Anda mendapatkan nama pengguna yang berbeda di sini daripada di Memasak? Ketika saya pertama kali melihat pertanyaan ini, saya pikir itu adalah seseorang yang menipu Anda.

— Ward - Reinstate Monica

@Ward: Siapa saja dapat mengedit nama pengguna mereka, itu bagian dari profil. Ini yang asli, hanya menggunakan yang lain di situs non-teknologi.

— Aaronaught

Masalah terpecahkan. Saya akhirnya memutuskan untuk membandingkan daftar modul berdampingan dan sebenarnya ada satu yang hilang. Ternyata ada dua modul Otentikasi Windows:

Daftar Modul

Di server, WindowsAuthenticationmodul yang dikelola ada di sana, tetapi bukan yang asli yang WindowsAuthenticationModuledisorot di atas. Mengapa itu dikonfigurasikan seperti itu adalah dugaan siapa pun, tetapi ternyata jika modul asli tidak dimuat, modul yang dikelola akan dengan senang hati memuat dan gagal.

Jadi untuk setiap pembaca di masa depan yang mengalami masalah ini, pastikan Anda memiliki kedua modul yang dimuat , karena IIS tidak akan memperingatkan Anda jika salah satu dari mereka hilang.

— Aaronaught
sumber

Modul WindowsAuthentication yang dikelola tidak seperti apa kedengarannya. Ini mendukung identitas Windows di ASP.Net, dan selalu terinstal (saat ASP.Net diinstal). Tetapi modul asli Windows Authentication adalah apa yang diinstal ketika Anda mencentang komponen Windows Auth di Server Manager, dan itulah yang Anda butuhkan agar opsi otentikasi menjadi terlihat di GUI Authentication.

— TristanK

@ ChristianK: Dalam hal ini, komponen itu dicentang, tetapi modul tidak diinstal. (Pilihannya adalah, bagaimanapun, terlihat di GUI Otentikasi - jadi saya cukup yakin bahwa layar tergantung pada modul yang dikelola, bukan yang asli.)

— Aaronaught

Saya berpikir bahwa ini mungkin terjadi karena beberapa gangguan pada file konfigurasi (mungkin ApplicationHost.config). Tapi kurasa tidak masalah bagaimana itu menjadi rusak; itu benar.

— Aaronaught

Ya jelas. Windows Auth tidak berfungsi kecuali terjadi sesuatu untuk memecahnya; dalam kasus ini, sementara pertanyaannya menyatakan konfigurasi adalah identik, yang ternyata tidak benar; jadi tidak bekerja sama. QED.

— TristanK

Masalah modul yang hilang ini hanya menggigit saya di Windows Server 2012 R2. Luar biasa bahwa tidak ada indikasi kapan kondisi ini terjadi. Bagaimanapun, terima kasih banyak atas jawaban ini; Saya benar-benar mencabut rambut saya!

— Rob Davis

Kami menemukan ini tidak serta merta memperbaiki masalah bagi pengembang yang bekerja secara lokal di situs ASP.NET yang berjalan di bawah Otentikasi Windows. Kami menemukan peretasan registri yang menonaktifkan pemeriksaan loopback; ini memperbaikinya: -

kunci registri - HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Control \ Lsa

Buat DWORD dengan nilai 1 yang disebut "DisableLoopbackCheck"

Anda harus me-reboot mesin agar pengaturannya berlaku

— sh1rts
sumber

Saya menemukan saya bisa beralih antara DisableLoopbackCheck menjadi 1 dan 0 dan perubahan akan segera berlaku. Selain itu, Anda dapat melihat ID Peristiwa 4625 di log peristiwa Log keamanan dengan pesan "Akun gagal masuk".

— alastairtree

Terima kasih! 2 hari mencari-cari dengan otentikasi IIS dan versi .Net hanya untuk menemukannya karena saya menggunakan file host saya untuk membuat entri DNS dummy saat menguji migrasi situs.

— JohnLBevan