Ошибка разрешения IUSR против АДМИНИСТРАТОРА

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

Это приложение использует шифрование TLS через стороннюю DLL, называемую cryptlib. http://www.coastrd.com/smtps/cryptlib Само по себе это не должно быть большой проблемой, так как большинство моих приложений CGI без проблем используют библиотеки MySQL / zlib / ... В этом случае (вероятно, из-за характера создания сеанса SSL / TLS) приложение работает нормально, если запускается двойным щелчком от имени администратора, но не запускается при запуске IIS в результате входящего запроса. IIS использует учетную запись «Гостевая учетная запись Интернета ... (... 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 но это не решило проблему.

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

ДОБАВЛЕНО

Добавление 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 

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

ДОБАВЛЕНО

Я изменил разрешения для файла 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.

ДОБАВЛЕНО

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

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

IUSR

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

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

CSIDL_APPDATA = C: \ Documents and Settings \ Administrator.MY-SERVER \ Application Data

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