Hva har Office 365-hybrider som er felles?

Hybrider

Når jeg sier hybrid, betyr det at jeg har et samarbeid med teknologier som partner programmer du eier og administrerer i virksomheten din, med de som vi administrerer i Microsoft Cloud (s).

Denne definisjonen fungerer ikke bare i Azure, men de fleste arbeids belastninger i Microsoft 365. Hvis du ikke vet hva en arbeids mengde er, er det et program som kjører på Microsoft 365 Sky plattformen – Skype for Business Online, Exchange Online og SharePoint Online er eksempler. Arbeids belastning er en metode for å holde dem atskilt fra de lokale motstykkene, noe som er nyttig for å holde hånd skrift og samtale fra å bli forvirrende.

Hybrid forplikter bruk alle ressurser på hånd, uansett hvor de bor.

Lokale maskin vare ressurser felles

Alle hybrider som jeg snakker om her, kobler et kunde miljø over Internet t til Microsoft 365 (og Azure Active Directory – AAD – i bakgrunnen fordi den fungerer som katalog for Microsoft 365 ). Infrastrukturen kan være vanskelig å konfigurere. Til tross for hva du kanskje har hørt, vil det ikke ta en viss grad i «alt-ology». Meste parten av Hybridene fungerer faktisk på samme måte med (for høyest del) de samme maskin vare kravene.

Per 2016 her er elementene som alle hybrider trenger. Der ting er valg frie, vil jeg si det.

Alle Microsoft 365 hybrid arbeids belastninger har følgende gode ting:

1. Noen lokale-servere (for eksempel en SharePoint-farm eller et Skype for Business-miljø).

2. Active Directory lokalt der brukerne bor eller er hjem (i S4B-terminologi).

3. En Azure Active Directory Connect-Server (AAD Connect) (som kan være på sin egen eller kombinert med en annen server, for eksempel WA-P). Dette er representert av Synkroniser-ikonet fordi AAD Connect brukes til å synkronisere kontoer fra lokaler til skyen i en hybrid.

4. [Valg fritt] En omvendt proxy-server, som i alle mine eksempler, er proxy-server for nett programmer (WA-P).

5. [Valg fritt] Du kan også bruke Active Directory Federation server (eller ADFS).

Hybrid vei visere er også innebygd i hver arbeids belastning for å hjelpe deg med å samarbeide med skyen, slik at du kan bruke alle verktøyene ved salgene dine (uansett hvor de bor).

Hvis du ikke har ADFS, har du ingen samsvars krav som krever det, og ikke vil ha den ekstra kompleksiteten, ikke bruk den. AAD Connect er utformet for å få jobben gjort (og Rep like Rings intervallet er nede på omtrent 3 timer til 30 minutter, noe som er en god forbedring å gjøre).

Mange store selskaper har noen av disse serverne på plass. Mange har domene kontrollere for Active Directory, eller de kan ha ADFS-servere. Hvis du tenker på å konfigurere en hybrid, vil du kanskje sjekke med andre administratorer for å finne ut hvilke lokale ressurser som allerede er på plass. Det vil hjelpe deg med å avgjøre om du vil bruke eksisterende infrastruktur deler, eller ny.

Hva er disse serverne?

Hopp over denne delen hvis du allerede vet hva disse serverne gjør.

De fleste er vant til operasjonene i Active Directory (AD) – hvordan den lister opp brukere og objekter i et domene eller en skog (blant annet) – og i den hybride delen er det en basis base for brukerne som blir replisert til Microsoft Cloud. Jobbene i synkroniseringen (AAD Connect), ADFS og WA-P (vårt eksempel på omvendt proxy) er litt nyere og mer sentral til å behandle hybride HTTPS-forespørsler og-identiteter, slik at La oss snakke om dem.

ADFS

