Konfigurera Windows-autentisering i ASP.NET Core

Windows-autentisering (kallas även Negotiate, Kerberos eller NTLM-autentisering) kan konfigureras för ASP.NET Core-appar som hanteras med IIS, Kestreleller HTTP.sys.

Windows-autentisering förlitar sig på operativsystemet för att autentisera användare av ASP.NET Core-appar. Windows-autentisering används för servrar som körs i ett företagsnätverk med hjälp av Active Directory-domänidentiteter eller Windows-konton för att identifiera användare. Windows-autentisering passar bäst för intranätmiljöer där användare, klientappar och webbservrar tillhör samma Windows-domän.

När du ska använda Windows-autentisering

Windows-autentisering är lämpligt för webbprogram som fungerar i en organisations privata interna nätverk, som endast är tillgängliga för anställda (och andra behöriga användare) i samma nätverk. Användarhanteringen görs i Active Directory (AD) och användarna använder sitt befintliga Windows-domänkonto för att autentisera.

Windows-autentisering ger flera fördelar för intranätprogram:

• Sömlös användarupplevelse – Användarna autentiseras automatiskt baserat på sin aktiva Windows-session eller uppmanas att ange sina Windows-autentiseringsuppgifter via en standardwebbläsare.
• Integrering med Active Directory – Utnyttjar befintlig Windows-infrastruktur och säkerhetsprinciper, inklusive användargrupper, kontoutelåsningar och multifaktorautentisering (MFA).
• Säker hantering av autentiseringsuppgifter – Autentisering hanteras via säkra protokoll som Kerberos, utan att du behöver hantera separata användarautentiseringsuppgifter.
• Rollbaserad auktorisering – Program kan komma åt användar- och gruppinformation från Active Directory och aktivera rollbaserad åtkomstkontroll (RBAC) i programmet.
• Minskade administrativa kostnader – Du behöver inte underhålla en separat användardatabas eller ett hanteringssystem för autentiseringsuppgifter.

Detta gör Windows-autentisering idealiskt för organisationer som vill använda sin befintliga Windows-infrastruktur, till exempel intranätportaler.

Windows-autentisering rekommenderas inte för offentliga program på grund av säkerhets- och användbarhetsproblem. Följande orsaker är:

• Windows-autentisering hålls bäst internt för att skydda Active Directory, vilket innebär säkerhetsrisker om det exponeras utanför ett internt nätverk.
• Externa användare har inte Windows-domänkonton.
• Det är komplext att konfigurera den nödvändiga nätverksinfrastrukturen på ett säkert sätt, och brandväggar eller proxyservrar kan störa autentiseringsprocessen.
• Det är inte plattformsoberoende och tillhandahåller inte anpassningsalternativ för design och användarupplevelser.

Alternativ för olika scenarier

Beroende på dina programkrav bör du överväga följande alternativ:

För offentliga program:

• OpenID Connect med externa identitetsprovidrar
• ASP.NET Core Identity med lokala användarkonton (introduktion till Identity på ASP.NET Core)
• Azure Active Directory (AAD) för Microsoft 365-miljöer

För blandade miljöer med både intranät och externa användare:

• Active Directory Federation Services (ADFS) med OpenID Connect
• Azure Active Directory med hybridkonfiguration

För företagsmiljöer med modern autentisering:

• Azure Active Directory med enkel inloggning
• SAML-baserade lösningar med identitetsprovidrar från tredje part

Proxy- och lastbalanseringsscenarier

Windows-autentisering är ett tillståndskänsligt scenario som främst används i ett intranät, där en proxy eller lastbalanserare vanligtvis inte hanterar trafik mellan klienter och servrar. Om en proxy eller lastbalanserare används fungerar Windows-autentisering endast om proxyn eller lastbalanseraren:

• Hanterar autentiseringen.
• Skickar användarautentiseringsinformationen till appen (till exempel i ett begärandehuvud), som agerar på autentiseringsinformationen.

Ett alternativ till Windows-autentisering i miljöer där proxyservrar och lastbalanserare används är Active Directory Federated Services (ADFS) med OpenID Connect (OIDC).

IIS/IIS Express

Lägg till NuGet-paketetMicrosoft.AspNetCore.Authentication.Negotiate och autentiseringstjänster genom att anropa AddAuthentication i Program.cs:

using Microsoft.AspNetCore.Authentication.Negotiate;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddAuthentication(NegotiateDefaults.AuthenticationScheme)
   .AddNegotiate();

builder.Services.AddAuthorization(options =>
{
    options.FallbackPolicy = options.DefaultPolicy;
});
builder.Services.AddRazorPages();

var app = builder.Build();
if (!app.Environment.IsDevelopment())
{
    app.UseExceptionHandler("/Error");
    app.UseHsts();
}

app.UseHttpsRedirection();
app.UseStaticFiles();

app.UseRouting();

app.UseAuthentication();
app.UseAuthorization();

