none
Accesso Negato all'amministatore della raccolta siti

    General discussion

  • Sto eseguendo dei test di Disaster\Recovery per cui ho eseguito un restore di una semplice farm su un server differente.

    Il restore è stato completato con successo e riesco ad entrare tranquillamente nell'interfaccia di amministrazione centrale di SharePoint.

    Se invece tento di entrare nelle impostazioni del sito utilizzando il seguente link:

    http://sito/_layouts/settings.aspx

    ottengo un access denied.

    E' importante sottolineare che l'utente utilizzato è amministratore della raccolta siti per cui dovrebbe avere pieno accesso a tutti i siti.

    Il tutto funziona regolarmente nel sito di origine.

    Quanche idea sulla possibile causa del problema?

    Grazie

     

    Tuesday, September 13, 2011 6:42 PM

All replies

  • Quali database sono stati oggetto di restore?
    Tuesday, September 13, 2011 7:26 PM
  • Ciao!
    Usi SharePoint 2010 o 2007 ?

     


    Giuseppe Marchi - SharePoint MVP
    www.peppedotnet.it
    www.dev4side.com
    www.sharepointcommunity.it
    Twitter: @PeppeDotNet
    Tuesday, September 13, 2011 9:14 PM
    Moderator
  • Ho eseguito il backup completo dell'intera farm utilizzando il comando poweshell (backup-spfarm).

    Il restore è stato eseguito dall'interfaccia di amministrazione selezionanado l'opzione nuova configurazione.

    Nessun errore è stato rilevato nelle operazioni di backup e restore.

    Grazie per l'interessamento

     

    Tuesday, September 13, 2011 10:28 PM
  • Uso SharePoint 2010, senza SP1.

    Grazie

    Tuesday, September 13, 2011 10:29 PM
  • Temo che il restore di farm completa che hai fatto (su di una macchina diversa con nome diverso) non sia esattamente supportato.

    A mio avviso avresti dovuto ricreare la farm da zero e POI fare il restore delle sole web application diverse dalla Central Admin.

     


    Wednesday, September 14, 2011 7:00 PM
  • Due check veloci:

    - Controlla che l'utenza utilizzata sia Primary Admin della site collection

    - Controlla che i DB non siano in readonly mode: http://technet.microsoft.com/en-us/library/cc263050(office.12).aspx


    Romeo Pruno | Microsoft MVP SharePoint Server | http://www.nonaka.eu/feed
    Wednesday, September 14, 2011 8:51 PM
  •  

    Premetto che non sono alle prime armi con SharePoint. Ho letto un paio di libri e la documentazione MS, ma queste sono le mie prime esperienze pratice.

    Da quello che ho avuto modo di apprendere, questa tecnica i backup e recovery è perfettamente supportata. A conforto di quanto detto c'è anche da dire che questa metodologia di restore è prevista anche dall'interfaccia grafica (vedi sotto).

     

     

    Se proprio non dovessi uscirmene con il restore della farm, tenterò quello della web application

    Grazie per l'interessamento

     

    Thursday, September 15, 2011 2:14 PM
  • - Controlla che l'utenza utilizzata sia Primary Admin della site collection

    Questa è la prima cosa che ho controllato. Tutto è ok.

    - Controlla che i DB non siano in readonly mode: http://technet.microsoft.com/en-us/library/cc263050(office.12).aspx

    I database SQL Server non sono in modalità readonly. Anche le configuratione delle quote sembra ok.

    Grazie per i suggerimenti

     

     

    Thursday, September 15, 2011 3:00 PM
  • Ciao,

    prova a vedere se sulla scheda Policy della Web Application l'amministratore ha full control sulla radice.


    Romeo Pruno | Microsoft MVP SharePoint Server | http://www.nonaka.eu/feed
    Thursday, September 15, 2011 3:12 PM
  • Purtroppo non funziona neanche questo tentativo anche inserendo l'utente utilizzato in "Criteri per l'application Web" con i grant "Full Control"

     

    Grazie

    Thursday, September 15, 2011 3:52 PM
  • hai controllato che ci sia anche NT AUTHORITY\local service ?
    Romeo Pruno | Microsoft MVP SharePoint Server | http://www.nonaka.eu/feed
    Thursday, September 15, 2011 8:09 PM
  • Nulla di fatto, questi sono i permessi

     

    Friday, September 16, 2011 7:22 PM
  • Eh ma non si impara mai abbastanza :-)

    Vediamo un po:

    1) le web applications a cui non accedi hanno dei nomi host diversi da quello della macchina e tu stai cercando di accedere direttamente dal server? Se questo è vero ti sei vittima del famigerato DisableLoopBackCheck....

    2)  gli account usati dagli application pool IIS associati ai web site che ospitano le web application (che giro contorto...) hanno diritto di accesso ai database dei contenuti?

     

    Friday, September 16, 2011 7:52 PM
  • Cerchiamo di ricapitolare:

    Accedi corretamente a http://sito ma non accedi correttamente a http://sito/_layout/settings.aspx ?

     


    Romeo Pruno | Microsoft MVP SharePoint Server | http://www.nonaka.eu/feed
    Saturday, September 17, 2011 2:02 PM
  • Ciao IDO,

    Visti i tempi trascorsi, ho modificato il tuo thread in "Discussione generale".

    Se riesci a risolvere nel frattempo, ti saremmo grati di aggiornare il thread (sarebbe d'aiuto per gli altri membri della community che magari si sono imbattuti in un caso simile al tuo).

    Grazie,

     


    Anca Popa Follow ForumTechNetIt on Twitter

    Come inserire immagini nei post

    Microsoft offre questo servizio gratuitamente, per aiutare gli utenti e aumentare il database dei prodotti e delle tecnologie. Il contenuto viene fornito “così come è” e non comporta alcuna responsabilità da parte dell'azienda

    Tuesday, September 20, 2011 7:29 AM
    Owner
  • Io ho avuto un problema simile cambiando l'amministratore della farm.

    E' stato sufficiente inserire l'account incriminato nei gruppi WSS_* della macchina su cui gira Sharepoint (per la cronaca è un Foundation 2010 con db e app sulla stessa macchina)

    Monday, November 07, 2011 4:54 PM
  • Ciao IDO!
    Hai risolto il problema? Puoi vedere se la soluzione di Fabio può andar bene anche per te?

    Peppe


    Giuseppe Marchi - SharePoint MVP
    www.peppedotnet.it
    www.dev4side.com
    www.sharepointcommunity.it
    Twitter: @PeppeDotNet
    Tuesday, November 08, 2011 8:39 AM
    Moderator
  • Putroppo nulla di fatto.

    Il problema sembra legato all'autenticazione SQL.

    System.Data.SqlClient.SqlException: Login failed. The login is from an untrusted domain and cannot be used with Windows authentication.   
     at System.Data.SqlClient.SqlInternalConnection.OnError(SqlException exception, Boolean breakConnection)   
     at System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj)   
     at System.Data.SqlClient.TdsParser.Run(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj)   
     at System.Data.SqlClient.SqlInternalConnectionTds.CompleteLogin(Boolean enlistOK)   
     at System.Data.SqlClient.SqlInternalConnectionTds.AttemptOneLogin(ServerInfo serverInfo, String newPassword, Boolean ignoreSniOpenTimeout, Int64 timerExpire, SqlConnection owningObject)   
     at System.Data.SqlClient.SqlInternalConnectionTds.LoginNoFailover(String host, String newPassword, Boolean redirectedUserInstance, SqlConnection owningObject, SqlConnectionString connectionOptions, Int64 timerStart)   
     at System.Data.SqlClient.SqlInternalConnectionTds.OpenLoginEnlist(SqlConnection owningObject, SqlConnectionString connectionOptions, String newPassword, Boolean redirectedUserInstance)   
     at System.Data.SqlClient.SqlInternalConnectionTds..ctor(DbConnectionPoolIdentity identity, SqlConnectionString connectionOptions, Object providerInfo, String newPassword, SqlConnection owningObject, Boolean redirectedUserInstance)   
     at System.Data.SqlClient.SqlConnectionFactory.CreateConnection(DbConnectionOptions options, Object poolGroupProviderInfo, DbConnectionPool pool, DbConnection owningConnection)   
     at System.Data.ProviderBase.DbConnectionFactory.CreatePooledConnection(DbConnection owningConnection, DbConnectionPool pool, DbConnectionOptions options)   
     at System.Data.ProviderBase.DbConnectionPool.CreateObject(DbConnection owningObject)   
     at System.Data.ProviderBase.DbConnectionPool.UserCreateRequest(DbConnection owningObject)   
     at System.Data.ProviderBase.DbConnectionPool.GetConnection(DbConnection owningObject)   
     at System.Data.ProviderBase.DbConnectionFactory.GetConnection(DbConnection owningConnection)   
     at System.Data.ProviderBase.DbConnectionClosed.OpenConnection(DbConnection outerConnection, DbConnectionFactory connectionFactory)   
     at System.Data.SqlClient.SqlConnection.Open()   
     at Microsoft.SharePoint.Utilities.SqlSession.OpenConnection()

    Comunque, mi sto facendo dare una mano dal supporto Microsoft.

     

    Vi tengo aggiornati non appena vi sono novità

     

    Tuesday, November 08, 2011 1:57 PM
  • Se non ho capito male le macchine sono su due domini differenti e la connessione al db avviene con autenticazione windows.

    Se si potresti provare ad impostare l'autenticazione sqlserver, tramite http://sito_amministrazione_centrale/_admin/defaultcontentdb.aspx

    Tuesday, November 08, 2011 2:17 PM
  • Sharepoint and il database server sono su due domini differenti ed utilizzano l'autenticazione SQL.

     

    Ho verificato la connessione al database e sembra tutto regolare.

     

    Ciao e grazie per la collaborazione

     

    Tuesday, November 08, 2011 2:39 PM
  • Non ho ben capito la situazione.

    Delle seguenti, quale sarebbe l'ìinfrastruttura?

    1)

    Dominio 1: sharepoint + sqlserver originali sulla stessa macchina fisica (o virtuale)

    Dominio 2: sharepoint + sqlserver restore sulla stessa macchina fisica (o virtuale)

     

    2)

    Dominio 1: sharepoint originale + restore sulla stessa macchina fisica (o virtuale)

    Dominio 2: sqlserver originale + restore sulla stessa macchina fisica (o virtuale)

     

    3)

    Dominio 1: sharepoint + sqlserver originali su diverse macchine fisiche (o virtuali)

    Dominio 2: sharepoint + sqlserver restore su diverse macchine fisiche (o virtuali) 

     

    4)

    Dominio 1: sharepoint originale + restore su diverse macchine fisiche (o virtuali)

    Dominio 2: sqlserver originale + restore su diverse macchine fisiche (o virtuali)

     

    Tuesday, November 08, 2011 3:25 PM
  • Dovremmo rientrare nel caso 4.

    A scanso di equivoci:

     

    FARM DI PRODUZIONE

       DOMINIO 1: SharePoint

       DOMINIO 2: Database

    FARM DI FAILOVER

       DOMINIO 1: SharePoint Failover (server differente da quello di produzione)

       DOMINIO 2: Database Failover (server differente da quello di produzione)

    La farm di failover è ottenuta mediante restore di quella di produzone

     

    Ciao e grazie

     

     

    Tuesday, November 08, 2011 4:04 PM
  • Ok perfetto. Ti faccio un terzo grado, magari anche con domande stupide, ma mi serve per capire meglio la situazione. Faccio riferimento solo alla farm di failover.

    1) L'account di login SQL è correttamente configurato in SQL? E' lo stesso della farm di produzione?

    2) L'account di login SQL è anche un account windows? Se si, è un account locale o AD? Se è locale, su quale macchina (sp o db) è stato creato?

     [Update]

    Se l'account di login SQL è anche utente windows...

    [/Update]

    ... verifica che sulla macchina DB ci siano i gruppi

    • SQLServerMSSQLUser$TUA_ISTANZA_SHAREPOINT$SHAREPOINT 
    • SQLServerSQLAgentUser$TUA_ISTANZA_SHAREPOINT$SHAREPOINT

    e che l'account di login sia correttamente inserito nei gruppi.

     


    • Edited by Fabio Ferraguti Tuesday, November 08, 2011 4:33 PM spiegazione migliore
    Tuesday, November 08, 2011 4:21 PM
  • Dovremmo rientrare nel caso 4.

    A scanso di equivoci:

     

    FARM DI PRODUZIONE

       DOMINIO 1: SharePoint

       DOMINIO 2: Database

    FARM DI FAILOVER

       DOMINIO 1: SharePoint Failover (server differente da quello di produzione)

       DOMINIO 2: Database Failover (server differente da quello di produzione)

    La farm di failover è ottenuta mediante restore di quella di produzone

     

    Ciao e grazie

     


    Chi vi ha consigliato una configurazione del genere?
    Soprattutto cosa intendete per FAILOVER?

     

     

    Tuesday, November 08, 2011 4:28 PM
  •  

     

    1) L'account di login SQL è correttamente configurato in SQL?

    Ritengo di si;infatti, il restore crea correttamente tutti i database utilizzando questo account.

    E' lo stesso della farm di produzione?

     

    2) L'account di login SQL è anche un account windows? Se si, è un account locale o AD? Se è locale, su quale macchina (sp o db) è stato creato?

     Ho creato una login con autenticazione SQL.

    Verifica che sulla macchina DB ci siano i gruppi

    • SQLServerMSSQLUser$TUA_ISTANZA_SHAREPOINT$SHAREPOINT
    • SQLServerSQLAgentUser$TUA_ISTANZA_SHAREPOINT$SHAREPOINT

    e che l'account di login sia correttamente inserito nei gruppi.

    E' una login SQL per cui non posso verificare l'appartenenza a questi gruppi.

    Ciao, martino

     

     

    Tuesday, November 08, 2011 4:29 PM
  • Voglio semplicemente effettuare un restore su server diversi partendo dal backup.

    E' pe la procedura di disaster\recovery.

     

     

    Tuesday, November 08, 2011 4:31 PM
  • Facendola molto semplice, visto che l'errore parla di "untrusted domain", mi verrebbe da dirti di mettere o far mettere i domini in trust. Ma se così fosse non mi spiego come faccia a funzionare correttamente l'ambiente di produzione.

    Mi accodo alla domanda di Gabriele, come mai una configurazione del genere?

     

    Tuesday, November 08, 2011 4:39 PM
  • Voglio semplicemente effettuare un restore su server diversi partendo dal backup.

    E' pe la procedura di disaster\recovery.

     

     


    PUoi delineare la procedura di disaster recovery?
    La parte di recovery per la parte SQLServer della Farm è abbastanza semplice se si usano gli Alias per le istanze, ma quella delle macchine SharePoint non è che sia solo reinstallare il prodotto sulla macchina.

     

    Tuesday, November 08, 2011 4:39 PM
  • Non capisco tutte queste perplessità sull'architettura.

    Poiché utilizzo l'autenticazione SQL, pienamente supportata, non dovrebbero esserci problemi. Almeno spero....

     

    Tuesday, November 08, 2011 4:44 PM
  • La procedura di recovery è molto banale.

    1. Eseguo una installazione base del prodotto

    2. Creo una farm

    3. Mi collego l'interfaccia di amministrazione ed esegui il restore del backup di produzione.

    Vedi qualche problema? Ho saltato qualcosa?


    Grazie

    Tuesday, November 08, 2011 4:45 PM
  • Ho seguito la stessa procedura effettuata sul server di produzione.

    La particolarità è dovuta all'utilizzo dell'autenticazione SQL e non windows.

    Per questa particolare configurazione ho seguito le istruzioni presenti su questo sito:

     

    http://blogs.msdn.com/b/ekraus/archive/2009/11/06/sharepoint-2010-provisioning-a-new-farm-with-powershell.aspx

     

    Tuesday, November 08, 2011 4:56 PM
  • 2. Creo la farm. Come? Collegandoti al database di configurazione sul DB esistente o rifai la farm da zero?

     

    Tuesday, November 08, 2011 4:57 PM
  • Ricreo la farm da zero, ma quando faccio il restore attraverso l'interfaccia di amministrazione chiedo di ripristinare il contenuto e le impostazioni di configurazione. Vedi sotto: 

     

     

     

    Tuesday, November 08, 2011 5:05 PM
  • Secondo me nella farm di recovery ti sei perso qualche passo nella configurazione dell'autenticazione.

    http://blogs.technet.com/b/patrick_heyde/archive/2010/07/04/install-sharepoint-2010-with-sql-authentication.aspx

    http://blogs.technet.com/b/sykhad-msft/archive/2011/07/29/building-sharepoint-2010-farm-using-sql-authentication-amp-its-limitations.aspx

    Motivi reali per i quali non debba esserci una Trust relationship fra i domini non ce ne sono se uno sa come gestire i gruppi di utenti. Usare l'autenticazione SQL Nativa espone a un rischio imponderabile in quanto è possibile che le password siano poi persistite dalle applicazioni in qualche file di testo o nel registry dei client il che è MOLTO più pericoloso. Ma il mondo di Windows è pieno di para-sistemisti con il tarlo della sicurazza tarlato di fabbrica...

     

    Tuesday, November 08, 2011 5:26 PM
  • Ti ringrazio per i link che studierò con molta attenzione.

    Definirmi un "para-sistemista con il tarlo della sicurezza" mi sembra un tantino eccessivo e superficiale da parte tua prima di conoscere esattamente l'ambiente ed i requisiti di sicurezza.

    Grazie per il supporto

    Tuesday, November 08, 2011 5:41 PM
  • Ti ringrazio per i link che studierò con molta attenzione.

    Definirmi un "para-sistemista con il tarlo della sicurezza" mi sembra un tantino eccessivo e superficiale da parte tua prima di conoscere esattamente l'ambiente ed i requisiti di sicurezza.

    Grazie per il supporto


    Non te la prendere a male :-) 
    La tua è configurazione è sicuramente frutto di approfondite letture sulla security in ambiente Windows.
    E chi sono io per criticarla? Nessuno.
    Tuesday, November 08, 2011 6:59 PM
  • Finalmente questo problema che mi ossessionava ormai da mesi ha avuto un sbocco positivo.

    Il problema era essenzialmente dovuto ad una errata configurazione degli account utilizzati dal sistema di cache.

    Vi riporto i passi della soluzione:

    - Attivare il log dettagliato

    - Controllare il log e verificare la presenza del seguente errore

    11/09/2011 17:47:08.22 w3wp.exe (0x2328) 0x1FD4 SharePoint Foundation General 8nca Verbose

    Application error when access /Pages/language-redirect.aspx,Error=Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))

    at Microsoft.SharePoint.Library.SPRequest.GetAclForCurrentWeb(StringbstrWebUrl, Boolean fRequirePermissionCheck, Object& pvarRawAcl, UInt64& lAnonymousMask)

    at Microsoft.SharePoint.SPReusableAcl..ctor(SPWeb web, BooleanrequirePermissionCheck)

    at Microsoft.SharePoint.SPWeb.GetReusableAcl(BooleanrequirePermissionCheck)

    at Microsoft.SharePoint.Publishing.AclCache.AddAclIfNecessary(GuidscopeId, SPSecurableObject o)

    at Microsoft.SharePoint.Publishing.CachedArea..ctor(PublishingWeb area,String id, String parentId, CachedUserResource title, String url,CachedUserResource description, CachedObjectFactoryfactory)

    atMicrosoft.SharePoint.Publishing.CachedArea.CreateCachedArea(PublishingWeb area,CachedObjectFactory factory, String parentId)

    atMicrosoft.SharePoint.Publishing.CachedObjectFactory.CreateObject(PublishingWebarea, String parentUrl)

    atMicrosoft.SharePoint.Publishing.PublishingPage.IsPublishingPage(SPListItemsourceListItem)

    atMicrosoft.SharePoint.Publishing.PublishingPage.TryGetPublishingPage(SPListItemsourceListItem)

    at Microsoft.SharePoint.Publishing.CachedObjectFactory.GetPageForCurrentItem()

    atMicrosoft.SharePoint.Publishing.PublishingHttpModule.EnableCachingIfAppropriate(Object source, EventArgs e)

    atSystem.Web.HttpApplication.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()

    at System.Web.HttpApplication.ExecuteStep(IExecutionStep step,Boolean& completedSynchronously)



    - Utilizzare le istruzioni nel seguente articolo per la configurazione degli account utilizzati dal sistema di cache

     http://technet.microsoft.com/en-us/library/ff758656.aspx

    Spero che queste mie indicazioni possano essere di aiuto ad altre persone con lo stesso problema.

    Un saluto

    Martino
    Friday, November 11, 2011 11:15 PM