Momentan sunteți offline, așteptați să vă reconectați la internet

Cum IIS autentifică browser-ul clientilor

IMPORTANT: Acest articol este tradus cu ajutorul software-ului Microsoft de traducere automată și poate fi corectat prin intermediul tehnologiei Community Translation Framework (CTF). Microsoft oferă articole traduse automat, post-editate de comunitate și articole traduse de oameni, pentru a permite accesul la toate articolele din Baza noastră de cunoștințe în mai multe limbi. Articolele traduse automat și post-editate pot conține greșeli de vocabular, sintaxă și/sau gramatică. Microsoft nu este responsabil de inexactitățile, erorile sau daunele cauzate de traducerea greșită a conținutului sau de utilizarea acestuia de către clienți. Găsiți mai multe informații despre traducerea în colaborare la http://support.microsoft.com/gp/machine-translation-corrections/ro.

Faceți clic aici pentru a vizualiza versiunea în limba engleză a acestui articol: 264921
Vă recomandăm cu tărie că toţi utilizatorii face upgrade la Internet Information Services (IIS) versiunea 7.0 rulează pe Windows Server 2008. IIS 7.0 creşte semnificativ web infrastructurii de securitate. Pentru mai multe informaţii despre subiecte legate de securitatea IIS, du-te la următorul site Web Microsoft:Pentru mai multe informaţii despre IIS 7.0, du-te la următorul site Web Microsoft:
Rezumat
Acest articol descrie metode de autentificare diferite care sunt disponibile în IIS pentru Windows NT 4.0 şi Windows 2000. Pentru o descriere mai completă de informaţii care este discutat în acest articol, consultaţi Windows NT 4.0 şi Windows 2000 Resource ghiduri.
Informaţii suplimentare

Metode de autentificare, care sunt disponibile pentru Windows NT 4.0

Anonim - logon nu este necesară şi oricine este permis pentru a avea acces la date protejat cu această metodă. Server utilizează un construită în cont (IUSR_ [machine nume] implicit) pentru a controla permisiunile fişierelor. Browser-ul nu trimite nici prerogativelor sau info utilizator cu acest tip de cerere.
  • Browsere acceptate: orice
  • Limitări: nici unul
  • drepturi utilizator necesare: cont utilizator anonim definite pe server trebuie să aibă permisiuni de "Jurnal pe local".
  • Tipul de criptare: nici unul
Basic (textul clar) - server solicită utilizatorului să se conecteze si apare o casetă de dialog în browser-ul care permite utilizatorului să introducă acreditările necesare. Aceste acreditări trebuie să se potrivească acreditările de utilizator definite pe fişierele pe care utilizatorul încearcă să acceseze.
  • Browsere acceptate: orice
  • Limitări: Nu foarte sigur. Parolele sunt uşor de descifrat.
  • drepturi utilizator necesare: Contul de utilizator trebuie să aibă permisiuni de "Jurnal pe local".
  • Tipul de criptare: Baza 64 codare (criptare nu este adevărat)
Provocare/răspuns Windows NT - server solicită utilizatorului să faceţi conecta. În cazul în care browser-ul sprijină provocare/răspuns Windows NT, se trimite automat acreditările de utilizator dacă utilizatorul este logat. Dacă domeniul pe care utilizatorul este pe este diferit de pe serverul de domeniu sau în cazul în care utilizatorul nu este conectat, apare o casetă de dialog solicită acreditările pentru a trimite. Provocare/răspuns Windows NT foloseste un algoritm pentru a genera un hash pe baza acreditărilor utilizatorului şi computerul pe care utilizatorul este folosind. Apoi trimite acest hash la server. Browser-ul nu trimite parola utilizatorului de pe server.
  • Browsere acceptate: Versiunile de Internet Explorer 3.01 şi mai târziu
  • Limitări: Necesită conexiune punct la punct. De obicei, un circuit este închis după o eroare "401 neautorizat" mesaj; cu toate acestea, atunci când negociază o secvenţă de autentificare provocare/răspuns Windows NT (care necesită mai multe runde excursii), server păstrează circuit deschis pentru durata de succesiunea dupa ce clientul a indicat că va folosi provocare/răspuns Windows NT. CERN proxy-uri şi anumite alte dispozitive Internet preveni acest lucru. De asemenea, provocare/răspuns Windows NT nu suporta dublu-hop impersonations (în care odată ce a trecut la server IIS, acreditările aceleaşi nu poate fi trecut la un server de back-end pentru autentificare).
  • drepturi utilizator necesare: Contul de utilizator care este accesarea server trebuie să aibă permisiuni de "Acces la acest computer din reţea".
  • Tipul de criptare: NTLM Hash algoritm care este, de asemenea, uuencoded.