app.MapRazorPages();

app.Run();

Föregående kod genererades av mallen ASP.NET Core Razor Pages med Windows-autentisering angiven.

Starta inställningar (felsökningsprogram)

Konfigurationen för startinställningar påverkar Properties/launchSettings.json endast filen för IIS Express och konfigurerar inte IIS för Windows-autentisering. Serverkonfigurationen beskrivs i avsnittet IIS .

De webbprogrammallar som är tillgängliga via Visual Studio eller .NET CLI kan konfigureras för att stödja Windows-autentisering, vilket uppdaterar Properties/launchSettings.json filen automatiskt.

"iisSettings": {
    "windowsAuthentication": true,
    "anonymousAuthentication": false,
    "iisExpress": {
        "applicationUrl": "http://localhost:52171/",
        "sslPort": 44308
    }
}

dotnet new webapp --auth Windows

"iisSettings": {
    "windowsAuthentication": true,
    "anonymousAuthentication": false,
    "iisExpress": {
        "applicationUrl": "http://localhost:52171/",
        "sslPort": 44308
    }
}

IIS

IIS använder ASP.NET Core-modulen som värd för ASP.NET Core-appar. Windows-autentisering konfigureras för IIS via filenweb.config . Följande avsnitt visar hur du:

• Ange en lokal web.config fil som aktiverar Windows-autentisering på servern när appen distribueras.
• Använd IIS-hanteraren för att konfigurera web.config-filen för en ASP.NET Core-app som redan har distribuerats till servern.

Om du inte redan har gjort det aktiverar du IIS som värd för ASP.NET Core-appar. Mer information finns i Host ASP.NET Core i Windows med IIS.

Aktivera IIS-rolltjänsten för Windows-autentisering. Mer information finns i Aktivera Windows-autentisering i IIS Role Services (se Steg 2).

IIS Integration Middleware har konfigurerats för att automatiskt autentisera begäranden som standard. Mer information finns i Host ASP.NET Core on Windows with IIS: IIS options (AutomaticAuthentication).

ASP.NET Core-modulen är konfigurerad för att vidarebefordra Windows-autentiseringstoken till appen som standard. Mer information finns i konfigurationsreferensen för ASP.NET Core Module: Attribut för aspNetCore-elementet.

Använd någon av följande metoder:

• Innan du publicerar och distribuerar projektet lägger du till följande web.config fil i projektroten:

  <?xml version="1.0" encoding="utf-8"?>
  <configuration>
    <location path="." inheritInChildApplications="false">
      <system.webServer>
        <security>
          <authentication>
            <anonymousAuthentication enabled="false" />
            <windowsAuthentication enabled="true" />
          </authentication>
        </security>
      </system.webServer>
    </location>
  </configuration>
  

  När projektet publiceras av .NET SDK (utan att egenskapen <IsTransformWebConfigDisabled> är satt till true i projektfilen) innehåller den publicerade web.config-filen <location><system.webServer><security><authentication> avsnittet. Mer information om egenskapen finns i <IsTransformWebConfigDisabled>web.config fil.

• När du har publicerat och distribuerat projektet utför du konfiguration på serversidan med IIS-hanteraren:

  1. I IIS-hanteraren väljer du IIS-webbplatsen under noden Platser i sidofältet Anslutningar .
  2. Dubbelklicka på Autentisering i IIS-området .
  3. Välj Anonym autentisering. Välj Inaktivera i sidofältet Åtgärder .
  4. Välj Windows-autentisering. Välj Aktivera i sidofältet Åtgärder .

  När dessa åtgärder vidtas ändrar IIS Manager appens web.config fil. En <system.webServer><security><authentication> nod läggs till med uppdaterade inställningar för anonymousAuthentication och windowsAuthentication:

  <system.webServer>
    <security>
      <authentication>
        <anonymousAuthentication enabled="false" />
        <windowsAuthentication enabled="true" />
      </authentication>
    </security>
  </system.webServer>
  

  Avsnittet <system.webServer> som läggs till i web.config-filen av IIS Manager ligger utanför appens <location> avsnitt som läggs till av .NET SDK när appen publiceras. Eftersom avsnittet läggs till utanför <location> noden ärvs inställningarna av alla underappar till den aktuella appen. Om du vill förhindra arv flyttar du det tillagda <security> avsnittet i avsnittet <location><system.webServer> som .NET SDK har angett.

  När IIS-hanteraren används för att lägga till IIS-konfigurationen påverkar det bara appens web.config fil på servern. En efterföljande distribution av appen kan skriva över inställningarna på servern om serverns kopia av web.config ersätts av projektets web.config-fil . Använd någon av följande metoder för att hantera inställningarna:

  • Använd IIS-hanteraren för att återställa inställningarna i web.config-filen när filen har skrivits över vid distributionen.
  • Lägg till en web.config fil i appen lokalt med inställningarna.

Kestrel

