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 Connessione (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 Core possono essere configurati per supportare l'autenticazione di Windows, che aggiorna automaticamente il Properties/launchSettings.json file.

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

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 sotto il nodo Siti della barra laterale Connessione ions.
    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:

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, II edizione Standard xpress e Kestrel supportano sia Kerberos che NTLM.

Esame dell'intestazione WWW-Authenticate: utilizzando IIS o II edizione Standard xpress con uno strumento come Fiddler mostra 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 Connessione Azure Data Studio per 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 Connessione Azure Data Studio per 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 delega l'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). 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 attributi e [AllowAnonymous] [[Authorize]](xref:Microsoft.AspNetCore.Authorization.AuthorizeAttribute) 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 attributi e [AllowAnonymous] gli attributi [[Authorize]](xref:Microsoft.AspNetCore.Authorization.AuthorizeAttribute). L'attributo [[Authorize]](xref:Microsoft.AspNetCore.Authorization.AuthorizeAttribute) 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'identità dell'app per tutte le richieste, usando il pool di app o l'identità del processo. Se l'app deve eseguire un'azione per conto di un utente, usa 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

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. È possibile usare l'autenticazione di Windows quando il server viene eseguito 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 Connessione (OIDC).

IIS/IIS Express

Aggiungere i servizi di autenticazione richiamando AddAuthentication (Microsoft.AspNetCore.Server.IISIntegration spazio dei nomi) in Startup.ConfigureServices:

services.AddAuthentication(IISDefaults.AuthenticationScheme);

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 .

Il modello applicazione Web disponibile tramite Visual Studio o l'interfaccia della riga di comando di .NET Core può essere configurato per supportare l'autenticazione di Windows, che aggiorna automaticamente il Properties/launchSettings.json file.

Nuovo progetto

  1. Creare un nuovo progetto.
  2. Selezionare Applicazione Web ASP.NET Core. Seleziona Avanti.
  3. Specificare un nome nel campo Nome progetto. Verificare che la voce Location sia corretta o specificare un percorso per il progetto. Seleziona Crea.
  4. Selezionare Cambia in Autenticazione.
  5. Nella finestra Modifica autenticazione selezionare Autenticazione di Windows. Seleziona OK.
  6. Selezionare Applicazione Web.
  7. Seleziona Crea.

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:

  1. Fare clic con il pulsante destro del mouse in Esplora soluzioni e scegliere Proprietà.
  2. Selezionare la scheda Debug.
  3. Deselezionare la casella di controllo Abilita autenticazione anonima.
  4. Selezionare la casella di controllo Abilita autenticazione di Windows.
  5. Salvare e chiudere la pagina delle proprietà.

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

Quando si modifica un progetto esistente, verificare che il file di progetto includa un riferimento al pacchetto per il metapacchettoMicrosoft.AspNetCore.App o il pacchetto NuGet Microsoft.AspNetCore.Authentication .

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 sotto il nodo Siti della barra laterale Connessione ions.
    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.

Aggiungere i servizi di autenticazione richiamando AddAuthentication e AddNegotiate in Startup.ConfigureServices:

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

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

Aggiungere il middleware di autenticazione chiamando UseAuthentication in Startup.Configure:

app.UseAuthentication();

Per altre informazioni sul middleware, vedere ASP.NET Middleware core.

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 query e userà il contesto dell'utente autenticato per eseguire query sul dominio LDAP:

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:

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

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.

AuthenticationScheme richiede il pacchetto NuGet Microsoft.AspNetCore.Authentication.Negotiate.

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.

Configurazione dell'ambiente Linux e macOS

Le istruzioni per aggiungere un computer Linux o macOS a un dominio Windows sono disponibili nell'articolo Connessione Azure Data Studio per 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 Connessione Azure Data Studio per 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.

Aggiungere i servizi di autenticazione richiamando AddAuthentication (Microsoft.AspNetCore.Server.HttpSys spazio dei nomi) in Startup.ConfigureServices:

services.AddAuthentication(HttpSysDefaults.AuthenticationScheme);

Configurare l'host Web dell'app per l'uso di HTTP.sys con l'autenticazione di Windows (Program.cs). UseHttpSys è nello spazio dei Microsoft.AspNetCore.Server.HttpSys nomi .

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

Nota

HTTP.sys delega l'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). 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'identità dell'app per tutte le richieste, usando il pool di app o l'identità del processo. Se l'app deve eseguire un'azione per conto di un utente, usa WindowsIdentity. RunImpersonated o RunImpersonatedAsync in un middleware inline del terminale in Startup.Configure. 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");

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

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