Hvis du vil se gjennom, kan jobben for Active Directory Federation Services hjelpe begge sider av hybrid til å gjenkjenne hverandre, og av det jeg betyr, skal Microsoft 365 vite og klarere ADFS (eller ADFS-klyngen) som et bekreftet offentlig domene navn tilhører. Dette gjør det mulig å enkelt logge på. Det betyr at når brukere med en tilknyttet UPN viser opp til å godkjenne mot ressurser på nettet, vil Microsoft 365 vite UPN og den bestemte ADFS-serveren som sender brukerne til godkjenning. Når Heidi@contoso.com går gjennom påloggings prosessen for Exchange Online, vil Microsoft 365 sende en forespørsel til din lokale, slik at ADFS kan gå gjennom godkjenning og enten bekrefte at hun er krav, eller nekte henne. Dette kan skje raskt hvis nettverket og konfigurasjonen tillater det. ADFS brukes hvis du vil bruke enkel pålogging: Når brukerne logger seg på en ADFS-økt, fanger ADFS-serveren opp med alle andre godkjennings spørsmål (som for eksempel når du bytter mellom arbeids oppgaver) for å minne på Microsoft 365 du fremdeles er den du sier. Siden enkelte IT-avdelinger har samsvars-eller informasjons innstillinger som krever at passord forblir lokalt, og noen ikke er ADFS valg fritt.

Reverser proxy

Nett tilgang – proxy er en omvendt proxy (RP) som er innebygd i Windows Server-operativsystemer, siden 2012 R2 ble utgitt. En omvendt proxy står på utgangs Point for å handle på vegne av farmen. Den har en "side" som skriver ut på Internet t og vet det offentlige domene navnet til Microsoft 365 hybrid, og en "side" som er på Netts IDen for intranettet eller perimeternettverket og vet domene navnet til de interne ressursene (for eksempel et SharePoint-nettsted). Den fanger opp alle forespørsler som kommer inn i virksomheten din og lar deg blokkere porter, begrense trafikken du vil godta fra Internet t, og skjule de interne adressene og Netta dressene for nettverket ditt fra utsiden av verden. På samme måte som med alle RPs, er det en proxy for interne servere på nettverket når brukere utenfor nettverket prøver å få tilgang til en ressurs.

Hybrider for SharePoint 2013 bruker en omvendt proxy, som for eksempel WA-P for å fange inn kommende trafikk (fra brukere i SPO å lage spørringer mot en søke indeks på lokale i tilfelle forbunding av søk), men fordi SharePoint 2016-skyen i skyen har hele indeksen, neste generasjon trenger ikke lenger én (som er den eneste årsaken til at det er merket som valg fritt i diagrammene). Men SharePoint 2013 er ikke det eneste stedet der du vil se en omvendt proxy som brukes til å fange opp uoppfordret trafikk som kommer fra Internet t. Skype for Business 2016 bruker en med sin Edge-konfigurasjon, og Exchange 2016 bruker én på den aktuelle kanten også. Siden noen situasjoner krever det, er WA-P valg fritt.

Synkronisere

Grafikken jeg bruker, viser synkronisering for Azure Active Directory Connect. I realiteten er synkroniseringen utført av AAD Connect den pågående overføringen av brukere og/eller bruker informasjon fra den lokale og i skyen. AAD Connect kan gjøre to ting: den replikerer bruker kontoer til Microsoft 365 (rep like ring), og den kan synkronisere passord informasjon inn i Microsoft 365 (den er ikke synkronisert passordet, men en ikke-reversibel hash-kode som representerer passord – synkroniseringen). Den trenger ikke synkronisere passordet ditt, men det synkroniserer alltid (rep likere) bruker kontoene fra Active Directory (eller en filtrert versjon av den lokale bruker katalogen)!

AAD Connect fungerer med velegnede domene kontrollere i Active Directory-domenet ditt for å tillate samme pålogginger i stedet for ADFS i enkel pålogging. Samme pålogging betyr at i stedet for å logge på en enkelt tid og at ADFS skal gå på alle spørsmålene for økten, logger du deg på med det samme passordet som på lokale (og presumably, velger du alternativet for å beholde deg selv pålogget for å redusere antall lede tekster som resultatet fra å navigere i flere arbeids belastninger). AAD Connect for Sync er ikke valg fri.

