Настройка аутентификации Windows в ASP.NET Core

Авторы: Рик Андерсон (Rick Anderson) и Кирк Ларкин (Kirk Larkin)

Проверка подлинности Windows (также известная как согласование, проверка подлинности Kerberos или NTLM) можно настроить для ASP.NET основных приложений, размещенных с помощью IIS, Kestrelили HTTP.sys.

Проверка подлинности Windows использует операционную систему для проверки подлинности пользователей приложений ASP.NET Core. Проверка подлинности Windows используется для серверов, работающих в корпоративной сети, с помощью удостоверений домена Active Directory или учетных записей Windows для идентификации пользователей. Проверка подлинности Windows лучше всего подходит для сред интрасети, где пользователи, клиентские приложения и веб-серверы принадлежат одному домену Windows.

Примечание.

Проверка подлинности Windows не поддерживается с http/2. Проблемы проверки подлинности можно отправлять на ответы HTTP/2, но перед проверкой подлинности клиент должен перейти на HTTP/1.1.

Сценарии прокси-сервера и подсистемы балансировки нагрузки

Проверка подлинности Windows — это сценарий с отслеживанием состояния, в основном используемый в интрасети, где прокси-сервер или подсистема балансировки нагрузки обычно не обрабатывает трафик между клиентами и серверами. Если используется прокси-сервер или подсистема балансировки нагрузки, проверка подлинности Windows работает только в том случае, если прокси-сервер или подсистема балансировки нагрузки:

• Обрабатывает проверку подлинности.
• Передает сведения о проверке подлинности пользователя приложению (например, в заголовке запроса), который действует на сведения о проверке подлинности.

Альтернативой проверке подлинности Windows в средах, где используются прокси-серверы и подсистемы балансировки нагрузки, являются федеративные службы Active Directory (ADFS) с OpenID Connect (OIDC).

IIS/IIS Express

Добавьте пакет NuGet Microsoft.AspNetCore.Authentication.Negotiate и службы проверки подлинности путем вызоваAddAuthentication: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();

Предыдущий код был создан шаблоном ASP.NET Core Razor Pages с указанной проверкой подлинности Windows.

Параметры запуска (отладчик)

Конфигурация параметров запуска влияет только на Properties/launchSettings.json файл IIS Express и не настраивает службы IIS для проверки подлинности Windows. Конфигурация сервера описана в разделе IIS .

Шаблоны веб-приложений, доступные через Visual Studio или .NET CLI, можно настроить для поддержки проверки подлинности Windows, которая Properties/launchSettings.json обновляет файл автоматически.

Visual Studio

Новый проект

Создайте новое Razor приложение Pages или MVC. В диалоговом окне "Дополнительные сведения" задайте тип проверки подлинности в Windows.

Выполнить приложение. Имя пользователя отображается в пользовательском интерфейсе отрисованного приложения.

Существующий проект

Свойства проекта позволяют включить проверку подлинности Windows и отключить анонимную проверку подлинности. Откройте диалоговое окно профилей запуска:

1. В Обозревателе решений щелкните проект правой кнопкой мыши и выберите Свойства.
2. Откройте вкладку Отладка > Общие и выберите пункт Открыть пользовательский интерфейс профилей запуска отладки.
3. Снимите флажок для включения анонимной проверки подлинности.
4. Установите флажок для включения проверки подлинности Windows.

Кроме того, свойства можно настроить в iisSettings узле launchSettings.json файла:

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

Интерфейс командной строки.NET

Новый проект

Выполните команду dotnet new с аргументом webapp (ASP.NET Core Web App) и --auth Windows переключитесь:

dotnet new webapp --auth Windows

Существующий проект

iisSettings Обновите узел launchSettings.json файла:

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

IIS

СЛУЖБА IIS использует модуль ASP.NET Core для размещения приложений ASP.NET Core. Проверка подлинности Windows настроена для IIS через файл web.config . В следующих разделах показано, как выполнить следующие задачи:

• Укажите локальный файл web.config , который активирует проверку подлинности Windows на сервере при развертывании приложения.
• Используйте диспетчер IIS для настройки файла web.config приложения ASP.NET Core, которое уже развернуто на сервере.

Если вы еще этого не сделали, включите службы IIS для размещения ASP.NET основных приложений. Дополнительные сведения см. в разделе Размещение ASP.NET Core в Windows со службами IIS.

