Konfigurowanie uwierzytelniania systemu Windows na platformie ASP.NET Core

Uwierzytelnianie systemu Windows (nazywane również uwierzytelnianiem Negotiate, Kerberos lub NTLM) można skonfigurować dla aplikacji ASP.NET Core hostowanych za pomocą usług IIS lub KestrelHTTP.sys.

Uwierzytelnianie systemu Windows opiera się na systemie operacyjnym do uwierzytelniania użytkowników aplikacji ASP.NET Core. Uwierzytelnianie systemu Windows jest używane na serwerach działających w sieci firmowej przy użyciu tożsamości domeny usługi Active Directory lub kont systemu Windows do identyfikowania użytkowników. Uwierzytelnianie systemu Windows najlepiej nadaje się do środowisk intranetowych, w których użytkownicy, aplikacje klienckie i serwery internetowe należą do tej samej domeny systemu Windows.

Kiedy należy używać uwierzytelniania systemu Windows

Uwierzytelnianie systemu Windows jest odpowiednie dla aplikacji internetowych działających w prywatnej sieci wewnętrznej organizacji, dostępnej tylko dla pracowników (i innych autoryzowanych użytkowników) w tej samej sieci. Zarządzanie użytkownikami odbywa się w usłudze Active Directory (AD), a użytkownicy używają istniejącego konta domeny systemu Windows do uwierzytelniania.

Uwierzytelnianie systemu Windows zapewnia kilka korzyści dla aplikacji intranetowych:

• Bezproblemowe środowisko użytkownika — użytkownicy są automatycznie uwierzytelniani na podstawie aktywnej sesji systemu Windows lub są monitowani o wprowadzenie poświadczeń systemu Windows za pośrednictwem standardowego okna dialogowego przeglądarki.
• Integracja z usługą Active Directory — wykorzystuje istniejące zasady infrastruktury i zabezpieczeń systemu Windows, w tym grupy użytkowników, blokady kont i uwierzytelnianie wieloskładnikowe (MFA).
• Bezpieczna obsługa poświadczeń — uwierzytelnianie jest obsługiwane za pośrednictwem bezpiecznych protokołów, takich jak Kerberos, bez konieczności zarządzania oddzielnymi poświadczeniami użytkownika.
• Autoryzacja oparta na rolach — aplikacje mogą uzyskiwać dostęp do informacji o użytkownikach i grupach z usługi Active Directory, włączając kontrolę dostępu opartą na rolach (RBAC) w aplikacji.
• Mniejsze obciążenie administracyjne — nie trzeba utrzymywać oddzielnej bazy danych użytkownika ani systemu zarządzania poświadczeniami.

Dzięki temu uwierzytelnianie systemu Windows jest idealne dla organizacji, które chcą korzystać z istniejącej infrastruktury systemu Windows, takiej jak portale intranetowe.

W przypadku aplikacji publicznych uwierzytelnianie systemu Windows nie jest zalecane ze względu na problemy z zabezpieczeniami i użytecznością. Oto następujące przyczyny:

• Uwierzytelnianie systemu Windows najlepiej jest utrzymywać wewnętrznie, aby chronić usługę Active Directory, ujawnienie jej poza sieć wewnętrzną wprowadza zagrożenia bezpieczeństwa.
• Użytkownicy zewnętrzni nie mają kont domeny systemu Windows.
• Skonfigurowanie niezbędnej infrastruktury sieciowej jest skomplikowane, a zapory lub serwery proxy mogą zakłócać proces uwierzytelniania.
• Nie jest to platforma międzyplatformowa i nie udostępnia opcji dostosowywania dla projektów i środowisk użytkownika.

Alternatywy dla różnych scenariuszy

W zależności od wymagań aplikacji rozważ następujące alternatywy:

W przypadku aplikacji publicznych:

• OpenID Connect z zewnętrznymi dostawcami tożsamości
• ASP.NET Core Identity z kontami użytkowników lokalnych (wprowadzenie do Identity ASP.NET Core)
• Usługa Azure Active Directory (AAD) dla środowisk platformy Microsoft 365

W przypadku środowisk mieszanych z użytkownikami intranetowymi i zewnętrznymi:

• Active Directory Federation Services (ADFS) z openID Connect
• Usługa Azure Active Directory z konfiguracją hybrydową

W przypadku środowisk firmowych korzystających z nowoczesnego uwierzytelniania:

• Usługa Azure Active Directory z logowaniem jednokrotnym
• Rozwiązania oparte na protokole SAML z zewnętrznymi dostawcami tożsamości

Scenariusze serwera proxy i modułu równoważenia obciążenia

