Pianificare la connettività tra Office 365 e SharePoint Server

**Si applica a:**SharePoint Online, SharePoint Server 2013, SharePoint Server 2016

**Ultima modifica dell'argomento:**2017-06-20

Riepilogo: Pianificare e preparare configurare la connettività in ingresso da Office 365 per l'ambiente ibrido di SharePoint Server.

In questo articolo è progettato per la pianificazione e preparazione per configurare la connettività in ingresso da Office 365 per aziendeSharePoint Server tramite un dispositivo proxy inverso. Questa operazione è necessaria per gli ambienti ibridi seguenti:

• Ricerca ibrida in ingresso (visualizzazione dei risultati di ricerca da SharePoint Server in Office 365 )

• Ibrida Servizi di integrazione applicativa

In questo articolo si forniscono le informazioni che è necessario conoscere, ad esempio i prerequisiti e un foglio di lavoro per raccogliere le informazioni necessarie prima di iniziare il processo di configurazione.

In questo argomento vengono fornite informazioni utili per effettuare le seguenti operazioni:

• Comprendere i prerequisiti e requisiti per la connettività in ingresso

• Pianificare l'architettura delle applicazioni Web

• Pianificare i certificati SSL

• Registrare le decisioni e le informazioni importanti

Raccolta e registrazione delle informazioni del foglio di lavoro e del log di compilazione

Foglio di lavoro. Durante il processo di pianificazione, è necessario raccogliere le informazioni e i file. È importante utilizzare il foglio di lavoro di SharePoint ibrido per tenere traccia delle informazioni di pianificazione e distribuzione di riferimento e condividere con altri membri del team di distribuzione. È Impossibile sollecitare abbastanza l'importanza di utilizzare questo foglio di lavoro per organizzare le informazioni prima di iniziare il processo di configurazione.

Creare un log di compilazione. Come in qualsiasi progetto di implementazione complesso, è importante registrare nei dettagli ogni decisione di progettazione, configurazione di server, procedura, output dei comandi ed errore per fornire un riferimento per la risoluzione dei problemi, il supporto e la compatibilità. È consigliabile documentare per intero il processo di distribuzione.

Raccolta e registrazione dei dati relativi a URL e nome host

In questa sezione vengono registrate le informazioni sugli URL e i nomi host dell'ambiente. Questi dati verranno utilizzati durante il processo di distribuzione.

• Registrare il nome del dominio DNS pubblico dell'organizzazione (ad esempio adventureworks.com).

• Registrare l'URL dell'endpoint pubblico del dispositivo proxy inverso che verrà utilizzato per l'ambiente ibrido di SharePoint. Questo è l'URL esterno. Se l'endpoint non esiste ancora, sarà necessario decidere quale sarà l'URL.

• Registrare l'indirizzo IP dell'endpoint esterno del dispositivo proxy inverso.

• Verificare che nella zona di ricerca diretta del DNS pubblico per il dominio pubblico sia presente un record A (noto anche come record host) per il mapping dell'URL esterno con l'indirizzo IP dell'endpoint con connessione Internet del dispositivo proxy inverso. Se non si dispone ancora di questo record A, crearlo ora.

• Verifica dell'esistenza di un record nella zona di ricerca diretta DNS intranet che esegue il mapping nome host per la farm SharePoint Server nel relativo indirizzo IP. Se non si dispone ancora questo record, crearla.

  Importante

  Se si configurano URL interni per l'accesso a un'applicazione Web durante il processo di distribuzione, creare record A anche per tali URL nella zona di ricerca diretta del DNS Intranet e registrarli nel foglio di lavoro.

Registrare le seguenti informazioni nella tabella 3 del foglio di lavoro per ambienti ibridi di SharePoint: Il nome del dominio DNS aziendale pubblico nella riga Public Internet Domain name. L'URL dell'endpoint pubblico del dispositivo proxy inverso nella riga External URL. L'indirizzo IP dell'endpoint esterno del dispositivo proxy inverso nella riga IP Address of the external endpoint.

Per ulteriori informazioni sulla relazione tra gli URL e nomi host in un ambiente ibrido, guardare il video informazioni su URL e nomi host. Durata: 6 minuti.

