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

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

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

Когда следует использовать проверку подлинности Windows

Проверка подлинности Windows подходит для веб-приложений, работающих в частной внутренней сети организации, доступной только сотрудникам (и другим авторизованным пользователям) в той же сети. Управление пользователями выполняется в Active Directory (AD), а пользователи используют имеющуюся учетную запись домена Windows для проверки подлинности.

Проверка подлинности Windows предоставляет несколько преимуществ для приложений интрасети:

• Простой пользовательский интерфейс . Пользователи автоматически проходят проверку подлинности на основе активного сеанса Windows или предлагается ввести учетные данные Windows через стандартное диалоговое окно браузера.
• Интеграция с Active Directory — использует существующие политики инфраструктуры и безопасности Windows, включая группы пользователей, блокировки учетных записей и многофакторную проверку подлинности (MFA).
• Безопасная обработка учетных данных . Проверка подлинности обрабатывается с помощью безопасных протоколов, таких как Kerberos, без необходимости управлять отдельными учетными данными пользователя.
• Авторизация на основе ролей . Приложения могут получать доступ к сведениям о пользователях и группах из Active Directory, что позволяет управлять доступом на основе ролей (RBAC) в приложении.
• Сокращение административных затрат . Нет необходимости поддерживать отдельную пользовательская база данных или систему управления учетными данными.

Это делает проверку подлинности Windows идеальной для организаций, которые хотят использовать свою уже имеющуюся инфраструктуру Windows, такую как порталы интрасети.

Для общедоступных приложений проверка подлинности Windows не рекомендуется из-за проблем безопасности и удобства использования. Ниже приведены следующие причины:

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

Альтернативные варианты для различных сценариев

В зависимости от требований приложения рассмотрите следующие варианты:

Для общедоступных приложений:

• OpenID Connect с внешними поставщиками удостоверений
• ASP.NET Core Identity с локальными учетными записями пользователей (введение в Identity ASP.NET Core)
• Azure Active Directory (AAD) для сред Microsoft 365

Для смешанных сред с интрасетью и внешними пользователями:

• Службы федерации Active Directory (ADFS) с OpenID Connect
• Azure Active Directory с гибридной конфигурацией

Для корпоративных сред, использующих современную проверку подлинности:

• Azure Active Directory с единым входом
• Решения на основе SAML с сторонними поставщиками удостоверений

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

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

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

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

IIS/IIS Express

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

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

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

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

"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

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

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

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

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

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

Модуль ASP.NET Core по умолчанию настроен для пересылки токена Windows аутентификации в приложение. Дополнительные сведения см. в справочнике по конфигурации модуля ASP.NET Core: атрибуты элемента 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 (без свойства <IsTransformWebConfigDisabled>, заданного true в файле проекта), опубликованный файл web.config включает раздел <location><system.webServer><security><authentication>. Дополнительные сведения о свойстве <IsTransformWebConfigDisabled> см. в web.config файле.

• После публикации и развертывания проекта выполните настройку на стороне сервера с помощью диспетчера 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 при публикации приложения. Так как раздел добавляется за пределами <location> узла, параметры наследуются любыми вложенными приложениями в текущем приложении. Чтобы предотвратить наследование, переместите добавленный <security> раздел внутри <location><system.webServer> раздела, предоставленного пакетом SDK для .NET.

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

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

Kestrel

Microsoft.AspNetCore.Authentication.Negotiate Пакет NuGet можно использовать с Kestrel, чтобы включить аутентификацию Windows с использованием протоколов Negotiate и Kerberos в Windows, Linux и macOS.

Проверка подлинности и резервная политика авторизации включены в следующем выделенном коде: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.

Выделенные строки:

• 5–6. AddAuthentication регистрируют и AddNegotiate настраивают обработчик проверки подлинности Negotiate.
• 8–11: AddAuthorization с резервной политикой применяет проверку подлинности пользователей по умолчанию.
• 26. UseAuthentication выполняет модуль проверки подлинности для каждого запроса и заполняет HttpContext.User.
• 27. UseAuthorization Оценивает политики авторизации, включая резервную политику.

Проверка подлинности 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 API выполняет проверку подлинности в пользовательском режиме. Имена субъектов-служб (SPN) необходимо добавить в учетную запись пользователя, выполняющую службу, а не учетную запись компьютера. Выполните setspn -S HTTP/myservername.mydomain.com myuser в командной строке с правами администратора.

Kerberos и NTLM

Пакет Kestrel Negotiate для 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-Authenticate: с помощью IIS или IISExpress и таких инструментов, как Fiddler, показывает Negotiate либо NTLM.

Kestrel показывает только WWW-Authenticate: Negotiate

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

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

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

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

После присоединения компьютера Linux или macOS к домену необходимо предпринять дополнительные шаги для предоставления файла keytab с SPN.

• На контроллере домена добавьте новые имена служб в учетную запись компьютера.
  • 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 для отображения SPN, доступных в настоящее время для использования.

HTTP.sys

HTTP.sys поддерживает Windows-аутентификацию в режиме ядра с использованием Negotiate, 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;
        });
}

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

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

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

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

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

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

Impersonation

ASP.NET Core не реализует имперсонацию. Приложения выполняются с идентичностью приложения для всех запросов, используя пул приложений или идентификацию процесса. Если приложению нужно выполнить действие от имени пользователя, используйте 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

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

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

