Удаленный доступ к файлам SharePoint 2007 запрещен CAS

У меня есть код, выполняющийся в ascx в PageLayout в SharePoint 2007, который обращается к файлам на удаленном сервере, например File.Create("\servername\sharename\folder\file.txt"). Код выполняется в веб-приложении SharePoint, для которого для доверия CAS установлено значение Full в файле web.config. File.Create выдает следующее исключение:

System.UnauthorizedAccessException

Доступ к пути \\servername\sharename\folder\file.txt запрещен.

Общая папка доступна всем пользователям с полным доступом, а разрешения NTFS установлены для всех пользователей с полным доступом. Пул приложений веб-приложения работает под учетной записью домена, также с явными разрешениями на доступ к этому ресурсу (не обязательно).

Я запустил Process Monitor на удаленной машине, и на сервере не было записано ни одного обращения. Это наводит меня на мысль, что это проблема с настройками безопасности доступа к коду SharePoint. Как я уже говорил выше, доверие к web.config установлено на Full.

Возможно ли, что CAS все еще блокирует удаленный доступ? Кто-нибудь может придумать какую-нибудь другую область для обзора?

Обновить

Немного больше информации...

Я попытался сделать пул приложений администратором домена acct, и проблема все еще возникает. При использовании того же метода для доступа к диску на локальной машине он работает нормально. Выполнение того же кода в SnippetCompiler за пределами sharepoint с использованием учетной записи пула приложений работает нормально.

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

Обновить

Я не уверен, если это повлияет на проблему, но локальный сервер работает под управлением Windows Server 2003, а удаленный сервер работает под управлением Windows 2000.

Обновить

Я только что попытался запустить код через веб-часть, и он работает нормально. Структура файла, которую я использую в проекте, который терпит неудачу, выглядит следующим образом:

wss
 - VirtualDirectories
   - SharePointWebApp
     - ...sp web app files
     - .
     - .
   - PageLayoutControls
     - control.ascx
     - .
     - .

Тогда в IIS у меня есть следующая структура:

IIS
 - Websites
   - SharePointWebApp (pointing to \wss\VirtualDirectories\SharePointWebApp)
     - PageLayoutControls (virtual directory pointing to \wss\VirtualDirectories\PageLayoutControls)

Затем в рамках PageLayouts я ссылаюсь на элементы управления, используя следующее:-

<%@ Register TagPrefix="TEST" TagName="MyControl" Src="~/PageLayoutControls/control.ascx" %>
<asp:Content ContentPlaceholderID="PlaceHolderMain" runat="server">
  <TEST:MyControl id="myControl" runat="server"/>
</asp:Content>Let me know if you need more info.

Обновить

Тайна углубляется...

Когда я получаю доступ к сайту sharepoint из Internet Explorer (6 или 7) на сервере переднего плана SharePoint, я НЕ получаю исключение.

Когда я захожу на сайт sharepoint из Mozilla Firefox с внешнего веб-сервера SP, я действительно получаю исключение.

Когда я получаю доступ к сайту sharepoint удаленно из ЛЮБОГО браузера, я получаю исключение.

Кроме того, не имеет значения, какого пользователя я использую для входа на сайт, если у него есть разрешения на доступ к сайту sharepoint.

Какие-нибудь мысли?

Обновить

Хм, теперь я обнаружил, что если я получаю доступ к сайту sharepoint удаленно и сайт sharepoint пытается выполнить File.Create() локально (то есть File.Create("C:\temp\abc.txt")), тогда он работает, Если я получаю доступ к сайту sharepoint из поля sharepoint и выполняю File.Create() удаленно (то есть File.Create("\ServerName\ShareName\FolderName\file.txt")), тогда он работает.

Сбой происходит только тогда, когда я получаю доступ к сайту sharepoint удаленно, и сайт sharepoint пытается также выполнить File.Create() удаленно. Вроде проблемы с двойным прыжком. Это заставляет меня думать, что это может быть проблемой NTLM / Kerberos.

В настоящее время мы работаем с использованием аутентификации NTLM.

Кто-нибудь еще сталкивался с такой проблемой?

Обновить

Да, я почти уверен, что это проблема NTLM, не допускающая двойной скачок. Я просто изменил аутентификацию на сайте sharepoint, чтобы использовать обычную аутентификацию, и она сработала. Изменил его обратно на встроенную аутентификацию, и это не удалось.

Теперь нужно решить, следует ли перенести ферму на использование Kerberos или найти другой способ решения проблемы.:-/

Обновить

Просто даю SPSecurity.RunWithElevatedPrivileges шанс. Одна вещь, хотя, RunWithElevatedPrivileges предназначен для использования в этом контексте? Ранее я использовал его только для получения доступа к спискам и библиотекам в SharePoint, а не для доступа к файлам в сети.

Какие-нибудь мысли?

Обновить

Да, SPSecurity.RunWithElevatedPrivileges решает проблему.:-)

Источник

1 ответ

Решение

Интересно, если это проблема двойного прыжка и ваш код пытается получить доступ к ресурсу от имени другого пользователя, но это не удается, потому что NTLM не будет выдавать себя за другой сервер (Kerberos будет).

Вы пробовали SPSecurity.RunWithElevatedPrivileges? Это уберет олицетворение (RevertToSelf), и тогда, возможно, владелец пула приложений может просто действовать как он сам, тогда как, может быть, раньше не мог.

Просто мысль и должно быть довольно легко попробовать.

Источник
Другие вопросы по тегам