Pianificazione dell'architettura delle applicazioni Web

Questa sezione consentono di pianificare l'architettura delle applicazioni web SharePoint Server che verrà utilizzato nell'ambiente ibrido.

La connettività in ingresso richiede un canale di proteggere le comunicazioni tra la farm locale SharePoint Server e SharePoint Online. Dati scambiati tra un'applicazione web locale e una raccolta siti in SharePoint Online tramite il canale di comunicazione.

SharePoint Online invia richieste a un server proxy inverso inoltra le richieste per un'applicazione web specifica nella farm locale SharePoint Server in cui è configurata per l'ambiente ibrido di SharePoint. E viene indicato come applicazione web principale.

L'applicazione web principale sia una singola raccolta siti all'interno dell'applicazione web principale deve essere configurati per accettare connessioni in ingresso da SharePoint Online.

L'amministratore di SharePoint consente di associare i servizi e gli oggetti di connessione necessarie per supportare le soluzioni ibride distribuite con l'applicazione web principale. Le connessioni in uscita possono essere effettuate da qualsiasi applicazione web di SharePoint Server locale utilizzando le configurazioni specifiche funzionalità.

Un'applicazione web di SharePoint Server è costituita da un sito Web Internet Information Services (IIS) che funge da un'unità logica per le raccolte di siti creati personalmente. Ogni applicazione web è rappresentata da un altro sito Web IIS che dispone di un pool di applicazioni esclusive o condivise, che dispone di un URL pubblico univoco e che possono inoltre essere configurato per utilizzare fino a cinque URL interno tramite Access Mapping Alternativo. Un'applicazione web specificata è associata a un singolo database del contenuto e configurata per l'utilizzo di un metodo di autenticazione specifici per la connessione al database. Più applicazioni web possono essere configurate per utilizzare diversi metodi di autenticazione e, facoltativamente, mapping di accesso alternativo, per consentire l'accesso a un singolo database del contenuto.

URL pubblico dell'applicazione web viene sempre utilizzato come URL radice in tutti i collegamenti a siti e del contenuto a cui accede tramite l'applicazione web. Prendere in considerazione un'applicazione web con l' URL pubblico https://spexternal.adventureworks.com con un URL interno https://sharepoint configurata nel mapping di accesso Alternativo. Quando si visualizza l'URL interno https://sharepoint, SharePoint Server restituisce il sito Web con https://spexternal.adventureworks.com URL e tutti i collegamenti all'interno del sito avrà gli URL in base a tale percorso.

Mapping di accesso alternativo (mapping di accesso Alternativo) è necessaria solo se si sta configurando la connettività in ingresso con una raccolta siti basata su percorso con un URL pubblico è diverso dall'URL esterno. Mapping di accesso Alternativo consente di associare l'URL esterno con l'URL interno di un sito di SharePoint all'interno dell'organizzazione. In questo modo SharePoint Server per instradare le richieste per gli URL interni configurati nel mapping di accesso Alternativo per l'applicazione web principale corrispondente.

Per ulteriori informazioni sulle applicazioni Web basate sulle attestazioni, vedere Creare applicazioni web basate sulle attestazioni in SharePoint Server.

Per ulteriori informazioni su come estendere un'applicazione Web, vedere Estendere le applicazioni Web basate sulle attestazioni in SharePoint.

Per ulteriori informazioni sulle raccolte siti, vedere Panoramica dei siti e delle raccolte siti in SharePoint Server.

Scelta di una strategia di raccolta siti

Prima di decidere se utilizzare un'applicazione Web esistente o crearne una nuova, è necessario conoscere i requisiti di configurazione che devono essere soddisfatti dall'applicazione Web e dalla raccolta siti per supportare la funzionalità ibrida. Utilizzare le informazioni contenute in questa sezione per determinare la strategia per la creazione di una nuova applicazione Web e di una nuova raccolta siti o per determinare se nell'ambiente ibrido è possibile utilizzare una raccolta siti inclusa in un'applicazione Web esistente.

Nella seguente figura viene mostrato il flusso decisionale per la definizione della strategia di raccolta siti.

Requisiti per le applicazioni Web ibride

