Konfigurieren der Windows-Authentifizierung in ASP.NET Core

Die Windows-Authentifizierung (auch als Aushandlungs-, Kerberos- oder NTLM-Authentifizierung bezeichnet) kann für ASP.NET Core-Apps konfiguriert werden, die mit IIS, Kestrel oder HTTP.sys gehostet werden.

Bei der Windows-Authentifizierung ist das Betriebssystem dafür zuständig, Benutzer*innen von ASP.NET Core-Apps zu authentifizieren. Die Windows-Authentifizierung wird für Server verwendet, die in einem Unternehmensnetzwerk ausgeführt werden und Active Directory-Domänenidentitäten oder Windows-Konten verwenden, um Benutzer*innen zu identifizieren. Die Windows-Authentifizierung eignet sich am besten für Intranetumgebungen, in denen Benutzer*innen, Client-Apps und Webserver derselben Windows-Domäne angehören.

Szenarien mit Proxy und Lastenausgleich

Die Windows-Authentifizierung ist ein zustandsbehaftetes Szenario, das hauptsächlich in Intranets verwendet wird, in denen der Datenverkehr zwischen Clients und Servern normalerweise nicht durch einen Proxy oder Lastenausgleich verarbeitet wird. Wenn ein Proxy oder Lastenausgleich verwendet wird, funktioniert die Windows-Authentifizierung nur, wenn Proxy oder Lastenausgleich folgende Funktionen übernehmen:

• Verarbeiten der Authentifizierung
• Übergeben von Benutzerauthentifizierungsinformationen an die App (z. B. in einem Anforderungsheader), die die Authentifizierungsinformationen nutzt

Eine Alternative zur Windows-Authentifizierung in Umgebungen, in denen Proxys und Lastenausgleichsmodule verwendet werden, bildet Active Directory-Verbunddienste (AD FS) mit OpenID Connect (OIDC).

IIS/IIS Express

Fügen Sie das NuGet-Paket Microsoft.AspNetCore.Authentication.Negotiate und die Authentifizierungsdienste hinzu, indem Sie AddAuthentication in Program.cs aufrufen:

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();

Der obige Code wurde von der ASP.NET Core Razor Pages-Vorlage mit angegebener Windows-Authentifizierung generiert.

Starteinstellungen (Debugger)

Die Konfiguration der Starteinstellungen wirkt sich nur auf die Datei Properties/launchSettings.json für IIS Express aus, IIS wird nicht für die Windows-Authentifizierung konfiguriert. Die Serverkonfiguration wird im Abschnitt IIS erläutert.

Die über Visual Studio oder die .NET CLI verfügbaren Webanwendungsvorlagen können so konfiguriert werden, dass sie die Windows-Authentifizierung unterstützen. In diesem Fall wird die Datei Properties/launchSettings.json automatisch aktualisiert.

"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 verwendet auch das ASP.NET Core-Modul zum Hosten von ASP.NET Core-Apps. Für IIS wird die Windows-Authentifizierung über die Datei web.config konfiguriert. In den folgenden Abschnitten werden diese Aktionen gezeigt:

• Geben Sie eine lokale Datei web.config an, die die Windows-Authentifizierung auf dem Server aktiviert, wenn die App bereitgestellt wird.
• Verwenden Sie den IIS-Manager, um die Datei web.config einer ASP.NET Core-App zu konfigurieren, die bereits auf dem Server bereitgestellt wurde.

Falls IIS noch nicht zum Hosten ASP.NET Core-Apps aktiviert wurde, aktivieren Sie es jetzt. Weitere Informationen finden Sie unter Hosten von ASP.NET Core unter Windows mit IIS.

Aktivieren Sie den IIS-Rollendienst für die Windows-Authentifizierung. Weitere Informationen finden Sie unter Aktivieren der Windows-Authentifizierung in IIS-Rollendiensten (siehe Schritt 2).

Die Middleware für die IIS-Integration ist so konfiguriert, dass Anforderungen standardmäßig automatisch authentifiziert werden. Weitere Informationen finden Sie unter Hosten von ASP.NET Core unter Windows mit IIS: IIS-Optionen (AutomaticAuthentication).

