Pianificare la connettività tra Microsoft 365 e SharePoint Server

SI APPLICA A:2013 2016 2019 Subscription Edition SharePoint in Microsoft 365

Questo articolo è progettato per semplificare la pianificazione e la preparazione della configurazione della connettività in ingresso da Microsoft 365 per le aziende a SharePoint Server tramite un dispositivo proxy inverso. Questa operazione è necessaria per gli ambienti ibridi seguenti:

• Ricerca ibrida in ingresso (visualizzazione dei risultati della ricerca da SharePoint Server in Microsoft 365)

• Servizi di integrazione applicativa ibridi

In questo articolo vengono fornite le informazioni necessarie, 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 i 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 informazioni e file. È importante usare il foglio di lavoro ibrido di SharePoint per tenere traccia delle informazioni di pianificazione e distribuzione come riferimento e condividere con altri membri del team di distribuzione. Non è possibile sottolineare abbastanza l'importanza di usare 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.

Attenzione

Per motivi di sicurezza, archiviare il foglio di lavoro e il log di compilazione in una posizione di sicurezza avanzata, ad esempio una condivisione file protetta o SharePoint nella raccolta documenti di Microsoft 365, e concedere le autorizzazioni solo agli amministratori coinvolti nel processo di distribuzione e devono conoscere queste informazioni.

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 di dominio DNS pubblico della società, ad esempio adventureworks.com.

• Registrare l'URL dell'endpoint pubblico del dispositivo proxy inverso che verrà usato per l'ambiente ibrido di SharePoint. Questo è l'URL esterno. Se questo 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.

• Assicurarsi che esista un record A nella zona di ricerca diretta DNS intranet che esegue il mapping del nome host della farm di SharePoint Server al relativo indirizzo IP. Se non si dispone ancora di questo record A, crearlo ora.

  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.

Pianificazione dell'architettura delle applicazioni Web

Questa sezione consente di pianificare l'architettura delle applicazioni Web di SharePoint Server che verranno usate nell'ambiente ibrido.

La connettività in ingresso richiede un canale di comunicazione sicuro tra la farm di SharePoint Server locale e SharePoint in Microsoft 365. I dati vengono scambiati tra una raccolta siti in SharePoint in Microsoft 365 e un'applicazione Web locale tramite questo canale di comunicazione.

SharePoint in Microsoft 365 invia richieste a un server proxy inverso che inoltra le richieste a un'applicazione Web specifica nella farm di SharePoint Server locale configurata per SharePoint ibrido. Tale applicazione viene indicata come applicazione Web principale.

Consiglio

Indipendentemente dal numero di soluzioni ibride che si prevede di configurare, in genere verrà utilizzata una sola applicazione Web principale. Non è necessario creare applicazioni Web primarie aggiuntive per ogni soluzione ibrida aggiuntiva.

Sia l'applicazione Web primaria che una singola raccolta siti all'interno dell'applicazione Web primaria devono essere configurate per accettare connessioni in ingresso da SharePoint in Microsoft 365.

L'amministratore di SharePoint associa i servizi e gli oggetti di connessione necessari per supportare le soluzioni ibride distribuite con l'applicazione Web primaria. Le connessioni in uscita possono essere effettuate da qualsiasi applicazione Web di SharePoint Server locale usando le configurazioni specifiche delle funzionalità.

Un'applicazione Web di SharePoint Server è costituita da un sito Web Internet Information Services (IIS) che funge da unità logica per le raccolte siti create. Ogni applicazione Web è rappresentata da un sito Web IIS diverso che dispone di un pool di applicazioni univoco o condiviso e di un URL pubblico univoco e che può essere configurata anche per utilizzare fino a cinque URL interni con il mapping di accesso alternativo. Un'applicazione Web è associata a un singolo database del contenuto ed è configurata per utilizzare un metodo di autenticazione specifico per la connessione al database. È possibile configurare più applicazioni Web per utilizzare metodi di autenticazione diversi e facoltativamente mapping di accesso alternativo per fornire l'accesso a un singolo database del contenuto.

L'URL pubblico di un'applicazione Web viene sempre usato come URL radice in tutti i collegamenti ai siti e al contenuto a cui si accede tramite l'applicazione Web. Si consideri un'applicazione Web con l'URL https://spexternal.adventureworks.com pubblico con un URL https://sharepoint interno configurato in AAM. Quando si passa all'URL https://sharepointinterno, SharePoint Server restituisce il sito Web con l'URL https://spexternal.adventureworks.come tutti i collegamenti all'interno del sito avranno URL basati su tale percorso.

Il mapping di accesso alternativo (AAM) è necessario solo quando si configura la connettività in ingresso usando una raccolta siti basata su percorso con un URL pubblico diverso dall'URL esterno. AAM consente di associare l'URL esterno all'URL interno di un sito di SharePoint in Microsoft 365 all'interno dell'organizzazione. In questo modo SharePoint Server può instradare le richieste per gli URL interni configurati in AAM all'applicazione Web primaria corrispondente.

Per altre informazioni sulle applicazioni Web basate su attestazioni, vedere Creare applicazioni Web basate su attestazioni in SharePoint Server.

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

