IIS autentica i client del browser

Articolo
07/17/2023

Questo articolo illustra come IIS autentica i client del browser.

Versione originale del prodotto: Internet Explorer
Numero KB originale: 264921

Riepilogo

Questo articolo descrive i diversi metodi di autenticazione disponibili in IIS per Windows NT 4.0, Windows 2000 e versioni successive di Windows. Per una descrizione più completa delle informazioni illustrate in questo articolo, vedere Le guide alle risorse di Windows NT 4.0 e Windows 2000.

Metodi di autenticazione disponibili per Windows NT 4.0

Anonimo: non è necessario alcun accesso e a chiunque è consentito accedere ai dati protetti con questo metodo. Il server usa un account predefinito (IUSR_[nome computer] per impostazione predefinita) per controllare le autorizzazioni sui file. Il browser non invia credenziali o informazioni utente con questo tipo di richiesta.

Browser supportati: qualsiasi
Limitazioni: Nessuna
Diritti utente obbligatori: l'account utente anonimo definito nel server deve disporre delle autorizzazioni di accesso locale .
Tipo di crittografia: Nessuno

Basic (Testo non crittografato): il server richiede all'utente di accedere e nel browser viene visualizzata una finestra di dialogo che consente all'utente di immettere le credenziali necessarie. Queste credenziali devono corrispondere alle credenziali utente definite nei file a cui l'utente sta tentando di accedere.

Browser supportati: qualsiasi
Limitazioni: non sicuro. Le password vengono facilmente decifrate.
Diritti utente obbligatori: l'account utente deve disporre delle autorizzazioni di accesso in locale .
Tipo di crittografia: codifica base 64 (non vera crittografia)

Richiesta/risposta di Windows NT: il server richiede all'utente di accedere. Se il browser supporta la richiesta di verifica/risposta di Windows NT, invia automaticamente le credenziali dell'utente se l'utente è connesso. Se il dominio in cui si trova l'utente è diverso dal dominio del server o se l'utente non è connesso, viene visualizzata una finestra di dialogo per richiedere le credenziali da inviare. La richiesta di verifica/risposta di Windows NT usa un algoritmo per generare un hash in base alle credenziali dell'utente e al computer in uso. Invia quindi questo hash al server. Il browser non invia la password dell'utente al server.

