Konfigurieren der Windows-Authentifizierung in ASP.NET Core

Von Rick Anderson und Kirk Larkin

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.

Gründe für die Verwendung der Windows-Authentifizierung

Die Windows-Authentifizierung eignet sich für Webanwendungen, die innerhalb des privaten internen Netzwerks einer Organisation arbeiten und nur für Mitarbeiter (und andere autorisierte Benutzer) innerhalb desselben Netzwerks zugänglich sind. Die Benutzerverwaltung erfolgt in Active Directory (AD), und Benutzer verwenden ihr vorhandenes Windows-Domänenkonto zur Authentifizierung.

Die Windows-Authentifizierung bietet mehrere Vorteile für Intranetanwendungen:

• Nahtlose Benutzererfahrung – Benutzer werden automatisch basierend auf ihrer aktiven Windows-Sitzung authentifiziert oder aufgefordert, ihre Windows-Anmeldeinformationen über ein Standard-Browserdialogfeld einzugeben.
• Integration in Active Directory – Nutzt vorhandene Windows-Infrastruktur- und Sicherheitsrichtlinien, einschließlich Benutzergruppen, Kontosperrungen und mehrstufigeR Authentifizierung (MFA).
• Sichere Verarbeitung von Anmeldeinformationen – Die Authentifizierung wird über sichere Protokolle wie Kerberos verarbeitet, ohne dass separate Benutzeranmeldeinformationen verwaltet werden müssen.
• Rollenbasierte Autorisierung – Anwendungen können auf Benutzer- und Gruppeninformationen aus Active Directory zugreifen und die rollenbasierte Zugriffssteuerung (RBAC) innerhalb der Anwendung aktivieren.
• Reduzierter Verwaltungsaufwand – Es ist nicht erforderlich, eine separate Benutzerdatenbank oder ein separates Verwaltungssystem für Anmeldeinformationen zu verwalten.

Dies macht die Windows-Authentifizierung ideal für Organisationen, die ihre vorhandene Windows-Infrastruktur nutzen möchten, z. B. Intranetportale.

Note

Bei HTTP/2 wird die Windows-Authentifizierung nicht unterstützt. Während Authentifizierungsprobleme über HTTP/2-Antworten gesendet werden können, muss der Client auf HTTP/1.1 downgradeen, um den Authentifizierungsprozess abzuschließen. Dies ist eine Protokolleinschränkung, keine Abschreibung der Windows-Authentifizierung. Nach der Authentifizierung kann die normale HTTP/2-Kommunikation für nachfolgende Anforderungen fortgesetzt werden.

Für öffentlich zugängliche Anwendungen wird die Windows-Authentifizierung aufgrund von Sicherheits- und Benutzerfreundlichkeitsbedenken nicht empfohlen. Zu diesen Gründen gehören:

• Die Windows-Authentifizierung sollte am besten intern gehalten werden, um Active Directory zu schützen. Wird sie außerhalb eines internen Netzwerks exponiert, führt dies zu Sicherheitsrisiken.
• Externe Benutzer verfügen nicht über Windows-Domänenkonten.
• Es ist komplex, die erforderliche Netzwerkinfrastruktur sicher zu konfigurieren, und Firewalls oder Proxys können den Authentifizierungsprozess beeinträchtigen.
• Es ist nicht plattformübergreifend und bietet keine Anpassungsoptionen für Designs und Benutzeroberflächen.

Alternativen für verschiedene Szenarien

Berücksichtigen Sie je nach Ihren Anwendungsanforderungen die folgenden Alternativen:

Für öffentlich zugängliche Anwendungen:

• OpenID Connect mit externen Identitätsanbietern
• ASP.NET Core Identity mit lokalen Benutzerkonten (Einführung in Identity ASP.NET Core)
• Azure Active Directory (AAD) für Microsoft 365-Umgebungen

Für gemischte Umgebungen mit Intranet- und externen Benutzern:

• Active Directory-Verbunddienste (ADFS) mit OpenID Connect
• Azure Active Directory mit Hybridkonfiguration

Für Unternehmensumgebungen mit moderner Authentifizierung:

• Azure Active Directory mit einmaligem Anmelden
• SAML-basierte Lösungen mit Drittanbieter-Identitätsdiensten

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 Microsoft.AspNetCore.Authentication.Negotiate NuGet-Paket 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.

Visual Studio

Neues Projekt

Erstellen Sie eine neue Razor Pages- oder MVC-App. Legen Sie im Dialogfeld Zusätzliche Informationen den Authentifizierungstyp auf Windows fest.

Führen Sie die App aus. Der Benutzername wird auf der Benutzeroberfläche der gerenderten App angezeigt.

Vorhandenes Projekt

Über die Projekteigenschaften wird die Windows-Authentifizierung aktiviert und die anonyme Authentifizierung deaktiviert. Öffnen Sie das Dialogfeld „Startprofile“:

1. Klicken Sie im Projektmappen-Explorer mit der rechten Maustaste auf das Projekt und dann auf Eigenschaften.
2. Klicken Sie auf die Registerkarte Debuggen > Allgemein und dann auf Öffnen der Benutzeroberfläche von Debugstartprofilen.
3. Deaktivieren Sie das Kontrollkästchen Anonyme Authentifizierung aktivieren.
4. Aktivieren Sie das Kontrollkästchen Windows-Authentifizierung aktivieren.

Alternativ können die Eigenschaften auch im Knoten iisSettings der Datei launchSettings.json konfiguriert werden:

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

.NET CLI

Neues Projekt

Führen Sie den dotnet new Befehl mit dem webapp Argument (ASP.NET Core Web App) und dem --auth Windows Wechsel aus.

