views:

614

answers:

1

I have code running in an ascx within PageLayout within SharePoint 2007 that accesses files on a remote server i.e. File.Create("\servername\sharename\folder\file.txt"). The code runs within a SharePoint web application that has CAS trust set to Full in the web.config. The File.Create throws the following exception:-

System.UnauthorizedAccessException

Access to the path '\\servername\sharename\folder\file.txt' is denied.

The share is shared to Everyone with Full Control and the NTFS permissions are set to Everyone with Full Control. The web application app pool is running under a domain account also with explicit permissions to access that resource (not that this should be needed).

I ran Process Monitor on the remote machine and no hits were being recorded on the server. This leads me to believe that it is an issue with the SharePoint Code Access Security settings. Like I've said above, the trust in the web.config is set to Full.

Is it possible that CAS is still blocking the remote access? Can anyone think of any other area to review?


Update

A bit more information...

I've tried making the app pool acct domain admin and the problem still occurs. When using the same method to access a drive on the local machine it works fine. Running the same code in SnippetCompiler outside of sharepoint using the app pool account works fine.

Hope this helps, let me know if you can think of any more avenues of investigation or tests I can try.


Update

Im not sure if this would affect the issue but the local server is running Windows Server 2003 and the remote server is running Windows 2000.


Update

I've just tried running the code through a web part and it works fine. The file structure I use in the project that is failing is as follows:-

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

Then in IIS I have the following structure:-

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

Then within the PageLayouts I reference the controls using the following:-

<%@ 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.


Update

The mystery deepens...

When I access the sharepoint site from Internet Explorer (6 or 7) on the SharePoint web front end server I do NOT get the exception.

When I access the sharepoint site from Mozilla Firefox from the SP web front end server I DO get the exception.

When I access the sharepoint site remotely from ANY browser I get the exception.

Also, it makes no difference what user I use to log on to the site, as long as they have permissions to access the sharepoint site.

Any thoughts?


Update

Hmm, I've now found that if I access the sharepoint site remotely and the sharepoint site tries to do a File.Create() locally (i.e. File.Create("C:\temp\abc.txt")) then it works. If I access the sharepoint site from the sharepoint box and do a File.Create() remotely (i.e. File.Create("\ServerName\ShareName\FolderName\file.txt")) then it works.

It only fails when I access the sharepoint site remotely and have the sharepoint site try to do a File.Create() remotely as well. Kind of a double hop problem. This makes me think it may be an NTLM / Kerberos issue.

Currently, we are running using NTLM authentication.

Has anyone else experienced this sort of issue?


Update

Yep, I'm pretty sure this is an NTLM issue not allowing a double hop. I just changed the authentication on the sharepoint site to use Basic Authentication and its worked. Changed it back to Integrated Authentication and it failed.

Now to decide whether to move the farm to use Kerberos or find another way around the issue. :-/


Update

Just giving SPSecurity.RunWithElevatedPrivileges a shot now. One thing though, is RunWithElevatedPrivileges meant to be used in this context? Previously, I've only used it to get access to lists and libraries within SharePoint rather than accessing a file access the network.

Any thoughts?


Update

Yep, SPSecurity.RunWithElevatedPrivileges resolves the issue. :-)

+1  A: 

I wonder if this is the double-hop issue and that your code is trying to access the resource as the impersonated user, but that fails because NTLM will not impersonate to another server (Kerberos would).

Have you tried SPSecurity.RunWithElevatedPrivileges? That would remove the impersonation (RevertToSelf) and then maybe the application pool owner can just act as himself (herself?) whereas maybe it couldn't before.

Just a thought and should be pretty easy to try out.

Kirk Liemohn
Cheers for the suggestion Kirk, I'll give it a try and let you know if SPSecurity.RunWithElevatedPrivileges sorts the issue out.
Russell Giddings