Uwierzytelnianie systemu Windows to scenariusz stanowy używany głównie w intranecie, w którym serwer proxy lub moduł równoważenia obciążenia zwykle nie obsługuje ruchu między klientami i serwerami. Jeśli używany jest serwer proxy lub moduł równoważenia obciążenia, uwierzytelnianie systemu Windows działa tylko wtedy, gdy serwer proxy lub moduł równoważenia obciążenia:

• Obsługuje uwierzytelnianie.
• Przekazuje informacje o uwierzytelnianiu użytkownika do aplikacji (na przykład w nagłówku żądania), która działa na podstawie informacji uwierzytelniania.

Alternatywą dla uwierzytelniania systemu Windows w środowiskach, w których są używane serwery proxy i moduły równoważenia obciążenia, jest usługa Active Directory Federated Services (ADFS) z protokołem OpenID Connect (OIDC).

IIS/IIS Express

Microsoft.AspNetCore.Authentication.Negotiate Dodaj pakiet NuGet i usługi uwierzytelniania, wywołując polecenie AddAuthentication w pliku 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();

Poprzedni kod został wygenerowany przez szablon ASP.NET Core Razor Pages z określonym uwierzytelnianiem systemu Windows.

Uruchamianie ustawień (debuger)

Konfiguracja ustawień uruchamiania ma wpływ tylko na plik dla usług IIS Express i nie konfiguruje Properties/launchSettings.json usług IIS na potrzeby uwierzytelniania systemu Windows. Konfiguracja serwera jest objaśniona w sekcji IIS .

Szablony aplikacji internetowej dostępne za pośrednictwem programu Visual Studio lub interfejsu wiersza polecenia platformy .NET można skonfigurować tak, aby obsługiwały uwierzytelnianie systemu Properties/launchSettings.json Windows, które automatycznie aktualizuje plik.

"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

Usługi IIS używają modułu ASP.NET Core do hostowania aplikacji ASP.NET Core. Uwierzytelnianie systemu Windows jest konfigurowane dla usług IIS za pośrednictwem pliku web.config . W poniższych sekcjach pokazano, jak:

• Podaj lokalny plik web.config , który aktywuje uwierzytelnianie systemu Windows na serwerze po wdrożeniu aplikacji.
• Użyj Menedżera usług IIS, aby skonfigurować plik web.config aplikacji ASP.NET Core, która została już wdrożona na serwerze.

Jeśli jeszcze tego nie zrobiono, włącz usługi IIS do hostowania aplikacji ASP.NET Core. Aby uzyskać więcej informacji, zobacz Host ASP.NET Core w systemie Windows z usługami IIS.

Włącz usługę roli USŁUG IIS na potrzeby uwierzytelniania systemu Windows. Aby uzyskać więcej informacji, zobacz Włączanie uwierzytelniania systemu Windows w usługach ról usług IIS (zobacz Krok 2).

Oprogramowanie pośredniczące integracji usług IIS jest domyślnie skonfigurowane do automatycznego uwierzytelniania żądań. Aby uzyskać więcej informacji, zobacz Host ASP.NET Core w systemie Windows z usługami IIS: opcje usług IIS (AutomaticAuthentication).

Moduł ASP.NET Core jest skonfigurowany do przekazywania tokenu uwierzytelniania systemu Windows do aplikacji domyślnie. Aby uzyskać więcej informacji, zobacz ASP.NET Core Module configuration reference: Attributes of the aspNetCore element (Atrybuty elementu aspNetCore).

Użyj jednej z następujących metod:

• Przed opublikowaniem i wdrożeniem projektu dodaj następujący plik web.config do katalogu głównego projektu:

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

  Po opublikowaniu projektu przez SDK .NET (bez ustawienia właściwości <IsTransformWebConfigDisabled>true w pliku projektu) opublikowany plik web.config zawiera sekcję <location><system.webServer><security><authentication>. Aby uzyskać więcej informacji dotyczących właściwości <IsTransformWebConfigDisabled>, zobacz plikweb.config.

