IIS autentiserar webbläsarklienter

Artikel
07/17/2023

Den här artikeln beskriver hur IIS autentiserar webbläsarklienter.

Ursprunglig produktversion: Internet Explorer
Ursprungligt KB-nummer: 264921

Sammanfattning

I den här artikeln beskrivs de olika autentiseringsmetoder som är tillgängliga i IIS för Windows NT 4.0, Windows 2000 och senare Windows-versioner. En mer fullständig beskrivning av den information som beskrivs i den här artikeln finns i resursguiderna för Windows NT 4.0 och Windows 2000.

Autentiseringsmetoder som är tillgängliga för Windows NT 4.0

Anonym – Ingen inloggning krävs och alla får åtkomst till data som skyddas med den här metoden. Servern använder ett inbyggt konto (IUSR_[datornamn] som standard) för att styra filernas behörigheter. Webbläsaren skickar inga autentiseringsuppgifter eller användarinformation med den här typen av begäran.

Webbläsare som stöds: Alla
Begränsningar: Ingen
Användarrättigheter krävs: Det anonyma användarkonto som definierats på servern måste ha inloggningsbehörighet lokalt .
Krypteringstyp: Ingen

Grundläggande (klartext) – Servern begär att användaren loggar in och en dialogruta visas i webbläsaren som gör att användaren kan ange de autentiseringsuppgifter som behövs. Dessa autentiseringsuppgifter måste matcha de användarautentiseringsuppgifter som definierats för de filer som användaren försöker komma åt.

Webbläsare som stöds: Alla
Begränsningar: Inte säker. Lösenord dechiffreras enkelt.
Användarrättigheter krävs: Användarkontot måste ha inloggningsbehörighet lokalt .
Krypteringstyp: Base 64-kodning (inte sann kryptering)

Windows NT Challenge/Response – servern begär att användaren loggar in. Om webbläsaren stöder Windows NT Challenge/Response skickar den automatiskt användarens autentiseringsuppgifter om användaren är inloggad. Om domänen som användaren är på skiljer sig från serverns domän, eller om användaren inte är inloggad, visas en dialogruta för att begära att autentiseringsuppgifterna ska skickas. Windows NT Challenge/Response använder en algoritm för att generera en hash baserat på användarens autentiseringsuppgifter och den dator som användaren använder. Den skickar sedan denna hash till servern. Webbläsaren skickar inte användarens lösenord till servern.

Webbläsare som stöds: Internet Explorer version 3.01 och senare
Begränsningar: Kräver punkt-till-punkt-anslutning. Vanligtvis stängs en krets efter ett felmeddelande av typen "401 obehörig". Men när du förhandlar om en Windows NT Challenge/Response-autentiseringssekvens (som kräver flera turer) håller servern kretsen öppen under sekvensens varaktighet efter att klienten har angett att den kommer att använda Windows NT Challenge/Response. CERN-proxyservrar och vissa andra Internetenheter förhindrar att detta fungerar. Dessutom stöder Windows NT Challenge/Response inte dubbelhoppspersonifieringar (eftersom samma autentiseringsuppgifter inte kan skickas till en serverdelsserver för autentisering när de väl har skickats till IIS-servern).
Användarrättigheter krävs: Användarkontot som ansluter till servern måste ha behörigheten "Åtkomst till den här datorn från nätverket".
Krypteringstyp: NTLM-hashalgoritm som också är okodad.

Prioritetsordning: När webbläsaren gör en begäran anser den alltid att den första begäran är anonym. Därför skickar den inga autentiseringsuppgifter. Om servern inte accepterar anonym eller om det anonyma användarkontot som angetts på servern inte har behörighet till filen som begärs svarar IIS-servern med ett felmeddelande om nekad åtkomst och skickar en lista över de autentiseringstyper som stöds med hjälp av något av följande scenarier:

Om Windows NT Challenge/Response är den enda metod som stöds (eller om Anonym misslyckas) måste webbläsaren ha stöd för den här metoden för att kommunicera med servern. Annars kan den inte förhandla med servern och användaren får felmeddelandet Åtkomst nekad .
Om Basic är den enda metod som stöds (eller om Anonym misslyckas) visas en dialogruta i webbläsaren för att hämta autentiseringsuppgifterna och skickar sedan dessa autentiseringsuppgifter till servern. Den försöker skicka dessa autentiseringsuppgifter upp till tre gånger. Om allt detta misslyckas är webbläsaren inte ansluten till servern.
Om både Basic och Windows NT Challenge/Response stöds avgör webbläsaren vilken metod som används. Om webbläsaren stöder Windows NT Challenge/Response använder den den här metoden och återgår inte till Basic. Om Windows NT Challenge/Response inte stöds använder webbläsaren Basic.

Obs!

När webbläsaren upprättar en anslutning till en webbplats med hjälp Basic av eller NTLM autentisering återgår den inte till Anonym under resten av sessionen med servern. Om du försöker ansluta till en webbsida som endast har markerats för Anonym efter autentiseringen nekas du. (Detta kan eller kanske inte gäller för Netscape).
När Internet Explorer har upprättat en anslutning till servern med hjälp Basic av eller NTLM autentisering skickar den autentiseringsuppgifterna för varje ny begäran under hela sessionen.

Autentiseringsmetoder som är tillgängliga för Windows 2000 och senare

Webbläsare som stöds: Alla
Begränsningar: Ingen
Användarrättigheter krävs: Det anonyma användarkonto som definierats på servern måste ha behörighet att logga in lokalt.
Krypteringstyp: Ingen

Webbläsare som stöds: Alla
Begränsningar: Inte säker. Lösenord dechiffreras enkelt.
Användarrättigheter krävs: Användarkontot måste ha inloggningsbehörighet lokalt
Krypteringstyp: Base 64-kodning (inte sann kryptering)

Sammanfattad – servern begär att användaren loggar in och skickar även en NONCE som används för att kryptera lösenordet. Webbläsaren använder NONCE för att kryptera lösenordet och skickar det till servern. Servern krypterar sedan sin egen kopia av användarens lösenord och jämför de två. Om de matchar och användaren har behörigheter beviljas åtkomst.

Webbläsare som stöds: Internet Explorer 5 och senare versioner
Begränsningar: Inte lika säker som integrerad. Kräver att servern har åtkomst till en Active Directory-server som har konfigurerats för sammanfattad autentisering.
Användarrättigheter krävs: Kräver att lösenord har "Spara lösenord som krypterad klartext"
Krypteringstyp: Baserat på NONCE som skickas av servern.

Windows Integrated (uppdelat i två underkategorier)

Kerberos – servern begär att en användare loggar in. Om webbläsaren stöder Kerberos sker följande:

IIS begär autentisering.
Om klienten inte har loggat in på en domän visas en dialogruta i Internet Explorer som begär autentiseringsuppgifter och kontaktar sedan KDC för att begära och ta emot en biljettbeviljande biljett. Den skickar sedan biljettbeviljande biljett tillsammans med information om IIS-servern till KDC.
Om IE-klienten redan har loggat in på domänen och tagit emot en biljettbeviljande biljett skickar den den här biljetten tillsammans med information om IIS-servern till KDC
KDC utfärdar en resursbiljett till klienten.
Klienten skickar det här ärendet till IIS-servern.

Kerberos använder biljetter som genererats på en biljettbeviljande server (KDC) för att autentisera. Det skickar det här ärendet till IIS-servern. Webbläsaren skickar INTE användarens lösenord till servern.

Webbläsare som stöds: Internet Explorer version 5.0 och senare
Begränsningar: Servern måste ha åtkomst till en Active Directory-server. Både servern och klienten måste ha en betrodd anslutning till en KDC.
Användarrättigheter krävs: Det anonyma användarkonto som definierats på servern måste ha inloggningsbehörighet lokalt .
Krypteringstyp: Krypterad biljett.