Microsoft.AspNetCore.Authentication.Negotiate NuGet-paketet kan användas med Kestrel för att aktivera Windows-autentisering med hjälp av Negotiate och Kerberos i Windows, Linux och macOS.

Autentisering och en reservauktoriseringsprincip aktiveras med följande markerade kod i Program.cs:

using Microsoft.AspNetCore.Authentication.Negotiate;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddAuthentication(NegotiateDefaults.AuthenticationScheme)
   .AddNegotiate();

builder.Services.AddAuthorization(options =>
{
    options.FallbackPolicy = options.DefaultPolicy;
});
builder.Services.AddRazorPages();

var app = builder.Build();
if (!app.Environment.IsDevelopment())
{
    app.UseExceptionHandler("/Error");
    app.UseHsts();
}

app.UseHttpsRedirection();
app.UseStaticFiles();

app.UseRouting();

app.UseAuthentication();
app.UseAuthorization();

app.MapRazorPages();

app.Run();

Föregående kod genererades av mallen ASP.NET Core Razor Pages med Windows-autentisering angiven.

Markerade rader:

• 5–6: AddAuthentication och AddNegotiate registrera och konfigurera Negotiate-autentiseringshanteraren.
• 8–11: AddAuthorization med en reservprincip tillämpas autentiserade användare som standard.
• 26: UseAuthentication kör autentiseringshanterare för varje begäran och fyller i HttpContext.User.
• 27: UseAuthorization utvärderar auktoriseringsprinciper, inklusive reservprincipen.

Kerberos-autentisering och rollbaserad åtkomstkontroll (RBAC)

Kerberos-autentisering i Linux eller macOS tillhandahåller ingen rollinformation för en autentiserad användare. Om du vill lägga till roll- och gruppinformation till en Kerberos-användare måste autentiseringshanteraren konfigureras för att hämta rollerna från en LDAP-domän. Den mest grundläggande konfigurationen anger bara en LDAP-domän att fråga mot och använder den autentiserade användarens kontext för att fråga LDAP-domänen:

using Microsoft.AspNetCore.Authentication.Negotiate;
using System.Runtime.InteropServices;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddAuthentication(NegotiateDefaults.AuthenticationScheme)
    .AddNegotiate(options =>
    {
        if (RuntimeInformation.IsOSPlatform(OSPlatform.Linux))
        {
            options.EnableLdap("contoso.com");
        }
    });

Vissa konfigurationer kan kräva specifika autentiseringsuppgifter för att köra frågor mot LDAP-domänen. Autentiseringsuppgifterna kan anges i följande markerade alternativ:

using Microsoft.AspNetCore.Authentication.Negotiate;
using System.Runtime.InteropServices;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddAuthentication(NegotiateDefaults.AuthenticationScheme)
        .AddNegotiate(options =>
        {
            if (RuntimeInformation.IsOSPlatform(OSPlatform.Linux))
            {
                options.EnableLdap(settings =>
                {
                    settings.Domain = "contoso.com";
                    settings.MachineAccountName = "machineName";
                    settings.MachineAccountPassword =
                                      builder.Configuration["Password"];
                });
            }
        });

builder.Services.AddRazorPages();

Som standard löser förhandlande autentiseringshanterare kapslade domäner. I en stor eller komplicerad LDAP-miljö kan matchning av kapslade domäner resultera i en långsam sökning eller mycket minne som används för varje användare. Kapslad domänupplösning kan inaktiveras med alternativet IgnoreNestedGroups.

Anonyma begäranden tillåts. Använd ASP.NET Core Authorization för att utmana anonyma begäranden om autentisering.

Windows-miljökonfiguration

API:etMicrosoft.AspNetCore.Authentication.Negotiate utför autentisering i användarläge. Tjänstens huvudnamn (SPN) måste läggas till i användarkontot som kör tjänsten, inte datorkontot. Kör setspn -S HTTP/myservername.mydomain.com myuser i ett administrativt kommandogränssnitt.

Kerberos vs NTLM

Negotiate-paketet på Kestrel för ASP.NET Core försöker använda Kerberos, vilket är ett säkrare och mer peformant autentiseringsschema än NTLM:

using Microsoft.AspNetCore.Authentication.Negotiate;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddAuthentication(NegotiateDefaults.AuthenticationScheme)
   .AddNegotiate();

builder.Services.AddAuthorization(options =>
{
    options.FallbackPolicy = options.DefaultPolicy;
});
builder.Services.AddRazorPages();

var app = builder.Build();

NegotiateDefaults.AuthenticationScheme anger Kerberos eftersom det är standardvärdet.

IIS, IISExpress och Kestrel stöder både Kerberos och NTLM.

Undersöka rubriken WWW-Authenticate: med IIS eller IISExpress med verktyg som Fiddler visar antingen Negotiate eller NTLM.

Kestrel visar endast WWW-Authenticate: Negotiate

