Configurare l'autenticazione di Windows in ASP.NET Core

Di Rick Anderson e Kirk Larkin

L'autenticazione di Windows (nota anche come autenticazione Negotiate, Kerberos o NTLM) può essere configurata per ASP.NET app Core ospitate con IIS, Kestrelo HTTP.sys.

L'autenticazione di Windows si basa sul sistema operativo per autenticare gli utenti delle app ASP.NET Core. L'autenticazione di Windows viene usata per i server eseguiti in una rete aziendale usando identità di dominio Active Directory o account Di Windows per identificare gli utenti. L'autenticazione di Windows è più adatta agli ambienti Intranet in cui gli utenti, le app client e i server Web appartengono allo stesso dominio di Windows.

Nota

L'autenticazione di Windows non è supportata con HTTP/2. Le richieste di autenticazione possono essere inviate nelle risposte HTTP/2, ma il client deve effettuare il downgrade a HTTP/1.1 prima dell'autenticazione.

Scenari di proxy e bilanciamento del carico

L'autenticazione di Windows è uno scenario con stato usato principalmente in una intranet, in cui un proxy o un servizio di bilanciamento del carico in genere non gestisce il traffico tra client e server. Se si usa un proxy o un servizio di bilanciamento del carico, l'autenticazione di Windows funziona solo se il proxy o il servizio di bilanciamento del carico:

• Gestisce l'autenticazione.
• Passa le informazioni di autenticazione utente all'app (ad esempio, in un'intestazione di richiesta), che agisce sulle informazioni di autenticazione.

Un'alternativa all'autenticazione di Windows negli ambienti in cui vengono usati proxy e servizi di bilanciamento del carico è Active Directory Federated Services (ADFS) con OpenID Connect (OIDC).

IIS/IIS Express

Aggiungere il pacchetto NuGet Microsoft.AspNetCore.Authentication.Negotiate e i servizi di autenticazione chiamando AddAuthentication in 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();

Il codice precedente è stato generato dal modello ASP.NET Core Razor Pages con l'autenticazione di Windows specificata.

Impostazioni di avvio (debugger)

La configurazione per le impostazioni di avvio influisce solo sul Properties/launchSettings.json file per IIS Express e non configura IIS per l'autenticazione di Windows. La configurazione del server è illustrata nella sezione IIS .

I modelli di applicazione Web disponibili tramite Visual Studio o l'interfaccia della riga di comando di .NET possono essere configurati per supportare l'autenticazione di Windows, che aggiorna automaticamente il Properties/launchSettings.json file.

Visual Studio

Nuovo progetto

Creare una nuova Razor app Pages o MVC. Nella finestra di dialogo Informazioni aggiuntive impostare Il tipo di autenticazione su Windows.

Eseguire l'app. Il nome utente viene visualizzato nell'interfaccia utente dell'app sottoposta a rendering.

Progetto esistente

Le proprietà del progetto abilitano l'autenticazione di Windows e disabilitano l'autenticazione anonima. Aprire la finestra di dialogo profili di avvio:

1. In Esplora soluzioni fare clic con il pulsante destro del mouse sul progetto e selezionare Proprietà.
2. Selezionare la scheda Debug > Generale e selezionare Aprire interfaccia utente profili di avvio debug.
3. Deselezionare la casella di controllo Abilita autenticazione anonima.
4. Selezionare la casella di controllo Abilita autenticazione di Windows.

In alternativa, le proprietà possono essere configurate nel iisSettings nodo del launchSettings.json file:

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

CLI .NET

Nuovo progetto

Eseguire il comando dotnet new con l'argomento webapp (ASP.NET Core Web App) e --auth Windows passare:

dotnet new webapp --auth Windows

Progetto esistente

Aggiornare il iisSettings nodo del launchSettings.json file:

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

IIS

IIS usa il modulo ASP.NET Core per ospitare ASP.NET app Core. L'autenticazione di Windows è configurata per IIS tramite il file web.config . Le sezioni seguenti mostrano come:

• Specificare un file web.config locale che attiva l'autenticazione di Windows nel server quando l'app viene distribuita.
• Usare Gestione IIS per configurare il file web.config di un'app ASP.NET Core già distribuita nel server.

