Configurar a autenticação do Windows no ASP.NET Core

A Autenticação do Windows (também conhecida como autenticação Negotiate, Kerberos ou NTLM) pode ser configurada para aplicativos ASP.NET Core hospedados com IISKestrel ou HTTP.sys.

A Autenticação do Windows depende do sistema operacional para autenticar usuários de aplicativos ASP.NET Core. A Autenticação do Windows é usada para servidores executados em uma rede corporativa usando identidades de domínio do Ative Directory ou contas do Windows para identificar usuários. A Autenticação do Windows é mais adequada para ambientes de intranet em que usuários, aplicativos cliente e servidores Web pertencem ao mesmo domínio do Windows.

Quando usar a Autenticação do Windows

A Autenticação do Windows é adequada para aplicativos Web que operam dentro da rede interna privada de uma organização, acessível apenas a funcionários (e outros usuários autorizados) dentro da mesma rede. O gerenciamento de usuários é feito no Ative Directory (AD) e os usuários usam sua conta de domínio existente do Windows para autenticar.

A Autenticação do Windows oferece vários benefícios para aplicativos de intranet:

• Experiência de usuário perfeita - Os usuários são autenticados automaticamente com base em sua sessão ativa do Windows ou são solicitados a inserir suas credenciais do Windows por meio de uma caixa de diálogo padrão do navegador.
• Integração com o Ative Directory - Aproveita a infraestrutura do Windows e as políticas de segurança existentes, incluindo grupos de usuários, bloqueios de conta e autenticação multifator (MFA).
• Tratamento seguro de credenciais - A autenticação é tratada por meio de protocolos seguros como Kerberos, sem a necessidade de gerenciar credenciais de usuário separadas.
• Autorização baseada em função - Os aplicativos podem acessar informações de usuário e grupo do Ative Directory, habilitando o controle de acesso baseado em função (RBAC) dentro do aplicativo.
• Sobrecarga administrativa reduzida - Não há necessidade de manter um banco de dados de usuários separado ou um sistema de gerenciamento de credenciais.

Isso torna a Autenticação do Windows ideal para organizações que desejam usar sua infraestrutura existente do Windows, como portais de intranet.

Para aplicativos voltados para o público, a Autenticação do Windows não é recomendada devido a questões de segurança e usabilidade. Estas razões incluem:

• A Autenticação do Windows é melhor mantida internamente para proteger o Ative Directory, expondo-o fora de uma rede interna introduz riscos de segurança.
• Os utilizadores externos não têm contas de domínio do Windows.
• É complexo configurar a infraestrutura de rede necessária com segurança, e firewalls ou proxies podem interferir no processo de autenticação.
• Não é multiplataforma e não fornece opções de personalização para designs e experiências do usuário.

Alternativas para diferentes cenários

Dependendo dos requisitos do seu aplicativo, considere estas alternativas:

Para aplicações públicas:

• OpenID Connect com provedores de identidade externos
• ASP.NET Core Identity com contas de usuário locais (Introdução ao Identity no ASP.NET Core)
• Azure Ative Directory (AAD) para ambientes Microsoft 365

Para ambientes mistos com intranet e usuários externos:

• Serviços de Federação do Active Directory (ADFS) com OpenID Connect
• Azure Ative Directory com configuração híbrida

Para ambientes corporativos que usam autenticação moderna:

• Azure Ative Directory com logon único
• Soluções baseadas em SAML com provedores de identidade de terceiros

Cenários de proxy e balanceador de carga

Autenticação do Windows é um cenário orientado a estado usado principalmente numa intranet, onde um proxy ou balanceador de carga geralmente não costuma lidar com o tráfego entre clientes e servidores. Se um proxy ou balanceador de carga for usado, a Autenticação do Windows só funcionará se o proxy ou balanceador de carga:

• Gere a autenticação.
• Passa as informações de autenticação do usuário para o aplicativo (por exemplo, em um cabeçalho de solicitação), que atua sobre as informações de autenticação.

Uma alternativa à Autenticação do Windows em ambientes onde proxies e balanceadores de carga são usados é o Ative Directory Federated Services (ADFS) com OpenID Connect (OIDC).

IIS/IIS Express

Adicione o Microsoft.AspNetCore.Authentication.Negotiate pacote NuGet e os serviços de autenticação chamando AddAuthentication em 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();

