Cosa hanno in comune gli ibridi di Office 365?

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.

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 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).

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.

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.

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.

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.

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.

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.

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.

Tabella di elementi comuni in Microsoft 365 ibridi

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

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:

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.

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.

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