Internet t og Internett-tilgjengelige hybrid deler, felles

Motsatte lokale servere i Microsoft 365 hybrid og over Internet t er Microsoft-skyen, der – uansett hvilken Microsoft 365 arbeids mengde – du bruker noen velkjente teknologier. Dette skjer når:

• Offentlige DNS-poster

• Offentlige sertifiserings instanser

• Azure Active Directory (AAD)

• Microsoft 365 (lisenser/abonnementer) og Microsoft 365 hybrid vei visere

• En server-til-server-klarering (S2S)

• Hurtig rute og/eller Internett-trafikk

• PowerShell-moduler

Offentlige DNS-registrarer, for eksempel GoDaddy, administrere og tillate registrering av domene navn. Hvis du vil bruke hybrid, må du registrere et domene navn med offentlig DNS (dette kan allerede være gjort i store selskaper). Dette domene navnet vil bli lagt til Microsoft 365, noe som også vil bekrefte at du eier det offentlige domene navnet du legger til.

Dette offentlige domene navnet er tradisjonelt det samme som Active Directory-UPNet som er koblet til hybrid brukere lokalt, men er ikke oppfanget på denne detaljene. Med advents av attributtet "onpremisessecurityidentifier" i PowerShell, som tilordner identitet til den lokale siden, er det ikke lenger like alvorlige for det registrerte domenet i Microsoft 365 med UPN for brukere på-lokale så det som så lite som det var. Det er viktigere å vite at du trenger et offentlig domene navn som du kan bevise, og dette offentlige domene navnet blir registrert i Microsoft 365 og vil representere Microsoft 365 tilstede værelsen på begge sider av hybrid tilkoblingen.

Offentlige sertifiserings instanser gir deg upålitelige SSL/TLS-sertifikater for å kryptere nettverks trafikken. I alle arbeids belastningene finner du hybrid kommunikasjon over en kryptert tilkobling. Du trenger et sertifikat fra en offentlig sertifiserings instans på Internet t. Henting og SSL/TLS-sertifikater er en standard praksis, og det er vanligvis offentlige sertifikat prosesser i store bedrifter for å gjøre dette. I mindre bedrifter må du kanskje kontakte IT-personen, Microsoft 365 dokumentasjon og Internett-leverandøren.

Azure Active Directory, eller Azure AD, er i bakgrunnen når du synkroniserer/replikerer brukere fra lokalt til Microsoft 365-abonnementet (Sky BAS ert lokale). Det er nøyaktig samme Active Directory som brukes i bredere Azure. Kraftig og sømløst blandet inn i Microsoft 365. Du skal administrere brukerne og bruker lisensene i denne katalogen. Administrasjon av lisenser i Microsoft 365 utføres ikke automatisk av hybrid vei viser. Lisenser for kunder koster penger, så avgjørelsen for hvem og hvor mange få lisenser blir ikke gjort automatisk.

Microsoft 365 er helt en halv del av hybriden. Den har hybrid vei visere for Internet t per arbeids belastning. Dette er ikke veldig effektivt, men det er slik hybrid fungerer på 2016 (eller, med andre ord, basert på utgivelsen av SharePoint Server 2016, Exchange Server 2016 og Skype for Business Server 2015, lokalt). Men det er ikke den enkleste måten å konfigurere alle elementene på i en hybrid. En enkelt hybrid vei viser som gjør det mulig for kunder å velge hvilke arbeids belastninger som skal være hybride, og gå gjennom denne prosessen per arbeids belastning, i tillegg til et hybrid kommando senter – en Microsoft 365 administrativt instrument bord – som kan rapportere om teknologier som brukes av alle hybrider, er sikre og/eller allerede på plass ennå ikke finnes.