O código anterior foi gerado pelo modelo ASP.NET Core Razor Pages com a Autenticação do Windows especificada.

Configurações de inicialização (depurador)

A configuração para definições de inicialização afeta apenas o ficheiro Properties/launchSettings.json para o IIS Express e não configura o IIS para autenticação do Windows. A configuração do servidor é explicada na seção IIS .

Os modelos de Aplicativo Web disponíveis por meio do Visual Studio ou da CLI do .NET podem ser configurados para oferecer suporte à Autenticação do Windows, que atualiza o Properties/launchSettings.json arquivo automaticamente.

"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

O IIS usa o ASP.NET Core Module para hospedar aplicativos ASP.NET Core. A Autenticação do Windows está configurada para o IIS através do ficheiro web.config . As seções a seguir mostram como:

• Forneça um arquivo web.config local que ative a Autenticação do Windows no servidor quando o aplicativo for implantado.
• Use o Gerenciador do IIS para configurar o arquivo deweb.config de um aplicativo ASP.NET Core que já foi implantado no servidor.

Se você ainda não tiver feito isso, habilite o IIS para hospedar aplicativos ASP.NET Core. Para obter mais informações, consulte Host ASP.NET Core no Windows com IIS.

Habilite o serviço de função do IIS para autenticação do Windows. Para obter mais informações, consulte Habilitar a autenticação do Windows nos Serviços de Função do IIS (consulte a Etapa 2).

O middleware de integração do IIS é configurado para autenticar automaticamente solicitações por padrão. Para obter mais informações, consulte Host ASP.NET Core no Windows com IIS: opções do IIS (AutomaticAuthentication).

O ASP.NET Core Module está configurado para encaminhar o token de Autenticação do Windows para o aplicativo por padrão. Para obter mais informações, consulte ASP.NET referência de configuração do módulo principal: atributos do elemento aspNetCore.

Use uma das seguintes abordagens:

• Antes de publicar e implantar o projeto, adicione o seguinte arquivo deweb.config à raiz do projeto:

  <?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 o projeto é publicado pelo SDK do .NET (sem a propriedade <IsTransformWebConfigDisabled> definida como true no arquivo de projeto), o arquivo de web.config publicado inclui a seção <location><system.webServer><security><authentication>. Para obter mais informações sobre a <IsTransformWebConfigDisabled> propriedade, consulte web.config arquivo.

• Depois de publicar e implantar o projeto, execute a configuração do lado do servidor com o Gerenciador do IIS:

  1. No Gerenciador do IIS, selecione o site do IIS no nó Sites da barra lateral Conexões .
  2. Clique duas vezes em Autenticação na área do IIS .
  3. Selecione Autenticação anônima. Selecione Desativar na barra lateral Ações .
  4. Selecione Autenticação do Windows. Selecione Ativar na barra lateral Ações .

  Quando essas ações são executadas, o Gerenciador do IIS modifica o arquivo deweb.config do aplicativo. Um <system.webServer><security><authentication> nó é adicionado com configurações atualizadas para anonymousAuthentication e windowsAuthentication:

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

  A <system.webServer> secção adicionada ao arquivo web.config pelo Gestor do IIS está fora da secção <location> do aplicativo adicionada pelo SDK do .NET quando o aplicativo é publicado. Como a seção é adicionada fora do <location> nó, as configurações são herdadas por quaisquer subaplicativos para o aplicativo atual. Para evitar herança, mova a seção adicionada <security> para dentro da seção <location><system.webServer> fornecida pelo SDK do .NET.

  Quando o Gerenciador do IIS é usado para adicionar a configuração do IIS, ele afeta apenas o arquivo deweb.config do aplicativo no servidor. Uma implantação subsequente do aplicativo pode substituir configurações no servidor se a cópia do servidor web.config for substituída pelo arquivo do projeto web.config. Use uma das seguintes abordagens para gerenciar as configurações:

  • Use o Gerenciador do IIS para redefinir as configurações no arquivo web.config depois que o arquivo for substituído na implantação.
  • Adicione um arquivoweb.config ao aplicativo localmente com as configurações.

Kestrel

O Microsoft.AspNetCore.Authentication.Negotiate pacote NuGet pode ser usado para Kestrel habilitar a Autenticação do Windows usando Negociar e Kerberos no Windows, Linux e macOS.

A autenticação e uma política de autorização de fallback são habilitadas pelo seguinte código realçado em 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();

