Устранение распространенных разрешений и проблем, связанных с безопасностью в ASP.NET

В этой статье описывается устранение распространенных проблем с разрешениями и безопасностью в ASP.NET.

Исходная версия продукта: ASP.NET
Исходный номер базы знаний: 910449

Полезные инструменты

Прежде чем пытаться исправить все, что неисправно, необходимо ознакомиться с несколькими инструментами, которые помогут вам сузить проблему. В нашем случае нас интересуют такие инструменты, как FileMon, RegMon и Аудит безопасности. Дополнительные сведения о FileMon см. в разделе FileMon для Windows версии 7.04.

Дополнительные сведения о RegMon см. в статье Windows Sysinternals.

Детализация для изоляции проблемы

• Работало ли приложение? Если да, то что изменилось, что могло привести к прерыванию работы приложения? Возможно, на сервере были применены обновления программного обеспечения или системы безопасности. Развертывание кода также могло вызвать проблему.
• Выполняются ли простые .html и .asp страницы из IIS?
• Было ли приложение перенесено в другую версию IIS?
• Другие приложения ASP.NET на сервере завершаются с той же ошибкой? Это единственное приложение, которое завершается сбоем?
• Возникает ли проблема для всех пользователей или только для определенных пользователей?
• Воспроизводима ли проблема при локальном просмотре веб-сервера или воспроизводима только для нескольких клиентов?
• Если вы используете олицетворение, имеет ли олицетворенный пользователь необходимый доступ к ресурсу?

Приведенные выше вопросы полезны для диагностики проблемы. Если вы публикуете свою проблему на любом из ASP.NET форумах и у вас уже есть ответы на большинство из этих вопросов, то, скорее всего, вы получите быстрый указатель или решение проблемы. Ключ заключается в том, чтобы опубликовать всю ошибку трассировки стека ASP.NET, если применимо, вместо того, чтобы сказать: "При попытке запустить приложение ASP.NET я получаю ошибку "Отказано в доступе". Может кто-нибудь помочь?" Кому-то гораздо проще взглянуть на трассировку стека и дать вам указатели, когда он увидит полное сообщение об ошибке. Так что вам нужно спросить себя...

Точный текст сообщения об ошибке.

Первый вопрос, который мы задаем клиентам: "Что такое точное сообщение об ошибке?" Если у вас есть четкое описание сообщения об ошибке, выданного microsoft платформа .NET Framework, этот раздел можно пропустить. Если приложение маскирует фактическое сообщение об ошибке и выводит понятное сообщение об ошибке, например "Произошла непредвиденная ошибка. Обратитесь к администратору веб-сайта для получения дополнительных сведений", это не так уж и бесполезно для всех. Вот несколько шагов, которые помогут вам получить фактическое сообщение об ошибке.

• Найдите и откройте файл Web.config в каталоге приложения и измените customErrors на mode="Off". Сохраните файл и воспроизведите проблему.

• По-прежнему невозможно увидеть фактическое сообщение об ошибке после выполнения приведенного выше шага из-за пользовательской обработки событий или ошибок, выполняемой разработчиком приложения. Вы можете попытаться найти событие Application_Error в файле Global.asax и закомментировать любой код, который использует Server.Transfer("Errors.aspx") функцию для перехода на настраиваемую страницу ошибки.

  //Global.asax 
  void Application_Error(object sender, EventArgs e) 
  { 
      // Code that runs when an unhandled error occurs 
      //Server.Transfer("Errors.aspx"); 
  }
  

Получив фактическое сообщение об ошибке, прочитайте его, чтобы определить, вызвана ли ошибка отсутствием разрешений на локальный ресурс или удаленный ресурс, к которому пытается получить доступ приложение ASP.NET.

Проблема возникает из-за отсутствия разрешений на локальный ресурс, к которому приложение ASP.NET пытается получить доступ.

Если не удается получить четкое описание проблемы из-за пользовательского сообщения об ошибке, запустите FileMon и воспроизведите проблему. Остановите и сохраните запись как FileMon.xls и откройте файл в Microsoft Excel. В меню Данные выберите пункт Фильтр, а затем выберите пункт Автофильтр , чтобы использовать возможности фильтрации Excel. Теперь выберите раскрывающийся список в столбце F и найдите ошибки "ДОСТУП ЗАПРЕЩЕН".

Ниже показан пример выходных данных FileMon.

10381 1:01:11 PM w3wp.exe:2320 OPEN C:\winnt\microsoft.net\framework\v1.1.4322\Temporary ASP.NET Files\sessiontest\8832e585\275ec327\global.asax.xml 
ACCESS DENIED NT 
AUTHORITY\NETWORK SERVICE