Se non è già stato fatto, abilitare IIS per ospitare ASP.NET app Core. Per altre informazioni, vedere Host ASP.NET Core on Windows with IIS (Host ASP.NET Core in Windows con IIS).

Abilitare il servizio ruolo IIS per l'autenticazione di Windows. Per altre informazioni, vedere Abilitare l'autenticazione di Windows in Servizi ruolo IIS (vedere Passaggio 2).

Il middleware di integrazione IIS è configurato per autenticare automaticamente le richieste per impostazione predefinita. Per altre informazioni, vedere Host ASP.NET Core in Windows con IIS: opzioni IIS (AutomaticAuthentication).For more information, see Host ASP.NET Core on Windows with IIS: IIS options (AutomaticAuthentication).

Il modulo ASP.NET Core è configurato per inoltrare il token di autenticazione di Windows all'app per impostazione predefinita. Per altre informazioni, vedere ASP.NET Informazioni di riferimento sulla configurazione del modulo core: Attributi dell'elemento aspNetCore.

Usare uno degli approcci seguenti:

• Prima di pubblicare e distribuire il progetto, aggiungere il file web.config seguente alla radice del progetto:

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

  Quando il progetto viene pubblicato da .NET Core SDK (senza la <IsTransformWebConfigDisabled> proprietà impostata true su nel file di progetto), il file web.config pubblicato include la <location><system.webServer><security><authentication> sezione . Per altre informazioni sulla <IsTransformWebConfigDisabled> proprietà, vedere Host ASP.NET Core in Windows con IIS.

• Dopo la pubblicazione e la distribuzione del progetto, eseguire la configurazione lato server con Gestione IIS:

  1. In Gestione IIS selezionare il sito IIS nel nodo Siti della barra laterale Connessioni .
  2. Fare doppio clic su Autenticazione nell'area IIS .
  3. Selezionare Autenticazione anonima. Selezionare Disabilita nella barra laterale Azioni .
  4. Selezionare Autenticazione di Windows. Selezionare Abilita nella barra laterale Azioni .

  Quando vengono eseguite queste azioni, Gestione IIS modifica il file web.config dell'app. Viene aggiunto un <system.webServer><security><authentication> nodo con le impostazioni aggiornate per anonymousAuthentication e windowsAuthentication:

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

  La <system.webServer> sezione aggiunta al file web.config da Gestione IIS si trova all'esterno della sezione dell'app <location> aggiunta da .NET Core SDK quando l'app viene pubblicata. Poiché la sezione viene aggiunta all'esterno del <location> nodo, le impostazioni vengono ereditate da tutte le app secondarie all'app corrente. Per impedire l'ereditarietà, spostare la sezione aggiunta <security> all'interno della <location><system.webServer> sezione fornita da .NET Core SDK.

  Quando Si usa Gestione IIS per aggiungere la configurazione IIS, influisce solo sul file web.config dell'app nel server. Una successiva distribuzione dell'app può sovrascrivere le impostazioni nel server se la copia di web.config del server viene sostituita dal file web.config del progetto. Usare uno degli approcci seguenti per gestire le impostazioni:

  • Usare Gestione IIS per reimpostare le impostazioni nel file web.config dopo la sovrascrittura del file durante la distribuzione.
  • Aggiungere un file web.config all'app in locale con le impostazioni.

Kestrel

Il pacchetto NuGet Microsoft.AspNetCore.Authentication.Negotiate può essere usato con Kestrel per supportare l'autenticazione di Windows tramite Negotiate e Kerberos in Windows, Linux e macOS.

Avviso

Le credenziali possono essere mantenute tra le richieste in una connessione. L'autenticazione negoziata non deve essere usata con proxy, a meno che il proxy non mantenga un'affinità di connessione 1:1 (una connessione permanente) con Kestrel.

Nota

Il gestore Negotiate rileva se il server sottostante supporta l'autenticazione di Windows in modo nativo e se è abilitato. Se il server supporta l'autenticazione di Windows ma è disabilitato, viene generato un errore che chiede di abilitare l'implementazione del server. Quando l'autenticazione di Windows è abilitata nel server, il gestore Negotiate inoltra in modo trasparente le richieste di autenticazione.

L'autenticazione è abilitata dal codice evidenziato seguente in 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();