O código anterior foi gerado pelo modelo ASP.NET Core Razor Pages com a Autenticação do Windows especificada.

Linhas em destaque:

• 5–6: AddAuthentication e AddNegotiate registam e configuram o manipulador de autenticação Negotiate.
• 8–11: AddAuthorization com uma política de fallback impõe usuários autenticados por padrão.
• 26: UseAuthentication executa manipuladores de autenticação para cada solicitação e preenche o HttpContext.User.
• 27: UseAuthorization Avalia as políticas de autorização, incluindo a política de contingência.

Autenticação Kerberos e RBAC (controle de acesso baseado em função)

A autenticação Kerberos no Linux ou macOS não fornece nenhuma informação de função para um usuário autenticado. Para adicionar informações de função e grupo a um usuário Kerberos, o manipulador de autenticação deve ser configurado para recuperar as funções de um domínio LDAP. A configuração mais básica especifica apenas um domínio LDAP para consulta e usa o contexto do usuário autenticado para consultar o domínio 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");
        }
    });

Algumas configurações podem exigir credenciais específicas para consultar o domínio LDAP. As credenciais podem ser especificadas nas seguintes opções realçadas:

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

Por padrão, o manipulador de autenticação de negociação é responsável por resolver domínios aninhados. Em um ambiente LDAP grande ou complicado, a resolução de domínios aninhados pode resultar em uma pesquisa lenta ou muita memória sendo usada para cada usuário. A resolução de domínio aninhada pode ser desativada usando a opção IgnoreNestedGroups.

São permitidos pedidos anónimos. Use ASP.NET Autorização Principal para desafiar solicitações anônimas de autenticação.

Configuração do ambiente Windows

A Microsoft.AspNetCore.Authentication.Negotiate API executa a autenticação do Modo de Usuário . Os SPNs (Nomes de Serviço) devem ser adicionados à conta de utilizador que executa o serviço, não à conta da máquina. Execute setspn -S HTTP/myservername.mydomain.com myuser em um shell de comando administrativo.

Kerberos vs NTLM

O pacote Negotiate no Kestrel para ASP.NET Core tenta usar Kerberos, que é um esquema de autenticação mais seguro e performante do que 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 especifica Kerberos porque é o padrão.

IIS, IISExpress e Kestrel suportam Kerberos e NTLM.

Examinando o cabeçalho WWW-Authenticate: usando IIS ou IISExpress com uma ferramenta como Fiddler, mostram, ou Negotiate, NTLM.

Kestrel só mostra WWW-Authenticate: Negotiate

O WWW-Authenticate: Negotiate cabeçalho significa que o servidor pode usar NTLM ou Kerberos. Kestrel requer o prefixo Negotiate cabeçalho, mas não suporta a especificação direta de NTLM nos cabeçalhos de autenticação de solicitação ou resposta. O NTLM é suportado no Kestrel, mas deve ser enviado como Negotiate.

Em Kestrel, para ver se NTLM ou Kerberos é utilizado, decodifica o cabeçalho Base64 e mostra um NTLM ou HTTP. HTTP indica que Kerberos foi usado.

Configuração do ambiente Linux e macOS

As instruções para associar uma máquina Linux ou macOS a um domínio do Windows estão disponíveis no artigo Conectar o Azure Data Studio ao seu SQL Server usando a autenticação do Windows - Kerberos . As instruções criam uma conta de máquina para a máquina Linux no domínio. Os SPNs devem ser adicionados a essa conta de computador.

Uma vez que a máquina Linux ou macOS é unida ao domínio, etapas adicionais são necessárias para fornecer um arquivo keytab com os SPNs:

• No controlador de domínio, adicione novos SPNs de serviço Web à conta da máquina:
  • setspn -S HTTP/mywebservice.mydomain.com mymachine
  • setspn -S HTTP/mywebservice@MYDOMAIN.COM mymachine
• Use ktpass para gerar um arquivo 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
  • Alguns campos devem ser especificados em maiúsculas, conforme indicado.
• Copie o arquivo keytab para a máquina Linux ou macOS.
• Selecione o arquivo keytab através de uma variável de ambiente: export KRB5_KTNAME=/tmp/mymachine.HTTP.keytab
• Invoque klist para mostrar os SPNs atualmente disponíveis para uso.

HTTP.sys

