Bagaimana IIS mengotentikasi browser klien

Terjemahan Artikel Terjemahan Artikel
ID Artikel: 264921 - Melihat produk di mana artikel ini berlaku.
Kami sangat menyarankan bahwa semua pengguna upgrade ke Internet Information Services (IIS) versi 7.0 berjalan pada Windows Server 2008. IIS 7,0 secara signifikan meningkatkan keamanan infrastruktur web. Untuk informasi lebih lanjut tentang IIS topik terkait keamanan, kunjungi website Microsoft berikut:
http://www.Microsoft.com/TechNet/Security/prodtech/IIS.mspx
Untuk informasi lebih lanjut tentang IIS 7,0, kunjungi website Microsoft berikut:
http://www.IIS.net/default.aspx?tabid=1
Perbesar semua | Perkecil semua

Pada Halaman ini

Ringkasan

Artikel ini menjelaskan metode autentikasi lain yang tersedia di IIS untuk Windows NT 4.0 dan Windows 2000. Untuk keterangan lebih lengkap informasi yang dibahas dalam artikel ini, lihat Windows NT 4.0 dan Windows 2000 sumber daya panduan.

Informasi lebih lanjut

metode autentikasi yang tersedia untuk Windows NT 4.0

Anonim - log masuk tidak diperlukan dan siapa pun diperbolehkan untuk mendapatkan akses ke data yang dilindungi dengan metode ini. Server menggunakan dibangun di account (IUSR_ [nama mesin] secara default) untuk mengontrol hak akses pada file. Peramban mengirim kredensial atau info pengguna dengan jenis permintaan.
  • Browser yang didukung: apapun
  • Keterbatasan: tidak ada
  • hak pengguna yang diperlukan: Account pengguna anonim didefinisikan pada server harus memiliki izin "Log pada lokal".
  • Enkripsi jenis: tidak ada
Dasar (teks yang jelas) - server meminta pengguna untuk masuk dan kotak dialog muncul dalam browser yang memungkinkan pengguna untuk memasukkan kredensial yang diperlukan. Mandat ini harus cocok dengan kredensial pengguna didefinisikan pada berkas yang pengguna mencoba untuk mengakses.
  • Browser yang didukung: apapun
  • Keterbatasan: Tidak sangat aman. Password mudah diuraikan.
  • hak pengguna yang diperlukan: Account pengguna harus memiliki izin "Log pada lokal".
  • Enkripsi jenis: Basis 64 Encoding (tidak benar enkripsi)
Windows NT tantangan/tanggapan - server meminta pengguna untuk login. Jika browser mendukung Windows NT tantangan/tanggapan, secara otomatis akan mengirimkan kredensial pengguna jika pengguna login. Jika domain yang pengguna berbeda dari server domain, atau jika pengguna tidak log masuk, kotak dialog muncul meminta kredensial untuk mengirim. Windows NT tantangan/tanggapan menggunakan algoritma untuk menghasilkan hash berdasarkan kredensial pengguna dan komputer yang pengguna menggunakan. Ia kemudian akan mengirimkan hash ini ke server. Browser tidak mengirim sandi di seluruh ke server.
  • Browser yang didukung: Internet Explorer versi 3,01 dan kemudian
  • Keterbatasan: Memerlukan sambungan point-to-point. Biasanya, sirkuit tertutup setelah "401 tidak sah" kesalahan pesan; Namun, ketika bernegosiasi urutan menurun otentikasi Windows NT tantangan/tanggapan (yang memerlukan beberapa perjalanan keliling), server membuat sirkuit terbuka selama urutan menurun setelah klien telah menunjukkan bahwa itu akan menggunakan Windows NT tantangan/tanggapan. CERN proxy dan tertentu peranti penangkap Internet mencegah hal ini bekerja. Juga, Windows NT tantangan/tanggapan tidak mendukung menirukan ganda-hop (di mana setelah lulus ke IIS server, mandat yang sama tidak dapat dilewatkan ke server back-end untuk otentikasi).
  • hak pengguna yang diperlukan: Account pengguna yang mengakses server harus memiliki izin "Akses komputer ini dari jaringan".
  • Enkripsi jenis: NTLM Hash algoritma yang juga uuencoded.
