Esempio di progettazione: siti di collaborazione (SharePoint Foundation 2010)
Si applica a: SharePoint Foundation 2010
Ultima modifica dell'argomento: 2016-11-30
In questo articolo viene descritta l'implementazione pratica dei componenti di un'architettura logica necessari per ottenere una progettazione efficace. Questo articolo è concepito per essere utilizzato insieme agli esempi di progettazione seguenti:
Esempio di progettazione: siti di collaborazione con autenticazione classica
Esempio di progettazione: siti di collaborazione con autenticazione basata sulle attestazioni
Per scaricare uno di questi modelli, vedere Esempi di progettazione di SharePoint Foundation 2010: collaborazione con autenticazione classica o basata sulle attestazioni (https://go.microsoft.com/fwlink/?linkid=219157&clcid=0x410).
Contenuto dell'articolo:
Informazioni sugli esempi di progettazione
Obiettivi generali di progettazione
Server farm
Utenti, aree e autenticazione
Siti di amministrazione
Servizi
Pool di applicazioni
Applicazioni Web
Raccolte siti
Database del contenuto
Aree e URL
Criteri per le aree
I modelli di progettazione mostrano una distribuzione aziendale generica di SharePoint Foundation 2010. Applicano quasi tutti i componenti dell'architettura logica e mostrano l'integrazione di questi componenti nella progettazione generale. Nei due esempi sono illustrati gli stessi servizi e siti, ma con metodi di autenticazione diversi, come descritto di seguito:
Autenticazione classica: questo esempio di progettazione rappresenta un percorso per aggiornare i siti da Windows SharePoint Services 3.0 a SharePoint Foundation 2010 e si basa sull'autenticazione classica, in cui vengono utilizzati i metodi di autenticazione Windows per accedere ai siti. Viene utilizzata un'area diversa per ogni metodo di autenticazione. Per i siti di SharePoint viene utilizzata l'autenticazione di Windows, mentre è possibile configurare un firewall o un gateway allo scopo di utilizzare l'autenticazione basata su moduli per raccogliere le credenziali Windows inoltrate a SharePoint Foundation 2010. Gli account dei dipendenti dei partner vengono aggiunti alla directory aziendale.
Autenticazione basata sulle attestazioni: in questo esempio di progettazione viene incorporato il nuovo modello di autenticazione basata sulle attestazioni, in cui vengono implementati più provider di autenticazione e tipi di autenticazione in un'unica area. L'autenticazione basata sulle attestazioni supporta l'autenticazione basata su moduli, l'autenticazione basata su token SAML e l'autenticazione di Windows. In questo esempio di progettazione le aziende partner vengono aggiunte mediante l'autenticazione basata su token SAML per eseguire l'autenticazione direttamente in base alle directory dei partner. Sono disponibili diverse opzioni di provider per gli account dei dipendenti dei partner.
Utilizzare l'esempio di progettazione che si adatta maggiormente ai requisiti specifici di autenticazione.
In questo articolo sono descritti gli obiettivi di progettazione per gli esempi ed è illustrato come raggiungere tali obiettivi mediante i componenti dell'architettura logica mostrati negli esempi.
Informazioni sugli esempi di progettazione
Negli esempi di progettazione viene illustrata una distribuzione per una società fittizia denominata Fabrikam, Inc. Se si sta pianificando una soluzione con uno o più tipi di siti di collaborazione tra quelli rappresentati in questo modello, è possibile utilizzare il modello come base per la propria progettazione.
Nel modello viene illustrata una distribuzione generica di SharePoint Foundation 2010 e vengono rappresentati i tre tipi di siti di collaborazione seguenti:
Siti del team
Siti in modalità self-service
Siti di collaborazione con partner
Gli esempi di progettazione applicano quasi tutti i componenti dell'architettura logica e mostrano l'integrazione di questi componenti nella progettazione generale. In questo articolo sono descritti gli obiettivi di progettazione per gli esempi e viene illustrato come raggiungere tali obiettivi mediante i componenti dell'architettura logica mostrati nel modello.
Ognuno dei diversi tipi di siti di collaborazione:
Ospita dati con caratteristiche diverse.
È soggetto a un diverso profilo di utilizzo.
Richiede una diversa strategia di gestione delle autorizzazioni.
Di conseguenza, le scelte di progettazione nel modello hanno lo scopo di ottimizzare le prestazioni e la sicurezza di ogni applicazione.
Siti del team
I siti del team rappresentano siti di collaborazione altamente strutturati e gestiti dotati delle caratteristiche seguenti:
Le raccolte siti principali sono presenti in numero inferiore e includono un'elevata quantità di dati rispetto ai siti in modalità self-service.
Gli URL principali sono significativi per ogni team.
Viene conferita maggiore importanza alle gerarchie di siti, alle tassonomie e alle personalizzazioni.
Il contenuto di ogni team è incluso in un database separato e può essere gestito in modo indipendente.
Siti in modalità self-service
I siti in modalità self-service costituiscono un'alternativa a siti del team con gestione avanzata. È possibile consentire agli utenti e ai team di creare le proprie raccolte siti utilizzando Gestione siti in modalità self-service. Questa funzionalità può essere attivata in Amministrazione centrale. Questo metodo è particolarmente indicato se si desidera consentire a gruppi o community di creare siti. Questo metodo è appropriato anche se si ospitano siti e si desidera consentire agli utenti di creare siti senza dover seguire un processo complesso.
Le caratteristiche dei siti in modalità self-service in genere sono diverse rispetto ai siti con gestione avanzata. Tra le caratteristiche di questi siti possono essere incluse le seguenti:
Numero elevato di raccolte siti principali
Quantità ridotta di dati per raccolta siti
URL generati automaticamente, ma in genere non significativi
Quando si implementano siti in modalità self-service, è opportuno tenere conto di alcuni aspetti. Gli svantaggi riportati nell'elenco seguente condizioneranno il modo in cui verranno gestiti i siti in modalità self-service:
Anziché implementare una tassonomia ponderata, i siti vengono creati senza alcun principio organizzativo tra siti. Poiché ogni nuovo sito è una raccolta siti, i modelli e la struttura del sito non possono essere condivisi tra i siti self-service.
Poiché ogni raccolta siti consente di ricercare solo il contenuto incluso nella raccolta siti stessa, non viene eseguita alcuna aggregazione dei risultati di ricerca tra raccolte siti.
Le raccolte siti possono variare in modo significativo per dimensioni e utilizzo.
I siti possono essere abbandonati facilmente.
La gestione dei siti self-service può comportare la gestione dello spazio di archiviazione del contenuto in base alle dimensioni di destinazione dei database del contenuto e l'eliminazione a intervalli regolari dei siti che non vengono più utilizzati.
Per ulteriori informazioni su come implementare Gestione siti in modalità self-service, vedere Turn on or turn off self-service site creation (SharePoint Foundation 2010).
Siti di collaborazione con partner
L'applicazione Web del partner ospita i siti disponibili esternamente per garantire una collaborazione sicura con le società partner e i singoli partner. Questa applicazione è concepita per consentire ai dipendenti di creare facilmente siti per una collaborazione sicura. I partner non sono in grado di accedere ad altri tipi di contenuto ospitati nella server farm. La progettazione per le aree e le applicazioni di servizio mira a raggiungere questo obiettivo. I proprietari dei singoli siti inoltre gestiscono le autorizzazioni per i propri siti, invitando a collaborare solo i partecipanti necessari.
Obiettivi generali di progettazione
Nel modello viene illustrata un'implementazione pratica di funzionalità di SharePoint Foundation 2010 con diversi tipi di applicazioni di collaborazione (siti del team, siti in modalità self-service e siti di partner). In questo articolo vengono illustrate le implementazioni della progettazione per ogni applicazione di sito. Tra gli obiettivi di progettazione principali del modello sono inclusi i seguenti:
Creazione di un framework per progettare un ambiente con potenziale di crescita. Le scelte di progettazione per una specifica applicazione di collaborazione non impediscono l'aggiunta di altre applicazioni. Ad esempio, una distribuzione iniziale può includere solo i siti del team di collaborazione o solo i siti dei partner. Utilizzando una progettazione dell'architettura logica di questo tipo è possibile aggiungere gli altri tipi di siti di collaborazione alla soluzione senza influire sulla progettazione dei siti di collaborazione iniziali. In altri termini, la progettazione non incorpora scelte che limitano l'utilizzo dell'ambiente.
Concessione dell'accesso a classi diverse di utenti senza compromettere la sicurezza del contenuto nelle diverse applicazioni di collaborazione. Possono partecipare alla collaborazione utenti di diverse aree della rete (sia interni che esterni) e diversi provider di autenticazione. Gli utenti possono tuttavia accedere solo al contenuto che li riguarda. Mediante questo tipo di progettazione dell'architettura logica è possibile offrire l'accesso agli utenti in più posizioni e con obiettivi diversi. Ad esempio, la progettazione iniziale può essere intesa solo per l'accesso dei dipendenti interni. In questo modo tuttavia è possibile consentire l'accesso anche ai dipendenti remoti, ai dipendenti dei partner o addirittura ai clienti.
Verifica della possibilità di utilizzare la progettazione in un ambiente Extranet. È possibile effettuare scelte di progettazione deliberate affinché le server farm vengano distribuite in modo sicuro in una rete perimetrale o in una delle topologie Extranet.
Nella parte restante di questo articolo vengono descritti i singoli componenti logici che sono presenti nel modello (dall'alto verso il basso) e vengono esaminate le scelte di progettazione applicate al modello. Lo scopo di questo approccio è dimostrare i diversi modi in cui è possibile configurare i componenti dell'architettura logica in base all'applicazione.
Server farm
Nel modello viene mostrata una farm a cinque server. È comunque possibile implementare il modello in farm di qualsiasi dimensione, inclusa una farm a server singolo. La server farm del modello è costituita da cinque server con la topologia seguente:
Due server Web front-end
Un server applicazioni per il server di ricerca e per le applicazioni di servizio (facoltativo)
Due server di database, in cluster o con mirroring
Nel modello viene illustrata l'architettura logica di SharePoint Foundation 2010 con le operazioni seguenti:
Viene eseguito il mirroring di tutti i siti nei server Web front-end.
Il sito Web Amministrazione centrale viene installato in un server applicazioni per proteggerlo dall'accesso diretto degli utenti.
In realtà, il numero di computer server e la topologia della server farm non sono importanti per l'architettura logica, tranne che per incrementare la capacità e le prestazioni in base alle esigenze. L'architettura logica può essere progettata in modo indipendente dalla topologia della server farm. Il processo di pianificazione delle prestazioni e della capacità consentiranno di definire le dimensioni della server farm in relazione agli obiettivi di prestazioni e capacità. Per ulteriori informazioni, vedere Risultati dei test delle prestazioni e della capacità e suggerimenti (SharePoint Foundation 2010).
Utenti, aree e autenticazione
Quando si crea un'applicazione Web in SharePoint Foundation 2010, è necessario selezionare l'autenticazione basata sulle attestazioni o l'autenticazione classica. La modalità di autenticazione determina il modo in cui gli account vengono utilizzati internamente da SharePoint Foundation 2010. Nella tabella seguente vengono riepilogati questi due approcci.
Tipo di autenticazione |
Descrizione |
Suggerimenti |
Autenticazione in modalità classica |
Gli account utente vengono considerati da SharePoint Foundation 2010 come normali account di Servizi di dominio Active Directory. Sono supportati i protocolli di autenticazione seguenti: Kerberos, NTLM, di base, digest e anonimo. L'autenticazione basata su moduli non è supportata. In un'area è possibile configurare un solo metodo di autenticazione. |
La modalità classica è consigliata per gli ambienti di aggiornamento da Windows SharePoint Services 3.0, nei quali l'autenticazione basata su moduli non rappresenta un requisito. Qualora si esegua l'aggiornamento, non è necessario eseguire la migrazione degli utenti se si utilizza l'autenticazione classica. |
Autenticazione basata sulle attestazioni |
Gli account utente vengono considerati da SharePoint Foundation 2010 come identità basate sulle attestazioni. Gli account Windows vengono convertiti automaticamente in identità basate sulle attestazioni. Questa modalità supporta anche l'autenticazione basata su form e l'autenticazione con un provider di identità attendibile. Possono essere configurati più tipi di autenticazione in un'unica area. |
L'autenticazione basata su attestazioni è consigliata per le nuove distribuzioni di SharePoint Foundation 2010 ed è necessaria per aggiornare le soluzioni Windows SharePoint Services 3.0 che richiedono l'autenticazione basata su form. |
I due esempi di progettazione esaminati in questo articolo rappresentano queste due opzioni. Nelle sezioni seguenti viene esaminato nello specifico come l'autenticazione viene incorporata nei due esempi di progettazione.
Esempio di progettazione basato sull'autenticazione classica
L'esempio di progettazione in cui è utilizzata l'autenticazione classica incorpora l'approccio tradizionale "un'area per tipo" utilizzato nella versione precedente. Per questo motivo, in questo esempio è incluso un percorso per l'aggiornamento da Windows SharePoint Services 3.0 a SharePoint Foundation 2010.
L'unico problema è che l'autenticazione basata su moduli non è supportata nella modalità classica, poiché in questa modalità tutti gli account autenticati devono trovarsi in Servizi di dominio Active Directory. È consigliabile che gli utenti che accedono in remoto ai siti utilizzino l'autenticazione basata su moduli nel firewall o nel gateway per recuperare le credenziali Windows inoltrate alla farm di SharePoint.
Nell'esempio basato sulla modalità classica sono illustrate tre classi diverse di utenti, ognuna assegnata a un'area diversa. All'interno di ogni applicazione Web è possibile creare fino a cinque aree che utilizzano uno dei nomi di area disponibili, ovvero Predefinita, Intranet, Internet, Personalizzata o Extranet.
Nella tabella seguente sono mostrati gli utenti, le aree e i tipi di autenticazione richiesti dall'esempio di progettazione basato sulla modalità classica.
| Area | Utenti | Autenticazione |
|---|---|---|
Intranet |
Dipendenti interni |
NTLM o Kerberos |
Predefinita |
Dipendenti remoti |
NTLM o Kerberos (con l'autenticazione basata su moduli nel firewall o nel gateway per la raccolta e l'inoltro delle credenziali) |
Extranet |
Singoli partner |
NTLM o Kerberos (con l'autenticazione basata su moduli nel firewall o nel gateway per la raccolta e l'inoltro delle credenziali) |
Esempio di progettazione con autenticazione basata sulle attestazioni
L'autenticazione basata sulle attestazioni è consigliata per tutte le nuove distribuzioni di SharePoint Foundation 2010 ed è necessaria per aggiornare le soluzioni Windows SharePoint Services 3.0 che richiedono l'autenticazione basata su moduli. Oltre ai metodi di autenticazione Windows standard, l'autenticazione basata sulle attestazioni consente di eseguire l'autenticazione in relazione ad altre directory, come Windows Live ID, Active Directory Federation Services (ADFS) 2.0 o un provider di identità di terze parti che supporta i token SAML e il protocollo WS Federation.
Nell'esempio di progettazione con autenticazione basata sulle attestazioni questa modalità di autenticazione viene utilizzata nella farm di collaborazione e consente l'utilizzo di più tipi di autenticazione nella stessa area. Nell'esempio di progettazione viene utilizzata l'area Predefinita per tutti i tipi di autenticazione. Nella tabella seguente sono mostrati gli utenti, le aree e i tipi di autenticazione richiesti dall'esempio per la farm di collaborazione.
| Area | Utenti | Autenticazione |
|---|---|---|
Intranet |
Dipendenti interni e remoti |
Servizi di dominio Active Directory (oppure archivio LDAP con autenticazione basata su moduli o autenticazione SAML) |
Predefinita |
Singoli partner |
Windows Live con autenticazione SAML oppure database di SQL Server con autenticazione basata su moduli |
Extranet |
Società partner |
Provider di identità di partner attendibile con autenticazione SAML |
Nell'esempio di progettazione i siti del team e i siti in modalità self-service sono disponibili solo per i dipendenti interni o esterni alla rete. Nell'esempio di progettazione viene implemento per ognuno di questi siti un solo URL (basato su SSL) che può essere utilizzato sia internamente che esternamente. Vengono utilizzati gli account di Servizi di dominio Active Directory. Se necessario, è possibile utilizzare LDAP con l'autenticazione basata su moduli o con SAML, che richiede operazioni di configurazione aggiuntive.
Nell'esempio di progettazione l'applicazione Web del partner rappresenta un sito Extranet disponibile per i dipendenti dei partner e le società partner. Per utilizzare l'autenticazione basata sulle attestazioni in questo scenario, è necessario configurare una relazione di trust per l'utilizzo di uno o più servizi token di sicurezza (STS) esterni. A tale scopo, è possibile utilizzare uno degli approcci seguenti:
La farm di SharePoint può essere configurata per considerare attendibile un servizio STS esterno, ad esempio il servizio STS associato a Windows Live (per l'autenticazione di singoli partner) o quello in uso in una società partner (per l'autenticazione diretta in base alla directory del partner).
Il servizio STS all'interno dell'ambiente aziendale può essere configurato per considerare attendibile un servizio STS esterno. Questa relazione deve essere stabilita in modo esplicito dagli amministratori delle due organizzazioni. In questo scenario la farm di SharePoint viene configurata per considerare attendibile solo il servizio STS in uso nel rispettivo ambiente aziendale. Questo servizio STS interno verifica il token che riceve dal servizio STS esterno e quindi genera un token che consente all'utente partner di accedere alla farm di SharePoint farm. Questo è l'approccio consigliato.
Un'alternativa all'implementazione di un ambiente basato sulle attestazioni per autenticare i partner consiste nell'utilizzare l'autenticazione basata su moduli e gestire tali account mediante un archivio separato, ad esempio un database.
Per ulteriori informazioni su come implementare un ambiente con autenticazione basata sulle attestazioni, vedere il white paper seguente: Identità basata sulle attestazioni per Windows: introduzione ad Active Directory Federation Services 2.0, Windows CardSpace 2.0 e Windows Identity Foundation (https://go.microsoft.com/fwlink/?linkid=196776&clcid=0x410).
Aree
Per la progettazione delle aree, l'esito della distribuzione è determinato da alcune decisioni chiave, tra cui le scelte effettuate per la progettazione e la configurazione delle aree seguenti:
Area Predefinita
Aree per l'accesso esterno
Nelle sezioni seguenti vengono descritte le decisioni incorporate nel modello.
Requisiti di configurazione dell'area Predefinita
L'area Predefinita richiede l'attenzione maggiore. In SharePoint Foundation 2010 sono previsti i requisiti seguenti per la configurazione dell'area Predefinita:
Quando la richiesta di un utente non può essere associata a un'area vengono applicati l'autenticazione e i criteri di tale area. Di conseguenza, l'area predefinita deve essere la più sicura.
Poiché vengono inviati messaggi di posta elettronica amministrativi con collegamenti all'area Predefinita, ad esempio messaggi di posta elettronica per i proprietari di siti che stanno raggiungendo i limiti di quota, gli utenti che ricevono questo tipo di messaggi e di avvisi devono essere in grado di accedere ai collegamenti tramite l'area Predefinita. Questo è particolarmente importante per i proprietari di siti.
Le raccolte siti con nome basato sull'host sono disponibili solo tramite l'area Predefinita. Per accedere alle raccolte siti con nome basato sull'host, gli utenti devono utilizzare l'area Predefinita.
Configurazione di aree per un ambiente Extranet
In un ambiente Extranet la progettazione delle aree è molto importante per i due motivi seguenti:
Le richieste degli utenti possono essere avviate da numerose reti diverse. Nel modello ad esempio gli utenti avviano le richieste dalla rete interna, da Internet e dalle società partner.
Gli utenti possono collaborare utilizzando più applicazioni Web. I dipendenti interni ed esterni ad esempio possono fornire e amministrare contenuto in tutte le applicazioni Web: siti del team, siti in modalità self-service e siti Web di partner.
In un ambiente Extranet verificare che vengano seguiti i principi di progettazione seguenti:
Configurare le aree in più applicazioni Web in modo che venga eseguito il mirroring reciproco. La configurazione dell'autenticazione e gli utenti previsti devono corrispondere. I criteri associati alle aree possono tuttavia differire tra le applicazioni Web. Assicurarsi ad esempio che l'area Intranet venga utilizzata per le stesse classi di dipendenti in tutte le applicazioni Web. In altri termini, non configurare l'area Intranet per i dipendenti interni in un'applicazione Web e per i dipendenti remoti in un'altra.
Configurare i mapping di accesso alternativo in modo corretto e accurato per ogni area e risorsa.
Negli esempi di progettazione l'area Predefinita di ogni applicazione Web viene configurata in modo identico. Le altre aree inoltre vengono configurate in modo identico in tutte le applicazioni Web a seconda delle esigenze.
I mapping di accesso alternativo vengono creati automaticamente quando si crea l'area. Se tuttavia si utilizza un server proxy o un gateway per rendere i siti disponibili da Internet, sarà necessario aggiungere un'ulteriore voce di mapping di accesso alternativo per ogni area. In questo modo, gli URL restituiti agli utenti all'esterno della rete interna saranno disponibili per gli utenti in base al contesto della relativa area.
Se non si esegue il mirroring tra le aree delle applicazioni Web e i collegamenti alle risorse esterne non sono corretti, si è esposti ai rischi seguenti:
I nomi dei server, i nomi DNS e gli indirizzi IP possono essere esposti all'esterno della rete interna.
Gli utenti potrebbero non essere in grado di accedere ai siti Web e ad altre risorse.
Siti di amministrazione
Nel modello il sito Amministrazione centrale è ospitato nel server applicazioni. In questo modo il sito viene protetto dal contatto diretto degli utenti. Se un collo di bottiglia delle prestazioni o un problema di sicurezza influisce sulla disponibilità dei server Web front-end, il sito Amministrazione centrale continuerà a essere disponibile. Il sito Amministrazione centrale inoltre è ospitato all'interno di un pool di applicazioni dedicato e di un'applicazione Web.
Gli URL con bilanciamento del carico per i siti di amministrazione non sono menzionati nel modello o in questo articolo. Tra le procedure consigliate sono incluse le seguenti:
Se negli URL amministrativi vengono utilizzati i numeri di porta, è consigliabile utilizzare porte non standard. I numeri di porta sono inclusi negli URL per impostazione predefinita. Benché i numeri di porta in genere non vengano utilizzati negli URL pubblici, l'utilizzo dei numeri di porta per i siti di amministrazione può aumentare il livello di sicurezza limitando l'accesso a tali siti alle porte non standard.
Creare voci DNS separate per i siti di amministrazione.
Servizi
L'architettura dei servizi illustrata nel modello rappresenta solo le due applicazioni di servizio incluse con SharePoint Foundation 2010. I due gruppi di servizi (rappresentati con un riquadro rosso e un riquadro tratteggiato in blu) non sono necessari nell'esempio fornito poiché includono le stesse due applicazioni di servizio. Valutare tuttavia quali applicazioni di servizio sono necessarie per i siti Web dei partner e configurare i due gruppi di servizi in base a tali considerazioni. Di seguito sono elencate le opzioni da considerare:
Valutare se è necessaria un'istanza separata dell'applicazione servizio di integrazione applicativa dei dati per i siti Web dei partner. Qualora sia necessaria, valutare la possibilità di distribuire questa applicazione di servizio per i siti dei partner in modalità partizionata. In questo modo i partner non avranno accesso ai dati nei siti dei partner.
È possibile che società di terze parti sviluppino applicazioni di servizio per SharePoint Foundation 2010. Se si utilizzano queste applicazioni, decidere se è opportuno utilizzarle in tutti i siti.
Pool di applicazioni
Vengono in genere implementati pool di applicazioni di Internet Information Services (IIS) separati in modo da garantire l'isolamento dei processi tra i siti. I pool di applicazioni consentono di eseguire più siti nello stesso computer server, mantenendo tuttavia i relativi processi di lavoro e identità. In questo modo è possibile ridurre il rischio che si verifichino problemi di sicurezza nel sito e che un utente malintenzionato possa aggiungere codice nel server per attaccare altri siti.
In termini pratici, prendere in considerazione l'utilizzo di un pool di applicazioni dedicato per gli scenari seguenti:
Separazione del contenuto autenticato dal contenuto anonimo.
Isolamento dei siti utilizzati principalmente per la collaborazione con clienti o partner esterni. In questo modo si isolano gli account esterni nei siti con un pool di applicazioni.
Isolamento dei siti in cui gli utenti dispongono di una maggiore libertà di creare e amministrare i siti nonché di collaborare al contenuto.
Nel modello i pool di applicazioni vengono utilizzati come segue:
Il sito di amministrazione è ospitato in un pool di applicazioni dedicato. Questo è un requisito di SharePoint Foundation 2010.
Tutte le applicazioni di servizio vengono distribuite in un singolo pool di applicazioni. Questa è la configurazione consigliata, a meno che non esista un valido motivo per distribuire le applicazioni di servizio in pool di applicazioni diversi. L'utilizzo di un pool di applicazioni per tutte le applicazioni di servizio consente di ottimizzare le prestazioni e ridurre il numero di pool di applicazioni da gestire.
I siti di collaborazione interna (siti del team e siti in modalità self-service) sono ospitati in un pool di applicazioni.
L'applicazione Web del partner è ospitata in un pool di applicazioni dedicato.
Applicazioni Web
Un'applicazione Web è un sito Web di IIS creato e utilizzato da Prodotti SharePoint 2010. Ogni applicazione Web è rappresentata da un sito Web diverso in IIS. A ogni applicazione Web viene assegnato un nome di dominio univoco per prevenire il rischio di attacchi di cross-site scripting (XSS).
È consigliabile in genere utilizzare applicazioni Web dedicate per eseguire le operazioni seguenti:
Separare il contenuto anonimo da quello autenticato.
Isolare gli utenti Nel modello il sito Web del partner è ospitato in un'applicazione Web e in un pool di applicazioni dedicati per garantire che i partner non abbiano accesso al contenuto di collaborazione interna.
Applicare le autorizzazioni Un'applicazione Web dedicata offre l'opportunità di applicare le autorizzazioni utilizzando la pagina Criteri per l'applicazione Web in Amministrazione centrale. È ad esempio possibile creare nei siti di collaborazione interna un criterio per negare in modo esplicito l'accesso agli account dei partner. I criteri per un'applicazione Web vengono applicati indipendentemente dalle autorizzazioni configurate nei singoli siti o documenti all'interno dell'applicazione Web.
Ottimizzare le prestazioni I siti offrono prestazioni migliori se vengono inseriti in applicazioni Web con altre applicazioni con caratteristiche dei dati simili. Ad esempio, le caratteristiche dei dati dei siti in modalità self-service includono in genere un numero elevato di siti di dimensioni contenute. Al contrario, i siti del team includono in genere un numero limitato di siti di dimensioni molto grandi. Se questi due tipi di siti vengono inseriti in applicazioni Web distinte, i database risultanti saranno composti da dati con caratteristiche simili, con conseguente ottimizzazione delle prestazioni dei database. Nel modello i siti del team e quelli in modalità self-service non presentano requisiti univoci di isolamento dei dati, bensì condividono lo stesso pool di applicazioni. Ciononostante, i siti del team e quelli in modalità self-service vengono posizionati in applicazioni Web separate per ottimizzare le prestazioni.
Ottimizzare la gestibilità Poiché la creazione di applicazioni Web separate determina la creazione di siti e database distinti, è possibile implementare limiti diversi per il sito (Cestino, scadenza e dimensioni) e negoziare contratti di servizio differenti. È ad esempio possibile concedere più tempo per ripristinare i siti in modalità self-service se non includono il tipo di contenuto più importante nell'organizzazione. In questo modo è possibile ripristinare il contenuto più importante prima di ripristinare questi siti. Nel modello i siti in modalità self-service sono posizionati in un'applicazione Web separata per consentire agli amministratori di gestire la crescita in modo più accurato rispetto alle altre applicazioni.
Raccolte siti
Le raccolte siti rappresentano il collegamento tra l'architettura logica e l'architettura delle informazioni. Gli obiettivi di progettazione per le raccolte siti nel modello consistono nel soddisfare i requisiti della progettazione dell'URL e nel creare divisioni logiche di contenuto.
Per soddisfare i requisiti della progettazione dell'URL, ogni applicazione Web include una singola raccolta siti a livello della radice. I percorsi gestiti vengono utilizzati per incorporare un secondo livello di raccolte siti principali. Per ulteriori informazioni sui requisiti per gli URL e l'utilizzo dei percorsi gestiti, vedere Aree e URL più avanti in questo articolo. Oltre il secondo livello di raccolte siti, ogni sito è un sito secondario.
Nella figura seguente viene illustrata la gerarchia dei siti del team.
.gif "Siti del team")
Poiché è richiesta una raccolta siti a livello della radice, le scelte di progettazione ruotano intorno al secondo livello delle raccolte siti. Nel modello sono incorporate scelte basate sulla natura dell'applicazione.
Siti in modalità self-service
Nel modello i siti in modalità self-service includono un sito principale il cui URL è http://siti. Viene incorporato tramite inclusione di caratteri jolly un percorso gestito, che accetta un numero illimitato di siti creati dagli utenti. Tutti i siti nel percorso gestito sono raccolte siti indipendenti che ereditano il modello di sito utilizzato per la creazione del sito principale.
Per ulteriori informazioni sui siti in modalità self-service, vedere Pianificare il processo per la creazione di siti (SharePoint Foundation 2010).
Siti del team
Quando si progettano raccolte siti in un'applicazione sito del team, è consigliabile creare un numero limitato di raccolte siti per l'organizzazione in base alle modalità operative dell'organizzazione. In questo approccio le raccolte siti vengono create da un amministratore di SharePoint Foundation 2010. Dopo la creazione della raccolta siti, i team possono creare siti al suo interno in base alle diverse esigenze.
Questo approccio offre l'opportunità di implementare una tassonomia ponderata che costituisce la base per la gestione e la crescita dei siti dei team. Vengono create inoltre più opportunità di condividere modelli e strutture del sito tra i progetti e i team che condividono una raccolta siti. La difficoltà principale per gli architetti informatici consiste nel creare un secondo livello di raccolte siti che sia appropriato all'organizzazione. Nella tabella seguente sono elencati alcuni suggerimenti per i diversi tipi di organizzazioni.
| Tipo di organizzazione | Tassonomie consigliate per le raccolte siti |
|---|---|
Sviluppo prodotti |
|
Ricerca |
|
Istituto di istruzione superiore |
|
Ufficio legislativo statale |
|
Ufficio legale aziendale |
|
Produzione |
|
Sito Web del partner
L'applicazione Web del partner è destinata alla collaborazione con i partner esterni su progetti con ambiti o durata definita. Da progettazione, i siti nell'applicazione Web del partner non sono concepiti per essere correlati. I requisiti per l'applicazione Web del partner includono la verifica degli aspetti seguenti:
I proprietari dei progetti devono poter creare facilmente i siti per la collaborazione con i partner.
I partner e gli altri collaboratori devono poter accedere solo ai progetti a cui sono assegnati.
Le autorizzazioni devono essere gestite dai proprietari dei siti.
I risultati delle ricerche di un progetto non devono esporre contenuto di altri progetti.
Gli amministratori devono poter identificare ed eliminare agevolmente i siti che non vengono più utilizzati.
Per soddisfare questi requisiti, nel modello è incorporata una raccolta siti per ogni progetto, in modo da usufruire dei vantaggi seguenti:
Singole raccolte siti garantiscono il livello appropriato di isolamento tra i progetti.
È possibile implementare la creazione di siti in modalità self-service.
Database del contenuto
È possibile utilizzare due approcci per incorporare i database del contenuto nella progettazione. Nel modello sono incorporati entrambi gli approcci seguenti:
Stabilire le dimensioni di destinazione per i database del contenuto con valori di soglia degli avvisi per le dimensioni appropriati. Creare un nuovo database quando si raggiungono i valori di soglia degli avvisi per le dimensioni. Se si utilizza questo approccio, le raccolte siti vengono aggiunte automaticamente al database o ai database disponibili esclusivamente in base alle dimensioni di destinazione.
Associare raccolte siti a database del contenuto specifici. Questo approccio consente di inserire una o più raccolte siti in un database dedicato che può essere gestito in modo indipendente dagli altri.
Se si decide di associare le raccolte siti a database del contenuto specifici, è possibile utilizzare i metodi indicati di seguito per eseguire le operazioni seguenti:
Utilizzare Windows PowerShell per creare una raccolta siti in un database specifico.
Dedicare un database a una singola raccolta siti applicando le impostazioni di capacità del database seguenti:
Numero di siti consentiti prima della generazione di un avviso = 1
Numero massimo di siti che è possibile creare nel database = 1
Aggiungere un gruppo di raccolte siti a un database dedicato eseguendo i passaggi seguenti:
Nell'applicazione Web creare il database e impostarne lo stato su Pronto.
Impostare lo stato di tutti gli altri database su Offline. Mentre i database del contenuto sono offline, non è possibile creare nuove raccolte siti. Le raccolte siti esistenti nei database offline sono tuttavia disponibili per le operazioni sia di lettura che di scrittura.
Creare le raccolte siti. Verranno aggiunte automaticamente al database.
Reimpostare lo stato di tutti gli altri database su Pronto.
Siti del team
Nell'esempio di progettazione è incorporato un database dedicato per ogni raccolta siti del team. Questo approccio consente di gestire il database di ogni team in modo indipendente per il backup, il ripristino e la migrazione. Quando un progetto è completo, è inoltre possibile archiviare facilmente il database a esso associato. Nell'esempio di progettazione sono incluse impostazioni dei database basate su un limite di 30 GB per le raccolte siti. Scegliere un limite appropriato ai siti dei team nell'organizzazione.
Siti in modalità self-service
Nel caso dei siti in modalità self-service, nel modello vengono gestiti i database fino alle dimensioni di destinazione massime per ottenere efficienza a livello di scalabilità. Vengono configurate le impostazioni seguenti per raggiungere questo obiettivo:
Dimensioni massime spazio di archiviazione del sito: questa impostazione, che può essere configurata nella pagina Modelli quote di Amministrazione centrale, limita le dimensioni di un sito.
Cestino secondario: questa impostazione, che può essere configurata nella pagina Impostazioni generali applicazione Web, determina quanto spazio aggiuntivo viene allocato al Cestino secondario.
Numero massimo di siti che è possibile creare nel database: questa impostazione viene configurata quando si crea un database. Calcolare le dimensioni totali consentite dei siti utilizzando i numeri specificati per i precedenti due valori. Determinare quindi quanti siti possono essere inclusi nel database, in base all'obiettivo in termini di dimensioni per ogni database.
Nell'esempio di progettazione sono descritte le impostazioni di esempio seguenti delle dimensioni, basate sulla dimensione di destinazione del database di 175 GB e sulla dimensione del sito personale di destinazione di 1 GB:
Limite dimensioni per sito = 1 GB
Dimensioni di destinazione del database = 175 GB
Riservato per il Cestino secondario = 15%
Numero massimo di siti = 180
Avviso numero siti = 150
Quando si raggiunge il livello di avviso per il numero di siti, creare un nuovo database. Dopo aver creato il nuovo database, i nuovi siti in modalità self-service vengono aggiunti in modo alternato nel nuovo database e in quello esistente fino a raggiungere il numero massimo di siti per uno dei database.
Sito Web del partner
Analogamente ai siti self-service, per ottenere efficienza a livello di scalabilità nel sito Web del partner vengono gestiti i database fino alle dimensioni di destinazione massime.
Poiché il sito Web del partner è ospitato in un'applicazione Web dedicata, è possibile creare limiti delle dimensioni appropriati per i tipi di siti creati. Nell'esempio di progettazione sono descritte le seguenti impostazioni di esempio delle dimensioni:
Dimensioni di destinazione del database = 200 GB
Quota di archiviazione per sito = 5 GB
Numero massimo di siti = 40
Aree e URL
Nel modello viene illustrato come coordinare gli URL tra più applicazioni in una distribuzione aziendale.
Obiettivi della progettazione
Gli obiettivi seguenti determinano le scelte di progettazione per gli URL:
Le convenzioni degli URL non limitano le aree attraverso le quali è possibile accedere al contenuto.
Le porte HTTP e HTTPS standard (80 e 443) possono essere utilizzate in tutte le applicazioni dell'esempio di progettazione.
I numeri di porta non sono inclusi negli URL. In effetti, i numeri di porta non vengono quasi mai utilizzati negli ambienti di produzione.
Principi della progettazione
Per raggiungere questi obiettivi di progettazione vengono applicati i principi seguenti:
Le raccolte siti con nome basato sull'host non vengono utilizzate. Tali raccolte siti sono diverse dalle intestazioni host IIS e non supportano la caratteristica di mapping di accesso alternativo. Tale caratteristica è necessaria per accedere allo stesso contenuto mediante più URL di dominio. Di conseguenza, se si utilizzano raccolte siti con nome basato sull'host, tali siti sono disponibili solo tramite l'area Predefinita.
Ogni applicazione incorpora una singola raccolta siti radice. Questo è un requisito per l'utilizzo dei mapping di accesso alternativo. Se sono necessarie più raccolte siti radice in un'applicazione Web e si prevede di utilizzare solo l'area Predefinita per l'accesso utente, le raccolte siti con nome basato sull'host rappresentano un'opzione valida.
Per le applicazioni che includono più raccolte siti principali, in cui ogni raccolta siti rappresenta un team o un progetto principale (ad esempio i siti del team), il modello incorpora i percorsi gestiti, che garantiscono un controllo maggiore sugli URL per questi tipi di siti.
Svantaggi della progettazione
Il raggiungimento degli obiettivi di progettazione comporta alcuni svantaggi, tra cui:
Gli URL sono più lunghi.
Le raccolte siti con nome basato sull'host non vengono utilizzate.
Progettazione di URL con bilanciamento del carico
Quando si crea un'applicazione Web, è necessario selezionare un URL con bilanciamento del carico da assegnare all'applicazione, nonché creare un URL con bilanciamento del carico per ogni area creata in un'applicazione Web. L'URL con bilanciamento del carico include il protocollo, lo schema, il nome host e la porta e deve essere univoco tra tutte le applicazioni Web e le aree. Di conseguenza, ogni applicazione e ogni area all'interno delle singole applicazioni richiede un URL univoco per tutto l'esempio di progettazione.
Siti di collaborazione interna
I due tipi di siti di collaborazione interna richiedono ognuno un URL univoco. Nell'esempio di progettazione il gruppo di destinazione del contenuto dell'Intranet è costituito dai dipendenti interni e da quelli remoti. Nell'esempio di progettazione con autenticazione basata sulle attestazioni i dipendenti utilizzano gli stessi URL per ognuna di queste applicazioni, indipendentemente dal fatto che si trovino nel sito o in remoto. Sebbene questo approccio aggiunga un livello di sicurezza alla progettazione (tutto il traffico è basato su SSL), richiede anche la distribuzione del traffico interno attraverso il firewall o il gateway insieme al traffico remoto oppure l'impostazione di un ambiente DNS diviso per risolvere le richieste interne generate nella rete interna.
Per l'esempio di progettazione con autenticazione classica gli URL sono diversi per i dipendenti interni e per quelli remoti. Nella tabella seguente vengono mostrati gli URL che gli utenti interni e quelli remoti devono utilizzare per accedere a ogni applicazione nell'esempio di progettazione con autenticazione classica.
| Applicazione | URL dipendente interno | URL dipendente remoto |
|---|---|---|
Siti del team |
http://team |
https://team.fabrikam.com |
Siti in modalità self-service |
http://siti |
https://siti.fabrikam.com |
Sito Web del partner
Nell'esempio di progettazione al sito Web del partner accedono dipendenti interni, dipendenti remoti e dipendenti dei partner. Nell'esempio di progettazione con autenticazione basata sulle attestazioni ogni utente immette lo stesso URL, indipendentemente dal metodo di autenticazione. Nell'esempio di progettazione con autenticazione classica ogni diverso tipo di utente immette un URL diverso. Sebbene sia i dipendenti remoti che i dipendenti del partner accedano al sito Web del partner dall'esterno utilizzando SSL (HTTPS), ogni gruppo deve disporre di un URL diverso per ottenere i vantaggi derivanti dall'utilizzo di aree separate, ovvero metodi di autenticazione e criteri delle aree diversi. Nella tabella seguente vengono mostrati gli URL che i dipendenti interni, quelli remoti e i partner utilizzano per accedere al sito Web del partner, come mostrato nell'esempio di progettazione con autenticazione classica.
| Area | URL |
|---|---|
URL dipendente interno |
http://sitoWebpartner |
URL dipendente remoto |
https://sitoWebpartnerremoto.fabrikam.com |
URL partner |
https://sitoWebpartner.fabrikam.com |
Utilizzo di inclusioni esplicite e di caratteri jolly per i percorsi URL
Mediante la definizione di percorsi gestiti è possibile specificare quali percorsi nello spazio dei nomi URL di un'applicazione Web utilizzare per le raccolte siti. È possibile specificare che deve esistere una raccolta siti o più raccolte siti in corrispondenza di un percorso distinto sotto il sito radice. Senza percorsi gestiti, tutti i siti creati sotto la raccolta siti radice fanno parte di tale raccolta.
È possibile creare i due tipi di percorsi gestiti seguenti:
Inclusione esplicita Raccolta siti con l'URL esplicito assegnato. Un'inclusione esplicita viene applicata a un'unica raccolta siti. È possibile creare più inclusioni esplicite in una raccolta siti radice. Un esempio di URL per una raccolta siti creata tramite questo metodo è http://team/team1. Per ogni percorso esplicito aggiunto si verifica un impatto sulle prestazioni, pertanto è consigliabile non creare più di 20 raccolte siti con un'inclusione esplicita.
Inclusione di caratteri jolly Percorso aggiunto all'URL. Tale percorso indica che tutti i siti specificati direttamente dopo il nome del percorso sono raccolte siti univoche. Questa opzione in genere viene utilizzata per le applicazioni che supportano la creazione di siti in modalità self-service. Un esempio di URL per una raccolta siti creata tramite questo metodo è http://siti/selfservice/sito1.
Nell'esempio di progettazione è mostrato l'utilizzo di entrambi i tipi, come descritto nelle sezioni seguenti.
Inclusioni esplicite
Nell'esempio di progettazione non è attualmente incorporato l'utilizzo di inclusioni esplicite. Nella tabella seguente viene fornita una serie di esempi di URL per un sito Intranet di Fabrikam basato sull'autenticazione classica, in cui vengono utilizzati URL diversi per l'accesso interno e per l'accesso remoto dei dipendenti.
| Dipendente interno (area Intranet) | Dipendente remoto (area Predefinita) |
|---|---|
http://fabrikam |
https://intranet.fabrikam.com |
http://fabrikam/risorseumane |
https://intranet.fabrikam.com/risorseumane |
http://fabrikam/strutture |
https://intranet.fabrikam.com/strutture |
http://fabrikam/acquisti |
https://intranet.fabrikam.com/acquisti |
In questo esempio la raccolta siti radice, http://fabrikam, rappresenta la home page predefinita per l'Intranet. Questo sito può ospitare il contenuto per gli utenti. Il sito successivo nel percorso, ad esempio http://fabrikam/risorse umane e http://fabrikam/strutture, rappresenta l'inclusione esplicita.
Inclusioni di caratteri jolly: siti del team, siti in modalità self-service e applicazione Web del partner
I siti del team, i siti in modalità self-service e l'applicazione Web del partner incorporano l'utilizzo di un'inclusione di caratteri jolly. Questo tipo di inclusioni è ideale per le applicazioni che consentono agli utenti di creare raccolte siti personali e per le applicazioni Web che includono numerose raccolte siti. Un'inclusione di caratteri jolly indica che l'elemento dopo il carattere jolly è un sito radice di una raccolta siti.
Siti del team
Nell'ambito dell'applicazione siti del team l'inclusione di caratteri jolly viene utilizzata per ogni raccolta siti del team. È consigliabile limitare il numero di siti del team principali entro una soglia gestibile. Inoltre, la tassonomia per i siti del team deve essere logica per le modalità operative dell'azienda.
Nel modello di progettazione con autenticazione classica l'utilizzo delle inclusioni di caratteri jolly determina l'implementazione degli URL illustrati nella tabella seguente.
| Dipendente interno (area Intranet) | Dipendente remoto (area Predefinita) |
|---|---|
http://team/siti/team1 |
https://team.fabrikam.com/siti/team1 |
http://team/siti/team2 |
https://team.fabrikam.com/siti/team2 |
http://team/siti/team3 |
https://team.fabrikam.com/siti/team3 |
In questo esempio la raccolta siti radice, http://team, non deve necessariamente ospitare il contenuto per gli utenti.
Siti in modalità self-service
Nel modello i siti in modalità self-service presentano un'inclusione di caratteri jolly denominata /selfservice (http://siti/selfservice).
Di conseguenza, gli URL hanno il formato indicato nella tabella seguente.
| Dipendente interno (area Intranet) | Dipendente remoto (area Predefinita) |
|---|---|
http://siti/selfservice/sito1 |
https://siti.fabrikam.com/selfservice/sito1 |
http://siti/selfservice/sito2 |
https://siti.fabrikam.com/selfservice/sito2 |
http://siti/selfservice/sito3 |
https://siti.fabrikam.com/selfservice/sito3 |
Sito Web del partner
Il sito Web del partner è progettato per consentire ai dipendenti di creare agevolmente siti per la collaborazione con partner esterni. Per supportare questo obiettivo è consentita la creazione di siti in modalità self-service.
Nel modello di progettazione con autenticazione classica l'applicazione Web del partner presenta un'inclusione di caratteri jolly denominata /siti (http://sitoWebpartner/siti). Di conseguenza, gli URL hanno il formato mostrato nella tabella seguente.
| Dipendente interno (area Intranet) | Dipendente remoto (area Predefinita) |
|---|---|
http://sitoWebpartner/siti/progetto1 |
https://sitoWebpartnerremoto.fabrikam.com/siti/progetto1 |
http://sitoWebpartner/siti/progetto2 |
https://sitoWebpartnerremoto.fabrikam.com/siti/progetto2 |
http://sitoWebpartner/siti/progetto3 |
https://sitoWebpartnerremoto.fabrikam.com/siti/progetto3 |
I collaboratori del partner possono accedere ai siti Web del partner utilizzando gli URL elencati nella tabella seguente.
| Partner (area Extranet) |
|---|
https://sitoWebpartner.fabrikam.com/siti/progetto1 |
https://sitoWebpartner.fabrikam.com/siti/progetto2 |
https://sitoWebpartner.fabrikam.com/siti/progetto3 |
Coordinamento di URL con mapping di accesso alternativo e DNS
Configurare mapping di accesso alternativo per ogni URL di sito della farm. In questo modo le richieste Web verranno mappate al sito corretto, soprattutto in ambienti in cui viene utilizzato il bilanciamento del carico oppure tecnologie di proxy inverso.
Nella tabella seguente vengono elencate le informazioni necessarie per la creazione o la modifica di mapping di accesso alternativo sulla base della versione dell'esempio di progettazione dell'architettura logica con autenticazione classica.
| Sito | Intestazione host | Area | Porta | URL pubblico di mapping di accesso alternativo |
|---|---|---|---|---|
Siti del team |
team |
Intranet |
80 |
http://team |
team.fabrikam.com |
Predefinita |
443 |
https://team.fabrikam.com |
|
Siti in modalità self-service |
siti |
Intranet |
80 |
http://siti |
siti.fabrikam.com |
Predefinita |
443 |
https://siti.fabrikam.com |
|
Sito Web del partner |
sitoWebpartner |
Intranet |
80 |
http://sitoWebpartner |
sitoWebpartnerremoto.fabrikam.com |
Predefinita |
443 |
https://sitoWebpartnerremoto.fabrikam.com |
|
sitoWebpartner.fabrikam.com |
Extranet |
443 |
https://sitoWebpartner.fabrikam.com |
Gli URL a nome singolo, ad esempio http://team, possono essere configurati per l'accesso Intranet. Questi URL vengono risolti dal client aggiungendo il suffisso DNS del client, ad esempio fabrikam.com, e quindi eseguendo una ricerca DNS del nome con il suffisso. Quando ad esempio un computer client nel dominio fabrikam.com richiede http://team, il computer invia una richiesta a DNS per http://team.fabrikam.com.
DNS deve essere configurato per l'utilizzo di un record A per ogni nome di dominio completo (FQDN). Il record A punta all'indirizzo IP con carico bilanciato dei server Web che ospitano un sito. In una distribuzione di produzione tipica i server sono configurati per l'utilizzo di indirizzi IP assegnati in modo statico, oltre a record A assegnati in modo statico in DNS.
Dopo aver ricevuto l'indirizzo IP virtuale del servizio di bilanciamento del carico, il browser client stabilisce le comunicazioni con un server Web front-end nella farm e quindi invia una richiesta HTTP con l'URL originale a nome singolo http://team. IIS e Prodotti SharePoint 2010 riconoscono che si tratta di una richiesta proveniente dall'area Intranet in base alle impostazioni configurate nei mapping di accesso alternativo (vedere la tabella precedente). Se l'utente avesse invece richiesto https://team.fabrikam.com, il processo sarebbe stato lo stesso, con la differenza che IIS e Prodotti SharePoint 2010 avrebbero ricevuto invece questo FQDN e pertanto avrebbero riconosciuto la richiesta per l'area Predefinita.
Negli ambienti con più domini immettere record CNAME per DNS nei domini in cui non sono contenuti i siti. Se ad esempio l'ambiente di rete Fabrikam include un secondo dominio denominato europa.fabrikam.com, vengono immessi record CNAME per tali siti nel dominio Europa. Per il sito Intranet dei siti del team (http://team), viene aggiunto un record CNAME denominato team al dominio europa.fabrikam.com che punta a team.fabrikam.com. Quando viene aggiunto il suffisso DNS del client alle richieste di ricerca DNS, una richiesta di http://team dal dominio Europa genera una ricerca DNS di team.europa.fabrikam.com e viene indirizzata dal record CNAME a team.fabrikam.com.
Nota
Esiste un problema noto con alcuni client Kerberos e la risoluzione di record CNAME. Per ulteriori informazioni, vedere Problemi noti della configurazione Kerberos (SharePoint Server 2010).
Criteri per le aree
È possibile creare un criterio per un'applicazione Web in modo da implementare le autorizzazioni a livello dell'applicazione Web. È possibile creare un criterio per l'applicazione Web in generale oppure solo per un'area specifica. Un criterio applica autorizzazioni per tutto il contenuto dell'applicazione Web o dell'area. Le autorizzazioni applicate tramite criteri sostituiscono tutte le altre impostazioni di sicurezza configurate per i siti e il contenuto. È possibile configurare criteri basati sugli utenti o su gruppi di utenti, ma non su gruppi di SharePoint.
Non vengono utilizzati criteri nell'esempio di progettazione con autenticazione basata sulle attestazioni per la farm di collaborazione in cui sono abilitati più tipi di autenticazione in un'unica area. I criteri vengono implementati nell'esempio di progettazione con autenticazione classica e nella farm pubblicata dell'esempio di progettazione con autenticazione basata sulle attestazioni, in cui è richiesta l'autenticazione di Windows. Se si utilizzano criteri nella farm pubblicata, si aggiunge un ulteriore livello di sicurezza tra gli utenti anonimi e gli utenti che hanno accesso per la gestione dei siti.
Nell'esempio di progettazione viene fornito un esempio in base al quale si nega agli account dei partner l'accesso ai siti di collaborazione interna.