IUSR vs АДМИНИСТРАТОР разрешение загвоздка

Приложение, запущенное IIS6 (в результате HTTP-запроса), не может инициализировать dll. Если я запускаю его как администратор при локальном входе двойным щелчком, все хорошо.

Это приложение использует шифрование TLS через сторонние библиотеки DLL, называемые cryptlib. http://www.coastrd.com/smtps/cryptlib Само по себе это не должно быть большим делом, так как большинство моих приложений CGI используют dll MySQL/zlib/... и т.д. без проблем. В этом случае (возможно, из-за характера создания сеанса SSL/TLS) приложение работает нормально, если оно запускается двойным щелчком от имени администратора, но не запускается при запуске IIS в результате входящего запроса. IIS использует учетную запись "Internet Guest Account... (... IUSR)" (мы предполагаем) для выполнения приложения CGI из простого запроса HTTP POST веб-страницы.

Я попытался дать полный контроль над учетной записью IUSR в приложении, DLL и папку, но без радости. Затем я запустил ProcMon и искал результат "Отказано в доступе". Единственное, что я смог найти, было в результате желаемого доступа CreateFile: чтение атрибутов, удаление, синхронизация, размещение: открытие, параметры: синхронный ввод-вывод без предупреждения, C:\WINDOWS\Debug\UserMode\ChkAcc.log

Это озадачивает, так как мое приложение не записывает в этот файл журнала (я полагаю, что IIS так, почему у него возникли проблемы?)

Затем я сравнил вывод ProcMon для успешного запуска Администратора с запуском IUSR и обнаружил, что операция "ReadFile" не присутствовала при неудачном запуске. Я не получаю сообщение об отказе в доступе для этого, операция просто не происходит.

Последовательность последовательных операций для cl32.dll должна быть следующей: QueryOpen CreateFile CreateFileMapping QueryStandardInformationFile CreateFileMapping CreateFileMapping CloseFile Загрузить изображение ReadFile

Я предполагаю, что это где DLL загружается в память для использования.

Вместо операции ReadFile (при неудачном запуске) есть: RegOpenKey HKU\S-1-5-21-4122272316-1273673783-4216733774-1003 ИМЯ НЕ НАЙДЕНО

Это немного похоже на проблему "проверки обхода", описанную здесь http://forums.iis.net/t/1153139.aspx http://technet.microsoft.com/en-us/library/cc739389(WS.10).aspx но это не решило проблему.

На данный момент мы превысили лимит моих знаний об учетных записях пользователей и разрешениях с большим отрывом. Ясно одно, это проблема с разрешениями. Вопрос в том, какое разрешение?

ADDED

Добавление ISUR к администраторам: 1. Щелкните правой кнопкой мыши "Мой компьютер" на рабочем столе и выберите "Управление". 2. Когда откроется окно "Управление компьютером", разверните "Локальные пользователи и группы". 3. Выберите "Группы" и дважды щелкните "Администраторы" на правой панели. 4. Нажмите кнопку "Добавить". 5. Нажмите "Дополнительно", затем "Найти сейчас" и выберите "IUSR". 6. Нажмите "ОК". 7. Перезагрузите IIS

Это НЕ решило проблему. Я выкопал Filemon v7.3, и это IUSR, который

er.exe:2240 OPEN C:\WINDOWS\system32\USERENV.dll SUCCESS Options: Open Access: 00100021  
er.exe:2240 CLOSE C:\WINDOWS\system32\USERENV.dll SUCCESS  
er.exe:2240 OPEN C:\WINDOWS\debug\UserMode\ChkAcc.log ACCESS DENIED MY-SERVER\IUSR_MY-SERVER  
er.exe:2240 CREATE C:\WINDOWS\debug\UserMode\ChkAcc.log ACCESS DENIED MY-SERVER\IUSR_MY-SERVER 

На данный момент я заберу любые удары в темноте, с какого разрешения это может быть:)

ADDED

Я изменил разрешение на файл ChkAcc.log и папку UserMode, я также проверил расширенные разрешения и нашел отказ в приложении и Dll. Я удалил их обоих. Я перезапустил IIS и даже перезагрузил машину. Все еще не повезло.

Мне интересно, если на самом деле проблема в отказе в доступе. Я переписал приложение для создания и записи в файл в этой папке, и оно работало:

OPEN            C:\WINDOWS\debug\UserMode\ChkAcc.txt    SUCCESS Options: OpenIf  Access: 00120196
SET INFORMATION     C:\WINDOWS\debug\UserMode\ChkAcc.txt    SUCCESS Length: 0
SET INFORMATION     C:\WINDOWS\debug\UserMode\ChkAcc.txt    SUCCESS Length: 0
WRITE           C:\WINDOWS\debug\UserMode\ChkAcc.txt    SUCCESS Offset: 0 Length: 41
WRITE           C:\WINDOWS\debug\UserMode\ChkAcc.txt    SUCCESS Offset: 41 Length: 2
SET INFORMATION     C:\WINDOWS\debug\UserMode\ChkAcc.txt    SUCCESS Length: 43
SET INFORMATION     C:\WINDOWS\debug\UserMode\ChkAcc.txt    SUCCESS Length: 43
CLOSE           C:\WINDOWS\debug\UserMode\ChkAcc.txt    SUCCESS 

Это заставляет меня подозревать, что разрешение папки не является проблемой вообще, но DLL по какой-то причине не может инициализироваться.

Есть ли способ дать IUSR те же разрешения, что и для ADMIN? тогда, возможно, я могу удалить их один за другим. Возможно, я мог бы даже создать второго пользователя с разрешениями ADMIN и использовать IIS вместо IUSR для входящих запросов CGI?

Очевидно, что добавление IUSR в группу ADMIN отличается от запуска приложения с ADMIN.

ADDED

Фактически проблема оказалась из-за того, что dll выполняла различные тесты проверки работоспособности при запуске, включая способность читать файлы. Для этого он пытается прочитать домашний каталог пользователя (или в терминах Windows каталог профиля пользователя)

При тестировании на Windows 2003 Server box я нахожу

IUSR

CSIDL_APPDATA = C: \ WINDOWS \ system32 \ config \ systemprofile \ Application Data

администратор

CSIDL_APPDATA = C:\Documents and Settings\ Администратор.Мой-сервер \ Данные приложения

Я подозреваю, что процессу cgi отказано в доступе к любым системным папкам. Это поведение, которое я ожидал бы, пока IUSR не будет добавлен к администраторам, тогда я ожидал бы, что это сработает.... но это не так. Решение было переписать DLL, но я все еще озадачен этим