Rubriken WWW-Authenticate: Negotiate innebär att servern kan använda NTLM eller Kerberos. Kestrel Negotiate kräver huvudprefixet, det stöder inte direkt angiven NTLM i begärande- eller svarsautentiseringshuvudena. NTLM stöds i Kestrel, men det måste skickas som Negotiate.

För Kestrelatt se om NTLM eller Kerberos används avkodar Base64 huvudet och visar antingen NTLM eller HTTP. HTTP anger att Kerberos användes.

Linux- och macOS-miljökonfiguration

Instruktioner för att ansluta en Linux- eller macOS-dator till en Windows-domän finns i artikeln Anslut Azure Data Studio till din SQL Server med Hjälp av Windows-autentisering – Kerberos . Anvisningarna skapar ett datorkonto för Linux-datorn på domänen. SPN måste läggas till i det datorkontot.

När Linux- eller macOS-datorn har anslutits till domänen krävs ytterligare steg för att tillhandahålla en nyckelfliksfil med SPN:erna:

• På domänkontrollanten lägger du till nya webbtjänst-SPN:er i datorkontot:
  • setspn -S HTTP/mywebservice.mydomain.com mymachine
  • setspn -S HTTP/mywebservice@MYDOMAIN.COM mymachine
• Använd ktpass för att generera en nyckelfliksfil:
  • ktpass -princ HTTP/mywebservice.mydomain.com@MYDOMAIN.COM -pass myKeyTabFilePassword -mapuser MYDOMAIN\mymachine$ -pType KRB5_NT_PRINCIPAL -out c:\temp\mymachine.HTTP.keytab -crypto AES256-SHA1
  • Vissa fält måste anges med versaler som specificerat.
• Kopiera nyckelfliksfilen till Linux- eller macOS-datorn.
• Välj nyckelfliksfilen via en miljövariabel: export KRB5_KTNAME=/tmp/mymachine.HTTP.keytab
• Anropa klist för att visa de SPN:er som för närvarande är tillgängliga för användning.

HTTP.sys

HTTP.sys stöder Windows-autentisering i kernelläge med hjälp av Negotiate, NTLM eller Basic-autentisering.

Följande kod lägger till autentisering och konfigurerar appens webbvärd att använda HTTP.sys med Windows-autentisering:

using Microsoft.AspNetCore.Server.HttpSys;
using System.Runtime.InteropServices;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddAuthentication(HttpSysDefaults.AuthenticationScheme);

if (RuntimeInformation.IsOSPlatform(OSPlatform.Windows))
{
    builder.WebHost.UseHttpSys(options =>
        {
            options.Authentication.Schemes =
                AuthenticationSchemes.NTLM |
                AuthenticationSchemes.Negotiate;
            options.Authentication.AllowAnonymous = false;
        });
}

Auktorisera användare

Konfigurationstillståndet för anonym åtkomst avgör hur attributen [Authorize] och [AllowAnonymous] används i appen. I följande två avsnitt beskrivs hur du hanterar otillåtna och tillåtna konfigurationstillstånd för anonym åtkomst.

Tillåt inte anonym åtkomst

När Windows-autentisering är aktiverat och anonym åtkomst är inaktiverad har attributen [Authorize] och [AllowAnonymous] ingen effekt. Om en IIS-webbplats har konfigurerats för att neka anonym åtkomst når begäran aldrig appen. Därför [AllowAnonymous] är attributet inte tillämpligt.

Tillåt anonym åtkomst

När både Windows-autentisering och anonym åtkomst är aktiverade använder du attributen [Authorize] och [AllowAnonymous] . Med [Authorize] attributet kan du skydda slutpunkter för appen som kräver autentisering. Attributet [AllowAnonymous] åsidosätter [Authorize] attributet i appar som tillåter anonym åtkomst. Information om attributanvändning finns i Enkel auktorisering i ASP.NET Core.

Impersonation

ASP.NET Core implementerar inte personifiering. Appar körs med appens identitet för alla begäranden med hjälp av apppoolen eller processidentiteten. Om appen ska utföra en åtgärd för en användares räkning använder du WindowsIdentity.RunImpersonated eller RunImpersonatedAsync i ett terminalt inline-mellanprogram i Program.cs. Kör en enda åtgärd i den här kontexten och stäng sedan kontexten.

app.Run(async (context) =>
{
    try
    {
        var user = (WindowsIdentity)context.User.Identity!;

        await context.Response
            .WriteAsync($"User: {user.Name}\tState: {user.ImpersonationLevel}\n");

        await WindowsIdentity.RunImpersonatedAsync(user.AccessToken, async () =>
        {
            var impersonatedUser = WindowsIdentity.GetCurrent();
            var message =
                $"User: {impersonatedUser.Name}\t" +
                $"State: {impersonatedUser.ImpersonationLevel}";

            var bytes = Encoding.UTF8.GetBytes(message);
            await context.Response.Body.WriteAsync(bytes, 0, bytes.Length);
        });
    }
    catch (Exception e)
    {
        await context.Response.WriteAsync(e.ToString());
    }
});

