Олицетворение пользователя домена с интегрированным конвейером
Это вопрос, который продолжает преследовать меня...
В локальной среде интрасети обречены ли мы использовать "классический" режим конвейера в нашем пуле приложений, если мы хотим использовать олицетворение наших пользователей домена Windows, или есть новый способ декларативно "работать как" их (так сказать))?
Моя цель - использовать проверку подлинности Windows для локальных веб-приложений в моей интрасети, чтобы пользователи могли проходить проверку подлинности и запускать приложения под своей учетной записью активного каталога (принцип). Каждый раз, когда я пытаюсь это сделать (используя идентификатор NetworkService, конечно), я получаю эту ошибку:
Спасибо!;)
2 ответа
Я написал небольшое приложение для отображения имени пользователя сети текущего пользователя, взятого из нескольких разных мест, таких как Page.User.Identity.Name
, Я также собрал информацию о пользователе домена, используя несколько различных методов для запроса ActiveDirectory. Все это подтверждает следующее.
Я обнаружил два основных режима для запуска вашего приложения с использованием аутентификации Windows, которая, в соответствии с моими исследованиями, в основном используется в среде интрасети. Вот минимальные существенные элементы конфигураций:
Классический режим
- AppPool - управляемый конвейер, установленный в классический режим.
- AppPool - для удостоверения установлено сетевое обслуживание.
- Аутентификация - отключена: анонимная аутентификация
- Аутентификация - включена: олицетворение ASP.NET
- Аутентификация - включена: аутентификация Windows
- Провайдеры - Отключено: Kerberos
- Расширенные настройки - режим ядра: либо
Интегрированный режим
- AppPool - управляемый конвейер установлен в интегрированный режим.
- AppPool - для удостоверения установлено сетевое обслуживание.
- Аутентификация - отключена: анонимная аутентификация
- Аутентификация - отключена: олицетворение ASP.NET
- Аутентификация - включена: аутентификация Windows
- Провайдеры - Включено: Kerberos
- Дополнительные настройки - режим ядра: отключено
Теперь вот кикер!!
Если вы хотите использовать Интегрированный режим (который идеален, так как предоставляет гораздо больше функциональных возможностей и, конечно же, интеграцию), вам необходимо включить делегирование. Вот пара статей, которые необходимо прочитать, чтобы понять основы делегирования и, в частности, динамическую регистрацию SPN. Так как это затрагивает больше аспектов Kerberos и безопасности, которые вы, вероятно, захотите вникнуть, может быть проще просто придерживаться классического режима, где все, что вам нужно сделать, это включить Impersonation и вызвать его на день; или же обмануть и отключить validateIntegratedModeConfiguration
,:П
Я надеюсь, что это помогает кому-то там на интервеже. Ура!:)
Нет, но "Интегрированный" конвейер требует, чтобы вы вручную олицетворяли пользователя, прошедшего проверку подлинности Windows. По крайней мере, в IIS8.5, то есть.
Зачем? Классическая олицетворение ломает асинхронные функции.NET. В частности, трудно управлять 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();
Проблемы? Иногда вам нужно использовать делегирование вместо олицетворения.