Включите службу ролей IIS для проверки подлинности Windows. Дополнительные сведения см. в разделе "Включение проверки подлинности Windows" в службах ролей IIS (см. шаг 2).

ПО промежуточного слоя интеграции IIS настроено для автоматической проверки подлинности запросов по умолчанию. Дополнительные сведения см. в разделе "Узел ASP.NET Ядро" в Windows с помощью служб IIS: параметры IIS (автоматическая проверка подлинности).

Модуль ASP.NET Core настроен для пересылки маркера проверки подлинности Windows в приложение по умолчанию. Дополнительные сведения см. в разделе ASP.NET Справочник по конфигурации ядра: атрибуты элемента aspNetCore.

Используйте любой из следующих подходов:

• Перед публикацией и развертыванием проекта добавьте следующий файл web.config в корневой каталог проекта:

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

  Когда проект публикуется пакетом SDK для .NET Core (без свойства, заданного <IsTransformWebConfigDisabled> true в файле проекта), опубликованный файл web.config содержит <location><system.webServer><security><authentication> раздел. Дополнительные сведения о свойстве <IsTransformWebConfigDisabled> см. в разделе "Узел ASP.NET Core" в Windows с помощью IIS.

• После публикации и развертывания проекта выполните настройку на стороне сервера с помощью диспетчера IIS:

  1. В диспетчере IIS выберите сайт IIS в узле "Сайты " боковой панели "Подключения ".
  2. Дважды щелкните проверку подлинности в области IIS .
  3. Выберите анонимную проверку подлинности. Выберите "Отключить " на боковой панели "Действия ".
  4. Выберите параметр Проверка подлинности Windows. Выберите "Включить " на боковой панели "Действия ".

  При выполнении этих действий диспетчер IIS изменяет файл веб-конфигурации приложения. Узел <system.webServer><security><authentication> добавляется с обновленными параметрами для anonymousAuthentication и windowsAuthentication:

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

  Раздел <system.webServer> , добавленный в файл конфигурации web.config диспетчером IIS, находится вне раздела приложения <location> , добавленного пакетом SDK для .NET Core при публикации приложения. Так как раздел добавляется за пределами <location> узла, параметры наследуются любыми вложенными приложениями в текущем приложении. Чтобы предотвратить наследование, переместите добавленный <security> раздел внутри <location><system.webServer> раздела, предоставленного пакетом SDK для .NET Core.

  Если диспетчер IIS используется для добавления конфигурации IIS, он влияет только на файл веб-конфигурации приложения на сервере. Последующее развертывание приложения может перезаписать параметры на сервере, если копия веб.config сервера заменена файлом web.config проекта. Используйте любой из следующих подходов для управления параметрами:

  • Используйте диспетчер IIS для сброса параметров в файле web.config после перезаписи файла при развертывании.
  • Добавьте файл web.config в приложение локально с параметрами.

Kestrel

Пакет NuGet Microsoft.AspNetCore.Authentication.Negotiate можно использовать для Kestrel поддержки проверки подлинности Windows с помощью переговоров и Kerberos в Windows, Linux и macOS.

Предупреждение

Учетные данные можно сохранять в запросах подключения. Согласование проверки подлинности не должно использоваться с прокси-серверами, если прокси-сервер не поддерживает сопоставление подключений 1:1 (постоянное подключение).Kestrel

Примечание.

Обработчик переговоров определяет, поддерживает ли базовый сервер проверку подлинности Windows в собственном коде и включен ли он. Если сервер поддерживает проверку подлинности Windows, но он отключен, возникает ошибка с просьбой включить реализацию сервера. Если проверка подлинности Windows включена на сервере, обработчик согласований прозрачно перенаправит запросы проверки подлинности на него.

Проверка подлинности включена следующим выделенным кодом 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();

Предыдущий код был создан шаблоном ASP.NET Core Razor Pages с указанной проверкой подлинности Windows. В предыдущем коде используются следующие API:

• AddAuthentication
• AddNegotiate
• UseAuthentication

Проверка подлинности Kerberos и управление доступом на основе ролей (RBAC)