Il codice precedente è stato generato dal modello ASP.NET Core Razor Pages con l'autenticazione di Windows specificata. Nel codice precedente vengono usate le API seguenti:

• AddAuthentication
• AddNegotiate
• UseAuthentication

Autenticazione Kerberos e controllo degli accessi in base al ruolo

L'autenticazione Kerberos in Linux o macOS non fornisce informazioni sul ruolo per un utente autenticato. Per aggiungere informazioni sui ruoli e sui gruppi a un utente Kerberos, è necessario configurare il gestore di autenticazione per recuperare i ruoli da un dominio LDAP. La configurazione più semplice specifica solo un dominio LDAP su cui eseguire una query e usa il contesto dell'utente autenticato per eseguire query sul dominio 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");
        }
    });

Alcune configurazioni possono richiedere credenziali specifiche per eseguire query sul dominio LDAP. Le credenziali possono essere specificate nelle opzioni evidenziate seguenti:

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

Per impostazione predefinita, il gestore di autenticazione negotiate risolve i domini annidati. In un ambiente LDAP di grandi dimensioni o complicato, la risoluzione dei domini annidati può comportare una ricerca lenta o una quantità elevata di memoria usata per ogni utente. La risoluzione del dominio annidata può essere disabilitata usando l'opzione IgnoreNestedGroups .

Le richieste anonime sono consentite. Usare ASP.NET'autorizzazione di base per verificare le richieste anonime per l'autenticazione.

Configurazione dell'ambiente Windows

Il componente Microsoft.AspNetCore.Authentication.Negotiate esegue l'autenticazione in modalità utente. I nomi dell'entità servizio (SPN) devono essere aggiunti all'account utente che esegue il servizio, non all'account del computer. Eseguire setspn -S HTTP/myservername.mydomain.com myuser in una shell dei comandi amministrativa.

Kerberos e NTLM

Il pacchetto Negotiate on Kestrel per ASP.NET Core tenta di usare Kerberos, che è uno schema di autenticazione più sicuro e peformante rispetto a 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 specifica Kerberos perché è l'impostazione predefinita.

IIS, IISExpress e Kestrel supportano sia Kerberos che NTLM.

Esaminando l'intestazione WWW-Authenticate: tramite IIS o IISExpress con uno strumento come Fiddler viene visualizzato Negotiate o NTLM.

Kestrel mostra solo WWW-Authenticate: Negotiate

L'intestazione WWW-Authenticate: Negotiate indica che il server può usare NTLM o Kerberos. Kestrel richiede il Negotiate prefisso dell'intestazione, non supporta la specifica NTLM diretta nelle intestazioni di autenticazione della richiesta o della risposta. NTLM è supportato in Kestrel, ma deve essere inviato come Negotiate.

In Kestrelper verificare se viene usato NTLM o Kerberos, La codifica Base64 dell'intestazione e mostra NTLM o HTTP. HTTP indica che è stato usato Kerberos.

Configurazione dell'ambiente Linux e macOS

Le istruzioni per aggiungere un computer Linux o macOS a un dominio Windows sono disponibili nell'articolo Connettere Azure Data Studio a SQL Server usando autenticazione di Windows - Kerberos. Le istruzioni creano un account computer per il computer Linux nel dominio. I nomi SPN devono essere aggiunti all'account del computer.

Nota

Quando si seguono le indicazioni riportate nell'articolo Connettere Azure Data Studio a SQL Server usando autenticazione di Windows - Kerberos, sostituire python-software-properties conpython3-software-properties, se necessario.

Dopo aver aggiunto il computer Linux o macOS al dominio, sono necessari passaggi aggiuntivi per fornire un file keytab con i nomi SPN:

• Nel controller di dominio aggiungere nuovi nomi SPN del servizio Web all'account del computer:
  • setspn -S HTTP/mywebservice.mydomain.com mymachine
  • setspn -S HTTP/mywebservice@MYDOMAIN.COM mymachine
• Usare ktpass per generare un file 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
  • Alcuni campi devono essere specificati in lettere maiuscole come indicato.
• Copiare il file keytab nel computer Linux o macOS.
• Selezionare il file keytab tramite una variabile di ambiente: export KRB5_KTNAME=/tmp/mymachine.HTTP.keytab
• Richiamare klist per visualizzare i nomi SPN attualmente disponibili per l'uso.