HTTP.sys suporta a Autenticação do Windows no Modo Kernel usando a autenticação Negotiate, NTLM ou Basic.

O seguinte código adiciona a autenticação e configura o host da aplicação para usar HTTP.sys com Autenticação do 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;
        });
}

Autorizar usuários

O estado de configuração do acesso anônimo determina a maneira como os [Authorize] atributos e [AllowAnonymous] são usados no aplicativo. As duas seções a seguir explicam como lidar com os estados de configuração não permitidos e permitidos do acesso anônimo.

Não permitir acesso anônimo

Quando a Autenticação do Windows está habilitada e o acesso anônimo está desabilitado, os [Authorize] atributos e [AllowAnonymous] não têm efeito. Se um site do IIS estiver configurado para não permitir acesso anônimo, a solicitação nunca chegará ao aplicativo. Por esse motivo, o [AllowAnonymous] atributo não é aplicável.

Permitir acesso anónimo

Quando a Autenticação do Windows e o acesso anônimo estiverem habilitados, use os atributos [Authorize] e [AllowAnonymous]. O [Authorize] atributo permite que você proteja pontos de extremidade do aplicativo que exigem autenticação. O [AllowAnonymous] atributo substitui o [Authorize] atributo em aplicativos que permitem acesso anônimo. Para obter detalhes sobre o uso do atributo, consulte Autorização simples no ASP.NET Core.

Impersonation

ASP.NET Core não implementa a personificação. As aplicações são executadas com a identidade da aplicação para todas as solicitações, usando o pool de aplicações ou a identidade do processo. Se o aplicativo deve executar uma ação em nome de um usuário, use WindowsIdentity.RunImpersonated ou RunImpersonatedAsync em um middleware embutido no terminal em Program.cs. Execute uma única ação neste contexto e, em seguida, feche o contexto.

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

Embora o Microsoft.AspNetCore.Authentication.Negotiatepacote permita a autenticação no Windows, Linux e macOS, a impersonação só é suportada no Windows.

Transformações de sinistros

Ao hospedar com o IIS, AuthenticateAsync não é chamado internamente para inicializar um usuário. Portanto, uma implementação de IClaimsTransformation usada para transformar declarações após cada autenticação não é ativada por padrão. Para obter mais informações e um exemplo de código que ativa transformações de declarações, consulte Diferenças entre hospedagem em processo e fora do processo.

Recursos adicionais

• dotnet publicar
• Alojar o ASP.NET Core no Windows com o IIS
• ASP.NET Módulo Principal (ANCM) para IIS
• pt-PT: Perfis de publicação do Visual Studio (.pubxml) para a implementação de aplicações ASP.NET Core

A Autenticação do Windows (também conhecida como autenticação Negotiate, Kerberos ou NTLM) pode ser configurada para aplicativos ASP.NET Core hospedados com IISKestrel ou HTTP.sys.

A Autenticação do Windows depende do sistema operacional para autenticar usuários de aplicativos ASP.NET Core. Você pode usar a Autenticação do Windows quando o servidor é executado em uma rede corporativa usando identidades de domínio do Ative Directory ou contas do Windows para identificar usuários. A Autenticação do Windows é mais adequada para ambientes de intranet em que usuários, aplicativos cliente e servidores Web pertencem ao mesmo domínio do Windows.

Quando usar a Autenticação do Windows

A Autenticação do Windows é adequada para aplicativos Web que operam dentro da rede interna privada de uma organização, acessível apenas a funcionários (e outros usuários autorizados) dentro da mesma rede. O gerenciamento de usuários é feito no Ative Directory (AD) e os usuários usam sua conta de domínio existente do Windows para autenticar.

A Autenticação do Windows oferece vários benefícios para aplicativos de intranet:

• Experiência de usuário perfeita - Os usuários são autenticados automaticamente com base em sua sessão ativa do Windows ou são solicitados a inserir suas credenciais do Windows por meio de uma caixa de diálogo padrão do navegador.
• Integração com o Ative Directory - Aproveita a infraestrutura do Windows e as políticas de segurança existentes, incluindo grupos de usuários, bloqueios de conta e autenticação multifator (MFA).
• Tratamento seguro de credenciais - A autenticação é tratada por meio de protocolos seguros como Kerberos, sem a necessidade de gerenciar credenciais de usuário separadas.
• Autorização baseada em função - Os aplicativos podem acessar informações de usuário e grupo do Ative Directory, habilitando o controle de acesso baseado em função (RBAC) dentro do aplicativo.
• Sobrecarga administrativa reduzida - Não há necessidade de manter um banco de dados de usuários separado ou um sistema de gerenciamento de credenciais.

