Configurar Windows autenticación en ASP.NET Core

Por Rick Anderson y Kirk Larkin

La Autenticación de Windows (también conocida como negociación, Kerberos o autenticación NTLM) se puede configurar para aplicaciones de ASP.NET Core hospedadas con IIS, Kestrelo HTTP.sys.

La Autenticación de Windows se basa en el sistema operativo para autenticar a los usuarios de aplicaciones de ASP.NET Core. La Autenticación de Windows se usa para servidores que se ejecutan en una red corporativa mediante identidades de dominio de Active Directory o cuentas de Windows para identificar a los usuarios. La Autenticación de Windows es más adecuada para entornos de intranet en los que los usuarios, las aplicaciones cliente y los servidores web pertenecen al mismo dominio de Windows.

Nota

La Autenticación de Windows no se admite con HTTP/2. Los desafíos de autenticación se pueden enviar en respuestas HTTP/2, pero el cliente debe cambiar a HTTP/1.1 antes de autenticarse.

Escenarios de proxy y equilibrador de carga

La Autenticación de Windows es un escenario con estado que se usa principalmente en una intranet, donde un proxy o equilibrador de carga no suele controlar el tráfico entre clientes y servidores. Si se usa un proxy o un equilibrador de carga, la Autenticación de Windows solo funciona si el proxy o el equilibrador de carga:

• Controla la autenticación.
• Pasa la información de autenticación de usuario a la aplicación (por ejemplo, en un encabezado de solicitud), que actúa sobre la información de autenticación.

Una alternativa a la Autenticación de Windows en entornos en los que se usan servidores proxy y equilibradores de carga son los Servicios federados de Active Directory (ADFS) con OpenID Connect (OIDC).

IIS/ IIS Express

Agregue el paquete NuGet Microsoft.AspNetCore.Authentication.Negotiate y los servicios de autenticación mediante una llamada a AddAuthentication en 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();

El código anterior lo generó la plantilla de Razor Pages de ASP.NET Core con la Autenticación de Windows especificada.

Configuración de inicio (depurador)

La configuración de los valores de inicio solo afecta al archivo Properties/launchSettings.json para IIS Express y no configura IIS para la Autenticación de Windows. La configuración del servidor se explica en la sección IIS.

Las plantillas de Aplicación web disponibles a través de Visual Studio o la CLI de .NET se pueden configurar para admitir la Autenticación de Windows, que actualiza el archivo Properties/launchSettings.json automáticamente.

Visual Studio

Nuevo proyecto

Cree una nueva aplicación de Razor Pages o MVC. En el cuadro de diálogo Información adicional, establezca el Tipo de autenticación en Windows.

Ejecutar la aplicación. El nombre de usuario aparece en la interfaz de usuario de la aplicación representada.

Proyecto existente

Las propiedades del proyecto habilitan la Autenticación de Windows y deshabilitan la Autenticación anónima. Abra el cuadro de diálogo de perfiles de inicio:

1. En el Explorador de soluciones, haga clic con el botón derecho en el proyecto y seleccione Propiedades.
2. Seleccione la pestaña Depurar > General y luego Abrir la interfaz de usuario de perfiles de inicio de depuración.
3. Desactive la casilla Habilitar Autenticación anónima.
4. Active la casilla Habilitar Autenticación de Windows.

Como alternativa, las propiedades se pueden configurar en el iisSettings nodo del archivo launchSettings.json:

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

CLI de .NET

Nuevo proyecto

Ejecute el comando dotnet new con el argumento webapp (ASP.NET Core Aplicación web) y --auth Windows cambie:

dotnet new webapp --auth Windows

Proyecto existente

Actualice el nodo iisSettings del archivo launchSettings.json:

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

IIS

IIS usa el Módulo de ASP.NET Core para hospedar aplicaciones de ASP.NET Core. La autenticación de Windows está configurada para IIS a través del archivo web.config. En las secciones siguientes se muestra cómo:

• Proporcione un archivo web.config local que active la Autenticación de Windows en el servidor cuando se implemente la aplicación.
• Use el Administrador de IIS para configurar el archivo web.config de una aplicación de ASP.NET Core que ya se ha implementado en el servidor.

