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.

Hinweis

Bei HTTP/2 wird die Windows-Authentifizierung nicht unterstützt. Authentifizierungsanforderungen können zwar in HTTP/2-Antworten gesendet werden, aber der Client muss vor der Authentifizierung ein Downgrade auf HTTP/1.1 ausführen.

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.

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 Befehl dotnet new mit dem webapp-Argument (ASP.NET Core-Web-App) und dem Schalter --auth Windows 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 ü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.

Warnung

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.

Hinweis

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

Hinweis

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.

Hinweis

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

Hinweis

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.

Hinweis

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

Hinweis

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.

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