Вопрос или проблема
Я недавно перенес один из наших серверов с Server 2003 и IIS6 на Server 2008 R2 и IIS7 (технически, я полагаю, это IIS7.5). В процессе я переношу небольшой инструмент управления учетными записями, написанный на классическом ASP, и столкнулся с проблемой имперсонации пользователей. Обширные поиски до сих пор не принесли особой помощи.
В IIS6 сайт был настроен на имперсонацию вошедшего пользователя. Таким образом, если в систему входил администратор домена, он мог выполнять команды для создания пользовательских каталогов, настройки разрешений и т. д. Используя Procmon, вы можете видеть процессы, выполняющиеся от имени этого пользователя. Это работало хорошо.
Однако с тем же кодом в IIS7 я не могу получить такое поведение. Я включил основную аутентификацию, отключил анонимную аутентификацию, включил имперсонацию и изменил пул приложений на классический вместо интегрированной конвейерной обработки. Все кажется настроенным правильно, однако все процессы, запущенные классическим сайтом ASP, продолжают выполняться от имени идентичности по умолчанию AppPool, а не вошедшего в систему пользователя.
Если это имеет значение, программы запускаются с помощью кода, такого как:
set Wsh = Server.CreateObject("WScript.Shell")
Wsh.Run("cmd.exe /C mkdir D:\users\foo")
Мониторинг через Procmon показывает, что cmd.exe выполняется либо как “Classic .NET AppPool”, либо как “DefaultAppPool” в зависимости от режима конвейера.
Любые предложения о том, как заставить классический сайт ASP имперсонировать и выполняться как аутентифицированный пользователь, были бы отличными. Спасибо!
Существует малоизвестная настройка под названием LogonMethod, которая варьирует возможности учетной записи пользователя, входящей с анонимным или открытым текстовым логином.
Я (думаю, что) помню, что это изменилось для IIS 5 или 6, так что это возможно снова изменилось для 7. Эффект был бы точно таким, о котором вы говорите – невозможность выполнять действия, которые интерактивный пользователь мог бы выполнить без труда.
Это плохая идея менять его оптом для достижения делегирования – в конце концов, для этого и предназначены ограниченная делегация Kerberos и переход протоколов – но это может помочь разрешить эту проблему.
LogonMethod – свойство IIS 6 и более ранних версий – http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/fa99f59f-d11f-41f7-b220-ad9d433f80b0.mspx?mfr=true
LogonType – похожее свойство для пула приложений, которое принимает меньше опций (но Service может подойти вам) – http://www.iis.net/ConfigReference/system.applicationHost/applicationPools/add/processModel
О, и возможно (хотя, как вы говорите, чертовски?) маловероятно, что ваш объект WScript работает в контейнере COM с другой идентичностью, чем у рабочего процесса.
Старый пост, но, возможно, кто-то найдет его полезным. Я боролся с этой проблемой и нашел способ.
Если вам нужно запускать .asp страницы с определенным пользователем (у меня были проблемы с форматом даты и валюты), попробуйте установить указанного пользователя в качестве идентичности в пуле приложений, затем установите “Load User Profile” на True. Это решило мои проблемы.
Почему вы не включили также “Интегрированную аутентификацию Windows” в IIS?
Вы входили локально?
под локальным администратором?
Убедитесь, что:
- Включен NTLM2
-
вы изменили web.config с значения по умолчанию
<authentication mode="None" />на
<authentication mode="Windows" />
Ответ или решение
Имитация пользователя, прошедшего аутентификацию, в Classic ASP на IIS7: Подробное руководство
Введение
Переход от Windows Server 2003 и IIS6 к Windows Server 2008 R2 и IIS7.5 может вызвать множество проблем, включая сложности с пользовательской имитацией в классическом ASP. Это руководство поможет разобраться в этом вопросе и предложит решения, необходимые для корректной работы вашего приложения.
Проблема
Вы столкнулись с тем, что после миграции на IIS7 ваши команды, исполняемые через WScript.Shell, работают от имени пула приложений (например, "Classic .NET AppPool") и не наследуют учетные данные аутентифицированного пользователя. Это поведение держит ограничения на выполнение определенных заданий, таких как создание директорий или изменение разрешений, что было возможно под IIS6.
Решение
Вот несколько шагов, которые могут помочь исправить проблему:
1. Настройка IIS для правильной аутентификации
Убедитесь, что для вашего сайта включены следующие настройки:
- Basic Authentication: При этом методе пользователю необходимо вводить учетные данные.
- Integrated Windows Authentication: Данный метод позволяет передавать идентификацию пользователя автоматически.
- Anonymous Authentication: Эта опция должна быть отключена, чтобы предотвратить доступ без аутентификации.
2. Настройка пула приложений
Измените идентичность вашего пула приложений. Выполните следующие действия:
- Откройте IIS Manager.
- Выберите ваш пул приложений и перейдите в его настройки.
- Настройте «Identity» пула приложений на логин пользователя с нужными правами (например, доменного администратора).
- Убедитесь, что параметр Load User Profile установлен на True. Это позволит загружать профиль пользователя и предоставляет необходимые права.
3. Убедитесь, что включен NTLM2
Если ваша система использует протокол NTLM для аутентификации, убедитесь, что включен NTLMv2. Это можно проверить в настройках политики безопасности сервера.
4. Конфигурация web.config
Обратите внимание на файл web.config вашего сайта:
<configuration>
<system.web>
<authentication mode="Windows" />
</system.web>
</configuration>Это должно быть установлено вместо значения по умолчанию (None).
5. Учтите параметры LogonMethod и LogonType
В IIS7 было применено и изменено множество параметров конфигурации, касающихся аутентификации. Вы можете рассмотреть возможность использования параметра LogonType для пула приложений и выставить его значение в Service. Это обеспечит возможность пользователю запускать процессы с требуемыми правами.
6. Мониторинг процессов
Для анализа работоспособности и устранения проблем можно использовать такие инструменты как Procmon для отслеживания процессов и обеспечения правильного выполнения команд. Убедитесь, что запросы действительно выполняются от имени аутентифицированного пользователя, а не по умолчанию от имени пула приложений.
Заключение
Проблемы с имитацией аутентифицированного пользователя в классическом ASP на IIS7 могут носить сложный характер, однако корректная настройка аутентификации, пула приложений и конфигурации приложения зачастую решает эти проблемы. Убедитесь, что вы применяете все рекомендации для достижения нужного поведения вашего приложения.