Isso torna a Autenticação do Windows ideal para organizações que desejam usar sua infraestrutura existente do Windows, como portais de intranet.

Para aplicativos voltados para o público, a Autenticação do Windows não é recomendada devido a questões de segurança e usabilidade. Estas razões incluem:

• A Autenticação do Windows é melhor mantida internamente para proteger o Ative Directory, expondo-o fora de uma rede interna introduz riscos de segurança.
• Os utilizadores externos não têm contas de domínio do Windows.
• É complexo configurar a infraestrutura de rede necessária com segurança, e firewalls ou proxies podem interferir no processo de autenticação.
• Não é multiplataforma e não fornece opções de personalização para designs e experiências do usuário.

Alternativas para diferentes cenários

Dependendo dos requisitos do seu aplicativo, considere estas alternativas:

Para aplicações públicas:

• OpenID Connect com provedores de identidade externos
• ASP.NET Core Identity com contas de usuário locais (Introdução ao Identity no ASP.NET Core)
• Azure Ative Directory (AAD) para ambientes Microsoft 365

Para ambientes mistos com intranet e usuários externos:

• Serviços de Federação do Active Directory (ADFS) com OpenID Connect
• Azure Ative Directory com configuração híbrida

Para ambientes corporativos que usam autenticação moderna:

• Azure Ative Directory com logon único
• Soluções baseadas em SAML com provedores de identidade de terceiros

Cenários de proxy e balanceador de carga

Autenticação do Windows é um cenário orientado a estado usado principalmente numa intranet, onde um proxy ou balanceador de carga geralmente não costuma lidar com o tráfego entre clientes e servidores. Se um proxy ou balanceador de carga for usado, a Autenticação do Windows só funcionará se o proxy ou balanceador de carga:

• Gere a autenticação.
• Passa as informações de autenticação do usuário para o aplicativo (por exemplo, em um cabeçalho de solicitação), que atua sobre as informações de autenticação.

Uma alternativa à Autenticação do Windows em ambientes onde proxies e balanceadores de carga são usados é o Ative Directory Federated Services (ADFS) com OpenID Connect (OIDC).

IIS/IIS Express

Adicione serviços de autenticação invocando AddAuthentication (Microsoft.AspNetCore.Server.IISIntegration namespace) em Startup.ConfigureServices:

services.AddAuthentication(IISDefaults.AuthenticationScheme);

Configurações de inicialização (depurador)

A configuração para definições de inicialização afeta apenas o ficheiro Properties/launchSettings.json para o IIS Express e não configura o IIS para autenticação do Windows. A configuração do servidor é explicada na seção IIS .

O modelo de Aplicativo Web disponível via Visual Studio ou a CLI do .NET pode ser configurado para dar suporte à Autenticação do Windows, que atualiza o Properties/launchSettings.json arquivo automaticamente.

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

Ao modificar um projeto existente, confirme se o arquivo de projeto inclui uma referência de pacote para o Microsoft.AspNetCore.App metapacoteou o Microsoft.AspNetCore.Authentication pacote NuGet.

IIS

O IIS usa o ASP.NET Core Module para hospedar aplicativos ASP.NET Core. A Autenticação do Windows está configurada para o IIS através do ficheiro web.config . As seções a seguir mostram como:

• Forneça um arquivo web.config local que ative a Autenticação do Windows no servidor quando o aplicativo for implantado.
• Use o Gerenciador do IIS para configurar o arquivo deweb.config de um aplicativo ASP.NET Core que já foi implantado no servidor.

Se você ainda não tiver feito isso, habilite o IIS para hospedar aplicativos ASP.NET Core. Para obter mais informações, consulte Host ASP.NET Core no Windows com IIS.

Habilite o serviço de função do IIS para autenticação do Windows. Para obter mais informações, consulte Habilitar a autenticação do Windows nos Serviços de Função do IIS (consulte a Etapa 2).

O middleware de integração do IIS é configurado para autenticar automaticamente solicitações por padrão. Para obter mais informações, consulte Host ASP.NET Core no Windows com IIS: opções do IIS (AutomaticAuthentication).