Browser supportati: Internet Explorer versioni 3.01 e successive
Limitazioni: richiede una connessione da punto a punto. In genere, un circuito viene chiuso dopo un messaggio di errore "401 non autorizzato"; tuttavia, quando si negozia una sequenza di autenticazione con richiesta/risposta di Windows NT (che richiede più round trip), il server mantiene aperto il circuito per la durata della sequenza dopo che il client ha indicato che userà la richiesta/risposta di Windows NT. I proxy CERN e alcuni altri dispositivi Internet impediscono il funzionamento. Inoltre, la richiesta di verifica/risposta di Windows NT non supporta le rappresentazione a doppio hop( in quanto una volta passate al server IIS, le stesse credenziali non possono essere passate a un server back-end per l'autenticazione).
Diritti utente obbligatori: l'account utente che accede al server deve disporre delle autorizzazioni "Accedi al computer dalla rete".
Tipo di crittografia: algoritmo hash NTLM anche non codificato.

Ordini di precedenza: Quando il browser effettua una richiesta, considera sempre la prima richiesta anonima. Pertanto, non invia credenziali. Se il server non accetta or anonimo se l'account utente anonimo impostato nel server non dispone delle autorizzazioni per il file richiesto, il server IIS risponde con un messaggio di errore Accesso negato e invia un elenco dei tipi di autenticazione supportati tramite uno degli scenari seguenti:

Se La richiesta di verifica/risposta di Windows NT è l'unico metodo supportato (o se Anonymous ha esito negativo), il browser deve supportare questo metodo per comunicare con il server. In caso contrario, non può negoziare con il server e l'utente riceve un messaggio di errore accesso negato .
Se Basic è l'unico metodo supportato (o se Anonymous ha esito negativo), nel browser viene visualizzata una finestra di dialogo per ottenere le credenziali e quindi queste credenziali vengono passate al server. Tenta di inviare queste credenziali fino a tre volte. Se tutte queste operazioni hanno esito negativo, il browser non è connesso al server.
Se sono supportati sia la richiesta di verifica/risposta di Base che Quella di Windows NT, il browser determina quale metodo viene usato. Se il browser supporta la richiesta di verifica/risposta di Windows NT, usa questo metodo e non esegue il backback a Basic. Se La richiesta di verifica/risposta di Windows NT non è supportata, il browser usa Basic.

Nota

Quando il browser stabilisce una connessione con un sito Web tramite Basic o NTLM l'autenticazione, non esegue il back a Anonymous durante il resto della sessione con il server. Se si tenta di connettersi a una pagina Web contrassegnata come Anonima solo dopo l'autenticazione, verrà negato. (Questo può o non può essere vero per Netscape).
Quando Internet Explorer ha stabilito una connessione con il server tramite Basic o NTLM l'autenticazione, passa le credenziali per ogni nuova richiesta per la durata della sessione.

Metodi di autenticazione disponibili per Windows 2000 e versioni successive

Browser supportati: qualsiasi
Limitazioni: Nessuna
Diritti utente obbligatori: l'account utente anonimo definito nel server deve disporre delle autorizzazioni di accesso in locale.
Tipo di crittografia: Nessuno

Browser supportati: qualsiasi
Limitazioni: non sicuro. Le password vengono facilmente decifrate.
Diritti utente obbligatori: l'account utente deve disporre dei diritti di accesso localmente
Tipo di crittografia: codifica base 64 (non vera crittografia)

Digest: il server richiede all'utente di accedere e invia anche un NONCE usato per crittografare la password. Il browser usa NONCE per crittografare la password e lo invia al server. Il server crittografa quindi la propria copia della password dell'utente e confronta i due. Se corrispondono e l'utente dispone delle autorizzazioni, viene concesso l'accesso.

Browser supportati: Internet Explorer 5 e versioni successive
Limitazioni: non sicuro come integrato. Richiede che il server abbia accesso a un server Active Directory configurato per l'autenticazione del digest.
Diritti utente necessari: richiede che le password abbiano "Salva password come testo non crittografato"
Tipo di crittografia: basato su NONCE inviato dal server.

Windows Integrato (suddiviso in due sottocategorie)

Kerberos: il server richiede a un utente di accedere. Se il browser supporta Kerberos, si verifica quanto segue:

IIS richiede l'autenticazione.
Se il client non ha eseguito l'accesso a un dominio, viene visualizzata una finestra di dialogo in Internet Explorer che richiede le credenziali e quindi contatta il KDC per richiedere e ricevere un ticket di concessione ticket. Invia quindi il ticket di concessione ticket insieme alle informazioni sul server IIS al KDC.
Se il client IE ha già eseguito correttamente l'accesso al dominio e ha ricevuto un ticket di concessione ticket, invia questo ticket insieme alle informazioni sul server IIS al KDC
Il KDC invia al client un ticket di risorsa.
Il client passa questo ticket al server IIS.

Kerberos usa i ticket generati in un server di concessione ticket (KDC) per l'autenticazione. Invia questo ticket al server IIS. Il browser NON invia la password dell'utente al server.

Browser supportati: Internet Explorer versione 5.0 e successive
Limitazioni: il server deve avere accesso a un server Active Directory. Sia il server che il client devono avere una connessione attendibile a un KDC.
Diritti utente obbligatori: l'account utente anonimo definito nel server deve disporre delle autorizzazioni di accesso locale .
Tipo di crittografia: ticket crittografato.

Richiesta/risposta di Windows NT: il server richiede all'utente di accedere. Se il browser supporta la richiesta di verifica/risposta di Windows NT, invia automaticamente le credenziali dell'utente se l'utente è connesso. Se il dominio in cui si trova l'utente è diverso dal dominio del server o se l'utente non è connesso, in Internet Explorer viene visualizzata una finestra di dialogo che richiede le credenziali da inviare. La richiesta di verifica/risposta di Windows NT usa un algoritmo per generare un hash in base alle credenziali dell'utente e al computer in uso. Invia quindi questo hash al server. Il browser non invia la password dell'utente al server.

Browser supportati: Internet Explorer versioni 3.01 e successive.
Limitazioni: richiede una connessione da punto a punto. In genere, un circuito viene chiuso dopo un messaggio di errore "401 non autorizzato"; tuttavia, quando si negozia una sequenza di autenticazione con richiesta/risposta di Windows NT (che richiede più round trip), il server mantiene aperto il circuito per la durata della sequenza dopo che il client ha indicato che userà la richiesta/risposta di Windows NT. I proxy CERN e alcuni altri dispositivi Internet impediscono il funzionamento. Inoltre, la richiesta di verifica/risposta di Windows NT non supporta le rappresentazione a doppio hop, ovvero una volta passato al server IIS, le stesse credenziali non possono essere passate a un server back-end per l'autenticazione, ad esempio quando IIS usa la richiesta di verifica/risposta di Windows NT, non può quindi autenticare l'utente in un database SQL Server in un altro computer usando la sicurezza integrata di SQL.
Diritti utente obbligatori: l'account utente che accede al server deve disporre delle autorizzazioni "Accedi al computer dalla rete".
Tipo di crittografia: algoritmo hash NTLM anche non codificato.

Ordini di precedenza: Quando il browser effettua una richiesta, considera sempre la prima richiesta anonima. Pertanto, non invia credenziali. Se il server non accetta Anonimo o se l'account utente anonimo impostato nel server non dispone delle autorizzazioni per il file richiesto, il server IIS risponde con un messaggio di errore Accesso negato e invia un elenco dei tipi di autenticazione supportati tramite uno degli scenari seguenti:

Se Windows Integrated è l'unico metodo supportato (o se Anonymous ha esito negativo), il browser deve supportare questo metodo per comunicare con il server. In caso di errore, il server non prova nessuno degli altri metodi.
Se Basic è l'unico metodo supportato (o se Anonymous ha esito negativo), viene visualizzata una finestra di dialogo in per ottenere le credenziali e quindi le passa al server. Tenta di inviare le credenziali fino a tre volte. In caso di esito negativo, il browser non si connette al server.
Se sono supportati sia Basic che Windows Integrated, il browser determina quale metodo viene usato. Se il browser supporta Kerberos o Windows NT Challenge/Response, usa questo metodo. Non torna a Basic. Se La richiesta di verifica/risposta di Windows NT e Kerberos non sono supportate, il browser usa Basic, Digest o Fortezza se supporta queste funzionalità. L'ordine di precedenza è Basic, Digest e quindi Fortezza.

Nota

Quando il browser stabilisce una connessione a un sito Web usando l'autenticazione di base o integrata di Windows, non viene eseguito il backback a Anonymous durante il resto della sessione con il server. Se si tenta di connettersi a una pagina Web contrassegnata per Anonimo solo dopo l'autenticazione, viene negato. (Questo può o non può essere vero per Netscape).
Quando Internet Explorer ha stabilito una connessione con il server usando un metodo di autenticazione diverso da Anonimo, passa automaticamente le credenziali per ogni nuova richiesta durante la durata della sessione.

Riferimenti

Per altre informazioni su come configurare l'autenticazione del sito Web IIS in Windows Server 2003, vedere Come configurare l'autenticazione del sito Web IIS in Windows Server 2003.