Проверка подлинности Kerberos в Linux или macOS не предоставляет никаких сведений о роли для пользователя, прошедшего проверку подлинности. Чтобы добавить сведения о роли и группе пользователю Kerberos, обработчик проверки подлинности должен быть настроен для получения ролей из домена LDAP. Самая базовая конфигурация указывает только домен LDAP для запроса и использует контекст пользователя, прошедший проверку подлинности, для запроса домена 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");
        }
    });

Для запроса домена 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(settings =>
                {
                    settings.Domain = "contoso.com";
                    settings.MachineAccountName = "machineName";
                    settings.MachineAccountPassword =
                                      builder.Configuration["Password"];
                });
            }
        });

builder.Services.AddRazorPages();

По умолчанию обработчик проверки подлинности согласовывает вложенные домены. В большой или сложной среде LDAP разрешение вложенных доменов может привести к медленному поиску или много памяти, используемой для каждого пользователя. Разрешение вложенных доменов можно отключить с помощью IgnoreNestedGroups параметра.

Анонимные запросы разрешены. Используйте ASP.NET Core Authorization для вызова анонимных запросов на проверку подлинности.

Конфигурация среды Windows

Компонент Microsoft.AspNetCore.Authentication.Negotiate выполняет проверку подлинности в пользовательском режиме . Имена субъектов-служб (SPN) необходимо добавить в учетную запись пользователя, выполняющую службу, а не учетную запись компьютера. Выполнение setspn -S HTTP/myservername.mydomain.com myuser в командной оболочке администрирования.

Kerberos и NTLM

Пакет Kestrel "Согласование" для ASP.NET Core пытается использовать Kerberos, что является более безопасной и пеформантной схемой проверки подлинности, чем 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 указывает Kerberos, так как это значение по умолчанию.

СЛУЖБЫ IIS, IISExpress и Kestrel поддержка Kerberos и NTLM.

Изучение заголовка WWW-Authentication с помощью IIS или IISExpress с помощью средства, например Fiddler, показывает Negotiate либо NTLM.

Kestrel только отображается WWW-Authenticate: Negotiate

Заголовок WWW-Authenticate: Negotiate означает, что сервер может использовать NTLM или Kerberos. KestrelNegotiate требует префикса заголовка, он не поддерживает непосредственное указание NTLM в заголовках проверки подлинности запроса или ответа. NTLM поддерживается в Kestrel, но он должен быть отправлен как Negotiate.

Чтобы Kestrelузнать, используется ли NTLM или Kerberos, base64 декодирует заголовок и отображает либо NTLM HTTP. HTTP указывает, что использовался Kerberos.

Конфигурация среды Linux и macOS

Инструкции по присоединению компьютера Linux или macOS к домену Windows доступны в статье Connect Azure Data Studio с SQL Server с помощью проверка подлинности Windows статьи Kerberos. Инструкции по созданию учетной записи компьютера Linux на домене. Имя участника-службы должно быть добавлено в учетную запись компьютера.

Примечание.

При выполнении инструкций, приведенных в руководстве по подключению Azure Data Studio к SQL Server с помощью проверка подлинности Windows статьи Kerberos, замените python-software-properties python3-software-properties его при необходимости.

После присоединения компьютера Linux или macOS к домену необходимо выполнить дополнительные действия, чтобы предоставить файл keytab с именами субъектов-служб:

• На контроллере домена добавьте новые имена субъектов-служб веб-службы в учетную запись компьютера:
  • setspn -S HTTP/mywebservice.mydomain.com mymachine
  • setspn -S HTTP/mywebservice@MYDOMAIN.COM mymachine
• Используйте ktpass для создания файла 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
  • Некоторые поля должны быть указаны в верхнем регистре, как указано.
• Скопируйте файл keytab на компьютер Linux или macOS.
• Выберите файл keytab с помощью переменной среды: export KRB5_KTNAME=/tmp/mymachine.HTTP.keytab
• Вызовите klist для отображения имен субъектов-служб, доступных в настоящее время для использования.

Примечание.

Файл keytab содержит учетные данные доступа к домену и должен быть защищен соответствующим образом.

HTTP.sys

HTTP.sys поддерживает проверку подлинности Windows в режиме ядра с помощью согласования, NTLM или базовой проверки подлинности.

Следующий код добавляет проверку подлинности и настраивает веб-узел приложения для использования HTTP.sys с проверкой подлинности 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;
        });
}

Примечание.

