Настройка аутентификации в IIS 8

IIS 8 поддерживает интегрированный режим ASP.NET, который помимо прочего объединяет конвейер обработки ASP.NET HTTP с конвейером обработки IIS HTTP. Это предоставляет в распоряжение богатейший набор новых возможностей, которые можно использовать в сочетании с имеющимися знаниями ASP.NET. Например, одна из них — это возможность применения аутентификации с помощью форм ASP.NET для других веб-приложений, сконфигурированных в IIS 8, которые не обязательно должны быть построены на ASP.NET.

Более того, IIS 8 использует файл web.config для хранения многих частей конфигурации веб-приложений внутри веб-сервера. Это означает возможность настройки многих параметров приложения с использованием либо консоли управления IIS 8, либо за счет непосредственной модификации файла web.config. Благодаря тесной интеграции средств конфигурирования ASP.NET и IIS 8, любые изменения, внесенные непосредственно в файл web.config, немедленно отражаются в консоли управления, и наоборот.

Давайте сначала рассмотрим возможности конфигурирования аутентификации с помощью форм из среды консоли управления IIS 8. Конфигурировать аутентификацию с помощью форм можно с использованием средства настройки аутентификации консоли управления IIS 8, как показано на рисунке ниже:

После разрешения аутентификации с помощью форм подобным образом также понадобится сконфигурировать необходимые правила авторизации. Наиболее важно добавить правило deny для анонимных пользователей с помощью средства конфигурирования авторизации в консоли управления IIS 8:

Обе конфигурационные настройки затрагивают файл web.config и веб-сервер берет эту информацию из web.config для определения собственного поведения, что видно в следующем фрагменте кода:

Вы заметите, что аутентификация с помощью форм, сконфигурированная IIS, как и следовало ожидать, находится в разделе . Но по умолчанию (и если вы ранее не добавили этого вручную), никаких правил авторизации там не будет. Как упоминалось ранее, не все опции конфигурации по умолчанию помещаются непосредственно в файл web.config. Авторизация URL — одна из таких опций конфигурации.

В любом случае унифицированная консоль управления очень хорошо продумана, так что настраивать безопасность IIS и ASP.NET посредством других инструментов нет необходимости. Многие опции по умолчанию сохраняются непосредственно в файле web.config. Как известно можно даже сконфигурировать IIS так, чтобы почти все опции помещались непосредственно в web.config. Однако, как упоминалось ранее, интеграция ASP.NET предоставляет множество возможностей при запуске IIS 8 в интегрированном с ASP NET режиме.

При запуске IIS 8 в интегрированном режиме (выбираемом по умолчанию) IIS использует канал обработки HTTP для обработки как основанных на ASP.NET HTTP-модулей, так и встроенных HTTP-модулей IIS 8.

Поскольку аутентификация с помощью форм реализована в виде HTTP-модуля ASP.NET, ее можно использовать для любого веб-приложения и виртуального каталога, сконфигурированного в IIS, который функционирует в интегрированном режиме. Это значит, что аутентификацию с помощью форм можно применять вместе с приложениями других типов, такими как статические HTML-сайты, классические приложения ASP или даже приложения PHP. Все, что потребуется сделать — это настроить веб-приложение как виртуальный каталог и затем сконфигурировать аутентификацию с помощью форм через консоль управления IIS 8. Это автоматически добавит к приложению конфигурацию web.config.

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

Теперь просто откройте доступ к папке, где расположен PHP-файл (например, test.php), как к виртуальному каталогу или веб-приложению внутри IIS. После этого можно сконфигурировать аутентификацию с помощью форм и настройки авторизации, как было описано ранее.

Поскольку IIS 8 органично поддерживает аутентификацию с помощью форм, полагаясь на HTTP-модуль аутентификации с помощью форм, поставляемый в ASP.NET, она работает точно также, как работала бы с приложением ASP.NET. Все что нужно — это удостовериться в наличии необходимой страницы входа, которая сама по себе является страницей ASP.NET. Также должны быть доступны части, необходимые для страницы ASP.NET, внутри веб-приложения (или в другом виртуальном каталоге, если применяются cookie-наборы аутентификации между приложениями).