• Po opublikowaniu i wdrożeniu projektu wykonaj konfigurację po stronie serwera za pomocą Menedżera usług IIS:

  1. W Menedżerze usług IIS wybierz lokację usług IIS w węźle Lokacje na pasku bocznym Połączenia .
  2. Kliknij dwukrotnie pozycję Uwierzytelnianie w obszarze IIS .
  3. Wybierz pozycję Uwierzytelnianie anonimowe. Wybierz pozycję Wyłącz na pasku bocznym Akcje .
  4. Wybierz pozycję Uwierzytelnianie systemu Windows. Wybierz pozycję Włącz na pasku bocznym Akcje .

  Po zakończeniu tych akcji Menedżer usług IIS modyfikuje plik web.config aplikacji. Węzeł <system.webServer><security><authentication> jest dodawany ze zaktualizowanymi ustawieniami dla anonymousAuthentication i windowsAuthentication:

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

  <system.webServer> Sekcja dodana do pliku web.config przez Menedżera usług IIS znajduje się poza sekcją aplikacji <location> dodaną przez zestaw SDK platformy .NET po opublikowaniu aplikacji. Ponieważ sekcja jest dodawana poza węzłem <location> , ustawienia są dziedziczone przez wszystkie aplikacje podrzędne do bieżącej aplikacji. Aby zapobiec dziedziczeniu, przenieś dodaną sekcję <security> wewnątrz sekcji <location><system.webServer>, którą zapewnia zestaw SDK platformy .NET.

  Gdy Menedżer usług IIS jest używany do dodawania konfiguracji usług IIS, ma wpływ tylko na plik web.config aplikacji na serwerze. Kolejne wdrożenie aplikacji może zastąpić ustawienia na serwerze, jeśli kopia pliku web.config serwera zostanie zastąpiona przez plik web.config projektu. Aby zarządzać ustawieniami, użyj jednej z następujących metod:

  • Użyj Menedżera usług IIS, aby zresetować ustawienia w pliku web.config po zastąpieniu pliku we wdrożeniu.
  • Dodaj plik web.config do aplikacji lokalnie przy użyciu ustawień.

Kestrel

PakietMicrosoft.AspNetCore.Authentication.Negotiate NuGet może służyć Kestrel do włączania uwierzytelniania systemu Windows przy użyciu usług Negotiate i Kerberos w systemach Windows, Linux i macOS.

Uwierzytelnianie i zasady autoryzacji rezerwowej są włączone przez następujący wyróżniony kod w pliku 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();

Poprzedni kod został wygenerowany przez szablon ASP.NET Core Razor Pages z określonym uwierzytelnianiem systemu Windows.

Wyróżnione wiersze:

• 5–6: Zarejestruj i skonfiguruj mechanizm uwierzytelniania Negotiate.
• 8–11: AddAuthorization zasady rezerwowe domyślnie wymuszają uwierzytelnionych użytkowników.
• 26: UseAuthentication wykonuje procedury obsługi uwierzytelniania dla każdego żądania i wypełnia HttpContext.User.
• 27: UseAuthorization ocenia zasady autoryzacji, w tym zasady rezerwowe.

Uwierzytelnianie Kerberos i kontrola dostępu oparta na rolach (RBAC)

Uwierzytelnianie Kerberos w systemie Linux lub macOS nie udostępnia żadnych informacji o rolach dla uwierzytelnionego użytkownika. Aby dodać informacje o roli i grupie do użytkownika protokołu Kerberos, należy skonfigurować procedurę obsługi uwierzytelniania w celu pobrania ról z domeny LDAP. Najbardziej podstawowa konfiguracja określa tylko domenę LDAP do wykonywania zapytań względem i używa kontekstu uwierzytelnionego użytkownika do wykonywania zapytań dotyczących domeny LDAP:

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

Niektóre konfiguracje mogą wymagać określonych poświadczeń w celu wykonania zapytania o domenę LDAP. Poświadczenia można określić w następujących wyróżnionych opcjach:

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

Domyślnie program obsługi uwierzytelniania negocjowanego rozpoznaje zagnieżdżone domeny. W dużym lub skomplikowanym środowisku LDAP rozpoznawanie zagnieżdżonych domen może spowodować powolne wyszukiwanie lub dużą ilość pamięci używanej dla każdego użytkownika. Rozpoznawanie domeny zagnieżdżonej można wyłączyć przy użyciu IgnoreNestedGroups opcji .

Żądania anonimowe są dozwolone. Użyj autoryzacji ASP.NET Core, aby wysyłać żądania anonimowe na potrzeby uwierzytelniania.

Konfiguracja środowiska systemu Windows

InterfejsMicrosoft.AspNetCore.Authentication.Negotiate API wykonuje uwierzytelnianie w trybie użytkownika. Nazwy główne usługi (SPN) muszą zostać dodane do konta użytkownika, na którym jest uruchomiona usługa, a nie do konta komputera. Wykonaj setspn -S HTTP/myservername.mydomain.com myuser polecenie w administracyjnej powłoce poleceń.

Kerberos vs NTLM

Pakiet Negotiate on Kestrel dla ASP.NET Core próbuje użyć protokołu Kerberos, który jest bezpieczniejszym i peformantnym schematem uwierzytelniania niż 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 określa kerberos, ponieważ jest to ustawienie domyślne.

Usługi IIS, IISExpress i Kestrel obsługują protokoły Kerberos i NTLM.

Badanie nagłówka WWW-Authenticate: przy użyciu usług IIS lub IISExpress za pomocą narzędzia takiego jak Fiddler pokazuje Negotiate albo NTLM.

Kestrel tylko pokazuje WWW-Authenticate: Negotiate