Microsoft.AspNetCore.Authentication.Negotiate Även om paketet möjliggör autentisering i Windows, Linux och macOS stöds personifiering endast i Windows.

Anspråkstransformeringar

Vid värdskap med IIS, anropas AuthenticateAsync inte internt för att initiera en användare. Därför aktiveras inte en IClaimsTransformation implementering som används för att omvandla anspråk efter varje autentisering som standard. Mer information och ett kodexempel som aktiverar anspråkstransformeringar finns i Skillnader mellan in-process och out-of-process hosting.

Ytterligare resurser

• dotnet publicera
• Köra ASP.NET Core på Windows med IIS
• ASP.NET Core Module (ANCM) för IIS
• Visual Studio publicerar profiler (.pubxml) för ASP.NET Core-appdistribution

Windows-autentisering (kallas även Negotiate, Kerberos eller NTLM-autentisering) kan konfigureras för ASP.NET Core-appar som hanteras med IIS, Kestreleller HTTP.sys.

Windows-autentisering förlitar sig på operativsystemet för att autentisera användare av ASP.NET Core-appar. Du kan använda Windows-autentisering när servern körs i ett företagsnätverk med hjälp av Active Directory-domänidentiteter eller Windows-konton för att identifiera användare. Windows-autentisering passar bäst för intranätmiljöer där användare, klientappar och webbservrar tillhör samma Windows-domän.

När du ska använda Windows-autentisering

Windows-autentisering är lämpligt för webbprogram som fungerar i en organisations privata interna nätverk, som endast är tillgängliga för anställda (och andra behöriga användare) i samma nätverk. Användarhanteringen görs i Active Directory (AD) och användarna använder sitt befintliga Windows-domänkonto för att autentisera.

Windows-autentisering ger flera fördelar för intranätprogram:

• Sömlös användarupplevelse – Användarna autentiseras automatiskt baserat på sin aktiva Windows-session eller uppmanas att ange sina Windows-autentiseringsuppgifter via en standardwebbläsare.
• Integrering med Active Directory – Utnyttjar befintlig Windows-infrastruktur och säkerhetsprinciper, inklusive användargrupper, kontoutelåsningar och multifaktorautentisering (MFA).
• Säker hantering av autentiseringsuppgifter – Autentisering hanteras via säkra protokoll som Kerberos, utan att du behöver hantera separata användarautentiseringsuppgifter.
• Rollbaserad auktorisering – Program kan komma åt användar- och gruppinformation från Active Directory och aktivera rollbaserad åtkomstkontroll (RBAC) i programmet.
• Minskade administrativa kostnader – Du behöver inte underhålla en separat användardatabas eller ett hanteringssystem för autentiseringsuppgifter.

Detta gör Windows-autentisering idealiskt för organisationer som vill använda sin befintliga Windows-infrastruktur, till exempel intranätportaler.

Windows-autentisering rekommenderas inte för offentliga program på grund av säkerhets- och användbarhetsproblem. Följande orsaker är:

• Windows-autentisering hålls bäst internt för att skydda Active Directory, vilket innebär säkerhetsrisker om det exponeras utanför ett internt nätverk.
• Externa användare har inte Windows-domänkonton.
• Det är komplext att konfigurera den nödvändiga nätverksinfrastrukturen på ett säkert sätt, och brandväggar eller proxyservrar kan störa autentiseringsprocessen.
• Det är inte plattformsoberoende och tillhandahåller inte anpassningsalternativ för design och användarupplevelser.

Alternativ för olika scenarier

Beroende på dina programkrav bör du överväga följande alternativ:

För offentliga program:

• OpenID Connect med externa identitetsprovidrar
• ASP.NET Core Identity med lokala användarkonton (introduktion till Identity på ASP.NET Core)
• Azure Active Directory (AAD) för Microsoft 365-miljöer

För blandade miljöer med både intranät och externa användare:

• Active Directory Federation Services (ADFS) med OpenID Connect
• Azure Active Directory med hybridkonfiguration

För företagsmiljöer med modern autentisering:

• Azure Active Directory med enkel inloggning
• SAML-baserade lösningar med identitetsprovidrar från tredje part

Proxy- och lastbalanseringsscenarier

Windows-autentisering är ett tillståndskänsligt scenario som främst används i ett intranät, där en proxy eller lastbalanserare vanligtvis inte hanterar trafik mellan klienter och servrar. Om en proxy eller lastbalanserare används fungerar Windows-autentisering endast om proxyn eller lastbalanseraren:

• Hanterar autentiseringen.
• Skickar användarautentiseringsinformationen till appen (till exempel i ett begärandehuvud), som agerar på autentiseringsinformationen.