Hva betyr dette? Det betyr at hver vei viser utfører de samme trinnene, og ofte mer enn én gang. Hver vei viser aktiverer OAuth (S2S Trust) for eksempel (vi skal snakke om OAuth senere). Noen vei visere, for eksempel hybrid velgeren for arbeids belastning for SharePoint Online, installerer OAuth uansett hvilken knapp du klikker (for hvert utvalg du gjør), enten det kreves OAuth for ditt hybride scenario. Andre vei visere, for eksempel vei viseren for Exchange hybrid, konfigurere OAuth i bakgrunnen og bare én gang.

En S2S-klarering trenger ikke å krysse Internet t, men hvis den er hybrid, må denne klareringen. En S2S er ikke lik domene-eller skog klarering. Det finnes ikke et stort antall porter å åpne, og det er ingen dypere integrasjon å opprette mellom aktive mapper. S2S bygger en klarert tilkobling mellom den lokale SharePoint-farmen og en del av Microsoft 365-skyen som kalles tilgangs kontroll tjenesten eller ACS (en rapportserver). Klareringen er basert på et SSL/TLS-sertifikat som signerer tokener som er utstedt på vegne av brukere, slik at de lokale og Microsoft 365 ACS ikke samtykker i å stole på det som er svært mye fem mellom lokale SharePoint (og ACS-Proxy-tjenesten) og Azure-ACS for hver bruker som har tilgang til tjenesten. Kommunikasjon om bruker identiteter (årsaken til denne klareringen) utføres over HTTP/443.

Hybrider kan bruke selv signerte eller offentlige sertifikater her. Mange store selskaper vil velge offentlige sertifikater på grunn av sine InfoSec-standarder – stort sett fordi trafikken krysser/kan krysse Internet t, et uklarert segment. For SharePoint-hybrider kan dette sertifikatet være et nytt selv signert sertifikat eller en trukket ut fra SP STS-tokenet for å signere sertifikatet lokalt. (Hvis du brukte et nytt sertifikat (offentlig eller selv signert) i en SharePoint-hybrid, må du erstatte SP STS token-signerings sertifikatet på alle noder i SharePoint-farmen.)

Trafikk i en hybrid beholder et klient selskap/en organisasjon, krysser Internet t og legger til skyen med Microsoft-organisasjonen/Microsoft Microsoft 365. Det finnes en metode for å hoppe over dette ikke-klarerte og ikke-kontrollerte segmentet, og det er ved å bruke en tredje parts leverandør BAS ert Express-rute fra firmaet eller organisasjonen til Microsoft 365-skyen. Hurtig rute omgår Internet t ved å tilby en privat WAN-tilkobling til Microsoft Cloud. Det er imidlertid viktig å realisere at i tilfeller der WAN svekket en feil, er reserven fremdeles Internet t.

Alle hybrider gjør bruk av PowerShell-moduler for deler i enten administrasjon eller konfigurasjon. De fleste moduler du trenger, vil sannsynligvis inkludere påloggings assistenten for Microsoft Online Servicesog Azure Active Directory-modulen for Windows PowerShell. Du kan forberedelser servere for konfigurasjon og administrering av Hybridene dine på forhånd, ved å installere disse vanlig brukte PowerShell-modulene.

Porter og protokoller felles

Hybrider er 1/2 de lokale og 1/2 Microsoft 365 (Azure SaaS eller PaaS hybrider er ikke dekket i dette dokumentet). Det er svært sannsynlig at begge halv delene kjører på HTTPs, men det er minst Microsoft 365 halv parten er 100% https/kryptert av TLS-sertifikater, og det betyr at den kjører over standard port 443. Du må kontrollere at et offentlig sertifikat er knyttet til trafikk som går ut fra utgangs-punktet. Det vil si at du må installere et sertifikat på data maskinen som snakker på kanten av nettverket – denne trafikken vil kjøre over 443 og være kryptert.

Alle hybrider vil bruke 443 (HTTPS) og 53 (DNS), som standard for hybrid trafikk. Noen vil bruke flere porter som port 25 (SMTP). Men det mest komplekse tilfellet i hybrid arbeids belastninger for porter er Skype for Business. Heldigvis er portene dokumentert.