Nagłówek WWW-Authenticate: Negotiate oznacza, że serwer może używać protokołu NTLM lub Kerberos. Kestrelwymaga prefiksu nagłówkaNegotiate żądania lub odpowiedzi. Protokół NTLM jest obsługiwany w systemie Kestrel, ale musi być wysyłany jako Negotiate.

W Kestrelsystemie , aby sprawdzić, czy jest używany protokół NTLM lub Kerberos, zdekoduj nagłówek Base64 i wyświetla NTLM wartość lub HTTP. HTTP wskazuje, że użyto protokołu Kerberos.

Konfiguracja środowiska systemu Linux i macOS

Instrukcje dotyczące dołączania maszyny z systemem Linux lub macOS do domeny systemu Windows są dostępne w artykule Łączenie programu Azure Data Studio z programem SQL Server przy użyciu uwierzytelniania systemu Windows — Kerberos . Instrukcje tworzenia konta maszyny dla maszyny z systemem Linux w domenie. Nazwy SPN należy dodać do tego konta komputera.

Po dołączeniu maszyny z systemem Linux lub macOS do domeny wymagane są dodatkowe kroki w celu dostarczenia pliku tab z nazwami SPN:

• Na kontrolerze domeny dodaj nowe nazwy SPN usługi internetowej do konta komputera:
  • setspn -S HTTP/mywebservice.mydomain.com mymachine
  • setspn -S HTTP/mywebservice@MYDOMAIN.COM mymachine
• Użyj narzędzia ktpass , aby wygenerować plik keytab:
  • 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
  • Niektóre pola muszą być określone wielkimi literami, jak wskazano.
• Skopiuj plik keytab na maszynę z systemem Linux lub macOS.
• Wybierz plik keytab za pomocą zmiennej środowiskowej: export KRB5_KTNAME=/tmp/mymachine.HTTP.keytab
• Wywołaj polecenie klist , aby wyświetlić nazwy SPN obecnie dostępne do użycia.

HTTP.sys

HTTP.sys obsługuje uwierzytelnianie systemu Windows w trybie jądra przy użyciu uwierzytelniania negocjacja, NTLM lub podstawowego.

Poniższy kod dodaje uwierzytelnianie i konfiguruje hosta internetowego aplikacji do używania HTTP.sys z uwierzytelnianiem systemu Windows:

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

Autoryzowanie użytkowników

Stan konfiguracji dostępu anonimowego określa sposób, w jaki [Authorize] atrybuty i [AllowAnonymous] są używane w aplikacji. W poniższych dwóch sekcjach opisano sposób obsługi niedozwolonych i dozwolonych stanów konfiguracji dostępu anonimowego.

Nie zezwalaj na dostęp anonimowy

Po włączeniu uwierzytelniania systemu Windows i wyłączeniu dostępu anonimowego [Authorize] atrybuty i [AllowAnonymous] nie mają wpływu. Jeśli witryna usług IIS jest skonfigurowana tak, aby nie zezwalała na dostęp anonimowy, żądanie nigdy nie dociera do aplikacji. Z tego powodu [AllowAnonymous] atrybut nie ma zastosowania.

Zezwalaj na dostęp anonimowy

Po włączeniu uwierzytelniania systemu Windows i dostępu anonimowego [Authorize] użyj atrybutów i [AllowAnonymous] . Atrybut [Authorize] umożliwia zabezpieczanie punktów końcowych aplikacji, które wymagają uwierzytelniania. Atrybut [AllowAnonymous] zastępuje [Authorize] atrybut w aplikacjach, które zezwalają na dostęp anonimowy. Aby uzyskać szczegółowe informacje o użyciu atrybutów, zobacz Simple authorization in ASP.NET Core (Prosta autoryzacja w programie ASP.NET Core).

Impersonation

ASP.NET Core nie implementuje personifikacji. Aplikacje są uruchamiane z tożsamością aplikacji dla wszystkich żądań przy użyciu puli aplikacji lub tożsamości procesu. Jeśli aplikacja powinna wykonać akcję w imieniu użytkownika, użyj WindowsIdentity.RunImpersonated lub RunImpersonatedAsync w końcowym środowisku pośredniczącym w Program.cs. Uruchom pojedynczą akcję w tym kontekście, a następnie zamknij kontekst.

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 Pakiet umożliwia uwierzytelnianie w systemach Windows, Linux i macOS, ale personifikacja jest obsługiwana tylko w systemie Windows.

Przekształcenia roszczeń

Hostowanie za pomocą usług IIS nie jest wywoływane wewnętrznie w AuthenticateAsync celu zainicjowania użytkownika. W związku z tym implementacja IClaimsTransformation używana do przekształcania oświadczeń po każdym uwierzytelnieniu nie jest domyślnie aktywowana. Aby uzyskać więcej informacji i przykład kodu, który aktywuje przekształcenia oświadczeń, zobacz Różnice między hostingiem w procesie i poza procesem.