Ett alternativ till Windows-autentisering i miljöer där proxyservrar och lastbalanserare används är Active Directory Federated Services (ADFS) med OpenID Connect (OIDC).

IIS/IIS Express

Lägg till autentiseringstjänster genom att anropa AddAuthentication (Microsoft.AspNetCore.Server.IISIntegration namnområde) i Startup.ConfigureServices:

services.AddAuthentication(IISDefaults.AuthenticationScheme);

Starta inställningar (felsökningsprogram)

Konfigurationen för startinställningar påverkar Properties/launchSettings.json endast filen för IIS Express och konfigurerar inte IIS för Windows-autentisering. Serverkonfigurationen beskrivs i avsnittet IIS .

Webbprogrammallen som är tillgänglig via Visual Studio eller .NET CLI kan konfigureras för att stödja Windows-autentisering, vilket uppdaterar Properties/launchSettings.json filen automatiskt.

"iisSettings": {
    "windowsAuthentication": true,
    "anonymousAuthentication": false,
    "iisExpress": {
        "applicationUrl": "http://localhost:52171/",
        "sslPort": 44308
    }
}

dotnet new webapp --auth Windows

"iisSettings": {
    "windowsAuthentication": true,
    "anonymousAuthentication": false,
    "iisExpress": {
        "applicationUrl": "http://localhost:52171/",
        "sslPort": 44308
    }
}

När du ändrar ett befintligt projekt kontrollerar du att projektfilen innehåller en paketreferens för Microsoft.AspNetCore.App metapaketetellerMicrosoft.AspNetCore.Authentication NuGet-paketet.

IIS

IIS använder ASP.NET Core-modulen som värd för ASP.NET Core-appar. Windows-autentisering konfigureras för IIS via filenweb.config . Följande avsnitt visar hur du:

• Ange en lokal web.config fil som aktiverar Windows-autentisering på servern när appen distribueras.
• Använd IIS-hanteraren för att konfigurera web.config-filen för en ASP.NET Core-app som redan har distribuerats till servern.

Om du inte redan har gjort det aktiverar du IIS som värd för ASP.NET Core-appar. Mer information finns i Host ASP.NET Core i Windows med IIS.

Aktivera IIS-rolltjänsten för Windows-autentisering. Mer information finns i Aktivera Windows-autentisering i IIS Role Services (se Steg 2).

IIS Integration Middleware har konfigurerats för att automatiskt autentisera begäranden som standard. Mer information finns i Host ASP.NET Core on Windows with IIS: IIS options (AutomaticAuthentication).

ASP.NET Core-modulen är konfigurerad för att vidarebefordra Windows-autentiseringstoken till appen som standard. Mer information finns i konfigurationsreferensen för ASP.NET Core Module: Attribut för aspNetCore-elementet.

Använd någon av följande metoder:

• Innan du publicerar och distribuerar projektet lägger du till följande web.config fil i projektroten:

  <?xml version="1.0" encoding="utf-8"?>
  <configuration>
    <location path="." inheritInChildApplications="false">
      <system.webServer>
        <security>
          <authentication>
            <anonymousAuthentication enabled="false" />
            <windowsAuthentication enabled="true" />
          </authentication>
        </security>
      </system.webServer>
    </location>
  </configuration>
  

  När projektet publiceras av .NET SDK (utan att egenskapen <IsTransformWebConfigDisabled> är satt till true i projektfilen) innehåller den publicerade web.config-filen <location><system.webServer><security><authentication> avsnittet. För mer information om <IsTransformWebConfigDisabled>-egenskapen, se Värd ASP.NET Core i Windows med IIS.

• När du har publicerat och distribuerat projektet utför du konfiguration på serversidan med IIS-hanteraren:

  1. I IIS-hanteraren väljer du IIS-webbplatsen under noden Platser i sidofältet Anslutningar .
  2. Dubbelklicka på Autentisering i IIS-området .
  3. Välj Anonym autentisering. Välj Inaktivera i sidofältet Åtgärder .
  4. Välj Windows-autentisering. Välj Aktivera i sidofältet Åtgärder .

  När dessa åtgärder vidtas ändrar IIS Manager appens web.config fil. En <system.webServer><security><authentication> nod läggs till med uppdaterade inställningar för anonymousAuthentication och windowsAuthentication:

  <system.webServer>
    <security>
      <authentication>
        <anonymousAuthentication enabled="false" />
        <windowsAuthentication enabled="true" />
      </authentication>
    </security>
  </system.webServer>
  

  Avsnittet <system.webServer> som läggs till i web.config-filen av IIS Manager ligger utanför appens <location> avsnitt som läggs till av .NET SDK när appen publiceras. Eftersom avsnittet läggs till utanför <location> noden ärvs inställningarna av alla underappar till den aktuella appen. Om du vill förhindra arv flyttar du det tillagda <security> avsnittet i avsnittet <location><system.webServer> som .NET SDK har angett.

  När IIS-hanteraren används för att lägga till IIS-konfigurationen påverkar det bara appens web.config fil på servern. En efterföljande distribution av appen kan skriva över inställningarna på servern om serverns kopia av web.config ersätts av projektets web.config-fil . Använd någon av följande metoder för att hantera inställningarna:

  • Använd IIS-hanteraren för att återställa inställningarna i web.config-filen när filen har skrivits över vid distributionen.
  • Lägg till en web.config fil i appen lokalt med inställningarna.