Perintah prioritas: Ketika browser membuat permintaan, itu selalu mempertimbangkan permintaan pertama menjadi anonim. Oleh karena itu, tidak mengirim kredensial apapun. Jika server tidak menerima anonim atau jika menetapkan account pengguna anonim pada server tidak memiliki izin untuk file yang diminta, IIS server menanggapi dengan pesan galat "Akses ditolak" dan mengirimkan daftar jenis otentikasi yang didukung dengan menggunakan salah satu skenario berikut:
  • Jika Windows NT tantangan/tanggapan adalah satu-satunya didukung metode (atau jika gagal anonim), maka browser harus mendukung metode ini untuk berkomunikasi dengan server. Jika tidak, itu tidak bisa bernegosiasi dengan server dan pengguna akan menerima pesan galat "Akses ditolak".
  • Jika dasar hanya didukung metode (atau jika gagal anonim), kemudian kotak dialog muncul dalam browser untuk mendapatkan kepercayaan, dan kemudian melewati kredensial ini ke server. Itu mencoba untuk mengirim surat-surat ini sampai tiga kali. Jika semua ini gagal, browser tidak terhubung ke server.
  • Jika dasar dan Windows NT tantangan/tanggapan didukung, browser menentukan metode mana yang digunakan. Jika browser mendukung Windows NT tantangan/tanggapan, menggunakan metode ini dan tidak jatuh kembali ke dasar. Jika Windows NT tantangan/tanggapan tidak didukung, browser menggunakan dasar.
Catatan
  • Ketika browser Anda menetapkan sambungan dengan sebuah situs web dengan menggunakan Basic atau NTLM otentikasi, itu tidak jatuh kembali ke Anonymous selama sisa sesi dengan server. Jika Anda mencoba untuk terhubung ke halaman web yang ditandai untuk anonim hanya setelah otentikasi, Anda akan ditolak. (Hal ini mungkin atau mungkin tidak sahih untuk Netscape).
  • Ketika Internet Explorer telah menjalin hubungan dengan server dengan menggunakan Basic atau NTLM otentikasi, melewati dengan kredensial untuk setiap permintaan baru selama sesi.

metode autentikasi yang tersedia untuk Windows 2000 dan di atas

Anonim - log masuk tidak diperlukan dan siapa pun diperbolehkan untuk mendapatkan akses ke data yang dilindungi dengan metode ini. Server menggunakan dibangun di account (IUSR_ [nama mesin] secara default) untuk mengontrol hak akses pada file. Peramban mengirim kredensial atau info pengguna dengan jenis permintaan.
  • Browser yang didukung: apapun
  • Keterbatasan: tidak ada
  • hak pengguna yang diperlukan: Account pengguna anonim didefinisikan pada server harus memiliki izin "Log pada lokal".
  • Enkripsi jenis: tidak ada
Dasar (teks yang jelas) - server meminta pengguna untuk masuk dan kotak dialog muncul dalam browser yang memungkinkan pengguna untuk memasukkan kredensial yang diperlukan. Mandat ini harus cocok dengan kredensial pengguna didefinisikan pada berkas yang pengguna mencoba untuk mengakses.
  • Browser yang didukung: apapun
  • Keterbatasan: Tidak sangat aman. Password mudah diuraikan.
  • hak pengguna yang diperlukan: Account pengguna harus memiliki hak "Log pada lokal"
  • Enkripsi jenis: Basis 64 Encoding (tidak benar enkripsi)
Digest - server meminta pengguna untuk masuk dan juga mengirimkan kesempatan ini digunakan untuk mengenkripsi password. Browser menggunakan kesempatan ini untuk mengenkripsi password dan mengirimkan ini ke server. Server kemudian mengenkripsi password pengguna kopi karbon sendiri dan membandingkan keduanya. Jika mereka cocok dan pengguna memiliki izin, akses diberikan.
  • Browser yang didukung: Internet Explorer 5 dan versi
  • Keterbatasan: Bukan sebagai aman sebagai terpadu. Memerlukan server untuk memiliki akses ke Server direktori aktif yang diatur untuk Otentikasi ringkasan.
  • hak pengguna yang diperlukan: Memerlukan password untuk memiliki "Simpan password terenkripsi jelas teks"
  • Enkripsi jenis: Didasarkan pada kesempatan ini yang dikirim oleh server.