Das ASP.NET Core-Modul ist so konfiguriert, dass das Token für die Windows-Authentifizierung standardmäßig an die App weitergeleitet wird. Weitere Informationen finden Sie unter Konfigurationsreferenz für das ASP.NET Core-Modul: Attribute des aspNetCore-Elements.

Verwenden Sie einen der folgenden Ansätze:

• Fügen Sie vor dem Veröffentlichen und Bereitstellen des Projekts am Projektstamm die folgende Datei web.config hinzu:

  <?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>
  

  Wenn das Projekt über das .NET Core SDK veröffentlicht wird (ohne dass die <IsTransformWebConfigDisabled>-Eigenschaft in der Projektdatei auf true festgelegt ist), enthält die veröffentlichte Datei web.config den Abschnitt <location><system.webServer><security><authentication>. Weitere Informationen zur <IsTransformWebConfigDisabled>-Eigenschaft finden Sie unter Hosten von ASP.NET Core unter Windows mit IIS.

• Führen Sie nach der Veröffentlichung und Bereitstellung des Projekts die serverseitige Konfiguration mit dem IIS-Manager durch:

  1. Wählen Sie im IIS-Manager auf der Randleiste Verbindungen unter dem Knoten Sites die IIS-Website aus.
  2. Doppelklicken Sie im Bereich IIS auf Authentifizierung.
  3. Wählen Sie Anonyme Authentifizierung aus. Wählen Sie auf der Randleiste Aktionen die Option Deaktivieren aus.
  4. Wählen Sie Windows-Authentifizierung. Wählen Sie auf der Randleiste Aktionen die Option Aktivieren aus.

  Wenn diese Aktionen ausgeführt werden, ändert der IIS-Manager die Datei web.config der App. Es wird ein Knoten <system.webServer><security><authentication> mit aktualisierten Einstellungen für anonymousAuthentication und windowsAuthentication hinzugefügt:

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

  Der Abschnitt <system.webServer>, der vom IIS-Manager in der Datei web.config hinzugefügt wurde, befindet sich außerhalb des Abschnitts <location> der App, der vom .NET Core SDK hinzugefügt wurde, als die App veröffentlicht wurde. Da der Abschnitt außerhalb des Knotens <location> hinzugefügt wird, werden die Einstellungen von allen untergeordneten Apps der aktuellen App geerbt. Um die Vererbung zu verhindern, verschieben Sie den hinzugefügten Abschnitt <security> in den Abschnitt <location><system.webServer>, den das .NET Core SDK bereitgestellt hat.

  Wenn der IIS-Manager zum Hinzufügen der IIS-Konfiguration verwendet wird, wirkt sich dies nur auf die Datei web.config der App auf dem Server aus. Eine nachfolgende Bereitstellung der App kann die Einstellungen auf dem Server überschreiben, wenn die Kopie der Datei web.config des Servers durch die Datei web.config des Projekts ersetzt wird. Verwenden Sie einen der folgenden Ansätze, um die Einstellungen zu verwalten:

  • Verwenden Sie den IIS-Manager, um die Einstellungen in der Datei web.config zurückzusetzen, nachdem die Datei bei der Bereitstellung überschrieben wurde.
  • Fügen Sie der App lokal eine Datei web.config mit den Einstellungen hinzu.

Kestrel

Das NuGet-Paket Microsoft.AspNetCore.Authentication.Negotiate kann mit Kestrel verwendet werden, um die Windows-Authentifizierung mithilfe von Aushandlung und Kerberos unter Windows, Linux und macOS zu unterstützen.

Die Authentifizierung wird durch den folgenden hervorgehobenen Code in Program.cs aktiviert:

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();

Der obige Code wurde von der ASP.NET Core Razor Pages-Vorlage mit angegebener Windows-Authentifizierung generiert. Die folgenden APIs werden im vorherigen Code verwendet:

• AddAuthentication
• AddNegotiate
• UseAuthentication