Kestrel

Microsoft.AspNetCore.Authentication.Negotiate NuGet-paketet kan användas med Kestrel för att stödja Windows-autentisering med Negotiate och Kerberos i Windows, Linux och macOS.

Lägg till autentiseringstjänster genom att anropa AddAuthentication och AddNegotiate i Startup.ConfigureServices:

// using Microsoft.AspNetCore.Authentication.Negotiate;
// using Microsoft.Extensions.DependencyInjection;

services.AddAuthentication(NegotiateDefaults.AuthenticationScheme)
   .AddNegotiate();

Lägg till mellanprogram för autentisering genom att anropa UseAuthentication i Startup.Configure:

app.UseAuthentication();

Mer information om mellanprogram finns i ASP.NET Core Middleware.

Kerberos-autentisering och rollbaserad åtkomstkontroll (RBAC)

Kerberos-autentisering i Linux eller macOS tillhandahåller ingen rollinformation för en autentiserad användare. Om du vill lägga till roll- och gruppinformation till en Kerberos-användare måste autentiseringshanteraren konfigureras för att hämta rollerna från en LDAP-domän. Den mest grundläggande konfigurationen anger bara en LDAP-domän att fråga mot och använder den autentiserade användarens kontext för att fråga LDAP-domänen:

services.AddAuthentication(NegotiateDefaults.AuthenticationScheme)
    .AddNegotiate(options =>
    {
        if (RuntimeInformation.IsOSPlatform(OSPlatform.Linux))
        {
            options.EnableLdap("contoso.com");
        }
    });

Vissa konfigurationer kan kräva specifika autentiseringsuppgifter för att köra frågor mot LDAP-domänen. Autentiseringsuppgifterna kan anges i följande markerade alternativ:

public void ConfigureServices(IServiceCollection services)
{
    services.AddDbContext<ApplicationDbContext>(options =>
        options.UseSqlServer(
            Configuration.GetConnectionString("DefaultConnection")));
    services.AddDatabaseDeveloperPageExceptionFilter();
    services.AddDefaultIdentity<IdentityUser>(options => options.SignIn.RequireConfirmedAccount = true)
        .AddEntityFrameworkStores<ApplicationDbContext>();

    services.AddAuthentication(NegotiateDefaults.AuthenticationScheme)
        .AddNegotiate(options =>
        {
            if (RuntimeInformation.IsOSPlatform(OSPlatform.Linux))
            {
                options.EnableLdap(settings =>
                {
                    settings.Domain = "contoso.com";
                    settings.MachineAccountName = "machineName";
                    settings.MachineAccountPassword = Configuration["Password"]
                });
            }
        });

    services.AddRazorPages();
}

Som standard löser förhandlande autentiseringshanterare kapslade domäner. I en stor eller komplicerad LDAP-miljö kan matchning av kapslade domäner resultera i en långsam sökning eller mycket minne som används för varje användare. Kapslad domänupplösning kan inaktiveras med alternativet IgnoreNestedGroups.

Anonyma begäranden tillåts. Använd ASP.NET Core Authorization för att utmana anonyma begäranden om autentisering.

AuthenticationSchemekräver NuGet-paketetMicrosoft.AspNetCore.Authentication.Negotiate.

Windows-miljökonfiguration

API:etMicrosoft.AspNetCore.Authentication.Negotiate utför autentisering i användarläge. Tjänstens huvudnamn (SPN) måste läggas till i användarkontot som kör tjänsten, inte datorkontot. Kör setspn -S HTTP/myservername.mydomain.com myuser i ett administrativt kommandogränssnitt.

Linux- och macOS-miljökonfiguration

Instruktioner för att ansluta en Linux- eller macOS-dator till en Windows-domän finns i artikeln Anslut Azure Data Studio till din SQL Server med Hjälp av Windows-autentisering – Kerberos . Anvisningarna skapar ett datorkonto för Linux-datorn på domänen. SPN måste läggas till i det datorkontot.

När Linux- eller macOS-datorn har anslutits till domänen krävs ytterligare steg för att tillhandahålla en nyckelfliksfil med SPN:erna:

• På domänkontrollanten lägger du till nya webbtjänst-SPN:er i datorkontot:
  • setspn -S HTTP/mywebservice.mydomain.com mymachine
  • setspn -S HTTP/mywebservice@MYDOMAIN.COM mymachine