O ASP.NET Core Module está configurado para encaminhar o token de Autenticação do Windows para o aplicativo por padrão. Para obter mais informações, consulte ASP.NET referência de configuração do módulo principal: atributos do elemento aspNetCore.

Use uma das seguintes abordagens:

• Antes de publicar e implantar o projeto, adicione o seguinte arquivo deweb.config à raiz do projeto:

  <?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 o projeto é publicado pelo SDK do .NET (sem a propriedade <IsTransformWebConfigDisabled> definida como true no arquivo de projeto), o arquivo de web.config publicado inclui a seção <location><system.webServer><security><authentication>. Para obter mais informações sobre a <IsTransformWebConfigDisabled> propriedade, consulte Host ASP.NET Core no Windows com IIS.

• Depois de publicar e implantar o projeto, execute a configuração do lado do servidor com o Gerenciador do IIS:

  1. No Gerenciador do IIS, selecione o site do IIS no nó Sites da barra lateral Conexões .
  2. Clique duas vezes em Autenticação na área do IIS .
  3. Selecione Autenticação anônima. Selecione Desativar na barra lateral Ações .
  4. Selecione Autenticação do Windows. Selecione Ativar na barra lateral Ações .

  Quando essas ações são executadas, o Gerenciador do IIS modifica o arquivo deweb.config do aplicativo. Um <system.webServer><security><authentication> nó é adicionado com configurações atualizadas para anonymousAuthentication e windowsAuthentication:

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

  A <system.webServer> secção adicionada ao arquivo web.config pelo Gestor do IIS está fora da secção <location> do aplicativo adicionada pelo SDK do .NET quando o aplicativo é publicado. Como a seção é adicionada fora do <location> nó, as configurações são herdadas por quaisquer subaplicativos para o aplicativo atual. Para evitar herança, mova a seção adicionada <security> para dentro da seção <location><system.webServer> fornecida pelo SDK do .NET.

  Quando o Gerenciador do IIS é usado para adicionar a configuração do IIS, ele afeta apenas o arquivo deweb.config do aplicativo no servidor. Uma implantação subsequente do aplicativo pode substituir configurações no servidor se a cópia do servidor web.config for substituída pelo arquivo do projeto web.config. Use uma das seguintes abordagens para gerenciar as configurações:

  • Use o Gerenciador do IIS para redefinir as configurações no arquivo web.config depois que o arquivo for substituído na implantação.
  • Adicione um arquivoweb.config ao aplicativo localmente com as configurações.

Kestrel

O Microsoft.AspNetCore.Authentication.Negotiate pacote NuGet pode ser usado com Kestrel para suportar a Autenticação Windows usando Negotiate e Kerberos no Windows, Linux e macOS.

Adicione serviços de autenticação invocando AddAuthentication e AddNegotiate em Startup.ConfigureServices:

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

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

Adicione o middleware de autenticação chamando UseAuthentication em Startup.Configure.

app.UseAuthentication();

Para obter mais informações sobre middleware, consulte ASP.NET Core Middleware.

Autenticação Kerberos e RBAC (controle de acesso baseado em função)

A autenticação Kerberos no Linux ou macOS não fornece nenhuma informação de função para um usuário autenticado. Para adicionar informações de função e grupo a um usuário Kerberos, o manipulador de autenticação deve ser configurado para recuperar as funções de um domínio LDAP. A configuração mais básica especifica apenas um domínio LDAP para consulta e usará o contexto do usuário autenticado para consultar o domínio LDAP:

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

Algumas configurações podem exigir credenciais específicas para consultar o domínio LDAP. As credenciais podem ser especificadas nas seguintes opções realçadas:

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

Por padrão, o manipulador de autenticação de negociação é responsável por resolver domínios aninhados. Em um ambiente LDAP grande ou complicado, a resolução de domínios aninhados pode resultar em uma pesquisa lenta ou muita memória sendo usada para cada usuário. A resolução de domínio aninhada pode ser desativada usando a opção IgnoreNestedGroups.

São permitidos pedidos anónimos. Use ASP.NET Autorização Principal para desafiar solicitações anônimas de autenticação.

AuthenticationScheme requer o Microsoft.AspNetCore.Authentication.Negotiate pacote NuGet.

Configuração do ambiente Windows