Si aún no lo ha hecho, habilite IIS para hospedar aplicaciones de ASP.NET Core. Para más información, vea Host ASP.NET Core on Windows with IIS (Hospedar ASP.NET Core en Windows con IIS).

Habilite el Servicio de rol de IIS para la Autenticación de Windows. Para obtener más información, vea Habilitar la Autenticación de Windows en Servicios de roles de IIS (consulte el Paso 2).

El Middleware de integración de IIS está configurado para autenticar automáticamente las solicitudes de forma predeterminada. Para más información, vea Hospedar ASP.NET Core en Windows con IIS (Auntenticación automática).

El módulo de ASP.NET Core está configurado para reenviar el token de Autenticación de Windows a la aplicación de forma predeterminada. Para obtener más información, vea Referencia de configuración del módulo de ASP.NET Core: atributos del elemento aspNetCore.

Use cualquiera de los procedimientos siguientes:

• Antes de publicar e implementar el proyecto, agregue el siguiente archivo web.config a la raíz del proyecto:

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

  Cuando el SDK de .NET Core publica el proyecto (sin la <IsTransformWebConfigDisabled> propiedad true establecida en el archivo del proyecto), el archivo web.config publicado incluye la sección <location><system.webServer><security><authentication>. Para más información sobre la propiedad <IsTransformWebConfigDisabled>, vea Hospedar ASP.NET Core en Windows con IIS.

• Después de publicar e implementar el proyecto, realice la configuración del lado servidor con el Administrador de IIS:

  1. En el Administrador de IIS, seleccione el sitio de IIS en el nodo Sitios de la barra lateral Conexiones.
  2. Haga doble clic en Autenticación en el área IIS.
  3. Seleccione Autenticación anónima. Seleccione Deshabilitar en la barra lateral Acciones.
  4. Seleccione Autenticación de Windows. Seleccione Habilitar en la barra lateral Acciones.

  Cuando se realizan estas acciones, el Administrador de IIS modifica el archivo web.config de la aplicación. Se agrega un nodo <system.webServer><security><authentication> con la configuración actualizada para anonymousAuthentication y windowsAuthentication:

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

  La sección <system.webServer> agregada al archivo web.config por el Administrador de IIS está fuera de la sección <location> de la aplicación agregada por el SDK de .NET Core cuando se publica la aplicación. Dado que la sección se agrega fuera del nodo <location>, cualquier subaplicación hereda la configuración a la aplicación actual. Para evitar la herencia, mueva la sección <security> agregada dentro de la sección <location><system.webServer> que proporcionó el SDK de .NET Core.

  Cuando se usa el Administrador de IIS para agregar la configuración de IIS, solo afecta al archivo web.config de la aplicación en el servidor. Una implementación posterior de la aplicación puede sobrescribir la configuración en el servidor si la copia del servidor de web.config se reemplaza por el archivo web.config del proyecto. Use cualquiera de los métodos siguientes para administrar la configuración:

  • Use el Administrador de IIS para restablecer la configuración en el archivo web.config después de sobrescribir el archivo en la implementación.
  • Agregue un archivo web.config a la aplicación localmente con la configuración.

Kestrel

El paquete NuGet Microsoft.AspNetCore.Authentication.Negotiate se puede usar con Kestrel para admitir la Autenticación de Windows mediante Negotiate y Kerberos en Windows, Linux y macOS.

Advertencia

Las credenciales se pueden conservar entre solicitudes en una conexión. La autenticación Negotiate no se debe usar con servidores proxy a menos que el proxy mantenga una afinidad de conexión 1:1 (una conexión persistente) con Kestrel.

Nota

El controlador Negotiate detecta si el servidor subyacente admite la Autenticación de Windows de forma nativa y si está habilitado. Si el servidor admite la Autenticación de Windows, pero está deshabilitado, se produce un error que le pide que habilite la implementación del servidor. Cuando la Autenticación de Windows está habilitada en el servidor, el controlador Negotiate reenvía de forma transparente las solicitudes de autenticación a él.