Kerberos-Authentifizierung und rollenbasierte Zugriffssteuerung (RBAC)

Bei der Kerberos-Authentifizierung unter Linux oder macOS werden keine Rolleninformationen zu den authentifizierten Benutzer*innen bereitgestellt. Um Kerberos-Benutzer*innen Rollen- und Gruppeninformationen hinzuzufügen, muss der Authentifizierungshandler so konfiguriert werden, dass die Rollen aus einer LDAP-Domäne abgerufen werden. Bei der einfachsten Konfiguration wird nur eine LDAP-Domäne zum Abfragen angegeben und der Kontext der authentifizierten Benutzer*innen verwendet, um die LDAP-Domäne abzufragen:

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");
        }
    });

Für einige Konfigurationen sind möglicherweise spezielle Anmeldeinformationen erforderlich, um die LDAP-Domäne abzufragen. Die Anmeldeinformationen können über die folgenden hervorgehobenen Optionen angegeben werden:

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();

Standardmäßig löst der Aushandlungshandler für die Authentifizierung geschachtelte Domänen auf. In einer großen oder komplizierten LDAP-Umgebung kann das Auflösen geschachtelter Domänen die Suche verlangsamen oder viel Arbeitsspeicher für einzelne Benutzer*innen verbrauchen. Die Auflösung geschachtelter Domänen kann mithilfe der IgnoreNestedGroups-Option deaktiviert werden.

Anonyme Anforderungen sind zulässig. Verwenden Sie die ASP.NET Core-Autorisierung, um anonyme Anforderungen für die Authentifizierung zu überprüfen.

Konfiguration von Windows-Umgebungen

Die Komponente Microsoft.AspNetCore.Authentication.Negotiate führt die Authentifizierung im Benutzermodus aus. Dienstprinzipalnamen (SPNs) müssen dem Benutzerkonto hinzugefügt werden, unter dem der Dienst ausgeführt wird, und nicht dem Computerkonto. Führen Sie setspn -S HTTP/myservername.mydomain.com myuser in einer Verwaltungsbefehlsshell aus.

Kerberos oder NTLM

Das Aushandlungspaket in Kestrel für ASP.NET Core versucht, Kerberos zu verwenden, ein sichereres und leistungsstärkeres Authentifizierungsschema als 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 gibt Kerberos an, da es sich um die Standardeinstellung handelt.

IIS, IIS Express und Kestrel unterstützen sowohl Kerberos als auch NTLM.

Bei der Untersuchung des Headers WWW-Authenticate: mithilfe von IIS oder IIS Express mit einem Tool wie Fiddler wird entweder Negotiate oder NTLM angezeigt.

Kestrel zeigt nur WWW-Authenticate: Negotiate an.

Der Header WWW-Authenticate: Negotiate bedeutet, dass der Server NTLM oder Kerberos verwenden kann. Kestrel erfordert das Headerpräfix Negotiate. Die direkte Angabe von NTLM in den Anforderungs- oder Antwortauthentifizierungsheadern wird nicht unterstützt. NTLM wird in Kestrel unterstützt, muss aber als Negotiate übermittelt werden.

Um in Kestrel zu sehen, ob NTLM oder Kerberos verwendet wird, dekodieren Sie den Base64-Header und es erscheint entweder NTLM oder HTTP. HTTP gibt an, dass Kerberos verwendet wurde.

Konfiguration von Linux- und macOS-Umgebungen

Anweisungen zum Verknüpfen eines Linux- oder macOS-Computers mit einer Windows-Domäne finden Sie im Artikel Verbinden von Azure Data Studio mit Ihrem SQL Server mithilfe von Windows-Authentifizierung – Kerberos. Mit den Anweisungen wird ein Computerkonto für den Linux-Computer in der Domäne erstellt. Diesem Computerkonto müssen SPNs (Dienstprinzipalnamen) hinzugefügt werden.

Nachdem der Linux- oder macOS-Computer der Domäne beigetreten ist, sind zusätzliche Schritte erforderlich, um eine Schlüsseltabellendatei mit den SPNs bereitzustellen:

• Fügen Sie dem Computerkonto auf dem Domänencontroller neue Webdienst-SPNs hinzu:
  • setspn -S HTTP/mywebservice.mydomain.com mymachine
  • setspn -S HTTP/mywebservice@MYDOMAIN.COM mymachine
• Verwenden Sie ktpass, um eine Schlüsseltabellendatei zu generieren:
  • 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
  • Einige Felder müssen wie gezeigt in Großbuchstaben angegeben werden.
• Kopieren Sie die Schlüsseltabellendatei auf den Linux- oder macOS-Computer.
• Wählen Sie die Schlüsseltabellendatei über eine Umgebungsvariable aus: export KRB5_KTNAME=/tmp/mymachine.HTTP.keytab
• Rufen Sie klist auf, um die derzeit verfügbaren SPNs anzuzeigen.

HTTP.sys

HTTP.sys unterstützt die Windows-Authentifizierung im Kernelmodus mithilfe der Aushandlungs-, NTLM- oder Standardauthentifizierung.

Der folgende Code fügt die Authentifizierung hinzu und konfiguriert den Webhost der App für die Verwendung von HTTP.sys mit Windows-Authentifizierung:

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;
        });
}

Autorisieren Sie Benutzer

Der Konfigurationsstatus für den anonymen Zugriff bestimmt, wie die Attribute [Authorize] und [AllowAnonymous] in der App verwendet werden. In den folgenden beiden Abschnitten wird erläutert, wie die nicht zulässigen und zulässigen Konfigurationszustände für den anonymen Zugriff behandelt werden.

Deaktivieren des anonymen Zugriffs

Wenn die Windows-Authentifizierung aktiviert und der anonyme Zugriff deaktiviert ist, haben die Attribute [Authorize] und [AllowAnonymous] keine Auswirkungen. Wenn eine IIS-Website so konfiguriert ist, dass der anonyme Zugriff nicht zugelassen wird, erreicht die Anforderung nie die App. Aus diesem Grund ist das [AllowAnonymous]-Attribut nicht anwendbar.

Aktivieren des anonymen Zugriffs

Wenn sowohl die Windows-Authentifizierung als auch der anonyme Zugriff aktiviert sind, verwenden Sie die Attribute [Authorize] und [AllowAnonymous]. Mit dem [Authorize]-Attribut können Sie Endpunkte der App schützen, die eine Authentifizierung erfordern. Das [AllowAnonymous]-Attribut setzt das [Authorize]-Attribut in Apps außer Kraft, die anonymen Zugriff zulassen. Details zur Verwendung des Attributs finden Sie unter Einfache Autorisierung in ASP.NET Core.

Identitätswechsel

ASP.NET Core implementiert keinen Identitätswechsel. Apps werden für alle Anforderungen mit der Identität der App ausgeführt, wobei die App-Pool- oder die Prozessidentität verwendet wird. Wenn die App eine Aktion im Namen bestimmter Benutzer*innen ausführen soll, verwenden Sie WindowsIdentity.RunImpersonated oder RunImpersonatedAsync in a terminal inline middleware in Program.cs. Führen Sie in diesem Kontext eine einzelne Aktion aus, und schließen Sie dann den Kontext.

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());
    }
});

Während das Paket Microsoft.AspNetCore.Authentication.Negotiate die Authentifizierung unter Windows, Linux und macOS aktiviert, werden Identitätswechsel nur unter Windows unterstützt.

Transformationen von Ansprüchen

Beim Hosting mit IIS wird AuthenticateAsync nicht intern aufgerufen, um Benutzer*innen zu initialisieren. Deshalb ist eine IClaimsTransformation-Implementierung, die verwendet wird, um Ansprüche nach jeder Authentifizierung zu transformieren, nicht standardmäßig aktiviert. Weitere Informationen und ein Codebeispiel zum Aktivieren von Anspruchstransformationen finden Sie unter Unterschiede zwischen In-Process- und Out-of-Process-Hosting.

