У нас есть сервер Windows 2012 с IIS 8 на нем.
На этом сервере работает приложение ASP.NET, которое аутентифицируется через REST API в отдельном приложении. Это отдельное приложение отвечает в виде файла .XML с именем login.xml, который приложение ASP.NET по умолчанию пытается поместить в локальную папку C: \ Windows \ System32 \ inetsrv. Приложение ASP.NET не запрашивает этот XML-файл, и, похоже, нет способа сделать так, чтобы этот файл сбрасывался в другое место.
Поскольку пользователь «IIS AppPool \ DefaultAppPool», который является идентификатором пула приложений, в котором работает приложение ASP.NET, не имеет разрешений в этой папке C: \ Windows \ System32 \ inetserv, файл .XML не может быть записан в нее и в браузере отображается ошибка.
Отчасти ошибка, отображаемая в браузере, гласит:
«Доступ к пути 'C: \ windows \ system32 \ inetserv \ login.xml' запрещен.
Я подозреваю, что, как правило, предоставление разрешений на каталог «C: \ windows \ system32 \ inetserv \» этому пользователю «IIS AppPool \ DefaultAppPool» не является такой уж важной идеей в плане безопасности, но в нашем конкретном случае это было бы нормально .
При поиске способа разрешения ошибки, отображаемой в браузере ранее, многие люди смогли успешно предоставить необходимые разрешения для папки. Однако также кажется, что во всех сообщениях, которые я вижу по этому поводу, используется версия IIS 7 или более ранняя.
Как локальный администратор, я безуспешно пытался добавить необходимые разрешения для пользователя в "C: \ windows \ system32 \ inetserv \", а также безуспешно пытался снять флажок с свойства только для чтения в папке, но мне было отказано, потому что даже Пользователь-администратор не имеет прав на изменение прав доступа к папке. Если внимательно присмотреться к разрешениям для папки, все пользователи имеют разрешения «Чтение и выполнение», «Список содержимого папки» и «Чтение», но у администраторов нет дополнительных разрешений.
Я не нашел в Интернете ничего, что конкретно говорило бы о том, что Microsoft заблокировала Windows Server 2012 или IIS 8, где нельзя предоставить дополнительные разрешения для этой папки ... Может ли кто-нибудь, читающий это, пролить свет на то, почему я не могу предоставить эти разрешения ?
Также связанный с этим вопрос - этот сервер расположен в AWS, созданный на основе AMI, предоставленного Amazon. Возможно ли, что AMI от Amazon каким-то образом специально усилены, чтобы отклонять такие изменения разрешений, чтобы серверы, размещенные на AWS, оставались максимально безопасными?
Спасибо Майк
Разрешения по умолчанию для system32\inetsrv на Server 2012:
NT SERVICE\TrustedInstaller:(F)
NT SERVICE\TrustedInstaller:(CI)(IO)(F)
NT AUTHORITY\SYSTEM:(M)
NT AUTHORITY\SYSTEM:(OI)(CI)(IO)(F)
BUILTIN\Administrators:(M)
BUILTIN\Administrators:(OI)(CI)(IO)(F)
BUILTIN\Users:(RX)
BUILTIN\Users:(OI)(CI)(IO)(GR,GE)
CREATOR OWNER:(OI)(CI)(IO)(F)
APPLICATION PACKAGE AUTHORITY\ALL APPLICATION PACKAGES:(RX)
APPLICATION PACKAGE AUTHORITY\ALL APPLICATION PACKAGES:(OI)(CI)(IO)(GR,GE)
Администраторы имеют права на изменение, что означает, что либо значения по умолчанию AWS отличаются, либо права доступа уже изменены кем-то другим.
Основная проблема заключается в том, что ваше приложение ASP.NET пытается писать в inetsrc, это нет-нет. Свяжитесь с тем, кто написал приложение, и попросите его исправить.
Если вы действительно хотите изменить разрешения на inetsrv, вам сначала нужно изменить владельца на администраторов
takeown.exe /F .\inetsrv /R /A
владелец по умолчанию на 2012 год TrustedInstaller
затем вы можете добавить разрешения на изменение для удостоверения AppPool.
Как вы правильно сказали, это ослабляет безопасность и может поставить под угрозу весь сервер, поэтому сначала попробуйте исправить приложение.