Dodatkowe zasoby

• dotnet publish
• Hostowanie aplikacji ASP.NET Core w systemie Windows przy użyciu usług IIS
• Moduł ASP.NET Core (ANCM) dla usług IIS
• Profile publikowania programu Visual Studio (pubxml) dla wdrożenia aplikacji ASP.NET Core

Uwierzytelnianie systemu Windows (nazywane również uwierzytelnianiem Negotiate, Kerberos lub NTLM) można skonfigurować dla aplikacji ASP.NET Core hostowanych za pomocą usług IIS lub KestrelHTTP.sys.

Uwierzytelnianie systemu Windows opiera się na systemie operacyjnym do uwierzytelniania użytkowników aplikacji ASP.NET Core. Uwierzytelnianie systemu Windows można użyć, gdy serwer działa w sieci firmowej przy użyciu tożsamości domeny usługi Active Directory lub kont systemu Windows, aby zidentyfikować użytkowników. Uwierzytelnianie systemu Windows najlepiej nadaje się do środowisk intranetowych, w których użytkownicy, aplikacje klienckie i serwery internetowe należą do tej samej domeny systemu Windows.

Kiedy należy używać uwierzytelniania systemu Windows

Uwierzytelnianie systemu Windows jest odpowiednie dla aplikacji internetowych działających w prywatnej sieci wewnętrznej organizacji, dostępnej tylko dla pracowników (i innych autoryzowanych użytkowników) w tej samej sieci. Zarządzanie użytkownikami odbywa się w usłudze Active Directory (AD), a użytkownicy używają istniejącego konta domeny systemu Windows do uwierzytelniania.

Uwierzytelnianie systemu Windows zapewnia kilka korzyści dla aplikacji intranetowych:

• Bezproblemowe środowisko użytkownika — użytkownicy są automatycznie uwierzytelniani na podstawie aktywnej sesji systemu Windows lub są monitowani o wprowadzenie poświadczeń systemu Windows za pośrednictwem standardowego okna dialogowego przeglądarki.
• Integracja z usługą Active Directory — wykorzystuje istniejące zasady infrastruktury i zabezpieczeń systemu Windows, w tym grupy użytkowników, blokady kont i uwierzytelnianie wieloskładnikowe (MFA).
• Bezpieczna obsługa poświadczeń — uwierzytelnianie jest obsługiwane za pośrednictwem bezpiecznych protokołów, takich jak Kerberos, bez konieczności zarządzania oddzielnymi poświadczeniami użytkownika.
• Autoryzacja oparta na rolach — aplikacje mogą uzyskiwać dostęp do informacji o użytkownikach i grupach z usługi Active Directory, włączając kontrolę dostępu opartą na rolach (RBAC) w aplikacji.
• Mniejsze obciążenie administracyjne — nie trzeba utrzymywać oddzielnej bazy danych użytkownika ani systemu zarządzania poświadczeniami.

Dzięki temu uwierzytelnianie systemu Windows jest idealne dla organizacji, które chcą korzystać z istniejącej infrastruktury systemu Windows, takiej jak portale intranetowe.

W przypadku aplikacji publicznych uwierzytelnianie systemu Windows nie jest zalecane ze względu na problemy z zabezpieczeniami i użytecznością. Oto następujące przyczyny:

• Uwierzytelnianie systemu Windows najlepiej jest utrzymywać wewnętrznie, aby chronić usługę Active Directory, ujawnienie jej poza sieć wewnętrzną wprowadza zagrożenia bezpieczeństwa.
• Użytkownicy zewnętrzni nie mają kont domeny systemu Windows.
• Skonfigurowanie niezbędnej infrastruktury sieciowej jest skomplikowane, a zapory lub serwery proxy mogą zakłócać proces uwierzytelniania.
• Nie jest to platforma międzyplatformowa i nie udostępnia opcji dostosowywania dla projektów i środowisk użytkownika.

Alternatywy dla różnych scenariuszy

W zależności od wymagań aplikacji rozważ następujące alternatywy:

W przypadku aplikacji publicznych:

• OpenID Connect z zewnętrznymi dostawcami tożsamości
• ASP.NET Core Identity z kontami użytkowników lokalnych (wprowadzenie do Identity ASP.NET Core)
• Usługa Azure Active Directory (AAD) dla środowisk platformy Microsoft 365

W przypadku środowisk mieszanych z użytkownikami intranetowymi i zewnętrznymi:

• Active Directory Federation Services (ADFS) z openID Connect
• Usługa Azure Active Directory z konfiguracją hybrydową

W przypadku środowisk firmowych korzystających z nowoczesnego uwierzytelniania:

• Usługa Azure Active Directory z logowaniem jednokrotnym
• Rozwiązania oparte na protokole SAML z zewnętrznymi dostawcami tożsamości

Scenariusze serwera proxy i modułu równoważenia obciążenia

Uwierzytelnianie systemu Windows to scenariusz stanowy używany głównie w intranecie, w którym serwer proxy lub moduł równoważenia obciążenia zwykle nie obsługuje ruchu między klientami i serwerami. Jeśli używany jest serwer proxy lub moduł równoważenia obciążenia, uwierzytelnianie systemu Windows działa tylko wtedy, gdy serwer proxy lub moduł równoważenia obciążenia:

• Obsługuje uwierzytelnianie.
• Przekazuje informacje o uwierzytelnianiu użytkownika do aplikacji (na przykład w nagłówku żądania), która działa na podstawie informacji uwierzytelniania.

Alternatywą dla uwierzytelniania systemu Windows w środowiskach, w których są używane serwery proxy i moduły równoważenia obciążenia, jest usługa Active Directory Federated Services (ADFS) z protokołem OpenID Connect (OIDC).

IIS/IIS Express

Dodaj usługi uwierzytelniania, wywołując AddAuthentication metodę (Microsoft.AspNetCore.Server.IISIntegration przestrzeń nazw) w pliku Startup.ConfigureServices:

services.AddAuthentication(IISDefaults.AuthenticationScheme);

Uruchamianie ustawień (debuger)

Konfiguracja ustawień uruchamiania ma wpływ tylko na plik dla usług IIS Express i nie konfiguruje Properties/launchSettings.json usług IIS na potrzeby uwierzytelniania systemu Windows. Konfiguracja serwera jest objaśniona w sekcji IIS .

Szablon aplikacji internetowej dostępny za pośrednictwem programu Visual Studio lub interfejsu wiersza polecenia platformy .NET można skonfigurować do obsługi uwierzytelniania systemu Windows, który automatycznie aktualizuje Properties/launchSettings.json plik.

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

Podczas modyfikowania istniejącego projektu upewnij się, że plik projektu zawiera odwołanie do Microsoft.AspNetCore.App pakietu metadanychlubMicrosoft.AspNetCore.Authentication pakietu NuGet.

IIS

Usługi IIS używają modułu ASP.NET Core do hostowania aplikacji ASP.NET Core. Uwierzytelnianie systemu Windows jest konfigurowane dla usług IIS za pośrednictwem pliku web.config . W poniższych sekcjach pokazano, jak:

• Podaj lokalny plik web.config , który aktywuje uwierzytelnianie systemu Windows na serwerze po wdrożeniu aplikacji.
• Użyj Menedżera usług IIS, aby skonfigurować plik web.config aplikacji ASP.NET Core, która została już wdrożona na serwerze.

Jeśli jeszcze tego nie zrobiono, włącz usługi IIS do hostowania aplikacji ASP.NET Core. Aby uzyskać więcej informacji, zobacz Host ASP.NET Core w systemie Windows z usługami IIS.

Włącz usługę roli USŁUG IIS na potrzeby uwierzytelniania systemu Windows. Aby uzyskać więcej informacji, zobacz Włączanie uwierzytelniania systemu Windows w usługach ról usług IIS (zobacz Krok 2).

Oprogramowanie pośredniczące integracji usług IIS jest domyślnie skonfigurowane do automatycznego uwierzytelniania żądań. Aby uzyskać więcej informacji, zobacz Host ASP.NET Core w systemie Windows z usługami IIS: opcje usług IIS (AutomaticAuthentication).

Moduł ASP.NET Core jest skonfigurowany do przekazywania tokenu uwierzytelniania systemu Windows do aplikacji domyślnie. Aby uzyskać więcej informacji, zobacz ASP.NET Core Module configuration reference: Attributes of the aspNetCore element (Atrybuty elementu aspNetCore).

Użyj jednej z następujących metod:

• Przed opublikowaniem i wdrożeniem projektu dodaj następujący plik web.config do katalogu głównego projektu:

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

  Po opublikowaniu projektu przez SDK .NET (bez ustawienia właściwości <IsTransformWebConfigDisabled>true w pliku projektu) opublikowany plik web.config zawiera sekcję <location><system.webServer><security><authentication>. Aby uzyskać więcej informacji na <IsTransformWebConfigDisabled> temat właściwości, zobacz Host ASP.NET Core w systemie Windows z usługami IIS.