La autenticación está habilitada mediante el código resaltado siguiente en 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();

El código anterior lo generó la plantilla de Razor Pages de ASP.NET Core con la Autenticación de Windows especificada. Las siguientes API se usan en el código anterior:

• AddAuthentication
• AddNegotiate
• UseAuthentication

Autenticación Kerberos y control de acceso basado en roles (RBAC)

La autenticación Kerberos en Linux o macOS no proporciona ninguna información de rol para un usuario autenticado. Para agregar información de rol y grupo a un usuario Kerberos, el controlador de autenticación debe configurarse para recuperar los roles de un dominio LDAP. La configuración más básica solo especifica un dominio LDAP en el que se va a consultar y usa el contexto del usuario autenticado para consultar el 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");
        }
    });

Algunas configuraciones pueden requerir credenciales específicas para consultar el dominio LDAP. Las credenciales se pueden especificar en las siguientes opciones resaltadas:

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

De forma predeterminada, el controlador de autenticación Negotiate resuelve los dominios anidados. En un entorno LDAP grande o complicado, resolver dominios anidados puede dar lugar a una búsqueda lenta o a una gran cantidad de memoria que se usa para cada usuario. La resolución de dominio anidada se puede deshabilitar mediante la opción IgnoreNestedGroups.

Se permiten solicitudes anónimas. Use la Autorización de ASP.NET Core para impugnar las solicitudes anónimas de autenticación.

Configuración del entorno de Windows

El componente Microsoft.AspNetCore.Authentication.Negotiate realiza la autenticación en Modo de usuario. Los Nombres de entidad de seguridad de servicio (SPN) deben agregarse a la cuenta de usuario que ejecuta el servicio, no a la cuenta de equipo. Ejecute setspn -S HTTP/myservername.mydomain.com myuser en un shell de comandos administrativo.

Kerberos frente a NTLM

El paquete Negotiate en Kestrel para ASP.NET Core intenta usar Kerberos, que es un esquema de autenticación más seguro y peformante 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 es el valor predeterminado.

IIS, IISExpress y Kestrel admiten Kerberos y NTLM.

Examinar el encabezado WWW-Authenticate: mediante IIS o IISExpress con una herramienta como Fiddler muestra Negotiate o NTLM.

Kestrel solo se muestra WWW-Authenticate: Negotiate

El encabezado WWW-Authenticate: Negotiate significa que el servidor puede usar NTLM o Kerberos. Kestrelrequiere el prefijo de encabezado de Negotiate, no admite la especificación NTLM directa en los encabezados de autenticación de solicitud o respuesta. NTLM se admite en Kestrel, pero se debe enviar como Negotiate.

En Kestrel, para ver si se usa NTLM o Kerberos, Base64 descodifica el encabezado y muestra NTLM o HTTP. HTTP indica que se usó Kerberos.

Configuración del entorno de Linux y macOS

Las instrucciones para unir una máquina Linux o macOS a un dominio de Windows están disponibles en el artículo Conexión de Azure Data Studio a SQL Server mediante la Autenticación de Windows: Kerberos. Las instrucciones crean una cuenta de máquina para la máquina Linux en el dominio. Los SPN deben agregarse a esa cuenta de máquina.

Nota

Al seguir las instrucciones del artículo Conexión de Azure Data Studio a SQL Server mediante la Autenticación de Windows: Kerberos, reemplace python-software-properties por python3-software-properties si es necesario.

Una vez que la máquina Linux o macOS está unida al dominio, se requieren pasos adicionales para proporcionar un archivo keytab con los SPN:

• En el controlador de dominio, agregue nuevos SPN de servicio web a la cuenta de equipo:
  • setspn -S HTTP/mywebservice.mydomain.com mymachine
  • setspn -S HTTP/mywebservice@MYDOMAIN.COM mymachine
• Use ktpass para generar un archivo 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
  • Algunos campos deben especificarse en mayúsculas como se indica.
• Copie el archivo keytab en la máquina Linux o macOS.
• Seleccione el archivo keytab mediante una variable de entorno: export KRB5_KTNAME=/tmp/mymachine.HTTP.keytab
• Invoque klist para mostrar los SPN disponibles actualmente para su uso.