Standout-protokollen som brukes av alle hybrider (fra og med ytelses tester som brukes for DNS-oppslag, HTTPS-trafikk, SMTP og andre standarder), er OAuth (Open Authentication), som også brukes i Active Directory Authentication Library. Den brukes når en serverressurs på én side av tilkoblingen må fungere på vegne av en bruker for å få tilgang til ressurser på en annen server, ofte i skyen. Det er en metode som gir nivået av bruker tilgang til en fil eller ressurs som kan måles for en godkjent bruker. Dette kalles også moderne godkjenning (selv om OAuth refererer til Authorization).

Alle arbeids belastninger bruker OAuth/S2S når de er i en hybrid (men ikke for hver hybride funksjon). Hybrid vei visere konfigurerer vanligvis denne nyttige protokollen automatisk. Det finnes imidlertid ingen Unification for denne innsatsen på tvers av arbeids belastningen, ingen rapportering av OAuth-tilstand til kunden, og ingen sentralisert metode for å administrere denne Universal ressursen på 2016.

I noen tilfeller slår hybrid vei viserne OAuth på når det ikke er nødvendig (for eksempel når SharePoint hybrid velger slår dette på for OneDrive for Business-omdirigering til skyen), eller på hvert valg av et hybrid alternativ i vei viseren (på nytt, se hybrid velgeren for SharePoint) , eller til og med utenfor hybrid velgeren i tilpassede installasjons skript, for eksempel med hybrid søk i skyen.

Tabell over vanlige elementer i Microsoft 365 hybrider

Så nå har vi en liste over vanlige elementer som ser slik ut:

Til slutt kan du få brukerne til å være likt på tvers av alle arbeids mengder, slik at vi har det samme i de viktigste funksjonene, slik at det blir enklere å se brukerens identitet, og hva hun har lov til å gjøre med informasjonen hun har fått tilgang til.

Et notat på «valg fritt»

Noen av disse elementene er satt til valg fri, men hvordan vil du vite om de er nødvendige? Noen elementer i Microsoft 365 hybrider er virkelig valg frie eller ikke valg frie på tvers av tavlen:

Inni en arbeids hybrid er det andre funksjoner som faller inn i et grått område. Den viktigste av dette er sannsynligvis S2S Trust/OAuth. Denne klareringen er bygget av hver hybrid vei viser som er opprettet i Microsoft, og klareringen er bygget som standard, selv når den ikke er nødvendig, i den rekkefølgen de er i fremtiden. Når du er hybrid via en vei viser, vil denne funksjonen være på. Men (som du så tidligere) er den for øyeblikket ikke brukt i alle tilfeller.

En omvendt proxy (WA-P i vårt eksempel) er nødvendig når det er en uoppfordret forespørsel til kunde organisasjonen for data eller informasjon (for eksempel når du bruker hybrid BCS, når du publiserer Office Web Apps eller Office Online server for dokument forhånds visning i Søk resultater). Det er også nødvendig når du publiserer et slutt punkt i et DMZ av selskapet, for eksempel når Exchange bruker WA-P som en ADFS-proxy (så hvis du bruker ADFS i en Exchange-hybrid, trenger du WA-P).

Du trenger kanter for å opprettholde konsekvente kommunikasjons kanaler for pågående chatter i Skype for Business hybrid, og kan brukes til å rute SMTP-trafikk til nettverket fra en perimeter i en Exchange-hybrid. Som beskrevet, brukes ADFS for enkel pålogging.

Det finnes lignende tabeller for S2S, for eksempel denne tabellen for SharePoint-servere i hybrid konfigurasjoner. Tabeller som dette kan være bygget ved bruk av logikken til S2S-protokollen, som brukes når en serverressurs på en side av hybrid tilkoblingen må fungere på vegne av en bruker for å få tilgang til ressurser på en annen server i skyen.

* Hybrid velgeren for SharePoint vil fortsatt slå på OAuth, men dette er for å ha en fremtidig hybrid konfigurasjon.