Nota

Un file keytab contiene le credenziali di accesso al dominio e deve essere protetto di conseguenza.

HTTP.sys

HTTP.sys supporta l'autenticazione di Windows in modalità kernel tramite l'autenticazione Negotiate, NTLM o Basic.

Il codice seguente aggiunge l'autenticazione e configura l'host Web dell'app per l'uso di HTTP.sys con l'autenticazione di 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;
        });
}

Nota

HTTP.sys delegati all'autenticazione in modalità kernel con il protocollo di autenticazione Kerberos. L'autenticazione in modalità utente non è supportata con Kerberos e HTTP.sys. È necessario usare l'account del computer per decrittografare il token/ticket Kerberos ottenuto da Active Directory e inoltrato dal client al server per autenticare l'utente. Registrare il nome dell'entità servizio per l'host, non l'utente dell'app.

Nota

HTTP.sys non è supportato in Nano Server versione 1709 o successiva. Per usare l'autenticazione di Windows e HTTP.sys con Nano Server, usare un contenitore Server Core (microsoft/windowsservercore) (vedere https://hub.docker.com/_/microsoft-windows-servercore). Per altre informazioni su Server Core, vedere Che cos'è l'opzione di installazione Server Core in Windows Server?.

Autorizzare gli utenti

Lo stato di configurazione dell'accesso anonimo determina il modo in cui [Authorize] gli attributi e [AllowAnonymous] vengono usati nell'app. Le due sezioni seguenti illustrano come gestire gli stati di configurazione non consentiti e consentiti dell'accesso anonimo.

Non consentire l'accesso anonimo

Quando l'autenticazione di Windows è abilitata e l'accesso anonimo è disabilitato, gli [Authorize] attributi e [AllowAnonymous] non hanno alcun effetto. Se un sito IIS è configurato per impedire l'accesso anonimo, la richiesta non raggiunge mai l'app. Per questo motivo, l'attributo [AllowAnonymous] non è applicabile.

Consenti accesso anonimo

Quando l'autenticazione di Windows e l'accesso anonimo sono abilitati, usare gli [Authorize] attributi e [AllowAnonymous] . L'attributo [Authorize] consente di proteggere gli endpoint dell'app che richiedono l'autenticazione. L'attributo [AllowAnonymous] esegue l'override dell'attributo nelle app che consentono l'accesso [Authorize] anonimo. Per informazioni dettagliate sull'utilizzo degli attributi, vedere Autorizzazione semplice in ASP.NET Core.

Nota

Per impostazione predefinita, gli utenti che non dispongono dell'autorizzazione per accedere a una pagina vengono presentati con una risposta HTTP 403 vuota. Il middleware StatusCodePages può essere configurato per offrire agli utenti una migliore esperienza di accesso negato.

Rappresentazione

ASP.NET Core non implementa la rappresentazione. Le app vengono eseguite con l'app identity per tutte le richieste, usando il pool di app o il processo identity. Se l'app deve eseguire un'azione per conto di un utente, usare WindowsIdentity.RunImpersonated o RunImpersonatedAsync in un middleware inline del terminale in Program.cs. Eseguire una singola azione in questo contesto e quindi chiudere il contesto.

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

Mentre il pacchetto Microsoft.AspNetCore.Authentication.Negotiate abilita l'autenticazione in Windows, Linux e macOS, la rappresentazione è supportata solo in Windows.

Trasformazioni delle attestazioni

Quando si ospita con IIS, AuthenticateAsync non viene chiamato internamente per inizializzare un utente. Pertanto, un'implementazione di IClaimsTransformation usate per trasformare le attestazioni dopo ogni autenticazione non viene attivata per impostazione predefinita. Per altre informazioni e un esempio di codice che attiva le trasformazioni delle attestazioni, vedere Differenze tra hosting in-process e out-of-process.

Risorse aggiuntive

• dotnet publish
• Host ASP.NET Core in Windows con IIS
• Modulo ASP.NET Core (ANCM) per IIS
• Profili di pubblicazione di Visual Studio (.pubxml) per la distribuzione di app ASP.NET Core