Kommentar
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
av Mike Wasson
Med integrerad Windows-autentisering kan användarna logga in med sina Windows-autentiseringsuppgifter med Kerberos eller NTLM. Klienten skickar autentiseringsuppgifter i auktoriseringshuvudet. Windows-autentisering passar bäst för en intranätmiljö. Mer information finns i Windows-autentisering.
| Fördelar | Disadvantages |
|---|---|
| Inbyggd i IIS. | Rekommenderas inte för Internetprogram. |
| Skickar inte användarautentiseringsuppgifterna i begäran. | Kräver Kerberos- eller NTLM-stöd i klienten. |
| Om klientdatorn tillhör domänen (till exempel intranätprogram) behöver användaren inte ange autentiseringsuppgifter. | Klienten måste finnas i Active Directory-domänen. |
Anmärkning
Om ditt program finns i Azure och du har en lokal Active Directory-domän kan du överväga att federera din lokala AD med Azure Active Directory. På så sätt kan användare logga in med sina lokala autentiseringsuppgifter, men autentiseringen utförs av Azure AD. Mer information finns i Azure Authentication.
Om du vill skapa ett program som använder integrerad Windows-autentisering väljer du mallen "Intranätprogram" i MVC 4-projektguiden. Den här projektmallen placerar följande inställning i filen Web.config:
<system.web>
<authentication mode="Windows" />
</system.web>
På klientsidan fungerar integrerad Windows-autentisering med alla webbläsare som stöder negotiate-autentiseringsschemat, som innehåller de flesta större webbläsare. För .NET-klientprogram stöder klassen HttpClient Windows-autentisering:
HttpClientHandler handler = new HttpClientHandler()
{
UseDefaultCredentials = true
};
HttpClient client = new HttpClient(handler);
Windows-autentisering är sårbart för attacker av typen Cross-Site Request Forgery (CSRF). Se Förhindra förfalskning av begäranden mellan webbplatser (CSRF).