Zusätzliche Ressourcen

• dotnet publish
• Hosten von ASP.NET Core unter Windows mit IIS
• ASP.NET Core-Modul (ANCM) für IIS
• Visual Studio-Veröffentlichungsprofile (PUBXML) für die Bereitstellung von ASP.NET Core-Apps

Die Windows-Authentifizierung (auch als Aushandlungs-, Kerberos- oder NTLM-Authentifizierung bezeichnet) kann für ASP.NET Core-Apps konfiguriert werden, die mit IIS, Kestrel oder HTTP.sys gehostet werden.

Bei der Windows-Authentifizierung ist das Betriebssystem dafür zuständig, Benutzer*innen von ASP.NET Core-Apps zu authentifizieren. Sie können die Windows-Authentifizierung verwenden, wenn der Server in einem Unternehmensnetzwerk ausgeführt wird und Active Directory-Domänenidentitäten oder Windows-Konten verwendet werden, um Benutzer*innen zu identifizieren. Die Windows-Authentifizierung eignet sich am besten für Intranetumgebungen, in denen Benutzer*innen, Client-Apps und Webserver derselben Windows-Domäne angehören.

Szenarien mit Proxy und Lastenausgleich

Die Windows-Authentifizierung ist ein zustandsbehaftetes Szenario, das hauptsächlich in Intranets verwendet wird, in denen der Datenverkehr zwischen Clients und Servern normalerweise nicht durch einen Proxy oder Lastenausgleich verarbeitet wird. Wenn ein Proxy oder Lastenausgleich verwendet wird, funktioniert die Windows-Authentifizierung nur, wenn Proxy oder Lastenausgleich folgende Funktionen übernehmen:

• Verarbeiten der Authentifizierung
• Übergeben von Benutzerauthentifizierungsinformationen an die App (z. B. in einem Anforderungsheader), die die Authentifizierungsinformationen nutzt

Eine Alternative zur Windows-Authentifizierung in Umgebungen, in denen Proxys und Lastenausgleichsmodule verwendet werden, bildet Active Directory-Verbunddienste (AD FS) mit OpenID Connect (OIDC).

IIS/IIS Express

Fügen Sie Authentifizierungsdienste hinzu, indem Sie AddAuthentication (Microsoft.AspNetCore.Server.IISIntegration-Namespace) in Startup.ConfigureServices aufrufen:

services.AddAuthentication(IISDefaults.AuthenticationScheme);

Starteinstellungen (Debugger)

Die Konfiguration der Starteinstellungen wirkt sich nur auf die Datei Properties/launchSettings.json für IIS Express aus, IIS wird nicht für die Windows-Authentifizierung konfiguriert. Die Serverkonfiguration wird im Abschnitt IIS erläutert.

Die über Visual Studio oder die .NET CLI verfügbaren Webanwendungsvorlagen können so konfiguriert werden, dass sie die Windows-Authentifizierung unterstützen. In diesem Fall wird die Datei Properties/launchSettings.json automatisch aktualisiert.

"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
    }
}

Vergewissern Sie sich beim Ändern eines vorhandenen Projekts, dass die Projektdatei einen Paketverweis für das Metapaket Microsoft.AspNetCore.App oder das NuGet-Paket Microsoft.AspNetCore.Authentication enthält.

IIS

IIS verwendet auch das ASP.NET Core-Modul zum Hosten von ASP.NET Core-Apps. Für IIS wird die Windows-Authentifizierung über die Datei web.config konfiguriert. In den folgenden Abschnitten werden diese Aktionen gezeigt:

• Geben Sie eine lokale Datei web.config an, die die Windows-Authentifizierung auf dem Server aktiviert, wenn die App bereitgestellt wird.
• Verwenden Sie den IIS-Manager, um die Datei web.config einer ASP.NET Core-App zu konfigurieren, die bereits auf dem Server bereitgestellt wurde.

Falls IIS noch nicht zum Hosten ASP.NET Core-Apps aktiviert wurde, aktivieren Sie es jetzt. Weitere Informationen finden Sie unter Hosten von ASP.NET Core unter Windows mit IIS.