Ordine de prioritate: Când browser-ul face o cerere, se consideră întotdeauna primul cererea de a fi anonim. Prin urmare, ea nu trimite orice acreditările. Dacă serverul nu acceptă anonim sau în cazul în care contul utilizator anonim setat pe server nu are permisiunile la dosar fiind solicitat, IIS serverul răspunde cu un mesaj de eroare "Access Denied" şi trimite o listă cu tipurile de autentificare care sunt acceptate utilizând unul dintre următoarele scenarii:
  • În cazul în care provocare/răspuns Windows NT este singurul sprijinit metoda (sau dacă anonimi nu), apoi browser-ul trebuie să accepte această metodă pentru a comunica cu serverul. În caz contrar, se poate negocia cu serverul şi utilizatorul primeşte un mesaj de eroare "Access Denied".
  • În cazul de bază este singurul sprijinit metoda (sau dacă anonimi nu), apoi o casetă de dialog apare în browser-ul pentru a obţine acreditările, şi apoi trece aceste acreditări de la server. Ea încearcă să trimită aceste acreditări până la de trei ori. În cazul în care acestea toate nu reuşesc, browser-ul nu este conectat la server.
  • Dacă sunt suportate atât de bază şi provocare/răspuns Windows NT, browser-ul stabileşte metoda pe care este folosit. Dacă browser-ul sprijină provocare/răspuns Windows NT, se foloseşte această metodă şi nu se încadrează înapoi la bază. În cazul în care provocare/răspuns Windows NT nu este acceptată, browser-ul foloseste de bază.
Note
  • Atunci când browser-ul stabileşte o conexiune cu un site Web utilizând autentificarea Basic sau NTLM, nu se înapoi la anonim în restul acelei sesiuni cu serverul. Dacă încercaţi să vă conectaţi la o pagină Web care este marcat pentru anonim numai după autentificare, vă va fi interzis. (Acest lucru poate sau nu poate deţine adevărat pentru Netscape).
  • Atunci când Internet Explorer a stabilit o conexiune cu serverul utilizând autentificarea Basic sau NTLM, ea trece acreditările pentru fiecare cerere de noi pe durata sesiunii.

Metode de autentificare, care sunt disponibile pentru Windows 2000 şi de mai sus

Anonim - logon nu este necesară şi oricine este permis pentru a avea acces la date protejate cu această metodă. Server utilizează un construită în cont (IUSR_ [machine nume] implicit) pentru a controla permisiunile fişierelor. Browser-ul nu trimite nici prerogativelor sau info utilizator cu acest tip de cerere.
  • Browsere acceptate: orice
  • Limitări: nici unul
  • drepturi utilizator necesare: cont utilizator anonim definite pe server trebuie să aibă permisiuni de "Jurnal pe local".
  • Tipul de criptare: nici unul
Basic (textul clar) - server solicită utilizatorului să se conecteze si apare o casetă de dialog în browser-ul care permite utilizatorului să introducă acreditările necesare. Aceste acreditări trebuie să se potrivească acreditările de utilizator definite pe fişierele pe care utilizatorul încearcă să acceseze.
  • Browsere acceptate: orice
  • Limitări: Nu extrem de sigure. Parolele sunt uşor de descifrat.
  • drepturi utilizator necesare: Contul de utilizator trebuie să aibă "Jurnal pe local" drepturile
  • Tipul de criptare: Baza 64 codare (criptare nu este adevărat)