Когда следует использовать проверку подлинности Windows

Проверка подлинности Windows подходит для веб-приложений, работающих в частной внутренней сети организации, доступной только сотрудникам (и другим авторизованным пользователям) в той же сети. Управление пользователями выполняется в Active Directory (AD), а пользователи используют имеющуюся учетную запись домена Windows для проверки подлинности.

Проверка подлинности Windows предоставляет несколько преимуществ для приложений интрасети:

• Простой пользовательский интерфейс . Пользователи автоматически проходят проверку подлинности на основе активного сеанса Windows или предлагается ввести учетные данные Windows через стандартное диалоговое окно браузера.
• Интеграция с Active Directory — использует существующие политики инфраструктуры и безопасности Windows, включая группы пользователей, блокировки учетных записей и многофакторную проверку подлинности (MFA).
• Безопасная обработка учетных данных . Проверка подлинности обрабатывается с помощью безопасных протоколов, таких как Kerberos, без необходимости управлять отдельными учетными данными пользователя.
• Авторизация на основе ролей . Приложения могут получать доступ к сведениям о пользователях и группах из Active Directory, что позволяет управлять доступом на основе ролей (RBAC) в приложении.
• Сокращение административных затрат . Нет необходимости поддерживать отдельную пользовательская база данных или систему управления учетными данными.

Это делает проверку подлинности Windows идеальной для организаций, которые хотят использовать свою уже имеющуюся инфраструктуру Windows, такую как порталы интрасети.

Для общедоступных приложений проверка подлинности Windows не рекомендуется из-за проблем безопасности и удобства использования. Ниже приведены следующие причины:

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

Альтернативные варианты для различных сценариев

В зависимости от требований приложения рассмотрите следующие варианты:

Для общедоступных приложений:

• OpenID Connect с внешними поставщиками удостоверений
• ASP.NET Core Identity с локальными учетными записями пользователей (введение в Identity ASP.NET Core)
• Azure Active Directory (AAD) для сред Microsoft 365

Для смешанных сред с интрасетью и внешними пользователями:

• Службы федерации Active Directory (ADFS) с OpenID Connect
• Azure Active Directory с гибридной конфигурацией

Для корпоративных сред, использующих современную проверку подлинности:

• Azure Active Directory с единым входом
• Решения на основе SAML с сторонними поставщиками удостоверений

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

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

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

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

IIS/IIS Express

Добавьте службы проверки подлинности через вызов AddAuthentication (Microsoft.AspNetCore.Server.IISIntegration пространства имен) в Startup.ConfigureServices:

services.AddAuthentication(IISDefaults.AuthenticationScheme);

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

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

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

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

При изменении существующего проекта убедитесь, что файл проекта содержит ссылку на пакет для Microsoft.AspNetCore.App метапакетаилиMicrosoft.AspNetCore.Authentication пакета NuGet.

IIS

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

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

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

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

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

Модуль ASP.NET Core по умолчанию настроен для пересылки токена Windows аутентификации в приложение. Дополнительные сведения см. в справочнике по конфигурации модуля ASP.NET Core: атрибуты элемента 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 (без свойства <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 при публикации приложения. Так как раздел добавляется за пределами <location> узла, параметры наследуются любыми вложенными приложениями в текущем приложении. Чтобы предотвратить наследование, переместите добавленный <security> раздел внутри <location><system.webServer> раздела, предоставленного пакетом SDK для .NET.

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

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

Kestrel

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

Добавьте службы проверки подлинности, вызывая AddAuthentication и AddNegotiate в Startup.ConfigureServices.

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

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

Добавление промежуточного ПО аутентификации с помощью вызова UseAuthentication в Startup.Configure.

app.UseAuthentication();

Дополнительные сведения о посредническом ПО см. в разделе ASP.NET Core Middleware.

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

Проверка подлинности Kerberos в Linux или macOS не предоставляет никаких сведений о роли для пользователя, прошедшего проверку подлинности. Чтобы добавить сведения о роли и группе пользователю Kerberos, обработчик проверки подлинности должен быть настроен для получения ролей из домена LDAP. Самая базовая конфигурация указывает только домен LDAP для запроса и будет использовать контекст пользователя, прошедший проверку подлинности, для запроса домена LDAP:

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

Для запроса домена LDAP могут потребоваться определенные учетные данные. Учетные данные можно указать в следующих выделенных параметрах:

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

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

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

AuthenticationScheme требуется Microsoft.AspNetCore.Authentication.Negotiate пакет NuGet.

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

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

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

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

После присоединения компьютера Linux или macOS к домену необходимо предпринять дополнительные шаги для предоставления файла keytab с SPN.

• На контроллере домена добавьте новые имена служб в учетную запись компьютера.
  • 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 для отображения SPN, доступных в настоящее время для использования.

HTTP.sys

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

Добавьте службы проверки подлинности через вызов AddAuthentication (Microsoft.AspNetCore.Server.HttpSys пространства имен) в Startup.ConfigureServices:

services.AddAuthentication(HttpSysDefaults.AuthenticationScheme);

Настройте веб-хост приложения для использования HTTP.sys с проверкой подлинности Windows (Program.cs). UseHttpSys находится в пространстве имен 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;
                    });
            });
}

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

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

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

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

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

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

Impersonation

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

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

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