Nota

Un archivo keytab contiene credenciales de acceso al dominio y debe protegerse en consecuencia.

HTTP.sys

HTTP.sys admite la autenticación de Windows en Modo Kernel mediante Negotiate, NTLM o Autenticación básica.

El código siguiente agrega autenticación y configura el host web de la aplicación para usar HTTP.sys con la Autenticación de 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 en la autenticación de Modo Kernel con el protocolo de autenticación de Kerberos. La autenticación de Modo usuario no se admite con Kerberos y HTTP.sys. Se debe usar la cuenta de equipo para descifrar el token o el vale de Kerberos que se obtiene de Active Directory y que el cliente reenvía al servidor para autenticar al usuario. Registre el nombre de entidad de seguridad de servicio (SPN) para el host, no el usuario de la aplicación.

Nota

HTTP.sys no se admite en Nano Server versión 1709 o posterior. Para utilizar la autenticación de Windows y HTTP.sys con Nano Server, utilice un contenedor Server Core (microsoft/windowsservercore) (consultar https://hub.docker.com/_/microsoft-windows-servercore). Para obtener más información sobre Server Core, vea ¿Qué es la opción de instalación Server Core en Windows Server?.

Autorizar a usuarios

El estado de configuración del acceso anónimo determina la forma en que se usan los atributos [Authorize] y [AllowAnonymous] en la aplicación. En las dos secciones siguientes se explica cómo controlar los estados de configuración no permitidos y permitidos del acceso anónimo.

No permitir el acceso anónimo

Cuando la Autenticación de Windows está habilitada y el acceso anónimo está deshabilitado, los atributos [Authorize] y [AllowAnonymous] no tienen ningún efecto. Si un sitio de IIS está configurado para no permitir el acceso anónimo, la solicitud nunca llega a la aplicación. Por este motivo, el atributo [AllowAnonymous] no es aplicable.

Permitir acceso anónimo

Cuando se habilita la Autenticación de Windows y el acceso anónimo, use los atributos [Authorize] y [AllowAnonymous]. El atributo [Authorize] permite proteger los puntos de conexión de la aplicación que requieren autenticación. El atributo [AllowAnonymous] invalida el atributo [Authorize] en las aplicaciones que permiten el acceso anónimo. Para más información sobre el uso de atributos, consulte Autorización simple en ASP.NET Core.

Nota:

De forma predeterminada, a los usuarios que carecen de autorización para acceder a una página se les presenta una respuesta HTTP 403 vacía. El Middleware StatusCodePages se puede configurar para proporcionar a los usuarios una mejor experiencia de "Acceso denegado".

Suplantación

ASP.NET Core no implementa la suplantación. Las aplicaciones se ejecutan con la identity de la aplicación para todas las solicitudes, mediante el grupo de aplicaciones o la identity del proceso. Si la aplicación debe realizar una acción en nombre de un usuario, utiliza WindowsIdentity.RunImpersonated o RunImpersonatedAsync en un middleware insertado de terminal en Program.cs. Ejecute una sola acción en este contexto y cierre el 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());
    }
});

Aunque el paquete Microsoft.AspNetCore.Authentication.Negotiate habilita la autenticación en Windows, Linux y macOS, la suplantación solo se admite en Windows.

Transformaciones de notificaciones

Cuando se hospeda con IIS, no se llama a AuthenticateAsync de forma interna para inicializar un usuario. Por tanto, se usa una implementación de IClaimsTransformation para transformar las notificaciones después de que cada autenticación no se active de forma predeterminada. Para obtener más información y un ejemplo de código que activa las transformaciones de notificaciones, consulte Diferencias entre el hospedaje dentro del proceso y fuera de proceso.

Recursos adicionales

• dotnet publish
• Hospedaje de ASP.NET Core en Windows con IIS
• Módulo ASP.NET Core (ANCM) para IIS
• Perfiles de publicación (.pubxml) de Visual Studio para la implementación de aplicaciones ASP.NET Core