• Använd ktpass för att generera en nyckelfliksfil:
  • ktpass -princ HTTP/mywebservice.mydomain.com@MYDOMAIN.COM -pass myKeyTabFilePassword -mapuser MYDOMAIN\mymachine$ -pType KRB5_NT_PRINCIPAL -out c:\temp\mymachine.HTTP.keytab -crypto AES256-SHA1
  • Vissa fält måste anges med versaler som specificerat.
• Kopiera nyckelfliksfilen till Linux- eller macOS-datorn.
• Välj nyckelfliksfilen via en miljövariabel: export KRB5_KTNAME=/tmp/mymachine.HTTP.keytab
• Anropa klist för att visa de SPN:er som för närvarande är tillgängliga för användning.

HTTP.sys

HTTP.sys stöder Windows-autentisering i kernelläge med hjälp av Negotiate, NTLM eller Basic-autentisering.

Lägg till autentiseringstjänster genom att anropa AddAuthentication (Microsoft.AspNetCore.Server.HttpSys namnområde) i Startup.ConfigureServices:

services.AddAuthentication(HttpSysDefaults.AuthenticationScheme);

Konfigurera appens webbvärd att använda HTTP.sys med Windows-autentisering (Program.cs). UseHttpSys finns i Microsoft.AspNetCore.Server.HttpSys namnområdet.

public class Program
{
    public static void Main(string[] args)
    {
        CreateHostBuilder(args).Build().Run();
    }

    public static IHostBuilder CreateHostBuilder(string[] args) =>
        Host.CreateDefaultBuilder(args)
            .ConfigureWebHostDefaults(webBuilder =>
            {
                webBuilder.UseStartup<Startup>()
                    .UseHttpSys(options =>
                    {
                        options.Authentication.Schemes = 
                            AuthenticationSchemes.NTLM | 
                            AuthenticationSchemes.Negotiate;
                        options.Authentication.AllowAnonymous = false;
                    });
            });
}

Auktorisera användare

Konfigurationstillståndet för anonym åtkomst avgör hur attributen [Authorize] och [AllowAnonymous] används i appen. I följande två avsnitt beskrivs hur du hanterar otillåtna och tillåtna konfigurationstillstånd för anonym åtkomst.

Tillåt inte anonym åtkomst

När Windows-autentisering är aktiverat och anonym åtkomst är inaktiverad har attributen [Authorize] och [AllowAnonymous] ingen effekt. Om en IIS-webbplats har konfigurerats för att neka anonym åtkomst når begäran aldrig appen. Därför [AllowAnonymous] är attributet inte tillämpligt.

Tillåt anonym åtkomst

När både Windows-autentisering och anonym åtkomst är aktiverade använder du attributen [Authorize] och [AllowAnonymous] . Med [Authorize] attributet kan du skydda slutpunkter för appen som kräver autentisering. Attributet [AllowAnonymous] åsidosätter [Authorize] attributet i appar som tillåter anonym åtkomst. Information om attributanvändning finns i Enkel auktorisering i ASP.NET Core.

Impersonation

ASP.NET Core implementerar inte personifiering. Appar körs med appens identitet för alla begäranden med hjälp av apppoolen eller processidentiteten. Om appen ska utföra en åtgärd för en användares räkning använder du WindowsIdentity.RunImpersonated eller RunImpersonatedAsync i ett infogat terminalmellanprogram i Startup.Configure. Kör en enda åtgärd i den här kontexten och stäng sedan kontexten.

app.Run(async (context) =>
{
    try
    {
        var user = (WindowsIdentity)context.User.Identity;

        await context.Response
            .WriteAsync($"User: {user.Name}\tState: {user.ImpersonationLevel}\n");

        WindowsIdentity.RunImpersonated(user.AccessToken, () =>
        {
            var impersonatedUser = WindowsIdentity.GetCurrent();
            var message =
                $"User: {impersonatedUser.Name}\t" +
                $"State: {impersonatedUser.ImpersonationLevel}";

            var bytes = Encoding.UTF8.GetBytes(message);
            context.Response.Body.Write(bytes, 0, bytes.Length);
        });
    }
    catch (Exception e)
    {
        await context.Response.WriteAsync(e.ToString());
    }
});

Microsoft.AspNetCore.Authentication.Negotiate Även om paketet möjliggör autentisering i Windows, Linux och macOS stöds personifiering endast i Windows.

Anspråkstransformeringar

Vid värdskap med IIS, anropas AuthenticateAsync inte internt för att initiera en användare. Därför aktiveras inte en IClaimsTransformation implementering som används för att omvandla anspråk efter varje autentisering som standard. Mer information och ett kodexempel som aktiverar anspråkstransformeringar finns i Skillnader mellan in-process och out-of-process hosting.

Ytterligare resurser

• dotnet publicera
• Köra ASP.NET Core på Windows med IIS
• ASP.NET Core Module (ANCM) för IIS
• Visual Studio publicerar profiler (.pubxml) för ASP.NET Core-appdistribution