Aktivieren Sie den IIS-Rollendienst für die Windows-Authentifizierung. Weitere Informationen finden Sie unter Aktivieren der Windows-Authentifizierung in IIS-Rollendiensten (siehe Schritt 2).

Die Middleware für die IIS-Integration ist so konfiguriert, dass Anforderungen standardmäßig automatisch authentifiziert werden. Weitere Informationen finden Sie unter Hosten von ASP.NET Core unter Windows mit IIS: IIS-Optionen (AutomaticAuthentication).

Das ASP.NET Core-Modul ist so konfiguriert, dass das Token für die Windows-Authentifizierung standardmäßig an die App weitergeleitet wird. Weitere Informationen finden Sie unter Konfigurationsreferenz für das ASP.NET Core-Modul: Attribute des aspNetCore-Elements.

Verwenden Sie einen der folgenden Ansätze:

• Fügen Sie vor dem Veröffentlichen und Bereitstellen des Projekts am Projektstamm die folgende Datei web.config hinzu:

  <?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>
  

  Wenn das Projekt über das .NET Core SDK veröffentlicht wird (ohne dass die <IsTransformWebConfigDisabled>-Eigenschaft in der Projektdatei auf true festgelegt ist), enthält die veröffentlichte Datei web.config den Abschnitt <location><system.webServer><security><authentication>. Weitere Informationen zur <IsTransformWebConfigDisabled>-Eigenschaft finden Sie unter Hosten von ASP.NET Core unter Windows mit IIS.

• Führen Sie nach der Veröffentlichung und Bereitstellung des Projekts die serverseitige Konfiguration mit dem IIS-Manager durch:

  1. Wählen Sie im IIS-Manager auf der Randleiste Verbindungen unter dem Knoten Sites die IIS-Website aus.
  2. Doppelklicken Sie im Bereich IIS auf Authentifizierung.
  3. Wählen Sie Anonyme Authentifizierung aus. Wählen Sie auf der Randleiste Aktionen die Option Deaktivieren aus.
  4. Wählen Sie Windows-Authentifizierung. Wählen Sie auf der Randleiste Aktionen die Option Aktivieren aus.

  Wenn diese Aktionen ausgeführt werden, ändert der IIS-Manager die Datei web.config der App. Es wird ein Knoten <system.webServer><security><authentication> mit aktualisierten Einstellungen für anonymousAuthentication und windowsAuthentication hinzugefügt:

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

  Der Abschnitt <system.webServer>, der vom IIS-Manager in der Datei web.config hinzugefügt wurde, befindet sich außerhalb des Abschnitts <location> der App, der vom .NET Core SDK hinzugefügt wurde, als die App veröffentlicht wurde. Da der Abschnitt außerhalb des Knotens <location> hinzugefügt wird, werden die Einstellungen von allen untergeordneten Apps der aktuellen App geerbt. Um die Vererbung zu verhindern, verschieben Sie den hinzugefügten Abschnitt <security> in den Abschnitt <location><system.webServer>, den das .NET Core SDK bereitgestellt hat.

  Wenn der IIS-Manager zum Hinzufügen der IIS-Konfiguration verwendet wird, wirkt sich dies nur auf die Datei web.config der App auf dem Server aus. Eine nachfolgende Bereitstellung der App kann die Einstellungen auf dem Server überschreiben, wenn die Kopie der Datei web.config des Servers durch die Datei web.config des Projekts ersetzt wird. Verwenden Sie einen der folgenden Ansätze, um die Einstellungen zu verwalten:

  • Verwenden Sie den IIS-Manager, um die Einstellungen in der Datei web.config zurückzusetzen, nachdem die Datei bei der Bereitstellung überschrieben wurde.
  • Fügen Sie der App lokal eine Datei web.config mit den Einstellungen hinzu.

Kestrel

Das NuGet-Paket Microsoft.AspNetCore.Authentication.Negotiate kann mit Kestrel verwendet werden, um die Windows-Authentifizierung mithilfe von Aushandlung und Kerberos unter Windows, Linux und macOS zu unterstützen.