На рисунке ниже показана страница PHP вместе со страницей входа ASP.NET в виртуальном каталоге. Аутентификация с помощью форм просто конфигурируется через управляющую консоль IIS 8, как было описано ранее:

Однако просто поместить содержимое PHP вместе с основанными на ASP.NET страницами входа и сконфигурировать аутентификацию с помощью форм еще недостаточно. Когда вы попытаетесь выполнить переход на страницу PHP, аутентификация с помощью форм пока работать не будет. В зависимости от аутентификации и правил авторизации, вы либо получите ответ «unauthorized» («неавторизовано»), либо сможете переходить к странице PHP без приглашения на вход.

Причина в том, что по умолчанию управляемые HTTP-модули, в том числе и модуль аутентификации с помощью форм, настроены так, что выполняются только по запросу кода, основанного на ASP.NET. Поэтому чтобы заставить работать аутентификацию с помощью форм, потребуется изменить это поведение, вызвав средство конфигурации HTTP Modules в консоли управления IIS 8 когда ваше веб-приложение выбрано. Затем нужно отобразить детальную информацию для модуля FormsAuthentication, сконфигурированного в списке модулей, как показано на рисунке ниже:

Открыв средство конфигурации HTTP Modules, найдите FormsAuthentication и дважды щелкните на нем или выберите ссылку Edit (Правка) в панели задач справа. В открывшемся диалоговом окне снимите отметку с флажка Invoke Only for Requests to ASP.NET Applications or Managed Handlers (Вызывать только для запросов к приложениям ASP.NET или управляемым обработчикам), как показано на рисунке ниже:

После завершения этой настройки при обращении к странице PHP в каталоге веб-приложения запрос будет аутентифицирован посредством аутентификации с помощью форм ASP.NET. Конфигурационный файл web.config для веб-приложения будет выглядеть следующим образом:

Конфигурация FormsAuthenticationModule важна. Флажок в неотмеченном состоянии задает preCondition=»», которое по умолчанию установлено в managedHandler.

Настройка Kerberos авторизации на сайте IIS

Пошаговая инструкция по настройке на веб-сайте IIS на Windows Server 2012 R2 прозрачной авторизации доменных пользователей в режиме SSO (Single Sign-On) по протоколу Kerberos.

На веб сервере запустите консоль IIS Manager, выберите нужный сайт и откройте раздел Authentication. Как вы видите, по умолчанию разрешена только анонимная аутентификация (Anonymous Authentication). Отключаем ее и включаем Windows Authentication (IIS всегда сначала пытается выполнить анонимную аутентификацию).

Открываем список провайдеров, доступных для Windows аутентификации (Providers). По умолчанию доступны два провайдера: Negotiate и NTLM. Negotiate – это контейнер, который в качестве первого метода проверки подлинности использует Kerberos, если эта аутентификация не удается, используется NTLM. Необходимо, чтобы в списке провайдеров метод Negotiate стоял первым.

