Accesso remoto ai file di SharePoint 2007 negato CAS

Question

Ho un codice in esecuzione in un ascx all'interno di PageLayout in SharePoint 2007 che accede ai file su un server remoto, ad esempio File.Create (" \ servername \ sharename \ folder \ file.txt "). Il codice viene eseguito all'interno di un'applicazione Web di SharePoint con trust CAS impostato su Completo in web.config. File.Create genera la seguente eccezione: -

System.UnauthorizedAccessException

L'accesso al percorso '\\ nomeserver \ nomecondivisione \ cartella \ file.txt' è negato.

La condivisione è condivisa con Tutti con controllo completo e le autorizzazioni NTFS sono impostate su Tutti con controllo completo. Il pool di applicazioni Web è in esecuzione con un account di dominio anche con autorizzazioni esplicite per accedere a quella risorsa (non che ciò sia necessario).

Ho eseguito Process Monitor sul computer remoto e non sono stati registrati hit sul server. Questo mi porta a credere che si tratti di un problema con le impostazioni di sicurezza dell'accesso al codice di SharePoint. Come ho detto sopra, la fiducia in web.config è impostata su Full.

È possibile che CAS stia ancora bloccando l'accesso remoto? Qualcuno può pensare a un'altra area da recensire?

---

Aggiorna

Altre informazioni ...

Ho provato a rendere il pool di applicazioni acct domain admin e il problema persiste. Quando si utilizza lo stesso metodo per accedere a un'unità sul computer locale, funziona correttamente. L'esecuzione dello stesso codice in SnippetCompiler al di fuori di sharepoint utilizzando l'account del pool di app funziona correttamente.

Spero che questo ti aiuti, fammi sapere se riesci a pensare ad altre vie di indagine o test che posso provare.

---

Aggiorna

Non sono sicuro che ciò influisca sul problema, ma il server locale esegue Windows Server 2003 e il server remoto esegue Windows 2000.

---

Aggiorna

Ho appena provato a eseguire il codice attraverso una web part e funziona benissimo. La struttura del file che utilizzo nel progetto che non funziona è la seguente: -

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

Quindi in IIS ho la seguente struttura: -

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

Quindi all'interno dei PageLayout faccio riferimento ai controlli usando quanto segue: -

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

---

Aggiorna

Il mistero si approfondisce ...

Quando accedo al sito sharepoint da Internet Explorer (6 o 7) sul server front-end Web di SharePoint NON ottengo l'eccezione.

Quando accedo al sito sharepoint da Mozilla Firefox dal server Web front-end SP, ottengo l'eccezione.

Quando accedo al sito sharepoint in remoto da QUALSIASI browser ottengo l'eccezione.

Inoltre, non fa differenza quale utente utilizzo per accedere al sito, purché dispongano delle autorizzazioni per accedere al sito sharepoint.

Qualche idea?

---

Aggiorna

Hmm, ora ho scoperto che se accedo al sito sharepoint in remoto e il sito sharepoint prova a fare un File.Create () localmente (cioè File.Create (" C: \ temp \ abc. txt ")) quindi funziona. Se accedo al sito sharepoint dalla casella sharepoint e eseguo un File.Create () in remoto (ad esempio File.Create (& Quot; \ ServerName \ ShareName \ FolderName \ file.txt & Quot;)) allora funziona .

Non riesce solo quando accedo al sito sharepoint in remoto e il sito sharepoint tenta di eseguire anche un File.Create () in remoto. Tipo di un problema di doppio hop. Questo mi fa pensare che potrebbe trattarsi di un problema NTLM / Kerberos.

Attualmente stiamo eseguendo l'autenticazione NTLM.

Qualcun altro ha riscontrato questo tipo di problema?

---

Aggiorna

Sì, sono abbastanza sicuro che si tratti di un problema NTLM che non consente un doppio hop. Ho appena cambiato l'autenticazione sul sito sharepoint per utilizzare l'autenticazione di base e ha funzionato. È stato modificato in Autenticazione integrata e non è riuscito.

Ora per decidere se spostare la farm per utilizzare Kerberos o trovare un altro modo per aggirare il problema. : - /

---

Aggiorna

Sto solo dando SPSecurity.RunWithElevatedPrivileges un colpo ora. Una cosa però, RunWithElevatedPrivileges è pensata per essere utilizzata in questo contesto? In precedenza, l'ho usato solo per ottenere l'accesso a elenchi e librerie all'interno di SharePoint anziché accedere a un file per accedere alla rete.

Qualche idea?

---

Aggiorna

Sì, SPSecurity.RunWithElevatedPrivileges risolve il problema. : -)

Answer 1

Mi chiedo se questo sia il problema del doppio hop e che il tuo codice stia tentando di accedere alla risorsa come utente impersonato, ma ciò fallisce perché NTLM non impersonerà su un altro server (Kerberos lo farebbe).

Hai provato SPSecurity.RunWithElevatedPrivileges? Ciò eliminerebbe la rappresentazione (RevertToSelf) e quindi forse il proprietario del pool di applicazioni può agire come se stesso (se stesso?) Mentre forse non potrebbe prima.

Solo un pensiero e dovrebbe essere abbastanza facile da provare.