Le applicazioni Web utilizzate per la funzionalità ibrida devono soddisfare tutti questi requisiti:

• L'URL pubblico dell'applicazione Web deve essere identico all'URL esterno.

  Il protocollo OAuth fornisce l'autorizzazione utente nelle soluzioni ibride di SharePoint. L'intestazione di richiesta Host in tutte le comunicazioni di SharePoint Online dirette verso soluzioni SharePoint locali contiene l'URL a cui è stata inviata in origine la richiesta. Per autenticare le richieste in ingresso provenienti da SharePoint Online, il servizio di autenticazione di SharePoint locale deve essere in grado di creare una corrispondenza tra questo URL contenuto in tutto il traffico proveniente da SharePoint Online e l'URL pubblico dell'applicazione Web principale. Questo è l'URL esterno. L'utilizzo di una raccolta siti con nome host per gli ambienti ibridi di SharePoint offre il vantaggio di poter configurare una raccolta siti con nome host per l'utilizzo dello stesso URL come URL esterno. In questo modo non è necessario configurare il mapping di accesso alternativo.

• L'applicazione Web deve essere configurata per l'utilizzo dell'autenticazione integrata di Windows con NTLM.

  L'autenticazione integrata di Windows con NTLM è necessaria per le applicazioni Web distribuite in scenari che supportano l'autenticazione da server a server e l'autenticazione delle app. Per ulteriori informazioni, vedere Pianificare l'autenticazione da server a server in SharePoint Server.

  

Requisiti per configurazioni di raccolte siti specifiche

Le raccolte siti utilizzate per la funzionalità ibrida devono soddisfare tutti questi requisiti e inoltre devono essere presenti o essere create in un'applicazione Web conforme ai requisiti delle applicazioni Web:

• Raccolte siti con nome host

  • L'applicazione Web deve supportare le raccolte siti con nome host.

    Per creare una raccolta siti con nome host, è necessario che l'applicazione Web sia stata precedentemente creata. Non è possibile abilitare questa funzionalità dopo aver creato l'applicazione Web.

    Per ulteriori informazioni su come creare una raccolta siti con nome host, vedere Architettura e distribuzione di raccolte siti con nome host in SharePoint Server.

    Nota

    Benché questo sia un requisito per le applicazioni Web, viene indicato qui perché si applica esclusivamente agli ambienti con raccolte siti con nome host.

  • Server DNS locali deve essere configurato con ambiente DNS diviso. È necessario creare una zona di ricerca diretta per il dominio Internet pubblico utilizzato per l'URL pubblico e un record (host) nella zona di ricerca diretta con l'indirizzo IP del server SharePoint Server e nome host per l'URL esterno.

    Importante

    Il dispositivo proxy inverso deve essere in grado di risolvere i nomi host in questa zona di ricerca diretta per inoltrare le richieste in ingresso alla farm SharePoint Server.

• Raccolte siti basate su percorso

  • Se l'URL pubblico è identico all'URL esterno:

    Server DNS locali deve essere configurato con ambiente DNS diviso. È necessario creare una zona di ricerca diretta per il dominio Internet pubblico utilizzato per l'URL pubblico e un record nella zona di ricerca diretta con l'indirizzo IP del server SharePoint Server e nome host per l'URL esterno.

    Importante

    Il dispositivo proxy inverso deve essere in grado di risolvere i nomi host in questa zona di ricerca diretta per inoltrare le richieste in ingresso alla farm SharePoint Server.

    Questo è un modo semplice per configurare un'applicazione Web per un ambiente ibrido di SharePoint. L'obiettivo è far corrispondere il campo URL pubblico della nuova applicazione Web all'URL dell'endpoint pubblico nel proxy inverso, noto anche come URL esterno.

  • Se l'URL pubblico è diverso dall'URL esterno:

    È necessario configurare un mapping di accesso alternativo per inoltrare le richieste in ingresso da SharePoint Online.

    Estendere l'applicazione Web principale e utilizzare l'URL esterno come URL pubblico. Creare quindi un URL interno (tramite Aggiungi URL interni) nella stessa area di sicurezza dell'applicazione Web estesa da utilizzare come URL bridging. Sarà necessario inoltre configurare il dispositivo proxy inverso per l'inoltro delle richieste in ingresso da SharePoint Online verso questo URL bridging.

    Tenere presente che il mapping di accesso alternativo (mapping di accesso Alternativo) è necessaria solo quando si configura la connettività in ingresso con una raccolta siti basata su percorso con un URL pubblico è diverso dall'URL esterno.