Как видно из отфильтрованных результатов, мы сузили причину проблемы. FileMon показывает, что в учетной записи NT AUTHORITY\NETWORK SERVICE отсутствуют разрешения NTFS для C:\Winnt\Microsoft.net\Framework\v1.1.4322\Temporary ASP.NET Files папки. Это должно быть прямо для исправления.

Большинство пользователей, как правило, переустановят microsoft платформа .NET Framework или даже переустановят операционную систему. Это не рекомендуемый шаг по устранению неполадок и не гарантирует, что проблема не повторится. Я привечу один из таких примеров. Периодические проблемы часто трудно изолировать и устранить неполадки. В этом сценарии приложение клиента будет работать нормально в течение нескольких часов, а затем вдруг произойдет сбой с приведенной ниже ошибкой. Клиент уже попытался переустановить платформа .NET Framework, а также операционную систему. Это, казалось, исправить проблему в течение нескольких дней, но затем она появилась снова.

При выполнении FileMon не отображались ошибки ACCESS DENIED . Для учетной записи ASPNET были созданы все необходимые разрешения. Единственный способ восстановиться после проблемы — перезагрузить коробку. Даже сброс IIS не поможет. Вы думаете: "Ах, Microsoft Software всегда нуждается в перезагрузке для восстановления?" Ну, ты ошибаешься!

Здесь важно внимательно изучить сообщение об ошибке. В этой ошибке четко говорится "не удается открыть файл для записи", а не обычная ошибка ACCESS DENIED , поэтому я думаю, что это какой-то другой процесс, который удерживает блокировку файла или папки и не позволяет ASP.NET записывать в него. Имеет смысл, что перезагрузка убивает другой процесс, и приложение ASP.NET начинает работать снова, пока изгойный процесс снова не заблокирует файл. Логично было бы отключить все антивирусные программы, сторонние шпионские программы или любое другое программное обеспечение для мониторинга файлов, которое выполняется на сервере. Я не хочу указывать на какое-либо конкретное стороннее программное обеспечение. Но в целом антивирусная программа, как известно, вызывает много горя для IIS и приложений ASP.NET. Другой известной проблемой, вызванной антивирусной программой, является потеря сеанса из-за перезапуска AppDomain при касании папки Bin или файлов .config.

Отслеживайте приложение, чтобы узнать, возникает ли проблема повторно. Если вы запускаете несколько антивирусных программ, используйте метод пробной версии и ошибки, чтобы определить, какая именно программа вызывает проблему.

См. ASP.NET обязательные контроль доступа Списки (ACL).

Вместо этого используйте командную строку и выполните следующую команду:

cacls %windir%\assembly /e /t /p domain\useraccount:r

Кроме того, перед использованием Windows Обозреватель отмените регистрацию Shfusion.dll с помощью следующей команды, чтобы предоставить разрешения через графический интерфейс:

C:\WINDOWS\Microsoft.NET\Framework\VersionNumber>regsvr32-u shfusion.dll

После настройки разрешений в Windows Обозреватель повторно зарегистрируйте Shfusion.dll с помощью следующей команды:

C:\WINDOWS\Microsoft.NET\Framework\VersionNumber>regsvr32 shfusion.dll

Проблема возникает из-за отсутствия разрешений на удаленный ресурс, к которому приложение ASP.NET пытается получить доступ.

Когда приложение ASP.NET обращается к удаленному ресурсу, такому как Microsoft SQL Server или UNC-ресурсу, есть много вещей, которые могут пойти не так. Кроме того, многие вещи могут быть неправильно настроены в удаленном ресурсе. Чтобы ресурс работал, необходимо устранить эти проблемы.

Сначала необходимо проверить, можно ли подключиться к удаленному серверу через Windows Обозреватель.

1. На удаленном сервере создайте папку с именем Test. На вкладках Общий доступ и безопасность папки Test добавьте свой домен или учетную запись, а также учетную запись процесса, используемую приложением ASP.NET, и предоставьте им полный доступ.

2. На сервере IIS войдите с помощью домена или учетной записи, нажмите кнопку Пуск, нажмите кнопку Выполнить, а затем введите UNC-путь к удаленному серверу: \\RemoteServerName*\Test.

   Если вам не удается получить доступ к этой папке, обратитесь к администратору сети, чтобы устранить эту проблему. Только после этого приложение ASP.NET сможет получить доступ к общей папке.