Windows NT Challenge/Response – servern begär att användaren loggar in. Om webbläsaren stöder Windows NT Challenge/Response skickar den automatiskt användarens autentiseringsuppgifter om användaren är inloggad. Om domänen som användaren är på skiljer sig från serverns domän, eller om användaren inte är inloggad, visas en dialogruta i Internet Explorer där autentiseringsuppgifterna ska skickas. Windows NT Challenge/Response använder en algoritm för att generera en hash baserat på användarens autentiseringsuppgifter och den dator som användaren använder. Den skickar sedan denna hash till servern. Webbläsaren skickar inte användarens lösenord till servern.

Webbläsare som stöds: Internet Explorer version 3.01 och senare.
Begränsningar: Kräver punkt-till-punkt-anslutning. Vanligtvis stängs en krets efter felmeddelandet "401 obehörig". Men när du förhandlar om en Windows NT Challenge/Response-autentiseringssekvens (som kräver flera turer) håller servern kretsen öppen under sekvensens varaktighet efter att klienten har angett att den kommer att använda Windows NT Challenge/Response. CERN-proxyservrar och vissa andra Internetenheter förhindrar att detta fungerar. Dessutom har Windows NT Challenge/Response inte stöd för dubbelhoppspersonifieringar (vilket innebär att samma autentiseringsuppgifter inte kan skickas till en serverdelsserver för autentisering när IIS använder Windows NT Challenge/Response och sedan inte kan autentisera användaren mot en SQL Server databas på en annan dator med hjälp av SQL-integrerad säkerhet).
Användarrättigheter krävs: Användarkontot som ansluter till servern måste ha behörigheten "Åtkomst till den här datorn från nätverket".
Krypteringstyp: NTLM-hashalgoritm som också är okodad.

Prioritetsordning: När webbläsaren gör en begäran anser den alltid att den första begäran är anonym. Därför skickar den inga autentiseringsuppgifter. Om servern inte accepterar Anonym eller om det anonyma användarkonto som angetts på servern inte har behörighet till filen som begärs svarar IIS-servern med ett felmeddelande om nekad åtkomst och skickar en lista över de autentiseringstyper som stöds med något av följande scenarier:

Om Windows Integrated är den enda metod som stöds (eller om Anonym misslyckas) måste webbläsaren ha stöd för den här metoden för att kommunicera med servern. Om detta misslyckas provar servern inte någon av de andra metoderna.
Om Basic är den enda metod som stöds (eller om Anonym misslyckas) visas en dialogruta i för att hämta autentiseringsuppgifterna och skickar sedan dessa till servern. Den försöker skicka autentiseringsuppgifterna upp till tre gånger. Om allt detta misslyckas ansluter inte webbläsaren till servern.
Om både Basic och Windows Integrated stöds avgör webbläsaren vilken metod som används. Om webbläsaren stöder Kerberos eller Windows NT Challenge/Response används den här metoden. Den återgår inte till Basic. Om Windows NT Challenge/Response och Kerberos inte stöds använder webbläsaren Basic, Digest eller Fortezza om den stöder dessa. Prioritetsordningen här är Basic, Digest och sedan Fortezza.

Obs!

När webbläsaren upprättar en anslutning till en webbplats med hjälp av grundläggande eller Windows-integrerad autentisering återgår den inte till Anonym under resten av sessionen med servern. Om du försöker ansluta till en webbsida som endast har markerats för Anonym efter autentisering nekas du. (Detta kan eller kanske inte gäller för Netscape).
När Internet Explorer har upprättat en anslutning till servern med en annan autentiseringsmetod än Anonym skickar den automatiskt autentiseringsuppgifterna för varje ny begäran under sessionens varaktighet.

Referenser

Mer information om hur du konfigurerar IIS-webbplatsautentisering i Windows Server 2003 finns i Konfigurera IIS-webbplatsautentisering i Windows Server 2003.

Dela via