Cosa hanno in comune gli ibridi di Office 365?

Il concetto di ibrido: l'idea che l'infrastruttura locale possa espandersi per includere risorse in Microsoft Cloud, esiste in molti prodotti Microsoft. Hybrid è presente in Microsoft 365 a causa di "carichi di lavoro" come Exchange Online, Skype for Business online e SharePoint in Microsoft 365. Si tratta di carichi di lavoro che hanno tutti una sorta di "immagine speculare" o "Twin", locale, ad esempio Skype for Business online ha un Twin locale, Skype for Business Server 2015 e SharePoint in Microsoft 365 ha SharePoint Server 2016.

Quando si parla di Microsoft 365 ibridi nel corso di questo articolo, si parla di connettere questi due gemelli in modo che funzionino insieme. Parliamo quindi di ibridi di SharePoint, ibridi di Exchange e ibridi Skype for Business--cose che si estendono Microsoft 365 e locali--qui. L'obiettivo è quello di rendere chiaro il terreno comune tecnologico che esiste in tutti questi ibridi Microsoft 365. In altre parole, verranno elencati i blocchi predefiniti di Microsoft 365 ibridi.

Ibridi

Quando dico ibrido, voglio dire una cooperazione tra le tecnologie che le applicazioni partner sono proprietarie e gestite nella tua azienda con quelle che gestiamo nel cloud Microsoft.

Questa definizione funziona non solo in Azure ma nella maggior parte dei carichi di lavoro in Microsoft 365. Se non si conosce il carico di lavoro, si tratta di un'applicazione in uso nella piattaforma cloud Microsoft 365, ad esempio Skype for business online, Exchange Online e SharePoint Online. "Carico di lavoro" è un modo per mantenerli distinti dalle controparti locali, che è utile per evitare che la scrittura e la conversazione vengano confuse.

Gli outfit ibridi usano tutte le risorse a disposizione, indipendentemente dal luogo in cui vivono.

Suggerimento: Hybrid è una tecnologia sempre in evoluzione in Microsoft, con molte nuove possibilità di ritaglio e quindi ci sono alcune parti della configurazione di un ibrido più avanzato per gli altri utenti. È probabile che le funzionalità delle configurazioni ibride crescano e cambino da qui.

Risorse hardware on-Prem in comune

Tutti gli ibridi di cui si parla qui collegano un ambiente cliente tramite Internet a Microsoft 365 (e ad Azure Active Directory-AAD-in background perché funge da directory per Microsoft 365 ). L'infrastruttura può sembrare difficile da configurare. Nonostante ciò che potresti aver sentito, non è necessario laurearsi in "anything-ology". In realtà, la maggior parte degli ibridi funziona allo stesso modo con (per la maggior parte) gli stessi requisiti hardware.

A partire da 2016, ecco gli elementi necessari per tutti gli ibridi. In cui le cose sono facoltative, lo dirò.

Tutti gli ibridi hanno bisogno di questi elementi: un prodotto server on-Prem, un server di AAD Connect, un Active Directory on-Prem, un ADFS facoltativo e un proxy inverso.

Tutti i Microsoft 365 carichi di lavoro ibridi hanno queste caratteristiche positive:

  1. Alcuni server on-Prem (ad esempio una farm di SharePoint o un ambiente Skype for business).

  2. Active Directory locale in cui gli utenti vivono o sono "ospitati" (in terminologia S4B).

  3. Un server di Azure Active Directory Connect (AAD Connect) (che potrebbe essere autonomo o combinato con un altro server, ad esempio WA-P). Questo è rappresentato dall'icona di sincronizzazione perché AAD Connect viene usato per sincronizzare gli account dal locale al cloud in un ibrido.

  4. [Facoltativo] Un server proxy inverso, che, in tutti i miei esempi, sarà il server di proxy applicazione Web (WA-P).

  5. [Facoltativo] È anche possibile usare Active Directory Federation Server (o ADFS).