Digest - server solicită utilizatorului să faceţi conecta şi, de asemenea, Trimite un NONCE utilizată la criptarea parola. Browser-ul foloseste NONCE pentru criptarea parola şi această trimite la server. Server apoi criptează propria copie a parola utilizatorului şi compară cele două. Dacă ei meci şi de utilizator deţine permisiunile, accesul se acordă.
  • Browsere acceptate: Internet Explorer 5 şi versiunile ulterioare
  • Limitări: Nu la fel de sigure ca integrate. Necesită server pentru a avea acces la un server director Active, care este configurat pentru Autentificare de tip digest.
  • drepturi utilizator necesare: Necesită parole pentru a avea "Salvare parolă ca Text criptat clar"
  • Tipul de criptare: Bazat pe NONCE trimise de către server.

Pentru mai multe informaţii, faceţi clic pe următorul număr de articol pentru a vedea articolul în bază de cunoştinţe Microsoft:
222028 Configurarea autentificare Digest pentru utilizare cu Internet informaţii consolidare servicii 5.0
Fortezza - pentru a utiliza securitate Fortezza cu IIS 5.0, trebuie să aveţi un fişier corespunzător criptografice API Service Provider (CSP) la un furnizor de Fortezza, cum ar fi http://www.spyrus.com.

Windows integrată (împărţită în două subcategorii)
Kerberos - server solicită un utilizator la spre conecta. În cazul în care browser-ul sprijină Kerberos, următoare are loc:
  • IIS solicită autentificarea.
  • Dacă clientul nu a conectat la un domeniu, o casetă de dialog apare în Internet Explorer solicită acreditările şi apoi contacte KDC pentru a solicita şi a primi un bilet de acordare a biletului. Apoi trimite acordarea bilet bilet informații despre IIS server KDC.
  • În cazul în care clientul IE a deja cu succes logat în domeniu şi a primit un bilet bilet de acordare, trimite acest bilet împreună cu informaţii despre IIS server KDC
  • KDC problemele clientului un bilet de resurse.
  • Clientul trece acest bilet la server IIS.
Kerberos foloseşte bilete generate la un bilet de acordare Server (KDC) pentru a autentifica. Trimite acest bilet IIS server. Browser-ul nu trimite parola utilizatorului de pe server.
  • Browsere acceptate: Versiuni de Internet Explorer 5.0 şi mai sus
  • Limitări: server trebuie să aibă acces la un server de Active Directory. Ambele server şi client trebuie să aibă o conexiune de încredere la o KDC.
  • drepturi utilizator necesare: cont utilizator anonim definite pe server trebuie să aibă permisiuni de "Jurnal pe local".
  • Tipul de criptare: criptate bilet.
Provocare/răspuns Windows NT - server solicită utilizatorului să faceţi conecta. În cazul în care browser-ul sprijină provocare/răspuns Windows NT, se trimite automat acreditările de utilizator dacă utilizatorul este logat. Dacă domeniul pe care utilizatorul este pe este diferit de pe serverul de domeniu sau în cazul în care utilizatorul nu este conectat, apare o casetă de dialog în Internet Explorer solicită acreditările pentru a trimite. Provocare/răspuns Windows NT foloseste un algoritm pentru a genera un hash pe baza acreditărilor utilizatorului şi computerul pe care utilizatorul este folosind. Apoi trimite acest hash la server. Browser-ul nu trimite parola utilizatorului de pe server.
  • Browsere acceptate: Versiunile de Internet Explorer 3.01 şi mai târziu.
  • Limitări: Necesită conexiune punct la punct. De obicei, un circuit este închis după o eroare "401 neautorizat" mesaj; cu toate acestea, atunci când negociază o secvenţă de autentificare provocare/răspuns Windows NT (care necesită mai multe runde excursii), server păstrează circuit deschis pentru durata de succesiunea dupa ce clientul a indicat că va folosi provocare/răspuns Windows NT. CERN proxy-uri şi anumite alte dispozitive Internet preveni acest lucru. De asemenea, provocare/răspuns Windows NT nu suporta dublu-hop impersonations (ceea ce înseamnă că după ce a trecut la server IIS, acreditările aceleaşi nu poate fi trecut la un server de back-end pentru autentificare, de exemplu, când IIS utilizează provocare/răspuns Windows NT, acesta nu poate apoi autentifica utilizatorul împotriva unei baze acoperire de date SQL Server pe un alt computer utilizând SQL integrate de securitate).
  • drepturi utilizator necesare: Contul de utilizator care accesează serverul trebuie să aibă permisiuni de "Acces la acest computer din reţea".
  • Tipul de criptare: NTLM Hash algoritm care este, de asemenea, uuencoded.