• Po opublikowaniu i wdrożeniu projektu wykonaj konfigurację po stronie serwera za pomocą Menedżera usług IIS:

  1. W Menedżerze usług IIS wybierz lokację usług IIS w węźle Lokacje na pasku bocznym Połączenia .
  2. Kliknij dwukrotnie pozycję Uwierzytelnianie w obszarze IIS .
  3. Wybierz pozycję Uwierzytelnianie anonimowe. Wybierz pozycję Wyłącz na pasku bocznym Akcje .
  4. Wybierz pozycję Uwierzytelnianie systemu Windows. Wybierz pozycję Włącz na pasku bocznym Akcje .

  Po zakończeniu tych akcji Menedżer usług IIS modyfikuje plik web.config aplikacji. Węzeł <system.webServer><security><authentication> jest dodawany ze zaktualizowanymi ustawieniami dla anonymousAuthentication i windowsAuthentication:

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

  <system.webServer> Sekcja dodana do pliku web.config przez Menedżera usług IIS znajduje się poza sekcją aplikacji <location> dodaną przez zestaw SDK platformy .NET po opublikowaniu aplikacji. Ponieważ sekcja jest dodawana poza węzłem <location> , ustawienia są dziedziczone przez wszystkie aplikacje podrzędne do bieżącej aplikacji. Aby zapobiec dziedziczeniu, przenieś dodaną sekcję <security> wewnątrz sekcji <location><system.webServer>, którą zapewnia zestaw SDK platformy .NET.

  Gdy Menedżer usług IIS jest używany do dodawania konfiguracji usług IIS, ma wpływ tylko na plik web.config aplikacji na serwerze. Kolejne wdrożenie aplikacji może zastąpić ustawienia na serwerze, jeśli kopia pliku web.config serwera zostanie zastąpiona przez plik web.config projektu. Aby zarządzać ustawieniami, użyj jednej z następujących metod:

  • Użyj Menedżera usług IIS, aby zresetować ustawienia w pliku web.config po zastąpieniu pliku we wdrożeniu.
  • Dodaj plik web.config do aplikacji lokalnie przy użyciu ustawień.

Kestrel

PakietMicrosoft.AspNetCore.Authentication.Negotiate NuGet może służyć Kestrel do obsługi uwierzytelniania systemu Windows przy użyciu usług Negotiate i Kerberos w systemach Windows, Linux i macOS.

Dodaj usługi uwierzytelniania, wywołując AddAuthentication polecenie i AddNegotiate w pliku Startup.ConfigureServices:

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

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

Dodaj oprogramowanie pośredniczące uwierzytelniania, wywołując polecenie w pliku UseAuthenticationStartup.Configure:

app.UseAuthentication();

Aby uzyskać więcej informacji na temat oprogramowania pośredniczącego, zobacz ASP.NET Core Middleware.

Uwierzytelnianie Kerberos i kontrola dostępu oparta na rolach (RBAC)

Uwierzytelnianie Kerberos w systemie Linux lub macOS nie udostępnia żadnych informacji o rolach dla uwierzytelnionego użytkownika. Aby dodać informacje o roli i grupie do użytkownika protokołu Kerberos, należy skonfigurować procedurę obsługi uwierzytelniania w celu pobrania ról z domeny LDAP. Najbardziej podstawowa konfiguracja określa tylko domenę LDAP do wykonywania zapytań względem i będzie używać kontekstu uwierzytelnionego użytkownika do wykonywania zapytań dotyczących domeny LDAP:

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

Niektóre konfiguracje mogą wymagać określonych poświadczeń w celu wykonania zapytania o domenę LDAP. Poświadczenia można określić w następujących wyróżnionych opcjach:

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

Domyślnie program obsługi uwierzytelniania negocjowanego rozpoznaje zagnieżdżone domeny. W dużym lub skomplikowanym środowisku LDAP rozpoznawanie zagnieżdżonych domen może spowodować powolne wyszukiwanie lub dużą ilość pamięci używanej dla każdego użytkownika. Rozpoznawanie domeny zagnieżdżonej można wyłączyć przy użyciu IgnoreNestedGroups opcji .

Żądania anonimowe są dozwolone. Użyj autoryzacji ASP.NET Core, aby wysyłać żądania anonimowe na potrzeby uwierzytelniania.

AuthenticationScheme Microsoft.AspNetCore.Authentication.Negotiate wymaga pakietu NuGet.

Konfiguracja środowiska systemu Windows

InterfejsMicrosoft.AspNetCore.Authentication.Negotiate API wykonuje uwierzytelnianie w trybie użytkownika. Nazwy główne usługi (SPN) muszą zostać dodane do konta użytkownika, na którym jest uruchomiona usługa, a nie do konta komputera. Wykonaj setspn -S HTTP/myservername.mydomain.com myuser polecenie w administracyjnej powłoce poleceń.

Konfiguracja środowiska systemu Linux i macOS

Instrukcje dotyczące dołączania maszyny z systemem Linux lub macOS do domeny systemu Windows są dostępne w artykule Łączenie programu Azure Data Studio z programem SQL Server przy użyciu uwierzytelniania systemu Windows — Kerberos . Instrukcje tworzenia konta maszyny dla maszyny z systemem Linux w domenie. Nazwy SPN należy dodać do tego konta komputera.