Registrare la scelta per la strategia di raccolta siti nella riga Site collection strategy della tabella 2 del foglio di lavoro.

Scelta di un'applicazione Web esistente o creazione di una nuova

È possibile utilizzare un'applicazione Web esistente oppure crearne una da utilizzare come applicazione Web principale.

Se si preferisce gestire l'applicazione Web utilizzata per la funzionalità ibrida in modo indipendente oppure se l'applicazione Web esistente non soddisfa i requisiti indicati nella sezione Scelta di una strategia di raccolta siti, creare una nuova applicazione Web.

Registrare la decisione annotandola nella riga New or existing web application della tabella 2.

Pianificazione dell'utilizzo di un'applicazione Web esistente

Se si decide di utilizzare come applicazione Web principale un'applicazione Web esistente, raccogliere i dati relativi all'URL dell'applicazione Web principale e all'URL della raccolta siti principale e registrarli nel foglio di lavoro.

Registrare le seguenti informazioni nel foglio di lavoro: A seconda della strategia di raccolta siti, registrare l'URL dell'applicazione Web principale nella riga Primary web application URL della tabella 5a, 5b o 5c. Se si utilizza una raccolta siti esistente con nome host, registrare l'URL della raccolta siti principale nella riga Host-named site collection URL della tabella 5a.

Dopo avere registrato queste informazioni, andare alla sezione Pianificazione dei certificati SSL.

Pianificazione della creazione di una nuova applicazione Web

Se si decide di creare una nuova applicazione Web, si otterranno indicazioni su come procedere durante la configurazione della topologia ibrida.

Pianificazione dei certificati SSL

I certificati SSL di stabilire l'identità del server e forniscono l'autenticazione del certificato per alcuni diversi servizi e connessioni in un ambiente ibrido di SharePoint. È necessario disporre di due certificati SSL: un certificato SSL di canale sicuroe un certificato servizio token di sicurezza.

Per ulteriori informazioni sull'utilizzo dei certificati SSL negli ambienti ibridi di SharePoint, vedere topologia ibrida di SharePoint 2013: certificati e modello di autenticazione.

Informazioni sui certificati SSL di canale sicuro

Un certificato SSL di canale sicuro fornisce l'autenticazione e la crittografia per il canale di proteggere le comunicazioni tra il dispositivo proxy inverso e Office 365, che funge da di un server e un certificato client. Consente inoltre di verificare l'identità dell'endpoint del proxy inverso utilizzato per pubblicare la raccolta di siti SharePoint Server locale.

Questo certificato deve essere di tipo SAN o con caratteri jolly e deve essere rilasciato da un'autorità di certificazione radice pubblica. Il campo del soggetto di questo certificato deve contenere il nome host dell'endpoint esterno del server proxy inverso o un URL con caratteri jolly per tutti i nomi host dello spazio dei nomi. È necessaria almeno una crittografia a 2048 bit.

In scenari in cui SharePoint Online è configurata per richiedere informazioni dal SharePoint Server, un certificato SSL è necessario eseguire le operazioni seguenti:

• Crittografare il traffico sul canale di sicurezza.

• Abilitare il dispositivo proxy inverso per l'autenticazione delle connessioni in ingresso utilizzando l'autenticazione del certificato.

• Consentire a SharePoint Online di identificare e considerare attendibile l'endpoint esterno.

Durante la distribuzione, il certificato SSL verrà installato sia nel dispositivo proxy inverso sia in un'applicazione di destinazione di archiviazione sicura di SharePoint Online. Questa applicazione verrà configurata quando si configura l'infrastruttura dell'ambiente ibrido.

Acquisizione di un certificato SSL di canale sicuro