Nota: Non è necessario usare ADFS. AAD Connect consente di "sincronizzare la password" con il cloud insieme alle identità degli utenti. Ma non si sta effettivamente inviando la password tramite Internet. Si sta inviando un hash non reversibile della password tramite una connessione protetta TLS.

Inoltre, le creazioni guidate ibride sono integrate in ogni carico di lavoro per aiutarti a collaborare con il cloud, in modo da poter usare tutti gli strumenti a tua disposizione (indipendentemente dal luogo in cui vivono).

Se non si dispone di ADFS, non si hanno richieste di conformità che lo richiedono e non si vuole usare la complessità aggiuntiva. AAD Connect è progettato per completare il processo (e l'intervallo di replica è in calo da circa 3 ore a 30 minuti, che è un utile miglioramento da apportare).

Molte aziende di grandi dimensioni hanno alcuni di questi server in posizione. Molti hanno controller di dominio Active Directory o possono avere server ADFS. Se si sta pensando alla configurazione di un ibrido, è consigliabile verificare con altri amministratori le informazioni sulle risorse locali già esistenti. Ti aiuterà a determinare se vuoi usare i pezzi di infrastruttura esistenti o nuovi.

Cosa fanno questi server?

Ignorare questa sezione se si sa già cosa stanno facendo questi server.

La maggior parte delle persone è abituata alle operazioni di Active Directory (AD): come enumera gli utenti e gli oggetti in un dominio o una foresta (tra le altre cose) e, nel caso dell'ibrido, è una base di partenza per gli utenti che verranno replicati nel cloud Microsoft. I processi della sincronizzazione (AAD Connect), ADFS e WA-P (il nostro esempio di proxy inverso) sono un po' più recenti e più centrali per l'elaborazione di richieste e identità HTTPS ibride, quindi parliamo di questi.

ADFS

Per la revisione, il processo di Active Directory Federation Services consiste nell'aiutare entrambi i lati dell'ibrido a riconoscersi e, in questo modo, Microsoft 365 sta per conoscere e considerare attendibile l'ADFS (o il cluster ADFS) a cui appartiene un nome di dominio pubblico verificato. Questo consente l'accesso singolo. Ciò significa che quando gli utenti con un UPN associato vengono visualizzati per l'autenticazione in base alle risorse online, Microsoft 365 conoscerà il proprio UPN e il server ADFS specifico in cui inviare gli utenti per il proprio utilizzo. Quando Heidi@contoso.com passa attraverso il processo di accesso per Exchange Online, Microsoft 365 invierà una richiesta alla propria sede, in modo che ADFS possa intervenire nell'autenticazione e confermare che è la persona che sostiene o negarla. Questo problema può verificarsi rapidamente se la rete e la configurazione lo consentono. ADFS viene usato se si vuole sfruttare Single Sign-on: quando gli utenti accedono a una sessione ADFS, il server ADFS intercetta automaticamente tutte le altre richieste di autenticazione, come accade quando si passa tra i carichi di lavoro, ad esempio, per ricordare a Microsoft 365 che si sta ancora dicendo di essere. Poiché alcuni reparti IT hanno impostazioni di sicurezza relative alla conformità o alle informazioni che richiedono la permanenza delle password in locale e altre no, ADFS è facoltativo.

Nota: Indipendentemente dal carico di lavoro ibrido, ADFS viene usato solo quando è necessario un Single Sign-on o quando non è conforme agli standard o alle esigenze del cliente per trasferire un hash di password su Internet e in una directory esterna al firewall Edge della società. È importante tenere presente che la sincronizzazione tramite password è attivata per impostazione predefinita dalla procedura guidata di connessione AAD in ibridi di Exchange. Le risposte di ADFS sulle directory degli utenti AD o ADAM (modalità applicazione Active Directory).

Proxy inverso

Web Access-proxy è un proxy inverso (RP) incorporato nei sistemi operativi Windows Server dopo la pubblicazione di 2012 R2. Un proxy inverso corrisponde al punto di uscita per agire per conto della farm. Ha un "lato" che si affaccia su Internet e conosce il nome di dominio pubblico della Microsoft 365 ibrida e un "lato" che deve affrontare la rete Intranet o perimetrale e conosce il nome di dominio delle risorse interne, ad esempio l'URL del sito di SharePoint. Intercetta tutte le richieste che entrano nella tua azienda e ti consente di bloccare le porte, limitare il traffico che accetterai da Internet e nascondere gli indirizzi interni e gli URL per la rete dal mondo esterno. Come tutti i RPs, è un proxy per i server interni della rete ogni volta che gli utenti esterni alla rete cercano di arrivare a una risorsa.

Gli ibridi di SharePoint 2013 usano un proxy inverso come WA-P per intercettare il traffico in ingresso (da utenti in SPO che effettuano query su un indice di ricerca su Prem nel caso della Federazione di ricerca), ma poiché gli ibridi cloud di SharePoint 2016 inseriscono l'intero indice nel cloud, l' la nuova generazione non ha più bisogno di una (che è la sola ragione per cui è contrassegnata come facoltativa nei diagrammi). Ma SharePoint 2013 non è l'unico posto in cui verrà visualizzato un proxy inverso usato per intercettare il traffico non richiesto proveniente da Internet. Skype for business 2016 usa uno con la sua configurazione Edge e Exchange 2016 ne usa uno anche sul proprio bordo. Dato che alcune situazioni lo richiedono, WA-P è facoltativo.

Note: 

  • WA-P viene usato negli ibridi di SharePoint (2013 ibridi federati) per pubblicare un endpoint di SharePoint attraverso il bordo di una società. WA-P intercetta le chiamate da SPO per i documenti da visualizzare nei risultati di ricerca o gli elementi da visualizzare negli elenchi alimentati da BCS o SAP. Nella ricerca ibrida nel cloud, il WA-P è necessario solo se si vuole visualizzare le anteprime di ricerca nei risultati della ricerca (è necessario pubblicare un endpoint per Office Web Apps Server tramite il bordo). In Skype for business, WA-P viene usato per intercettare il traffico di messaggistica istantanea e congressuale dall'esterno della società e reindirizzarlo al vantaggio di Skype for business per ulteriori elaborazioni.

  • Exchange Hybrid usa lo strumento AAD Connect durante la creazione guidata ibrida per offrire ai clienti l'opzione di installare e configurare automaticamente ADFS e WA-P per l'uso di Exchange Hybrid, riducendo la complessità che si dovrà affrontare durante la configurazione di un ibrido. Nessuna configurazione e configurazione, né la registrazione di certificati ADFS è automatica per qualsiasi altro carico di lavoro ibrido.

Sincronizzazione

L'elemento grafico che uso Mostra "Sync" per Azure Active Directory Connect. La sincronizzazione eseguita da AAD Connect implica in realtà il transito continuo di utenti e/o informazioni utente dal locale e nel cloud. AAD Connect può eseguire due operazioni: replica gli account utente in Microsoft 365 (replica) e può sincronizzare le informazioni sulla password in Microsoft 365 (in realtà non è la sincronizzazione della password, ma un hash non reversibile che rappresenta la password, ovvero la sincronizzazione). Non è necessario "sincronizzare la password", ma Sincronizza sempre (replica) gli account utente da Active Directory o da una versione filtrata della directory degli utenti locale.

AAD Connect funziona con controller di dominio sani nel dominio Active Directory per consentire "lo stesso accesso" anziché ADFS "Single Sign-on". Lo stesso Sign-on indica che, invece di eseguire l'accesso a una sola volta e ad ADFS di intervenire per tutte le richieste di una sessione, accedi con la stessa password di Prem (e, presumibilmente, seleziona l'opzione per mantenersi connessi per ridurre il numero di richieste che risultato dell'esplorazione di più carichi di lavoro). AAD Connect for Sync non è facoltativo.

Note: 

  • Indipendentemente dal carico di lavoro ibrido, tutti richiedono la connessione AAD. In tutti i casi è necessaria una replica e la sincronizzazione facoltativa delle password degli utenti a Microsoft 365 (e AD Azure AD).

  • Altre similitudini includono che la sincronizzazione delle password (usata per l'accesso stesso) richiede anche di impostare la replica delle modifiche della directory e di replicare le modifiche della directory in tutti i domini di Active Directory sincronizzati: eseguire questa operazione per l'account locale usato da AAD Connect e che è necessario creare una voce host DNS A o AAAA per il nome del servizio federativo di un server ADFS usato per SSO in modo che WA-P possa risolvere internamente l'indirizzo del server ADFS.

Internet e Internet-parti ibride disponibili in comune

Di fronte ai server locali della Microsoft 365 ibrida e su Internet è il cloud Microsoft, dove-indipendentemente dal carico di lavoro Microsoft 365-si usano alcune tecnologie familiari. Questi sono:

  • Record DNS pubblici

  • Autorità di certificazione pubbliche

  • Azure Active Directory (AAD)

  • Microsoft 365 (licenze/Subs) e Microsoft 365 creazioni guidate ibride

  • Attendibilità da server a server (S2S)

  • Route Express e/o traffico Internet

  • Moduli di PowerShell

I registrar pubblici DNS, come GoDaddy, gestiscono e consentono la registrazione dei nomi di dominio. Se si vuole usare Hybrid, è necessario registrare un nome di dominio con DNS pubblico (questo può già essere eseguito per le aziende di grandi dimensioni). Questo nome di dominio verrà aggiunto a Microsoft 365, che consentirà anche di verificare che si è proprietari del nome di dominio pubblico aggiunto.

Tradizionalmente, questo nome di dominio pubblico è lo stesso dell'UPN di Active Directory allegato agli utenti ibridi in locale, ma non rimanere impigliati in questo dettaglio. Con l'avvento dell'attributo ' onpremisessecurityidentifier ' in PowerShell, che associa l'identità al SID locale, la corrispondenza del dominio registrato in Microsoft 365 con l'UPN degli utenti on-Prem non è più così importante come lo era una volta. È più importante sapere che è necessario un nome di dominio pubblico che può essere dimostrato, questo nome di dominio pubblico verrà registrato in Microsoft 365 e rappresenterà la presenza di Microsoft 365 su entrambi i lati della connessione ibrida.

Le autorità di certificazione pubbliche forniscono certificati SSL/TLS affidabili per crittografare il traffico di rete. In tutti i carichi di lavoro, la comunicazione ibrida avviene tramite una connessione crittografata. È necessario un certificato di un'autorità di certificazione pubblica su Internet. L'ottenimento dei certificati SSL/TLS è una prassi standard e in genere i processi di certificazione pubblica sono disponibili in grandi aziende per facilitare l'operazione. Nelle aziende di piccole dimensioni potrebbe essere necessario consultare la propria persona, Microsoft 365 la documentazione e il proprio ISP.

Nota: Potrebbe non essere necessario applicare i certificati pubblici manualmente. L'assistente per la distribuzione di Exchange (EDA) per gli ibridi di Exchange sfrutta Azure AD Connect per illustrare questo processo e registrare i certificati per il server ADFS (se si usa un ADFS). L'EDA è progettato per semplificare il processo di ibridazione.

Azure Active Directory o Azure AD è in background quando si sincronizzano o si replicano gli utenti dall'locale all'abbonamento Microsoft 365 (il cloud locale). È l'esatta stessa Active Directory usata in Azure più ampio. Potente e perfettamente amalgamato in Microsoft 365. Potrai gestire gli utenti e le licenze utente in questa directory. La gestione delle licenze in Microsoft 365 non viene eseguita automaticamente da una procedura guidata ibrida. Le licenze costano ai clienti i soldi, quindi la decisione di chi e quante licenze Get non viene eseguita automaticamente.

Microsoft 365 è completamente a metà della tua ibrida. Ha creazioni guidate ibride online per carico di lavoro. Questo non è molto efficiente, ma questo è il modo in cui Hybrid funziona da 2016 (o, in altre parole, dal rilascio di SharePoint Server 2016, Exchange Server 2016 e Skype for Business Server 2015, locale). Ma questo non è il modo più semplice per configurare tutti gli elementi in un ibrido. Una singola procedura guidata ibrida che consentirebbe ai clienti di scegliere quali carichi di lavoro per creare un processo ibrido e a piedi per ogni carico di lavoro, oltre a un centro comandi ibrido, ovvero un dashboard di amministrazione Microsoft 365, che potrebbe segnalare se le tecnologie usate da ogni ibrido sono sane e/o già esistenti.

Che cosa significa? Significa che ogni procedura guidata esegue gli stessi passaggi e spesso più volte. Ogni procedura guidata attiva OAuth (S2S Trust) ad esempio (ne parleremo in seguito). Alcune procedure guidate, ad esempio la selezione ibrida del carico di lavoro di SharePoint Online, consentono di installare OAuth indipendentemente dal pulsante che si fa clic (per ogni selezione effettuata), indipendentemente dal fatto che OAuth sia necessario per lo scenario ibrido. Altre procedure guidate, ad esempio la procedura guidata ibrida di Exchange, configurano OAuth in background e una sola volta.

Non è necessario che un trust S2S attraversi Internet, ma in caso di ibrido questo deve essere attendibile. Un S2S non è simile a un dominio o a un trust tra insiemi di strutture. Non ci sono grandi quantità di porte da aprire e nessuna integrazione più profonda da creare tra Active Directory. S2S crea una connessione attendibile tra la farm di SharePoint locale e un pezzo del cloud Microsoft 365 denominato servizio di controllo di accesso o ACS (un server di autorizzazione). Il trust si basa su un certificato SSL/TLS che firma i token emessi per conto degli utenti, che l'utente locale e l' Microsoft 365 ACS concordano in modo attendibile: Consideralo come un massimo di cinque tra la posta in arrivo di SharePoint (e il suo servizio proxy ACS) e l'ACS di Azure per tutti gli utenti validi che accedono al servizio. La comunicazione sulle identità degli utenti (causa di questo trust) viene eseguita tramite HTTP/443.

Nota: Come con Azure AD, Microsoft 365 ha un trust con ACS di Azure.

Gli ibridi possono usare i certificati auto-firmati o pubblici qui. Molte aziende di grandi dimensioni sceglieranno i certificati pubblici a causa dei loro standard di InfoSec, in gran parte perché il traffico incrocia/può attraversare Internet, un segmento non attendibile. Per gli ibridi di SharePoint, questo certificato può essere un nuovo certificato autofirmato o uno Estratto dal token STS SP-signing CERT locale. Se è stato usato un nuovo certificato (pubblico o autofirmato) in un ibrido di SharePoint, è necessario sostituire il CERT della firma del token STS SP in tutti i nodi della farm di SharePoint.

Il traffico in un ibrido lascia una società client/org, attraversa Internet ed entra nell'organizzazione Microsoft/Microsoft Microsoft 365 cloud. Esiste un modo per aggirare questo segmento non attendibile e non controllato e questo è l'uso di un provider di terze parti basato su un percorso espresso dalla società o dall'organizzazione al cloud Microsoft 365. Express Route bypassa Internet offrendo una connessione WAN privata al cloud Microsoft. Tuttavia, è importante rendersi conto che nei casi in cui la rete WAN soffre di un errore, il fallback è ancora Internet.

Tutti gli ibridi usano i moduli di PowerShell per parti di una gestione o di una configurazione. La maggior parte dei moduli necessari includerà probabilmente l' Assistente per l'accesso ai Microsoft Online Servicese il modulo Azure Active Directory per Windows PowerShell. È possibile preparare i server per la configurazione e la gestione degli ibridi in anticipo installando i moduli di PowerShell usati di frequente.

Porte e protocolli in comune

Gli ibridi sono ½ in locale e ½ Microsoft 365 (gli ibridi di Azure SaaS o PaaS non sono coperti in questo documento). È molto probabile che entrambe le metà vengano eseguite su HTTPs, ma almeno la metà Microsoft 365 è 100% HTTPS/crittografato da certificati TLS e questo significa che viene eseguito su una porta standard 443. È necessario assicurarsi che un certificato pubblico sia associato al traffico che esce dal punto di uscita. In altre parole, dovrai installare un certificato nel computer per comunicare sul bordo della rete: il traffico verrà eseguito su 443 e verrà crittografato.

Nota: Se si usa ADFS, saranno effettivamente necessari tre certificati, uno dei quali verrà pubblicato pubblicamente e usato per la comunicazione dei servizi (vivrà sul proxy WA-P se si sceglie di usare ADFS), due dei quali saranno i CERT autofirmati eseguiti quando ADFS viene installato , in base al rinnovo automatico, sono i certificati di firma del token e di decrittografia dei token usati per la firma di tutti i token creati da ADFS. Ma oltre ai certificati necessari per gli ADFS facoltativi, tutti gli ibridi devono avere un certificato S2S (a volte chiamato S2S ACS Trust CERT, che è un nome troppo lungo).

Tutti gli ibridi useranno 443 (HTTPS) e 53 (DNS), per impostazione predefinita, per il traffico ibrido. Alcuni utilizzeranno porte aggiuntive come la porta 25 (SMTP). Ma il caso più complesso nei carichi di lavoro ibridi per le porte è Skype for business. Fortunatamente, le porte sono documentate.

Il protocollo standout usato da tutti gli ibridi (ad eccezione dei benchmark usati per la ricerca DNS, il traffico HTTPS, SMTP e altri standard) è OAuth (Open Authorization), usato anche nella libreria di autenticazione di Active Directory. Viene usato quando una risorsa server su un lato della connessione deve agire per conto di un utente per accedere alle risorse di un altro server, spesso nel cloud. Si tratta di un mezzo tramite cui il livello di accesso degli utenti a un file o a una risorsa può essere valutato per un utente autenticato. Questa operazione viene chiamata anche "autenticazione moderna" (anche se OAuth fa riferimento all'autorizzazione).

Tutti i carichi di lavoro usano OAuth/S2S quando sono in un ibrido (anche se non per ogni caratteristica ibrida). Le creazioni guidate ibride in genere configurano automaticamente questo protocollo utile. Tuttavia, non c'è un'unificazione di questo sforzo tra i carichi di lavoro, nessuna segnalazione dello stato OAuth al cliente e nessun modo centralizzato per gestire questa risorsa universale da 2016.

In alcuni casi, le creazioni guidate ibride attivano OAuth quando non è necessario (ad esempio, quando SharePoint Hybrid Picker attiva il reindirizzamento per OneDrive for business nel cloud) o su ogni selezione di un'opzione ibrida nella procedura guidata (di nuovo, vedere la selezione ibrida di SharePoint) o anche all'esterno della selezione ibrida negli script di configurazione personalizzati, ad esempio con la ricerca ibrida nel cloud.

Nota: Puoi considerare l'fulcro dell'ibrido come attendibile da server a server (S2S) tra locale e cloud. Può essere utile tenere presente che S2S è il nome di Microsoft per l'implementazione di OAuth. S2S/OAuth sottostante in tutti i carichi di lavoro sono i livelli di autenticazione e identità, che usano entrambi l'autenticazione delle attestazioni.

Tabella di elementi comuni in Microsoft 365 ibridi

Ora abbiamo un elenco di elementi comuni che hanno un aspetto simile al seguente:

Elementi in comune con i carichi di lavoro ibridi

Hardware on-Prem

Applicazioni locali che collaborano con i carichi di lavoro in Microsoft 365 (ad esempio Exchange Server a Exchange Online)

AAD Connect

Proxy inverso (se necessario)

ADFS (facoltativo)

Elementi Internet

Record DNS pubblici

Autorità di certificazione pubbliche

Azure Active Directory (AAD è la directory degli utenti in Microsoft 365 )

Microsoft 365 (E1, E3, E5 abbonamenti)

Microsoft 365 creazioni guidate ibride

Attendibilità da server a server (S2S)

Porte e protocolli

HTTPS

DNS

S2S/OAuth

In definitiva, in tutti i carichi di lavoro, l'obiettivo è quello di far sì che gli utenti siano gli stessi oltre i confini, in modo da semplificare due delle funzioni più importanti di un ibrido: capire l'identità dell'utente e cosa può fare con le informazioni che può vedere.

Una nota su "facoltativo"

Alcuni di questi elementi sono impostati su "facoltativo", ma in che modo saprete se sono necessari? Alcuni elementi di Microsoft 365 ibridi sono veramente facoltativi o non facoltativi in tutta la bacheca:

Completamente facoltativo: tutti Microsoft 365 ibridi

Non facoltativo/obbligatorio per tutti Microsoft 365 ibridi

ADFS

AAD Connect

All'interno di un ibrido funzionante esistono altre caratteristiche che rientrano in un'area grigia. Probabilmente il più importante di questi è il S2S trust/OAuth. Questo trust viene compilato da ogni procedura guidata ibrida creata all'interno di Microsoft e il trust viene creato per impostazione predefinita, anche quando non è necessario, per gli ibridi "a prova di futuro". Quando si passa a una procedura guidata ibrida, questa funzionalità sarà attiva. Ma (come hai visto prima) non è attualmente usato in tutti i casi.

Un proxy inverso (WA-P nell'esempio) è necessario ogni volta che è presente una richiesta indesiderata in arrivo all'organizzazione del cliente per dati o info, ad esempio quando si usa BCS ibrido, quando si pubblicano Office Web Apps o Office Online Server per l'anteprima dei documenti nella ricerca Risultati). È anche necessario quando si pubblica un endpoint in una DMZ della società, ad esempio quando Exchange USA WA-P come proxy ADFS (quindi se si usa ADFS in un ibrido di Exchange è necessario WA-P).

I bordi sono necessari per mantenere i canali di comunicazione coerenti per le chat in corso in Skype for business Hybrid e possono essere usati per instradare il traffico SMTP nella rete da un perimetro in un ibrido di Exchange. Come illustrato, ADFS viene usato per Single-Sign-on.

Deve usare un proxy inverso

Può usare un proxy inverso (facoltativo)

Non è necessario un proxy inverso

Ricerca in ingresso ibrida di SharePoint

BCS ibrido di SharePoint

Skype for Business ibrido

SharePoint Cloud Hybrid (cloud SSA)

Exchange Hybrid using ADFS per SSO

Reindirizzamento di OneDrive for business

Caratteristiche del sito ibrido di SharePoint

Reindirizzamento dei profili ibridi di SharePoint

Reindirizzamento Extranet ibrido

Esistono tabelle simili per S2S, ad esempio questa tabella per i server di SharePoint nelle configurazioni ibride. Le tabelle come questa possono essere create usando la logica del protocollo S2S, che viene usato quando una risorsa server su un lato della connessione ibrida deve agire per conto di un utente per accedere alle risorse di un altro server nel cloud.

Caratteristiche ibride di SharePoint che devono usare OAuth

Caratteristiche ibride di SharePoint che non usano OAuth

Ricerca ibrida (in uscita + in ingresso)

Ricerca ibrida nel cloud (cloud SSA) con l'uso delle anteprime di ricerca

Servizio di connettività aziendale ibrida (BCS)

Caratteristiche del sito ibrido

Profili ibridi

Metadati gestiti ibridi

Reindirizzamento di OneDrive for business *

Extranet ibrida *

Profili ibridi *

Ricerca ibrida nel cloud (cloud SSA) senza usare le anteprime di ricerca

* La selezione ibrida di SharePoint continuerà a essere attivata per OAuth, ma per tutte le future configurazioni ibride.

Serve aiuto?

Amplia le tue competenze
Esplora i corsi di formazione
Ottieni in anticipo le nuove caratteristiche
Partecipa a Microsoft Insider

Queste informazioni sono risultate utili?

Grazie per il feedback!

Grazie per il tuo feedback! Potrebbe essere utile metterti in contatto con uno dei nostri operatori del supporto di Office.

×