dotnet new webapp --auth Windows

Vorhandenes Projekt

Aktualisieren Sie den Knoten iisSettings der Datei launchSettings.json:

"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 vom .NET SDK veröffentlicht wird (wenn die <IsTransformWebConfigDisabled> Eigenschaft nicht in der Projektdatei festgelegt ist), enthält die veröffentlichte true Datei den Abschnitt. Weitere Informationen zur <IsTransformWebConfigDisabled> Eigenschaft finden Sie unter web.config Datei.

• 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 <system.webServer> Abschnitt, der der web.config-Datei vom IIS-Manager hinzugefügt wurde, befindet sich außerhalb des <location>-Abschnitts der App, der vom .NET SDK hinzugefügt wird, wenn die App veröffentlicht wird. 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 <security> Abschnitt innerhalb des <location><system.webServer> Abschnitts, den das .NET 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 Microsoft.AspNetCore.Authentication.Negotiate NuGet-Paket kann mit Kestrel verwendet werden, um die Windows-Authentifizierung mithilfe von Negotiate und Kerberos unter Windows, Linux und macOS zu aktivieren.

Warning

Anmeldeinformationen können über Anforderungen hinweg für eine Verbindung beibehalten werden. Die Aushandlungsauthentifizierung darf nicht mit Proxys verwendet werden, es sei denn, der Proxy behält eine 1:1-Verbindungsaffinität (eine persistente Verbindung) mit Kestrel bei.

Note

Der Aushandlungshandler erkennt, ob der zugrunde liegende Server die Windows-Authentifizierung nativ unterstützt und ob sie aktiviert ist. Wenn der Server die Windows-Authentifizierung unterstützt, diese aber deaktiviert ist, wird ein Fehler ausgelöst, und Sie werden aufgefordert, die Serverimplementierung zu aktivieren. Wenn die Windows-Authentifizierung auf dem Server aktiviert ist, leitet der Aushandlungshandler Authentifizierungsanforderungen transparent dorthin weiter.

Die Authentifizierung und eine Fallbackautorisierungsrichtlinie werden durch den folgenden hervorgehobenen Code aktiviert: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();

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

Hervorgehobene Linien:

• 5–6: AddAuthentication Registrieren und AddNegotiate Konfigurieren des Aushandlungsauthentifizierungshandlers.
• 8–11: AddAuthorization Mit einer Fallbackrichtlinie werden standardmäßig authentifizierte Benutzer erzwungen.
• 26: UseAuthentication führt Authentifizierungshandler für jede Anfrage aus und befüllt HttpContext.User.
• 27: UseAuthorization bewertet Autorisierungsrichtlinien, einschließlich der Fallbackrichtlinie.

Note

Das Aufrufen von AddAuthentication und AddNegotiate registriert und konfiguriert den Negotiate-Handler, führt keine Authentifizierung pro Anfrage aus. Die Authentication Middleware (UseAuthentication) ruft den Handler auf, füllt HttpContext.User aus und muss vor UseAuthorization, damit die Richtlinienauswertung funktioniert.

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 Microsoft.AspNetCore.Authentication.Negotiate API führt die Benutzermodusauthentifizierung 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 der Standardwert ist.

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.

Note

Wenn Sie den Leitfaden im Artikel Verbinden von Azure Data Studio mit Ihrem SQL Server mithilfe von Windows-Authentifizierung – Kerberos befolgen, müssen Sie bei Bedarf python-software-properties durch python3-software-properties ersetzen.

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.

Note

Eine Schlüsseltabellendatei enthält Anmeldeinformationen für den Domänenzugriff und muss daher entsprechend geschützt werden.

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

Note

HTTP.sys delegiert zur Authentifizierung im Kernelmodus mit dem Kerberos-Authentifizierungsprotokoll. Die Benutzer im Benutzermodus wird nicht von Kerberos und HTTP.sys unterstützt. Das Computerkonto muss zum Entschlüsseln des Kerberos-Tokens/-Tickets verwendet werden, das von Active Directory abgerufen und zur Authentifizierung des Benutzers vom Client an den Server weitergeleitet wird. Registrieren Sie den Dienstprinzipalnamen (SPN) für den Host, nicht für den Benutzer der App.

Note

HTTP.sys wird unter Nano Server Version 1709 oder höher nicht unterstützt. Um die Windows-Authentifizierung und HTTP.sys mit Nano Server zu nutzen, verwenden Sie einen Server Core-Container (microsoft/windowsservercore) (weitere Informationen finden Sie unter https://hub.docker.com/_/microsoft-windows-servercore). Weitere Informationen zu Server Core finden Sie unter Was ist die Server Core-Installationsoption unter Windows Server?.

Autorisieren von Benutzern

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.

Note

Standardmäßig wird Benutzer*innen, die keine Autorisierung für den Zugriff auf eine Seite haben, eine leere HTTP 403-Antwort angezeigt. Sie können die StatusCodePages-Middleware konfigurieren, um Benutzer*innen eine bessere Antwort als „Zugriff verweigert“ zu bieten.

Impersonation

ASP.NET Core implementiert keinen Identitätswechsel. Apps werden für alle Anforderungen mit der Identität der App ausgeführt, wobei der App-Pool oder die Prozessidentität verwendet wird. Wenn die App eine Aktion im Namen eines Benutzers ausführen soll, verwenden Sie WindowsIdentity.RunImpersonated oder RunImpersonatedAsync in einer 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 Microsoft.AspNetCore.Authentication.Negotiate unter Windows, Linux und macOS ermöglicht, wird der Identitätswechsel nur unter Windows ermöglicht.

Forderungstransformationen

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.

Weitere 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