Олицетворение пользователя домена с интегрированным конвейером

В локальной среде интрасети обречены ли мы использовать "классический" конвейерный режим в нашем пуле приложений, если мы хотим использовать олицетворение наших пользователей домена Windows, или есть новый способ декларативно "работать от них" (так сказать) )?

Моя цель - использовать проверку подлинности Windows для локальных веб-приложений в моей интрасети, чтобы пользователи могли проходить проверку подлинности и запускать приложения под своей учетной записью активного каталога (принцип). Каждый раз, когда я пытаюсь это сделать (используя идентификатор NetworkService, конечно), я получаю эту ошибку:

screenshot of error message

Ответ 1

Я написал небольшое приложение для отображения текущего имени пользователя в сети, полученного из нескольких разных мест, таких как Page.User.Identity.Name. Я также собрал информацию о пользователе домена, используя несколько разных методов для запросов к Active Directory. Все это подтверждает следующее.

Я обнаружил два основных режима для запуска вашего приложения с использованием аутентификации Windows, которая, в соответствии с моими исследованиями, в основном используется в среде интрасети. Вот минимально необходимые элементы конфигурации:

Классический режим

  • AppPool - управляемый конвейер установлен в классический режим.
  • AppPool - для удостоверения установлено сетевое обслуживание.
  • Аутентификация - отключена: анонимная аутентификация
  • Аутентификация - включена: олицетворение ASP.NET
  • Аутентификация - включена: аутентификация Windows
  • Поставщики - отключено: Kerberos
  • Дополнительные настройки - режим ядра: либо

Интегрированный режим

  • AppPool - управляемый конвейер установлен в интегрированный режим.
  • AppPool - для удостоверения установлено сетевое обслуживание.
  • Аутентификация - отключена: анонимная аутентификация
  • Аутентификация - отключена: олицетворение ASP.NET
  • Аутентификация - включена: аутентификация Windows
  • Поставщики - включены: Kerberos
  • Расширенные настройки - режим ядра: отключено

Теперь здесь кикер !!

Если вы хотите использовать Интегрированный режим (который идеален, так как дает гораздо больше функциональности и, конечно же, интеграцию), вам необходимо включить делегирование. Вот пара статей, которые необходимо прочитать, чтобы понять основы Делегирования и, в свою очередь, Динамическая регистрация SPN. Поскольку это затрагивает больше аспектов Kerberos и безопасности, которые вы, вероятно, захотите вникнуть, может быть проще просто придерживаться классического режима, где все, что вам нужно сделать, это включить Impersonation и вызвать его на день; или же обмануть и отключить validateIntegratedModeConfiguration.

Ответ 2

Нет, но конвейер "Интегрированный" требует, чтобы вы вручную выдавали себя за пользователя, прошедшего проверку подлинности Windows. По крайней мере, в IIS8.5, то есть.

Почему? Классический перерыв олицетворения .NET async. В частности, трудно управлять WindowsIdentity потока, когда он используется несколькими пользователями одновременно.

Как? Использовать WindowsImpersonationContext, например.

// Start with identity assigned by IIS Application Pool
var current = System.Security.Principal.WindowsIdentity.GetCurrent();

// Enable Windows Authentication in ASP.NET *and* IIS, which ensures 
// User.Identity is a WindowsIdentity
WindowsIdentity clientId = (WindowsIdentity)User.Identity;

// When 'using' block ends, the thread reverts back to previous Windows identity,
// because under the hood WindowsImpersonationContext.Undo() is called by Dispose()
using (WindowsImpersonationContext wic = clientId.Impersonate())
{
    // WindowsIdentity will have changed to match clientId
    current = System.Security.Principal.WindowsIdentity.GetCurrent();
}
// Back to the original identity
current = System.Security.Principal.WindowsIdentity.GetCurrent();

Проблемы? Иногда вам нужно использовать делегирование вместо олицетворения.