Untuk informasi lebih lanjut, klik nomor artikel berikut ini untuk melihat artikel di dalam Pangkalan Pengetahuan Microsoft:
222028 Menyiapkan Otentikasi ringkasan untuk digunakan dengan Internet informasi Layanan 5.0
Fortezza - menggunakan Fortezza keamanan dengan IIS 5.0, Anda perlu memiliki tepat kriptografi API Layanan penyedia (CSP) file dari Fortezza penyedia seperti http://www.spyrus.com.

Windows terpadu (dibagi ke dalam dua sub kategori)
Kerberos - server meminta pengguna untuk login. Jika browser mendukung Kerberos, berikut terjadi:
  • IIS permintaan otentikasi.
  • Jika klien tidak log masuk ke domain, kotak dialog muncul di Internet Explorer meminta kredensial, dan kemudian kontak KDC untuk meminta dan menerima tiket pemberian Tiket. Ia kemudian akan mengirimkan tiket tiket pemberian informasi tentang IIS server untuk KDC.
  • Jika klien IE memiliki sudah berhasil masuk ke domain dan menerima tiket pemberian Tiket, ia akan mengirimkan tiket ini bersama dengan info tentang IIS server untuk KDC
  • KDC masalah klien tiket sumber daya.
  • Klien melewati tiket ini ke IIS server.
Kerberos menggunakan tiket yang dihasilkan di tiket pemberian Server (KDC) untuk mengotentikasi. Ia akan mengirimkan tiket ini ke IIS server. Browser tidak mengirim sandi di seluruh ke server.
  • Browser yang didukung: Versi Internet Explorer 5.0 dan di atas
  • Keterbatasan: server harus memiliki akses ke server Active Directory. Server dan klien harus memiliki sambungan terpercaya ke KDC.
  • hak pengguna yang diperlukan: Account pengguna anonim didefinisikan pada server harus memiliki izin "Log pada lokal".
  • Enkripsi jenis: dienkripsi Tiket.
Windows NT tantangan/tanggapan - server meminta pengguna untuk login. Jika browser mendukung Windows NT tantangan/tanggapan, secara otomatis akan mengirimkan kredensial pengguna jika pengguna login. Jika domain yang pengguna berbeda dari server domain, atau jika pengguna tidak log masuk, kotak dialog muncul di Internet Explorer meminta kredensial untuk mengirim. Windows NT tantangan/tanggapan menggunakan algoritma untuk menghasilkan hash berdasarkan kredensial pengguna dan komputer yang pengguna menggunakan. Ia kemudian akan mengirimkan hash ini ke server. Browser tidak mengirim sandi di seluruh ke server.
  • Browser yang didukung: Internet Explorer versi 3,01 dan kemudian.
  • Keterbatasan: Memerlukan sambungan point-to-point. Biasanya, sirkuit tertutup setelah "401 tidak sah" kesalahan pesan; Namun, ketika bernegosiasi urutan menurun otentikasi Windows NT tantangan/tanggapan (yang memerlukan beberapa perjalanan keliling), server membuat sirkuit terbuka selama urutan menurun setelah klien telah menunjukkan bahwa itu akan menggunakan Windows NT tantangan/tanggapan. CERN proxy dan tertentu peranti penangkap Internet mencegah hal ini bekerja. Juga, Windows NT tantangan/tanggapan tidak mendukung menirukan ganda-hop (berarti bahwa setelah berlalu ke IIS server, mandat yang sama tidak dapat dilewatkan ke server back-end untuk otentikasi, misalnya, ketika menggunakan IIS Windows NT tantangan/tanggapan, itu tidak bisa kemudian mengotentikasi pengguna database SQL Server di komputer lain dengan menggunakan keamanan terintegrasi SQL).
  • hak pengguna yang diperlukan: Account pengguna mengakses server harus memiliki izin "Akses komputer ini dari jaringan".
  • Enkripsi jenis: NTLM Hash algoritma yang juga uuencoded.