Fügen Sie Authentifizierungsdienste hinzu, indem Sie AddAuthentication und AddNegotiate in Startup.ConfigureServices aufrufen:

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

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

Fügen Sie Authentifizierungsmiddleware hinzu, indem Sie UseAuthentication in Startup.Configure aufrufen:

app.UseAuthentication();

Weitere Informationen zu Middleware finden Sie unter ASP.NET Core-Middleware.

Kerberos-Authentifizierung und rollenbasierte Zugriffssteuerung (RBAC)

Bei der Kerberos-Authentifizierung unter Linux oder macOS werden keine Rolleninformationen zu den authentifizierten Benutzer*innen bereitgestellt. Um Kerberos-Benutzer*innen Rollen- und Gruppeninformationen hinzuzufügen, muss der Authentifizierungshandler so konfiguriert werden, dass die Rollen aus einer LDAP-Domäne abgerufen werden. Bei der einfachsten Konfiguration wird nur eine LDAP-Domäne zum Abfragen angegeben und der Kontext der authentifizierten Benutzer*innen verwendet, um die LDAP-Domäne abzufragen:

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

Für einige Konfigurationen sind möglicherweise spezielle Anmeldeinformationen erforderlich, um die LDAP-Domäne abzufragen. Die Anmeldeinformationen können über die folgenden hervorgehobenen Optionen angegeben werden:

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();
}

Standardmäßig löst der Aushandlungshandler für die Authentifizierung geschachtelte Domänen auf. In einer großen oder komplizierten LDAP-Umgebung kann das Auflösen geschachtelter Domänen die Suche verlangsamen oder viel Arbeitsspeicher für einzelne Benutzer*innen verbrauchen. Die Auflösung geschachtelter Domänen kann mithilfe der IgnoreNestedGroups-Option deaktiviert werden.

Anonyme Anforderungen sind zulässig. Verwenden Sie die ASP.NET Core-Autorisierung, um anonyme Anforderungen für die Authentifizierung zu überprüfen.

AuthenticationScheme erfordert das NuGet-Paket Microsoft.AspNetCore.Authentication.Negotiate.

Konfiguration von Windows-Umgebungen

Die Komponente Microsoft.AspNetCore.Authentication.Negotiate führt die Authentifizierung im Benutzermodus aus. Dienstprinzipalnamen (SPNs) müssen dem Benutzerkonto hinzugefügt werden, unter dem der Dienst ausgeführt wird, und nicht dem Computerkonto. Führen Sie setspn -S HTTP/myservername.mydomain.com myuser in einer Verwaltungsbefehlsshell aus.

Konfiguration von Linux- und macOS-Umgebungen

Anweisungen zum Verknüpfen eines Linux- oder macOS-Computers mit einer Windows-Domäne finden Sie im Artikel Verbinden von Azure Data Studio mit Ihrem SQL Server mithilfe von Windows-Authentifizierung – Kerberos. Mit den Anweisungen wird ein Computerkonto für den Linux-Computer in der Domäne erstellt. Diesem Computerkonto müssen SPNs (Dienstprinzipalnamen) hinzugefügt werden.

Nachdem der Linux- oder macOS-Computer der Domäne beigetreten ist, sind zusätzliche Schritte erforderlich, um eine Schlüsseltabellendatei mit den SPNs bereitzustellen:

• Fügen Sie dem Computerkonto auf dem Domänencontroller neue Webdienst-SPNs hinzu:
  • setspn -S HTTP/mywebservice.mydomain.com mymachine
  • setspn -S HTTP/mywebservice@MYDOMAIN.COM mymachine
• Verwenden Sie ktpass, um eine Schlüsseltabellendatei zu generieren:
  • 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
  • Einige Felder müssen wie gezeigt in Großbuchstaben angegeben werden.