Acquisire un certificato SSL di canale sicuro con caratteri jolly o SAN (Subject Alternative Name, nome alternativo del soggetto) per il dominio pubblico locale da un'Autorità di certificazione conosciuta, ad esempio DigiCert, VeriSign, Thawte o GeoTrust.

Registrare le seguenti informazioni nella tabella 4b Secure Channel SSL Certificate del foglio di lavoro: Il nome del certificato e il percorso in cui è stato archiviato nella riga Secure Channel Certificate location and file name. Il nome descrittivo del certificato nella riga Secure Channel SSL Certificate Friendly Name. Specificare il tipo di certificato (SAN o con caratteri jolly) nella riga Type of certificate. La data di scadenza del certificato nella riga Expiration date. Se il certificato ha un'estensione di file pfx, registrare la password del certificato nella riga Secure Channel SSL Certificate Password. Ricordarsi di proteggere con password il foglio di lavoro qualora venga aggiornato con informazioni relative alla password.

Informazioni sui certificati servizio token di sicurezza

Il certificato servizio token di sicurezza della farm di SharePoint locale richiede un certificato predefinito per convalidare i token in ingresso. In un ambiente ibrido di SharePoint, Azure Active Directory funge da un servizio la firma di token attendibile e utilizza il certificato servizio token di sicurezza come certificato di firma. Azure Active Directory è possibile utilizzare il certificato servizio token di sicurezza predefinito da SharePoint Server a come un certificato di firma, poiché non è possibile verificare la catena di attendibilità.

È necessario pertanto sostituire il certificato servizio token di sicurezza predefinito in ogni server nella farm di SharePoint locale con uno dei seguenti certificati:

• Un certificato rilasciato da un'autorità di certificazione pubblica (CA) attendibile da Azure Active Directory

• Un certificato autofirmato

Il certificato servizio token di sicurezza predefinito viene sostituito in un secondo momento quando si configura l'infrastruttura di gestione delle identità.

Se si sceglie di utilizzare un certificato autofirmato, sarà necessario crearlo durante la configurazione della distribuzione. I passaggi per la creazione di un nuovo certificato autofirmato per SharePoint sono inclusi nell'argomento Configurare l'autenticazione da server a server tra SharePoint Server e SharePoint Online.

Acquisizione di un certificato servizio token di sicurezza

Acquisire il certificato servizio token di sicurezza prima di iniziare il processo di configurazione.

Registrare le seguenti informazioni nella tabella 4a STS Certificate del foglio di lavoro: Nome descrittivo del certificato servizio token di sicurezza nella riga STS Certificate Friendly Name Percorso\nome file del certificato servizio token di sicurezza (file *.pfx) nella riga STS Certificate path\filename (*.pfx file) Password del certificato servizio token di sicurezza nella riga STS Certificate Password Percorso\nome file del certificato servizio token di sicurezza (file *.cer) nella riga STS Certificate path\filename (*.cer file) Nome soggetto nella riga Subject Name Data di inizio del certificato servizio token di sicurezza nella riga STS Certificate Start Date Data di fine del certificato servizio token di sicurezza nella riga STS Certificate End Date

Registrazione degli account necessari per la configurazione e i test

Una configurazione dell'ambiente ibrido di SharePoint richiede più account utente in Active Directory locale e la directory di Office 365 (Azure Active Directory che viene visualizzata nella directory di Office 365). Questi account dispongono di autorizzazioni diverse e le appartenenze gruppo o un ruolo. Alcuni degli account utilizzati per distribuire e configurare il software e alcuni sono necessari per testare le funzionalità specifiche per aiutare a garantire che la sicurezza e sistemi di autenticazione funzionino nel modo previsto.

• Passare a Account necessari per la configurazione e la verifica di una soluzione ibrida per una spiegazione completa degli account utente necessari, incluse indicazioni su provider di identità e ruoli.

• Registrare le informazioni di account necessarie nel foglio di lavoro come indicato.

• Tornare a questo articolo sulla pianificazione dopo avere completato questo passaggio.

Passaggi successivi

A questo punto devono avere compilazione completati il foglio di lavoro necessari per la connettività in ingresso ed pronto per avviare il processo di configurazione. Il passaggio successivo consiste nel Selezionare una Guida di orientamento alla configurazione.