HTTP.sys делегировать проверку подлинности в режиме ядра с помощью протокола проверки подлинности Kerberos. Проверка подлинности в режиме пользователя не поддерживается с Kerberos и HTTP.sys. Необходимо использовать учетную запись компьютера для расшифровки маркера/билета Kerberos, полученного из Active Directory и переадресованного клиентом на сервер для проверки подлинности пользователя. Зарегистрируйте имя субъекта-службы (SPN) для узла, а не пользователя приложения.

Примечание.

HTTP.sys не поддерживается в Nano Server версии 1709 или более поздней. Чтобы использовать проверку подлинности Windows и HTTP.sys с Nano Server, используйте контейнер Server Core (microsoft/windowsservercore) (см. раздел https://hub.docker.com/_/microsoft-windows-servercore). Дополнительные сведения о серверных ядрах см. в разделе "Что такое параметр установки основных серверных компонентов в Windows Server?".

Авторизуйте пользователей

Состояние конфигурации анонимного доступа определяет способ [Authorize] использования атрибутов [AllowAnonymous] и атрибутов в приложении. В следующих двух разделах объясняется, как обрабатывать запрещенные и разрешенные состояния конфигурации анонимного доступа.

Запрет анонимного доступа

Если включена проверка подлинности Windows и анонимный доступ отключен, [Authorize] [AllowAnonymous] атрибуты не влияют. Если сайт IIS настроен для запрета анонимного доступа, запрос никогда не достигает приложения. По этой причине [AllowAnonymous] атрибут не применяется.

Разрешить анонимный доступ

Если включена проверка подлинности Windows и анонимный доступ, используйте [Authorize] их и [AllowAnonymous] атрибуты. Атрибут [Authorize] позволяет защитить конечные точки приложения, для которых требуется проверка подлинности. Атрибут [AllowAnonymous] переопределяет [Authorize] атрибут в приложениях, которые разрешают анонимный доступ. Сведения об использовании атрибутов см. в разделе "Простая авторизация" в ASP.NET Core.

Примечание.

По умолчанию пользователи, которые не имеют авторизации для доступа к странице, отображаются с пустым ответом HTTP 403. ПО промежуточного слоя StatusCodePages можно настроить для предоставления пользователям более эффективного интерфейса "Отказано в доступе".

Имперсонация

ASP.NET Core не реализует олицетворение. Приложения выполняются с identity приложением для всех запросов, используя пул приложений или процесс identity. Если приложение должно выполнить действие от имени пользователя, используйте WindowsIdentity.RunImpersonated или RunImpersonatedAsync в встроенном ПО промежуточного слоя терминалаProgram.cs. Выполните одно действие в этом контексте и закройте контекст.

app.Run(async (context) =>
{
    try
    {
        var user = (WindowsIdentity)context.User.Identity!;

        await context.Response
            .WriteAsync($"User: {user.Name}\tState: {user.ImpersonationLevel}\n");

        await WindowsIdentity.RunImpersonatedAsync(user.AccessToken, async () =>
        {
            var impersonatedUser = WindowsIdentity.GetCurrent();
            var message =
                $"User: {impersonatedUser.Name}\t" +
                $"State: {impersonatedUser.ImpersonationLevel}";

            var bytes = Encoding.UTF8.GetBytes(message);
            await context.Response.Body.WriteAsync(bytes, 0, bytes.Length);
        });
    }
    catch (Exception e)
    {
        await context.Response.WriteAsync(e.ToString());
    }
});

Хотя пакет Microsoft.AspNetCore.Authentication.Negotiate обеспечивает проверку подлинности в Windows, Linux и macOS, олицетворение поддерживается только в Windows.

Преобразования утверждений

При размещении с помощью IIS AuthenticateAsync не вызывается внутренне для инициализации пользователя. Таким образом, реализация IClaimsTransformation, используемая для преобразования утверждений после каждой проверки подлинности, не активируется по умолчанию. Дополнительные сведения и пример кода, который активирует преобразования утверждений, см. в разделе "Различия между внутрипроцессным и внепроцессным размещением".

Дополнительные ресурсы

• dotnet publish
• Размещение ASP.NET Core в Windows со службами IIS
• модуль ASP.NET Core (ANCM) для IIS
• Профили публикации Visual Studio (.pubxml) для развертывания приложений ASP.NET Core