• Kopieren Sie die Schlüsseltabellendatei auf den Linux- oder macOS-Computer.
• Wählen Sie die Schlüsseltabellendatei über eine Umgebungsvariable aus: export KRB5_KTNAME=/tmp/mymachine.HTTP.keytab
• Rufen Sie klist auf, um die derzeit verfügbaren SPNs anzuzeigen.

HTTP.sys

HTTP.sys unterstützt die Windows-Authentifizierung im Kernelmodus mithilfe der Aushandlungs-, NTLM- oder Standardauthentifizierung.

Fügen Sie Authentifizierungsdienste hinzu, indem Sie AddAuthentication (Microsoft.AspNetCore.Server.HttpSys-Namespace) in Startup.ConfigureServices aufrufen:

services.AddAuthentication(HttpSysDefaults.AuthenticationScheme);

Konfigurieren Sie den Webhost der App für die Verwendung von HTTP.sys mit Windows-Authentifizierung (Program.cs). UseHttpSys befindet sich im Microsoft.AspNetCore.Server.HttpSys-Namespace.

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;
                    });
            });
}

Autorisieren Sie Benutzer

Der Konfigurationsstatus für den anonymen Zugriff bestimmt, wie die Attribute [Authorize] und [AllowAnonymous] in der App verwendet werden. In den folgenden beiden Abschnitten wird erläutert, wie die nicht zulässigen und zulässigen Konfigurationszustände für den anonymen Zugriff behandelt werden.

Deaktivieren des anonymen Zugriffs

Wenn die Windows-Authentifizierung aktiviert und der anonyme Zugriff deaktiviert ist, haben die Attribute [Authorize] und [AllowAnonymous] keine Auswirkungen. Wenn eine IIS-Website so konfiguriert ist, dass der anonyme Zugriff nicht zugelassen wird, erreicht die Anforderung nie die App. Aus diesem Grund ist das [AllowAnonymous]-Attribut nicht anwendbar.

Aktivieren des anonymen Zugriffs

Wenn sowohl die Windows-Authentifizierung als auch der anonyme Zugriff aktiviert sind, verwenden Sie die Attribute [Authorize] und [AllowAnonymous]. Mit dem [Authorize]-Attribut können Sie Endpunkte der App schützen, die eine Authentifizierung erfordern. Das [AllowAnonymous]-Attribut setzt das [Authorize]-Attribut in Apps außer Kraft, die anonymen Zugriff zulassen. Details zur Verwendung des Attributs finden Sie unter Einfache Autorisierung in ASP.NET Core.

Identitätswechsel

ASP.NET Core implementiert keinen Identitätswechsel. Apps werden für alle Anforderungen mit der Identität der App ausgeführt, wobei die App-Pool- oder die Prozessidentität verwendet wird. Wenn die App eine Aktion im Namen bestimmter Benutzer*innen ausführen soll, verwenden Sie WindowsIdentity.RunImpersonated oder RunImpersonatedAsync in einer Terminal Inline-Middleware in Startup.Configure. Führen Sie in diesem Kontext eine einzelne Aktion aus, und schließen Sie dann den Kontext.

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());
    }
});

Während das Paket Microsoft.AspNetCore.Authentication.Negotiate die Authentifizierung unter Windows, Linux und macOS aktiviert, werden Identitätswechsel nur unter Windows unterstützt.

Transformationen von Ansprüchen

Beim Hosting mit IIS wird AuthenticateAsync nicht intern aufgerufen, um Benutzer*innen zu initialisieren. Deshalb ist eine IClaimsTransformation-Implementierung, die verwendet wird, um Ansprüche nach jeder Authentifizierung zu transformieren, nicht standardmäßig aktiviert. Weitere Informationen und ein Codebeispiel zum Aktivieren von Anspruchstransformationen finden Sie unter Unterschiede zwischen In-Process- und Out-of-Process-Hosting.

Zusätzliche Ressourcen

• dotnet publish
• Hosten von ASP.NET Core unter Windows mit IIS
• ASP.NET Core-Modul (ANCM) für IIS
• Visual Studio-Veröffentlichungsprofile (PUBXML) für die Bereitstellung von ASP.NET Core-Apps