Следующий этап – регистрация Service Principal Name (SPN) записей для имени сайта, к которому будут обращаться пользователи. В том случае, если сайт IIS должен быть доступен только по имени сервера, на котором он расположен (http://server-name или http://server-name.contoso.com), создавать дополнительные SPN записи не нужно (SPN записи уже имеются в учетной записи сервера в AD). При использовании адреса сайта, отличного от имени хоста, или при построении веб-фермы с балансировкой, придется привязывать дополнительные записи SPN к учётной записи сервера или пользователя.

Предположим, у нас имеется ферма IIS серверов. В этом случае оптимально создать отдельную учетную запись в AD и привязать SPN записи к ней. Из-под этой же учетной записи будут запускать целевой Application Pool нашего сайта.

Создадим доменную учетную запись iis_service. Убедимся, что SPN записи для этого объекта не назначены (атрибут servicePrincipalName пустой).

Предположим, что сайт должен отвечать по адресам _http://webportal and _http://webportal.contoso.loc. Мы должны прописать эти адреса в SPN атрибут служебной учетной записи

Setspn /s HTTP/webportal contoso\iis_service
Setspn /s HTTP/webportal.contoso.loc contoso\iis_service

Таким образом, мы разрешим этой учетной записи расшифровывать тикеты Kerberos при обращении пользователей к данным адресам и аутентифицировать сессии.

Проверить настройки SPN у учетной записи можно так:

setspn /l iis_service

Следующий этап – настройка в IIS Application Pool для запуска из-под созданной сервисной учетной записи.

Выберите Application Pool сайта (в нашем примере это DefaultAppPool).

Откройте раздел настроек Advanced Settings и перейдите к параметру Identity.

Измените его с ApplicationPoolIdentity на contoso\iis_service.

Затем в консоли IIS Manager перейдите на свой сайт и выберите секцию Configuration Editor.

В выпадающем меню перейдите в раздел system.webServer > security > authentication > windowsAuthentication

Измените useAppPoolCredentials на True.

Тем самым мы разрешим IIS использовать доменную учетку для расшифровки билетов Kerberos от клиентов.

Перезапустим IIS командой:

Аналогичную настройку нужно выполнить на всех серверах веб-фермы.

Протестируем работу Kerberos авторизации, открыв в браузере клиента (браузер нужно предварительно настроить для использования Kerberos) адрес _http://webportal.contoso.loc

Убедится, что для авторизации на сайте используется Kerberos можно с помощью инспектирования HTTP трафика утилитой Fiddler (ранее мы уже упоминали эту утилиту).

Запускаем Fiddler, в браузере открываем целевой сайт. В левом окне находим строку обращения к сайте. Справа переходим на вкладку Inspectors. Строка Authorization Header (Negotiate) appears to contain a Kerberos ticket, говорит о том, что для авторизации на IIS сайте использовался протокол Kerberos.

Настройка проверки подлинности Windows в ASP.NET Core Configure Windows Authentication in ASP.NET Core

Проверка подлинности Windows (также известная как согласование, Kerberos или проверка подлинности NTLM) может быть настроена для ASP.NET Core приложений, размещенных в IIS, Kestrelили HTTP.sys. Windows Authentication (also known as Negotiate, Kerberos, or NTLM authentication) can be configured for ASP.NET Core apps hosted with IIS, Kestrel, or HTTP.sys.

Проверка подлинности Windows (также известная как Negotiate, Kerberos или NTLM) может быть настроена для ASP.NET Core приложений, размещенных в IIS или HTTP.sys. Windows Authentication (also known as Negotiate, Kerberos, or NTLM authentication) can be configured for ASP.NET Core apps hosted with IIS or HTTP.sys.

Проверка подлинности Windows полагается на операционную систему для проверки подлинности пользователей ASP.NET Core приложений. Windows Authentication relies on the operating system to authenticate users of ASP.NET Core apps. Проверку подлинности Windows можно использовать, когда сервер работает в корпоративной сети, используя удостоверения домена Active Directory или учетные записи Windows для идентификации пользователей. You can use Windows Authentication when your server runs on a corporate network using Active Directory domain identities or Windows accounts to identify users. Проверка подлинности Windows лучше всего подходит для сред интрасети, где пользователи, клиентские приложения и веб-серверы принадлежат одному и тому же домену Windows. Windows Authentication is best suited to intranet environments where users, client apps, and web servers belong to the same Windows domain.

Проверка подлинности Windows не поддерживается HTTP/2. Windows Authentication isn’t supported with HTTP/2. Проблемы проверки подлинности могут отправляться в ответах HTTP/2, но перед проверкой подлинности клиент должен перейти на HTTP/1.1. Authentication challenges can be sent on HTTP/2 responses, but the client must downgrade to HTTP/1.1 before authenticating.

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

Проверка подлинности Windows — это сценарий с отслеживанием состояния, который в основном используется в интрасети, где прокси-сервер или балансировщик нагрузки обычно не обрабатывал трафик между клиентами и серверами. Windows Authentication is a stateful scenario primarily used in an intranet, where a proxy or load balancer doesn’t usually handle traffic between clients and servers. Если используется прокси-сервер или балансировщик нагрузки, проверка подлинности Windows работает только в том случае, если прокси-сервер или балансировщик нагрузки: If a proxy or load balancer is used, Windows Authentication only works if the proxy or load balancer:

• Обрабатывает проверку подлинности. Handles the authentication.
• Передает сведения о проверке подлинности пользователя в приложение (например, в заголовке запроса), которое действует на данные проверки подлинности. Passes the user authentication information to the app (for example, in a request header), which acts on the authentication information.

Альтернативой проверки подлинности Windows в средах, где используются прокси-серверы и подсистемы балансировки нагрузки, — Active Directory Федеративные службы (ADFS) с OpenID Connect Connect (OIDC). An alternative to Windows Authentication in environments where proxies and load balancers are used is Active Directory Federated Services (ADFS) with OpenID Connect (OIDC).

IIS/IIS Express IIS/IIS Express

Добавьте службы проверки подлинности, вызвав AddAuthentication ( Microsoft.AspNetCore.Server.IISIntegration пространство имен) в Startup.ConfigureServices : Add authentication services by invoking AddAuthentication (Microsoft.AspNetCore.Server.IISIntegration namespace) in Startup.ConfigureServices :

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

Настройка параметров запуска влияет только на Свойства и launchSettings.jsв файле для IIS Express и не НАСТРАИВАЕТ службы IIS для проверки подлинности Windows. Configuration for launch settings only affects the Properties/launchSettings.json file for IIS Express and doesn’t configure IIS for Windows Authentication. Конфигурация сервера описывается в разделе IIS . Server configuration is explained in the IIS section.

Шаблон веб-приложения , доступный через Visual Studio или .NET Core CLI можно настроить для поддержки проверки подлинности Windows, который автоматически обновляет Свойства и launchSettings.jsв файле. The Web Application template available via Visual Studio or the .NET Core CLI can be configured to support Windows Authentication, which updates the Properties/launchSettings.json file automatically.

Новый проект New project

1. Создайте новый проект. Create a new project.
2. Выберите Новое веб-приложение ASP.NET Core. Select ASP.NET Core Web Application. Выберите Далее. Select Next.
3. Введите имя в поле имя проекта . Provide a name in the Project name field. Убедитесь, что для проекта правильно указано существующее расположение или укажите новое. Confirm the Location entry is correct or provide a location for the project. Нажмите кнопку создания. Select Create.
4. В разделе Проверка подлинностивыберите изменить . Select Change under Authentication.
5. В окне Изменение проверки подлинности выберите Проверка подлинности Windows. In the Change Authentication window, select Windows Authentication. Щелкните ОК. Select OK.
6. Выберите Веб-приложение. Select Web Application.
7. Нажмите кнопку создания. Select Create.

Запустите приложение. Run the app. Имя пользователя отображается в пользовательском интерфейсе отображаемого приложения. The username appears in the rendered app’s user interface.

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

Свойства проекта включают проверку подлинности Windows и отключение анонимной проверки подлинности: The project’s properties enable Windows Authentication and disable Anonymous Authentication:

1. В обозревателе решений щелкните проект правой кнопкой мыши и выберите пункт Свойства. Right-click the project in Solution Explorer and select Properties.
2. Выберите вкладку Отладка. Select the Debug tab.
3. Снимите флажок включить анонимную проверку подлинности. Clear the check box for Enable Anonymous Authentication.
4. Установите флажок включить проверку подлинности Windows. Select the check box for Enable Windows Authentication.
5. Сохраните и закройте страницу свойств. Save and close the property page.

Кроме того, свойства можно настроить в iisSettings узле launchSettings.jsв файле: Alternatively, the properties can be configured in the iisSettings node of the launchSettings.json file:

Новый проект New project

Выполните команду DotNet New с webapp аргументом (ASP.NET Core веб-приложение) и —auth Windows параметром: Execute the dotnet new command with the webapp argument (ASP.NET Core Web App) and —auth Windows switch:

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

Обновите iisSettings узел launchSettings.jsв файле: Update the iisSettings node of the launchSettings.json file:

При изменении существующего проекта убедитесь, что файл проекта содержит ссылку на пакет для пакета NuGet Microsoft. AspNetCore. app метапакет или Microsoft. AspNetCore. Authentication . When modifying an existing project, confirm that the project file includes a package reference for the Microsoft.AspNetCore.App metapackage or the Microsoft.AspNetCore.Authentication NuGet package.

IIS IIS

Службы IIS используют модуль ASP.NET Core для размещения ASP.NET Core приложений. IIS uses the ASP.NET Core Module to host ASP.NET Core apps. Проверка подлинности Windows настраивается для служб IIS с помощью файла web.config . Windows Authentication is configured for IIS via the web.config file. В следующих разделах показано, как выполнить следующие задачи: The following sections show how to:

• Укажите локальный файл web.config , который активирует проверку подлинности Windows на сервере при развертывании приложения. Provide a local web.config file that activates Windows Authentication on the server when the app is deployed.
• Используйте диспетчер служб IIS для настройки файла web.config ASP.NET Core приложения, которое уже развернуто на сервере. Use the IIS Manager to configure the web.config file of an ASP.NET Core app that has already been deployed to the server.

Если вы еще не сделали этого, включите IIS для размещения ASP.NET Core приложений. If you haven’t already done so, enable IIS to host ASP.NET Core apps. Для получения дополнительной информации см. Размещение ASP.NET Core в Windows со службами IIS. For more information, see Размещение ASP.NET Core в Windows со службами IIS.

Включите службу роли IIS для проверки подлинности Windows. Enable the IIS Role Service for Windows Authentication. Дополнительные сведения см. в разделе Включение проверки подлинности Windows в службах РОЛЕЙ IIS (см. шаг 2). For more information, see Enable Windows Authentication in IIS Role Services (see Step 2).

По умолчанию по промежуточного слоя интеграции IIS настроено на автоматическую проверку подлинности запросов. IIS Integration Middleware is configured to automatically authenticate requests by default. Дополнительные сведения см. в разделе Host ASP.NET Core в Windows с IIS: параметры IIS (аутоматикаусентикатион). For more information, see Host ASP.NET Core on Windows with IIS: IIS options (AutomaticAuthentication).

Модуль ASP.NET Core настроен на пересылку маркера проверки подлинности Windows в приложение по умолчанию. The ASP.NET Core Module is configured to forward the Windows Authentication token to the app by default. Дополнительные сведения см. в разделе Справочник по конфигурации модуля ASP.NET Core: атрибуты элемента aspNetCore. For more information, see ASP.NET Core Module configuration reference: Attributes of the aspNetCore element.

Используйте один из следующих подходов: Use either of the following approaches:

Перед публикацией и развертыванием проекта добавьте следующий файл web.config в корневой каталог проекта: Before publishing and deploying the project, add the following web.config file to the project root:

После публикации и развертывания проекта выполните настройку на стороне сервера с помощью диспетчера IIS. After publishing and deploying the project, perform server-side configuration with the IIS Manager:

1. В диспетчере служб IIS выберите сайт IIS в узле сайты на боковой панели подключения . In IIS Manager, select the IIS site under the Sites node of the Connections sidebar.
2. Дважды щелкните Проверка подлинности в области IIS . Double-click Authentication in the IIS area.
3. Выберите Анонимная проверка подлинности. Select Anonymous Authentication. На боковой панели действия выберите Отключить . Select Disable in the Actions sidebar.
4. Выберите параметр Проверка подлинности Windows. Select Windows Authentication. Выберите включить на боковой панели действия . Select Enable in the Actions sidebar.

Раздел, добавленный в файл web.config диспетчером IIS, находится за пределами раздела приложения, добавленного пакет SDK для .NET Core при публикации приложения. The section added to the web.config file by IIS Manager is outside of the app’s section added by the .NET Core SDK when the app is published. Так как раздел добавляется за пределы узла, параметры наследуются любыми вложенными приложениями для текущего приложения. Because the section is added outside of the node, the settings are inherited by any sub-apps to the current app. Чтобы предотвратить наследование, переместите добавленный раздел в раздел, указанный пакет SDK для .NET Core. To prevent inheritance, move the added section inside of the section that the .NET Core SDK provided.

Когда диспетчер IIS используется для добавления конфигурации IIS, он влияет только на файл web.config приложения на сервере. When IIS Manager is used to add the IIS configuration, it only affects the app’s web.config file on the server. Последующее развертывание приложения может перезаписать параметры на сервере, если копия web.config сервера заменяется web.configным файлом проекта. A subsequent deployment of the app may overwrite the settings on the server if the server’s copy of web.config is replaced by the project’s web.config file. Для управления параметрами используйте один из следующих подходов. Use either of the following approaches to manage the settings:

• Используйте диспетчер IIS для сброса параметров в файле web.config после того, как файл будет перезаписан при развертывании. Use IIS Manager to reset the settings in the web.config file after the file is overwritten on deployment.
• Добавьте файлweb.config в приложение локально с параметрами. Add a web.config file to the app locally with the settings.

Kestrel Kestrel

Пакет NuGet Microsoft. AspNetCore. Authentication. Negotiate можно использовать с Kestrel для поддержки проверки подлинности Windows с помощью Negotiate и Kerberos в Windows, Linux и macOS. The Microsoft.AspNetCore.Authentication.Negotiate NuGet package can be used with Kestrel to support Windows Authentication using Negotiate and Kerberos on Windows, Linux, and macOS.

Учетные данные могут быть сохранены в запросах к соединению. Credentials can be persisted across requests on a connection. Проверка подлинности Negotiate не должна использоваться с прокси, если только прокси-сервер не поддерживает сопоставление соединения 1:1 (постоянное подключение) с Kestrel. Negotiate authentication must not be used with proxies unless the proxy maintains a 1:1 connection affinity (a persistent connection) with Kestrel.

Обработчик согласования определяет, поддерживает ли базовый сервер встроенную проверку подлинности Windows и включен ли он. The Negotiate handler detects if the underlying server supports Windows Authentication natively and if it’s enabled. Если сервер поддерживает проверку подлинности Windows, но отключен, выдается сообщение об ошибке, предлагающее включить серверную реализацию. If the server supports Windows Authentication but it’s disabled, an error is thrown asking you to enable the server implementation. Если на сервере включена проверка подлинности Windows, обработчик согласования прозрачно пересылает его. When Windows Authentication is enabled in the server, the Negotiate handler transparently forwards to it.

Добавьте службы проверки подлинности, вызвав AddAuthentication и AddNegotiate в Startup.ConfigureServices : Add authentication services by invoking AddAuthentication and AddNegotiate in Startup.ConfigureServices :

Добавьте по промежуточного слоя проверки подлинности, вызвав UseAuthentication в Startup.Configure : Add Authentication Middleware by calling UseAuthentication in Startup.Configure :

Дополнительные сведения о по промежуточного слоя см. в разделе ПО промежуточного слоя ASP.NET Core . For more information on middleware, see ПО промежуточного слоя ASP.NET Core.

Анонимные запросы разрешены. Anonymous requests are allowed. Используйте ASP.NET Coreную авторизацию для запроса анонимных запросов на проверку подлинности. Use ASP.NET Core Authorization to challenge anonymous requests for authentication.

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

Компонент Microsoft. AspNetCore. Authentication. Negotiate выполняет проверку подлинности пользователя в пользовательском режиме. The Microsoft.AspNetCore.Authentication.Negotiate component performs User Mode authentication. Имена участников-служб (SPN) должны быть добавлены в учетную запись пользователя, запускающего службу, а не в учетную запись компьютера. Service Principal Names (SPNs) must be added to the user account running the service, not the machine account. Выполните setspn -S HTTP/myservername.mydomain.com myuser команду в административной командной консоли. Execute setspn -S HTTP/myservername.mydomain.com myuser in an administrative command shell.

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

Инструкции по присоединению компьютера Linux или macOS к домену Windows доступны в статье подключение Azure Data Studio к SQL Server с помощью проверки подлинности Windows — Kerberos . Instructions for joining a Linux or macOS machine to a Windows domain are available in the Connect Azure Data Studio to your SQL Server using Windows authentication — Kerberos article. Эти инструкции создают учетную запись компьютера для компьютера Linux в домене. The instructions create a machine account for the Linux machine on the domain. Имена участников-служб должны быть добавлены в эту учетную запись компьютера. SPNs must be added to that machine account.

При выполнении рекомендаций, приведенных в разделе подключение Azure Data Studio к SQL Server с помощью проверки подлинности Windows — Kerberos , замените python-software-properties на python3-software-properties при необходимости. When following the guidance in the Connect Azure Data Studio to your SQL Server using Windows authentication — Kerberos article, replace python-software-properties with python3-software-properties if needed.

После присоединения компьютера Linux или macOS к домену необходимо выполнить дополнительные действия, чтобы предоставить keytab- файл с именами участников-служб: Once the Linux or macOS machine is joined to the domain, additional steps are required to provide a keytab file with the SPNs:

• На контроллере домена добавьте новые имена SPN веб-службы в учетную запись компьютера: On the domain controller, add new web service SPNs to the machine account:
  • setspn -S HTTP/mywebservice.mydomain.com mymachine
  • setspn -S HTTP/mywebservice@MYDOMAIN.COM mymachine
• Используйте ктпасс для создания файла keytab: Use ktpass to generate a keytab file:
  • 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
  • Некоторые поля должны быть указаны в верхнем регистре, как указано. Some fields must be specified in uppercase as indicated.
• Скопируйте файл keytab на компьютер Linux или macOS. Copy the keytab file to the Linux or macOS machine.
• Выберите файл keytab с помощью переменной среды: export KRB5_KTNAME=/tmp/mymachine.HTTP.keytab Select the keytab file via an environment variable: export KRB5_KTNAME=/tmp/mymachine.HTTP.keytab
• Вызовите klist , чтобы отобразить имена участников-служб, доступные в настоящее время для использования. Invoke klist to show the SPNs currently available for use.

Файл keytab содержит учетные данные доступа к домену и должен быть защищен соответствующим образом. A keytab file contains domain access credentials and must be protected accordingly.

HTTP.sys HTTP.sys

HTTP.sys поддерживает проверку подлинности Windows в режиме ядра с помощью Negotiate, NTLM или обычной проверки подлинности. HTTP.sys supports Kernel Mode Windows Authentication using Negotiate, NTLM, or Basic authentication.

Добавьте службы проверки подлинности, вызвав AddAuthentication ( Microsoft.AspNetCore.Server.HttpSys пространство имен) в Startup.ConfigureServices : Add authentication services by invoking AddAuthentication (Microsoft.AspNetCore.Server.HttpSys namespace) in Startup.ConfigureServices :

Настройте веб-узел приложения для использования HTTP.sys с проверкой подлинности Windows (Program.CS). Configure the app’s web host to use HTTP.sys with Windows Authentication (Program.cs). UseHttpSys находится в пространстве имен Microsoft.AspNetCore.Server.HttpSys. UseHttpSys is in the Microsoft.AspNetCore.Server.HttpSys namespace.

HTTP.sys делегирует задачи в проверку подлинности в режиме ядра с помощью протокола проверки подлинности Kerberos. HTTP.sys delegates to kernel mode authentication with the Kerberos authentication protocol. Проверка подлинности в режиме пользователя не поддерживается с Kerberos и HTTP.sys. User mode authentication isn’t supported with Kerberos and HTTP.sys. Необходимо использовать учетную запись компьютера для расшифровки маркера/билета Kerberos, полученного из Active Directory и переадресованного клиентом на сервер для проверки подлинности пользователя. The machine account must be used to decrypt the Kerberos token/ticket that’s obtained from Active Directory and forwarded by the client to the server to authenticate the user. Зарегистрируйте имя субъекта-службы (SPN) для узла, а не пользователя приложения. Register the Service Principal Name (SPN) for the host, not the user of the app.

HTTP.sys не поддерживается на сервере Nano Server версии 1709 или более поздней. HTTP.sys isn’t supported on Nano Server version 1709 or later. Чтобы использовать проверку подлинности Windows и HTTP.sys с Nano Server, используйте контейнер Server Core (Microsoft/windowsservercore). To use Windows Authentication and HTTP.sys with Nano Server, use a Server Core (microsoft/windowsservercore) container. Дополнительные сведения о Server Core см. в разделе что такое вариант установки Server Core в Windows Server?. For more information on Server Core, see What is the Server Core installation option in Windows Server?.

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

Состояние конфигурации анонимного доступа определяет способ [Authorize] [AllowAnonymous] использования атрибутов и в приложении. The configuration state of anonymous access determines the way in which the [Authorize] and [AllowAnonymous] attributes are used in the app. В следующих двух разделах объясняется, как управлять состояниями запрещенных и разрешенных конфигураций анонимного доступа. The following two sections explain how to handle the disallowed and allowed configuration states of anonymous access.

Запретить анонимный доступ Disallow anonymous access

Если включена проверка подлинности Windows, а анонимный доступ отключен, [Authorize] [AllowAnonymous] атрибуты и не действуют. When Windows Authentication is enabled and anonymous access is disabled, the [Authorize] and [AllowAnonymous] attributes have no effect. Если сайт IIS настроен для запрета анонимного доступа, запрос никогда не достигнет приложения. If an IIS site is configured to disallow anonymous access, the request never reaches the app. По этой причине [AllowAnonymous] атрибут неприменим. For this reason, the [AllowAnonymous] attribute isn’t applicable.

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

Если включена проверка подлинности Windows и анонимный доступ, [Authorize] Используйте [AllowAnonymous] атрибуты и. When both Windows Authentication and anonymous access are enabled, use the [Authorize] and [AllowAnonymous] attributes. [Authorize] Атрибут позволяет защитить конечные точки приложения, требующие проверки подлинности. The [Authorize] attribute allows you to secure endpoints of the app which require authentication. [AllowAnonymous] Атрибут переопределяет [Authorize] атрибут в приложениях, разрешающих анонимный доступ. The [AllowAnonymous] attribute overrides the [Authorize] attribute in apps that allow anonymous access. Сведения об использовании атрибутов см. в разделе Простая Авторизация в ASP.NET Core . For attribute usage details, see Простая Авторизация в ASP.NET Core.

По умолчанию пользователям, у которых отсутствует авторизация на доступ к странице, предоставляется пустой ответ HTTP 403. By default, users who lack authorization to access a page are presented with an empty HTTP 403 response. По промежуточного слоя статускодепажес можно настроить для предоставления пользователям более качественного интерфейса «отказ в доступе». The StatusCodePages Middleware can be configured to provide users with a better «Access Denied» experience.

Олицетворение Impersonation

ASP.NET Core не реализует олицетворение. ASP.NET Core doesn’t implement impersonation. Приложения запускаются с удостоверением приложения для всех запросов с использованием пула приложений или удостоверения процесса. Apps run with the app’s identity for all requests, using app pool or process identity. Если приложение должно выполнить действие от имени пользователя, используйте WindowsIdentity. рунимперсонатед во встроенном по промежуточного слоя терминала в Startup.Configure . If the app should perform an action on behalf of a user, use WindowsIdentity.RunImpersonated in a terminal inline middleware in Startup.Configure . Выполните одно действие в этом контексте и закройте контекст. Run a single action in this context and then close the context.

RunImpersonated не поддерживает асинхронные операции и не следует использовать для сложных сценариев. RunImpersonated doesn’t support asynchronous operations and shouldn’t be used for complex scenarios. Например, не поддерживается или не рекомендуется заключать в оболочку все запросы или цепочки промежуточного слоя. For example, wrapping entire requests or middleware chains isn’t supported or recommended.