У меня есть код, выполняющийся в ascx в PageLayout в SharePoint 2007, который обращается к файлам на удаленном сервере, т.е. File.Create ("\ servername \ sharename \ folder \ file.txt"). Код выполняется в веб-приложении SharePoint, в котором для доверия CAS установлено значение Full в файле web.config. File.Create выдает следующее исключение: -
System.UnauthorizedAccessException
Доступ к пути '\\ имя_сервера \ 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 SP, я действительно получаю исключение.
Когда я получаю удаленный доступ к сайту sharepoint из ЛЮБОГО браузера, я получаю исключение.
Кроме того, не имеет значения, какого пользователя я использую для входа на сайт, если у него есть разрешения на доступ к сайту sharepoint.
Есть мысли?
Update
Хм, теперь я обнаружил, что если я получаю доступ к сайту 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 решает проблему. : -)