Недавно я переместил один из наших серверов с 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 выдавать себя за аутентифицированного пользователя и выполнять его, были бы замечательными. Спасибо!
Старый пост, но, возможно, кому-нибудь он пригодится. Я боролся с этой проблемой и нашел способ.
Если вам нужно запускать страницы .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 - похожее свойство для пула приложений, которое принимает меньше параметров (но служба может работать на вас) - http://www.iis.net/ConfigReference/system.applicationHost/applicationPools/add/processModel
О, и возможно (хотя, как вы говорите, чертовски?) Маловероятно, что ваш объект WScript работает в COM-контейнере с идентификатором, отличным от рабочего процесса.
Почему вы не включили также «Встроенную проверку подлинности Windows» в IIS?
Был ли он авторизован локально?
под локальным администратором?
Удостоверься что:
вы изменили web.config по умолчанию
<authentication mode="None" />
к
<authentication mode="Windows" />