Perintah prioritas:Ketika browser membuat permintaan, itu selalu mempertimbangkan permintaan pertama menjadi anonim. Oleh karena itu, tidak mengirim kredensial apapun. Jika server tidak menerima anonim atau jika mengatur account pengguna anonim pada server tidak memiliki hak akses ke file yang diminta, IIS server menanggapi dengan pesan galat "Akses ditolak" dan mengirimkan daftar jenis otentikasi yang didukung dengan menggunakan salah satu skenario berikut:
  • Jika Windows terpadu adalah satu-satunya didukung metode (atau jika gagal anonim), maka browser harus mendukung metode ini untuk berkomunikasi dengan server. Jika gagal, server tidak mencoba salah satu metode lain.
  • Jika dasar hanya didukung metode (atau jika gagal anonim), kemudian kotak dialog muncul dalam untuk mendapatkan mandat, dan kemudian melewati ini ke server. Ini upaya untuk mengirimkan kredensial hingga tiga kali. Jika semua ini gagal, browser tidak terhubung ke server.
  • Jika dasar dan terpadu Windows didukung, browser menentukan metode mana yang digunakan. Jika browser mendukung Kerberos atau Windows NT tantangan/tanggapan, menggunakan metode ini. Itu tidak jatuh kembali ke dasar. Jika Windows NT tantangan/tanggapan dan Kerberos tidak didukung, browser menggunakan Basic, mencerna, atau Fortezza jika mendukung ini. urutan menurun prioritas di sini adalah dasar, mencerna, dan kemudian Fortezza.
Catatan:
  • Ketika browser Anda menetapkan sambungan dengan sebuah situs web dengan menggunakan dasar atau terintegrasi Windows otentikasi, itu tidak jatuh kembali ke Anonymous selama sisa sesi dengan server. Jika Anda mencoba untuk terhubung ke halaman web yang ditandai untuk anonim hanya setelah otentikasi, Anda ditolak. (Hal ini mungkin atau mungkin tidak sahih untuk Netscape).
  • Ketika Internet Explorer telah menjalin hubungan dengan server dengan menggunakan metode autentikasi lain anonim, secara otomatis lolos dengan kredensial untuk setiap permintaan baru selama durasi sesi.

Referensi

Untuk selengkapnya tentang cara mengkonfigurasi otentikasi situs IIS Web pada Windows Server 2003, klik nomor artikel berikut ini untuk melihat artikel di dalam Pangkalan Pengetahuan Microsoft:
324274 Cara mengkonfigurasi otentikasi situs IIS Web pada Windows Server 2003
Untuk informasi lebih lanjut tentang isu-isu yang mungkin terjadi jika kolam aplikasi situs web yang di-host di IIS 6.0 mendaur ulang selama proses otentikasi, klik nomor artikel berikut ini untuk melihat artikel di dalam Pangkalan Pengetahuan Microsoft:
902160 Anda menerima "HTTP Error 401" pesan kesalahan, dan Anda sebentar-sebentar tidak dapat terhubung ke situs web yang di-host di IIS 6.0

Properti

ID Artikel: 264921 - Kajian Terakhir: 19 November 2013 - Revisi: 3.0
Berlaku bagi:
  • Microsoft Internet Information Services 5.0
  • Microsoft Internet Information Services 5.1
  • Microsoft Internet Information Services 6.0
  • Microsoft Internet Explorer 6.0
  • Windows Internet Explorer 7
  • Windows Internet Explorer 8
  • Windows Internet Explorer 9
Kata kunci: 
kbinfo kbmt KB264921 KbMtid
Penerjemahan Mesin
PENTING: Artikel ini diterjemahkan oleh perangkat lunak penerjemahan mesin Microsoft, dan mungkin telah diedit oleh Masyarakat Microsoft melalui teknologi CTF dan bukan oleh seorang penerjemah profesional. Microsoft menawarkan baik artikel yang diterjemahkan oleh manusia maupun artikel hasil editan terjemahan oleh mesin/komunitas, sehingga Anda dapat mengakses semua artikel di Sentra Pengetahuan yang kami miliki dalam berbagai bahasa. Namun artikel hasil editan mesin atau bahkan komunitas tidak selalu sempurna. Artikel ini dapat mengandung kesalahan dalam hal kosa kata, sintaksis atau tatabahasa, sangat mirip dengan penutur asing yang membuat kekeliruan ketika berbicara dalam bahasa Anda. Microsoft tidak bertanggung jawab atas ketidakakuratan, kesalahan atau kerugian apa pun akibat dari kekeliruan dalam penerjemahan isi atau penggunaannya oleh pelanggan kami. Microsoft juga akan senantiasa memperbarui perangkat lunak penerjemahan mesin dan alat untuk menyempurnakan Editan Hasil Penerjemahan Mesin.
Klik disini untuk melihat versi Inggris dari artikel ini: 264921

Berikan Masukan

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com