Po dołączeniu maszyny z systemem Linux lub macOS do domeny wymagane są dodatkowe kroki w celu dostarczenia pliku tab z nazwami SPN:

• Na kontrolerze domeny dodaj nowe nazwy SPN usługi internetowej do konta komputera:
  • setspn -S HTTP/mywebservice.mydomain.com mymachine
  • setspn -S HTTP/mywebservice@MYDOMAIN.COM mymachine
• Użyj narzędzia ktpass , aby wygenerować plik keytab:
  • 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
  • Niektóre pola muszą być określone wielkimi literami, jak wskazano.
• Skopiuj plik keytab na maszynę z systemem Linux lub macOS.
• Wybierz plik keytab za pomocą zmiennej środowiskowej: export KRB5_KTNAME=/tmp/mymachine.HTTP.keytab
• Wywołaj polecenie klist , aby wyświetlić nazwy SPN obecnie dostępne do użycia.

HTTP.sys

HTTP.sys obsługuje uwierzytelnianie systemu Windows w trybie jądra przy użyciu uwierzytelniania negocjacja, NTLM lub podstawowego.

Dodaj usługi uwierzytelniania, wywołując AddAuthentication metodę (Microsoft.AspNetCore.Server.HttpSys przestrzeń nazw) w pliku Startup.ConfigureServices:

services.AddAuthentication(HttpSysDefaults.AuthenticationScheme);

Skonfiguruj hosta internetowego aplikacji do używania HTTP.sys z uwierzytelnianiem systemu Windows (Program.cs). UseHttpSys znajduje się w Microsoft.AspNetCore.Server.HttpSys przestrzeni nazw.

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

Autoryzowanie użytkowników

Stan konfiguracji dostępu anonimowego określa sposób, w jaki [Authorize] atrybuty i [AllowAnonymous] są używane w aplikacji. W poniższych dwóch sekcjach opisano sposób obsługi niedozwolonych i dozwolonych stanów konfiguracji dostępu anonimowego.

Nie zezwalaj na dostęp anonimowy

Po włączeniu uwierzytelniania systemu Windows i wyłączeniu dostępu anonimowego [Authorize] atrybuty i [AllowAnonymous] nie mają wpływu. Jeśli witryna usług IIS jest skonfigurowana tak, aby nie zezwalała na dostęp anonimowy, żądanie nigdy nie dociera do aplikacji. Z tego powodu [AllowAnonymous] atrybut nie ma zastosowania.

Zezwalaj na dostęp anonimowy

Po włączeniu uwierzytelniania systemu Windows i dostępu anonimowego [Authorize] użyj atrybutów i [AllowAnonymous] . Atrybut [Authorize] umożliwia zabezpieczanie punktów końcowych aplikacji, które wymagają uwierzytelniania. Atrybut [AllowAnonymous] zastępuje [Authorize] atrybut w aplikacjach, które zezwalają na dostęp anonimowy. Aby uzyskać szczegółowe informacje o użyciu atrybutów, zobacz Simple authorization in ASP.NET Core (Prosta autoryzacja w programie ASP.NET Core).

Impersonation

ASP.NET Core nie implementuje personifikacji. Aplikacje są uruchamiane z tożsamością aplikacji dla wszystkich żądań przy użyciu puli aplikacji lub tożsamości procesu. Jeśli aplikacja powinna wykonać akcję w imieniu użytkownika, użyj elementu WindowsIdentity.RunImpersonated lub RunImpersonatedAsync w terminalu wbudowanego oprogramowania pośredniczącego w programie Startup.Configure. Uruchom pojedynczą akcję w tym kontekście, a następnie zamknij kontekst.

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 Pakiet umożliwia uwierzytelnianie w systemach Windows, Linux i macOS, ale personifikacja jest obsługiwana tylko w systemie Windows.

Przekształcenia roszczeń

Hostowanie za pomocą usług IIS nie jest wywoływane wewnętrznie w AuthenticateAsync celu zainicjowania użytkownika. W związku z tym implementacja IClaimsTransformation używana do przekształcania oświadczeń po każdym uwierzytelnieniu nie jest domyślnie aktywowana. Aby uzyskać więcej informacji i przykład kodu, który aktywuje przekształcenia oświadczeń, zobacz Różnice między hostingiem w procesie i poza procesem.

Dodatkowe zasoby

• dotnet publish
• Hostowanie aplikacji ASP.NET Core w systemie Windows przy użyciu usług IIS
• Moduł ASP.NET Core (ANCM) dla usług IIS
• Profile publikowania programu Visual Studio (pubxml) dla wdrożenia aplikacji ASP.NET Core