3. Создайте файл с именем CreateUNCFile.aspx с приведенным ниже кодом и сохраните его в каталоге приложения.

   <%@ Page Language="vb" %>
   <%@ Import Namespace="System.IO" %>
   <html>
   <head>
   <title>Writing to a Text File</title>
   <script runat="server">
       Sub WriteToFile(ByVal sender As System.Object, ByVal e As System.EventArgs)
           Dim fp As StreamWriter
               fp = File.CreateText("\\<RemoteServerName>\Test\" & "test.txt")
               fp.WriteLine(txtMyFile.Text)
               lblStatus.Text = "The File Successfully created! Your ASP.NET process is able to access this remote share"
               fp.Close()
       End Sub
   </script>
   
   </head>
   <body style="font: 10pt verdana">
               <h3 align="center">Creating a Text File in ASP.NET</h3>
       <form id="Form1" method="post" runat="server">
                           Type your text:
                           <asp:TextBox ID="txtMyFile" TextMode="MultiLine" Rows="10" Columns="60" Runat="server" /><br>
                           <asp:button ID="btnSubmit" Text="Create File" OnClick="WriteToFile" Runat="server" />
                           <asp:Label ID="lblStatus" Font-Bold="True" ForeColor="#ff0000" Runat="server" />
       </form>
   </body>
   </html> 
   

4. Убедитесь, что вы изменяете< RemoteServerName> в следующей строке кода.

   fp = File.CreateText("\\<RemoteServerName>\Test\" &"test.txt")
   

   Чтобы оно отражало имя удаленного сервера.

5. Откройте Windows Internet Обозреватель и перейдите на страницу http://**IISServerName**/**AppName**/CreateUNCFile.aspx с клиентского компьютера, отличного от сервера IIS.

6. Если файл Test.txt создан успешно, приложение ASP.NET сможет пройти проверку подлинности в удаленном ресурсе.

7. Если создание файла завершается сбоем в браузере клиента Обозреватель Интернета, но работает, если вы переходите на ту же страницу на самом сервере IIS, скорее всего, вы работаете в сценарии двойного прыжка. Если вы используете пользовательские встроенные веб-части для доступа к удаленным ресурсам, которым требуется проверка подлинности и авторизация пользователей, скорее всего, возникнет проблема двойного прыжка. Чтобы получить доступ к удаленному ресурсу, может потребоваться предоставить ресурсу учетные данные конечного пользователя, чтобы выходные данные из ресурса были ограничены данными, на доступ к которым у пользователя есть разрешение.

В приведенных выше шагах предполагается, что в службах IIS включена проверка подлинности NTLM. Обычная проверка подлинности не использует Kerberos.

Дополнительные сведения см. в статье Устранение неполадок Kerberos в Интернете Обозреватель.

Дополнительные сведения о методах проверки подлинности IIS см. в технической документации по Visual Studio 2003 с устаревшим доступом.

Существует множество других причин возникновения сообщения об ошибке "Серверное приложение недоступно". Журнал событий — это лучший вариант для получения дополнительных сведений о причине проблемы.

Ошибки, связанные с IIS

Журналы IIS полезны в случаях ошибок, связанных с проверкой подлинности IIS.

Вам нужно искать коды состояния и вложенных состояний для этой конкретной ошибки.

2006-10-12 22:47:28 W3SVC1 65.52.18.230 GET /MyAPP/login.aspx - 80  
MyDomain\UserID_91 65.52.22.58 Mozilla/4.0+  
(compatible;+MSIE+6.0;+Windows+NT+5.2;+SV1;+.NET+CLR+1.1.4322;+.NET+CLR+2.0.50727;+InfoPath.1) 401 3 5

Мы видим 401 с подсостоянием 3, которое указывает на "Не авторизовано из-за ACL в ресурсе".

Это указывает на отсутствие разрешений NTFS для файла или папки. Эта ошибка может возникнуть, даже если разрешения правильные для файла, к которому вы пытаетесь получить доступ, но разрешения по умолчанию и права пользователя могут отсутствовать в других папках SYSTEM и IIS. Например, эта ошибка может возникнуть, если у учетной записи IUSR_ComputerName нет доступа к каталогу C:\Winnt\System32\Inetsrv.

Кроме того, здесь интересен код состояния 5. Чтобы получить дополнительные сведения об этом коде состояния, можно использовать команду net helpmsg:

C:\Documents and Settings\User> net helpmsg 5

Отказ в доступе.

Давайте попробуем другой распространенный код состояния, код 50:

C:\Documents and Settings\User> net helpmsg 50

Запрос не поддерживается.

Идея заключается в том, чтобы использовать все доступные в журнале сведения, чтобы получить максимальные сведения о проблеме.

Ресурсы

Дополнительные сведения см. в разделе:

• Общие сведения об удостоверении ASP.NET

• Создание учетной записи службы для приложения ASP.NET 2.0

• Создание безопасных приложений ASP.NET: проверка подлинности, авторизация и безопасное взаимодействие