Ordine de prioritate:Când browser-ul face o cerere, se consideră întotdeauna primul cererea de a fi anonim. Prin urmare, ea nu trimite orice acreditările. Dacă serverul nu acceptă anonim sau în cazul în care contul utilizator anonim setat pe server nu are permisiunile la dosar fiind solicitat, IIS serverul răspunde cu un mesaj de eroare "Access Denied" şi trimite o listă cu tipurile de autentificare care sunt acceptate utilizând unul dintre următoarele scenarii:
  • Dacă Windows integrată este singurul sprijinit metoda (sau dacă anonimi nu), apoi browser-ul trebuie să accepte această metodă pentru a comunica cu serverul. În cazul în care aceasta nu reuşeşte, serverul nu încercaţi oricare din celelalte metode.
  • Dacă de bază este singurul sprijinit metoda (sau dacă anonimi nu), apoi o casetă de dialog apare în pentru a obţine acreditările, şi apoi trece la server. Ea încearcă să trimită acreditările până la de trei ori. În cazul în care acestea toate nu reuşesc, browser-ul nu se conecta la server.
  • Dacă sunt suportate atât de bază şi Windows integrată, browser-ul stabileşte metoda pe care este folosit. În cazul în care browser-ul sprijină Kerberos sau provocare/răspuns Windows NT, se foloseşte această metodă. Aceasta nu intră înapoi de bază. În cazul în care provocare/răspuns Windows NT şi Kerberos nu sunt acceptate, browser-ul utilizează Basic, Digest sau Fortezza dacă acestea acceptă. Ordinea de prioritate aici este de bază, Digest, şi apoi Fortezza.
Note:
  • Atunci când browser-ul stabileşte o conexiune cu un site Web utilizând autentificarea Basic sau Windows integrată, nu se înapoi la anonim în restul acelei sesiuni cu serverul. Dacă încercaţi să vă conectaţi la o pagină Web care este marcat pentru anonim numai după autentificare, sunt refuzate. (Acest lucru poate sau nu poate deţine adevărat pentru Netscape).
  • Atunci când Internet Explorer a stabilit o conexiune cu serverul folosind o metodă de autorizare decât anonimi, se trece automat acreditările pentru fiecare nouă cerere durata sesiunii.
Referinţe
Pentru mai multe informaţii despre cum se configurează autentificarea de site-ul IIS Web în Windows Server 2003, faceţi clic pe următorul număr de articol pentru a vedea articolul în bază de cunoştinţe Microsoft:
324274 Cum se configurează autentificarea de site-ul IIS Web în Windows Server 2003
Pentru mai multe informaţii despre problemele care pot apărea în cazul în care un rezervor de aplicații Web site-ul care este găzduit pe IIS 6.0 reciclează în timpul procesului de autentificare, faceţi clic pe următorul număr de articol pentru a vedea articolul în bază de cunoştinţe Microsoft:
902160 Veti primi "eroare HTTP 401" mesaje de eroare, şi vă intermitent nu se poate conecta la un site Web care este găzduit pe IIS 6.0

Avertisment: acest articol a fost tradus automat

Proprietăți

ID articol: 264921 - Ultima examinare: 11/19/2013 09:18:00 - Revizie: 1.0

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

  • kbinfo kbmt KB264921 KbMtro
Feedback