A Microsoft.AspNetCore.Authentication.Negotiate API executa a autenticação do Modo de Usuário . Os SPNs (Nomes de Serviço) devem ser adicionados à conta de utilizador que executa o serviço, não à conta da máquina. Execute setspn -S HTTP/myservername.mydomain.com myuser em um shell de comando administrativo.

Configuração do ambiente Linux e macOS

As instruções para associar uma máquina Linux ou macOS a um domínio do Windows estão disponíveis no artigo Conectar o Azure Data Studio ao seu SQL Server usando a autenticação do Windows - Kerberos . As instruções criam uma conta de máquina para a máquina Linux no domínio. Os SPNs devem ser adicionados a essa conta de computador.

Uma vez que a máquina Linux ou macOS é unida ao domínio, etapas adicionais são necessárias para fornecer um arquivo keytab com os SPNs:

• No controlador de domínio, adicione novos SPNs de serviço Web à conta da máquina:
  • setspn -S HTTP/mywebservice.mydomain.com mymachine
  • setspn -S HTTP/mywebservice@MYDOMAIN.COM mymachine
• Use ktpass para gerar um arquivo 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
  • Alguns campos devem ser especificados em maiúsculas, conforme indicado.
• Copie o arquivo keytab para a máquina Linux ou macOS.
• Selecione o arquivo keytab através de uma variável de ambiente: export KRB5_KTNAME=/tmp/mymachine.HTTP.keytab
• Invoque klist para mostrar os SPNs atualmente disponíveis para uso.

HTTP.sys

HTTP.sys suporta a Autenticação do Windows no Modo Kernel usando a autenticação Negotiate, NTLM ou Basic.

Adicione serviços de autenticação invocando AddAuthentication (Microsoft.AspNetCore.Server.HttpSys namespace) em Startup.ConfigureServices:

services.AddAuthentication(HttpSysDefaults.AuthenticationScheme);

Configure o host web do aplicativo para usar HTTP.sys com Autenticação do Windows (Program.cs). UseHttpSys está no espaço de nomes Microsoft.AspNetCore.Server.HttpSys.

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

Autorizar usuários

O estado de configuração do acesso anônimo determina a maneira como os [Authorize] atributos e [AllowAnonymous] são usados no aplicativo. As duas seções a seguir explicam como lidar com os estados de configuração não permitidos e permitidos do acesso anônimo.

Não permitir acesso anônimo

Quando a Autenticação do Windows está habilitada e o acesso anônimo está desabilitado, os [Authorize] atributos e [AllowAnonymous] não têm efeito. Se um site do IIS estiver configurado para não permitir acesso anônimo, a solicitação nunca chegará ao aplicativo. Por esse motivo, o [AllowAnonymous] atributo não é aplicável.

Permitir acesso anónimo

Quando a Autenticação do Windows e o acesso anônimo estiverem habilitados, use os atributos [Authorize] e [AllowAnonymous]. O [Authorize] atributo permite que você proteja pontos de extremidade do aplicativo que exigem autenticação. O [AllowAnonymous] atributo substitui o [Authorize] atributo em aplicativos que permitem acesso anônimo. Para obter detalhes sobre o uso do atributo, consulte Autorização simples no ASP.NET Core.

Impersonation

ASP.NET Core não implementa a personificação. As aplicações são executadas com a identidade da aplicação para todas as solicitações, usando o pool de aplicações ou a identidade do processo. Se o aplicativo deve executar uma ação em nome de um usuário, use WindowsIdentity.RunImpersonated ou RunImpersonatedAsync em um middleware embutido de terminal em Startup.Configure. Execute uma única ação neste contexto e, em seguida, feche o contexto.

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

Embora o Microsoft.AspNetCore.Authentication.Negotiatepacote permita a autenticação no Windows, Linux e macOS, a impersonação só é suportada no Windows.

Transformações de sinistros

Ao hospedar com o IIS, AuthenticateAsync não é chamado internamente para inicializar um usuário. Portanto, uma implementação de IClaimsTransformation usada para transformar declarações após cada autenticação não é ativada por padrão. Para obter mais informações e um exemplo de código que ativa transformações de declarações, consulte Diferenças entre hospedagem em processo e fora do processo.

Recursos adicionais

• dotnet publicar
• Alojar o ASP.NET Core no Windows com o IIS
• ASP.NET Módulo Principal (ANCM) para IIS
• pt-PT: Perfis de publicação do Visual Studio (.pubxml) para a implementação de aplicações ASP.NET Core