Per altre 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 della richiesta host in tutte le comunicazioni di SharePoint in Microsoft 365 con SharePoint locale contiene l'URL a cui è stata originariamente inviata la richiesta. Per autenticare le richieste in ingresso da SharePoint in Microsoft 365, il servizio di autenticazione di SharePoint locale deve essere in grado di corrispondere a questo URL in tutto il traffico da SharePoint in Microsoft 365 all'URL pubblico dell'applicazione Web primaria. 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 altre 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.

  • Il server DNS locale deve essere configurato con il sistema DNS diviso. È necessario creare una zona di ricerca diretta per il dominio Internet pubblico usato per l'URL pubblico e un record A (host) nella zona di ricerca diretta con l'indirizzo IP di SharePoint Server e il nome host dell'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 di SharePoint Server.

• Raccolte siti basate su percorso

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

    Il server DNS locale deve essere configurato con il sistema DNS diviso. È necessario creare una zona di ricerca diretta per il dominio Internet pubblico usato per l'URL pubblico e un record A nella zona di ricerca diretta con l'indirizzo IP di SharePoint Server e il nome host dell'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 di 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 (AAM) per inoltrare le richieste in ingresso da SharePoint in Microsoft 365.

    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. Si configurerà anche il dispositivo proxy inverso per inoltrare le richieste in ingresso da SharePoint in Microsoft 365 a questo URL di bridging.

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

Nota

Ricordare che l'URL esterno è l'URL dell'endpoint con connessione Internet del dispositivo proxy inverso.

	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.

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 stabiliscono l'identità dei server e forniscono l'autenticazione del certificato per connessioni e servizi diversi in un ambiente ibrido di SharePoint. È necessario disporre di due certificati SSL: un certificato SSL del canale sicuro e un certificato stS.

Per altre informazioni sull'uso dei certificati SSL negli ambienti ibridi di SharePoint, vedere Topologia ibrida di SharePoint 2013: modello di certificato e autenticazione.

Nota

Se si sceglie di proteggere la farm di SharePoint locale con SSL, sarà necessario anche un certificato SSL per l'applicazione Web principale. Non esistono considerazioni specifiche per questo certificato, pertanto è possibile seguire le procedure consigliate generali per la configurazione di SharePoint Server con SSL.

Nota

"Secure Channel" non è una classe di certificato; il termine viene usato per distinguere questo particolare certificato da altri certificati SSL usati nell'ambiente.

Informazioni sui certificati SSL di canale sicuro

Un certificato SSL del canale sicuro fornisce l'autenticazione e la crittografia per il canale di comunicazione sicuro tra il dispositivo proxy inverso e Microsoft 365, fungendo sia da server che da certificato client. Verifica anche l'identità dell'endpoint proxy inverso usato per pubblicare la raccolta siti di 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.

Importante

I certificati con caratteri jolly possono proteggere solo un livello di uno spazio dei nomi DNS. Ad esempio, se l'URL esterno è https://spexternal.public.adventureworks.com, l'oggetto del certificato con caratteri jolly deve essere *.public.adventureworks.com, non *.adventureworks.com.

Negli scenari in cui SharePoint in Microsoft 365 è configurato per richiedere informazioni da SharePoint Server, è necessario un certificato SSL per 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 in Microsoft 365 di identificare e considerare attendibile l'endpoint esterno.

Durante la distribuzione, si installerà il certificato SSL sia nel dispositivo proxy inverso che in un'applicazione di destinazione Di SharePoint in Microsoft 365 Secure Store. Questa applicazione verrà configurata quando si configura l'infrastruttura dell'ambiente ibrido.

Acquisizione di un certificato SSL di canale sicuro

Ottenere un certificato SAN (Subject Alternative Name) o un carattere jolly SSL del canale sicuro per il dominio pubblico locale da un'autorità di certificazione nota, ad esempio DigiCert, VeriSign, Thawte o GeoTrust.

Nota

Questo certificato deve supportare più nomi e deve essere almeno a 2048 bit. I certificati in genere scadono a intervalli di un anno. È quindi importante pianificare in anticipo i rinnovi del certificato per evitare interruzioni del servizio. Gli amministratori di SharePoint devono pianificare un promemoria per la sostituzione del certificato che offra un tempo di lead-in sufficiente per evitare un arresto del lavoro.

Informazioni sui certificati servizio token di sicurezza

Un certificato servizio token di sicurezza della farm di SharePoint locale richiede un certificato predefinito per la convalida dei token in ingresso. In un ambiente ibrido di SharePoint, Microsoft Entra ID funge da servizio di firma token attendibile e usa il certificato stS come certificato di firma. Se si sceglie di usare un certificato diverso dal certificato stS predefinito (ad esempio, un certificato di un'autorità di certificazione pubblica), sostituire il certificato predefinito prima di iniziare il processo di configurazione ibrida.

Registrazione degli account necessari per la configurazione e i test

Una configurazione dell'ambiente ibrido di SharePoint richiede diversi account utente sia nella directory Active Directory locale che nella directory di Microsoft 365 (MICROSOFT ENTRA ID visualizzato nella directory di Microsoft 365). Questi account dispongono di autorizzazioni e di appartenenze a gruppi o ruoli diverse. Alcuni vengono utilizzati per la distribuzione e la configurazione del software e altri sono necessari per testare funzionalità specifiche e garantire che i sistemi di sicurezza e autenticazione funzionino come previsto.

• Passare a Accounts needed for hybrid configuration and testing per una spiegazione completa degli account utente necessari, incluse indicazioni su provider di identità e ruoli.

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

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

Passaggi successivi

A questo punto, è necessario aver completato la compilazione del foglio di lavoro necessario per la connettività in ingresso ed essere pronti per avviare il processo di configurazione. Il passaggio successivo consiste nel scegliere una roadmap di configurazione.