Administrere Microsoft 365-endepunkter

De fleste bedriftsorganisasjoner som har flere kontorplasseringer og en wan-tilkobling, må konfigureres for Microsoft 365-nettverkstilkobling. Du kan optimalisere nettverket ved å sende alle klarerte Microsoft 365-nettverksforespørsler direkte gjennom brannmuren, og omgå all ekstra inspeksjon eller behandling på pakkenivå. Dette reduserer ventetiden og kravene til perimeterkapasiteten. Identifisering av Microsoft 365-nettverkstrafikk er det første trinnet for å gi optimal ytelse for brukerne. Hvis du vil ha mer informasjon, kan du se Prinsipper for nettverkstilkobling for Microsoft 365.

Microsoft anbefaler at du får tilgang til endepunktene for Microsoft 365-nettverket og pågående endringer i dem ved hjelp av Microsoft 365 IP-adresse og nettadressewebtjeneste.

Uansett hvordan du administrerer viktig Microsoft 365-nettverkstrafikk, krever Microsoft 365 Internett-tilkobling. Andre nettverksendepunkter der tilkobling kreves, er oppført på flere endepunkter som ikke er inkludert i Microsoft 365 IP-adressen og nettadressewebtjenesten.

Hvordan du bruker endepunktene for Microsoft 365-nettverket, avhenger av organisasjonens nettverksarkitektur. Denne artikkelen beskriver flere måter bedriftsnettverksarkitekturer kan integreres på med IP-adresser og NETT-adresser for Microsoft 365. Den enkleste måten å velge hvilke nettverksforespørsler du vil klarere på, er å bruke SD-WAN-enheter som støtter automatisert Microsoft 365-konfigurasjon på hver av kontorplasseringene dine.

SD-WAN for lokal avdelingsutgang av viktig Microsoft 365-nettverkstrafikk

På hver avdelingskontorplassering kan du oppgi en SD-WAN-enhet som er konfigurert til å rute trafikk for Microsoft 365 Optimize-kategorien for endepunkter, eller Optimaliser og tillat kategorier, direkte til Microsofts nettverk. Annen nettverkstrafikk, inkludert lokal datasentertrafikk, generell trafikk på Internett-nettsteder og trafikk til Standardkategori-endepunkter for Microsoft 365, sendes til et annet sted der du har en mer betydelig nettverksperimeter.

Microsoft arbeider med SD-WAN-leverandører for å aktivere automatisert konfigurasjon. Hvis du vil ha mer informasjon, kan du se Microsoft 365 Networking Partner Program.

Bruk en PAC-fil for direkte ruting av viktig Microsoft 365-trafikk

Bruk PAC- eller WPAD-filer til å administrere nettverksforespørsler som er knyttet til Microsoft 365, men som ikke har en IP-adresse. Vanlige nettverksforespørsler som sendes via en proxy- eller perimeterenhet, øker ventetiden. Mens TLS Break and Inspect oppretter den største ventetiden, kan andre tjenester som proxy-godkjenning og omdømmeoppslag føre til dårlig ytelse og en dårlig brukeropplevelse. I tillegg trenger disse perimeternettverksenhetene nok kapasitet til å behandle alle forespørslene om nettverkstilkobling. Vi anbefaler at du omgår proxy- eller inspeksjonsenhetene for direkte nettverksforespørsler fra Microsoft 365.

PowerShell Gallery Get-PacFile er et PowerShell-skript som leser de nyeste nettverksendepunktene fra Microsoft 365 IP-adressen og nettadressewebtjenesten, og oppretter et eksempel på en PAC-fil. Du kan endre skriptet slik at det integreres med den eksisterende PAC-filbehandlingen.

Obs!

Hvis du vil ha mer informasjon om sikkerhets- og ytelseshensyn ved direkte tilkobling til Microsoft 365-endepunkter, kan du se Prinsipper for nettverkstilkobling for Microsoft 365.

Figur 1 – enkel nettverksperimeter for virksomheter

PAC-filen distribueres til nettlesere på punkt 1 i Figur 1. Når du bruker en PAC-fil for direkte utgående trafikk av viktig Microsoft 365-nettverkstrafikk, må du også tillate tilkobling til IP-adressene bak disse nettadressene på brannmuren for nettverksperimeteren. Dette gjøres ved å hente IP-adressene for de samme Microsoft 365-endepunktkategoriene som er angitt i PAC-filen og opprette brannmur-ACLer basert på disse adressene. Brannmuren er punkt 3 i figur 1.

Hvis du velger å bare utføre direkte ruting for endepunktene for optimaliser kategori, må alle nødvendige Tillat kategoriendepunkter som du sender til proxy-serveren, være oppført på proxy-serveren for å omgå videre behandling. TLS-brudd og Undersøk og Proxy-godkjenning er for eksempel ikke kompatible med kategoriendepunktene Optimaliser og Tillat. Proxy-serveren er punkt 2 i figur 1.

Den vanlige konfigurasjonen er å tillate uten å behandle all utgående trafikk fra proxy-serveren for mål-IP-adressene for Microsoft 365-nettverkstrafikk som treffer proxy-serveren. Hvis du vil ha informasjon om problemer med TLS Break and Inspect, kan du se Bruke tredjeparts nettverksenheter eller løsninger på Microsoft 365-trafikk.

Det finnes to typer PAC-filer som Get-PacFile skriptet genererer.

Type:	Beskrivelse
1	Send optimaliser endepunkttrafikk direkte og alt annet til proxy-serveren.
2	Send optimaliser og tillat endepunkttrafikk direkte og alt annet til proxy-serveren. Denne typen kan også brukes til å sende all støttet ExpressRoute for Microsoft 365-trafikk til ExpressRoute-nettverkssegmenter og alt annet til proxy-serveren.

Her er et enkelt eksempel på kall til PowerShell-skriptet:

Get-PacFile -ClientRequestId b10c5ed1-bad1-445f-b386-b919946339a7

Det finnes mange parametere du kan sende til skriptet:

Parameteren	Beskrivelse
ClientRequestId	Dette er nødvendig og er en GUID sendt til nettjenesten som representerer klientmaskinen som foretar kallet.
Eksempel	Microsoft 365-tjenesteforekomsten, som er standard for Worldwide. Dette sendes også til nettjenesten.
TenantName	Microsoft 365-leiernavnet ditt. Sendt til nettjenesten og brukt som en utskiftbar parameter i noen Nettadresser for Microsoft 365.
Type	Typen proxy PAC-fil du vil generere.

Her er et annet eksempel på kall til PowerShell-skriptet med flere parametere:

Get-PacFile -Type 2 -Instance Worldwide -TenantName Contoso -ClientRequestId b10c5ed1-bad1-445f-b386-b919946339a7

Proxy-server omgår behandling av Microsoft 365-nettverkstrafikk

Der PAC-filer ikke brukes til direkte utgående trafikk, vil du likevel omgå behandling på nettverksperimeteret ved å konfigurere proxy-serveren. Noen proxy-serverleverandører har aktivert automatisert konfigurasjon av dette som beskrevet i Microsoft 365 Networking Partner Program.

Hvis du gjør dette manuelt, må du hente kategoridataene Optimaliser og tillat endepunkt fra IP-adressen og netttjenesten for Microsoft 365 og konfigurere proxy-serveren til å omgå behandling for disse. Det er viktig å unngå TLS Break og Undersøk og Proxy-godkjenning for kategoriendepunktene Optimaliser og Tillat.

Endringsbehandling for IP-adresser og nettadresser for Microsoft 365

I tillegg til å velge riktig konfigurasjon for nettverksperimeteren, er det viktig at du tar i bruk en endringsbehandlingsprosess for Microsoft 365-endepunkter. Disse endepunktene endres regelmessig. Hvis du ikke administrerer endringene, kan du ende opp med at brukere blokkeres eller har dårlig ytelse etter at en ny IP-adresse eller nettadresse er lagt til.

Endringer i IP-adresser og nettadresser for Microsoft 365 publiseres vanligvis nær den siste dagen i hver måned. Noen ganger publiseres en endring utenfor denne tidsplanen på grunn av operasjonelle, støtte- eller sikkerhetskrav.

Når en endring publiseres som krever at du handler fordi en IP-adresse eller nettadresse ble lagt til, bør du forvente å motta 30 dagers varsel fra tidspunktet vi publiserer endringen til det finnes en Microsoft 365-tjeneste på det endepunktet. Dette gjenspeiles som gjeldende dato. Selv om vi tar sikte på denne varslingsperioden, er det kanskje ikke alltid mulig på grunn av operasjonelle, støtte- eller sikkerhetskrav. Endringer som ikke krever umiddelbar handling for å opprettholde tilkobling, for eksempel fjernede IP-adresser eller nettadresser eller mindre betydelige endringer, inkluderer ikke forhåndsvarsel. I disse tilfellene er det ikke angitt noen gyldig dato. Uavhengig av hvilket varsel som er angitt, viser vi den forventede aktive tjenestedatoen for hver endring.

Endre varsel ved hjelp av webtjenesten

Du kan bruke Microsoft 365 IP-adressen og nettadressewebtjenesten til å få endringsvarsel. Vi anbefaler at du ringer / version-nettmetoden én gang i timen for å kontrollere hvilken versjon av endepunktene du bruker til å koble til Microsoft 365. Hvis denne versjonen endres sammenlignet med versjonen du har i bruk, bør du hente de nyeste endepunktdataene fra /endpoints-webmetoden og eventuelt hente forskjellene fra /changes-nettmetoden . Det er ikke nødvendig å kalle opp metodene /endpoints eller /changes web if there hasn't been any change to the version you found.

Hvis du vil ha mer informasjon, kan du se Microsoft 365 IP-adresse og nettadressewebtjeneste.

Endre varsel ved hjelp av RSS-feeder

Ip-adressen og netttjenesten for Microsoft 365 tilbyr en RSS-feed som du kan abonnere på i Outlook. Det finnes koblinger til RSS-nettadressene på hver av de forekomstspesifikke sidene for Microsoft 365-tjenesten for IP-adresser og nettadresser. Hvis du vil ha mer informasjon, kan du se Microsoft 365 IP-adresse og nettadressewebtjeneste.

Endre varslings- og godkjenningsgjennomgang ved hjelp av Power Automate

Vi forstår at du fortsatt kan kreve manuell behandling for nettverksendepunktendringer som kommer gjennom hver måned. Du kan bruke Power Automate til å opprette en flyt som varsler deg via e-post, og eventuelt kjøre en godkjenningsprosess for endringer når endepunktene i Microsoft 365-nettverket har endringer. Når gjennomgangen er fullført, kan du få flyten til å sende endringene automatisk til brannmuren og administrasjonsteamet for proxy-servere.

Hvis du vil ha informasjon om et power automate-eksempel og -mal, kan du se Bruke Power Automate til å motta en e-postmelding for endringer i Ip-adresser og nettadresser for Microsoft 365.

Vanlige spørsmål om nettverksendepunkter for Microsoft 365

Se disse vanlige spørsmålene om Nettverkstilkobling til Microsoft 365.

Hvordan sende inn et spørsmål?

Velg koblingen nederst for å angi om artikkelen var nyttig eller ikke, og send inn flere spørsmål. Vi overvåker tilbakemeldingen og oppdaterer spørsmålene her med de vanligste spørsmålene.

Hvordan bestemme plasseringen til leieren min?

Leierplassering bestemmes best ved hjelp av datasenterkartet vårt.

Er jeg nodefordeling på riktig måte med Microsoft?

Nodenodplasseringer beskrives mer detaljert i nodefordeling med Microsoft.

Med over 2500 isp nodefordelingsrelasjoner globalt og 70 tilstedeværelsespunkter, bør det være sømløst å komme fra nettverket til vårt. Det kan ikke skade å bruke noen minutter på å sørge for at Internett-leverandørens nodefordelingsrelasjon er den mest optimale, her er noen eksempler på gode og ikke så gode peering hand-offs til nettverket vårt.

Jeg ser nettverksforespørsler til IP-adresser som ikke finnes i den publiserte listen. Trenger jeg å gi tilgang til dem?

Vi tilbyr bare IP-adresser for Microsoft 365-serverne du bør rute direkte til. Dette er ikke en fullstendig liste over alle IP-adresser du ser nettverksforespørsler for. Du ser nettverksforespørsler til Microsoft og tredjepartseide, upubliserte IP-adresser. Disse IP-adressene genereres dynamisk eller administreres på en måte som hindrer rettidig varsel når de endres. Hvis brannmuren ikke kan tillate tilgang basert på FQDN-er for disse nettverksforespørslene, kan du bruke en PAC- eller WPAD-fil til å administrere forespørslene.

Ser du en IP-adresse tilknyttet Microsoft 365 som du vil ha mer informasjon om?

1. Kontroller om IP-adressen er inkludert i et større publisert område ved hjelp av en CIDR-kalkulator, for eksempel disse for IPv4 eller IPv6. 40.96.0.0/13 inkluderer for eksempel IP-adressen 40.103.0.1 til tross for at 40.96 ikke samsvarer med 40.103.
2. Se om en partner eier IP-adressen med en whois-spørring. Hvis det er Microsoft-eid, kan det være en intern partner. Mange partnernettverksendepunkter er oppført som tilhører standardkategorien , der IP-adresser ikke publiseres.
3. IP-adressen er kanskje ikke en del av Microsoft 365 eller en avhengighet. Publisering av nettverksendepunkt for Microsoft 365 inkluderer ikke alle endepunktene i Microsoft-nettverket.
4. Kontroller sertifikatet. Koble til IP-adressen med en nettleser ved hjelp av HTTPS://< IP_ADDRESS> og kontroller domenene som er oppført på sertifikatet, for å forstå hvilke domener som er knyttet til IP-adressen. Hvis det er en Microsoft-eid IP-adresse og ikke på listen over Microsoft 365 IP-adresser, er det sannsynlig at IP-adressen er knyttet til en Microsoft CDN, for eksempel MSOCDN.NET eller et annet Microsoft-domene uten publisert IP-informasjon. Hvis du finner domenet på sertifikatet der vi hevder å liste opp IP-adressen, kan du gi oss beskjed.

Noen Nettadresser for Microsoft 365 peker til CNAME-poster i stedet for A-poster i DNS. Hva har jeg å gjøre med CNAME-postene?

Klientdatamaskiner trenger en DNS A- eller AAAA-post som inneholder én eller flere IP-adresser for å koble til en skytjeneste. Noen nettadresser som er inkludert i Microsoft 365, viser CNAME-poster i stedet for A- eller AAAA-poster. Disse CNAME-postene er mellomledd, og det kan være flere i en kjede. De vil alltid etter hvert løses til en A- eller AAAA-post for en IP-adresse. Vurder for eksempel følgende serie med DNS-poster, som til slutt løses til IP-adressen IP_1:

serviceA.office.com -> CNAME: serviceA.domainA.com -> CNAME: serviceA.domainB.com -> A: IP_1

Disse CNAME-omadresseringene er en normal del av DNS og er gjennomsiktige for klientdatamaskinen og gjennomsiktige for proxy-servere. De brukes til belastningsfordeling, innholdsleveringsnettverk, høy tilgjengelighet og begrensning av tjenestehendelser. Microsoft publiserer ikke de mellomliggende CNAME-postene, de kan endres når som helst, og du trenger ikke å konfigurere dem som tillatt i proxy-serveren.

En proxy-server validerer den opprinnelige nettadressen, som i eksemplet ovenfor er serviceA.office.com, og denne nettadressen vil bli inkludert i Microsoft 365-publisering. Proxy-serveren ber om DNS-løsning for nettadressen til en IP-adresse og mottar tilbake IP_1. Den validerer ikke postene for mellomliggende CNAME-omadressering.

Hardkodede konfigurasjoner eller bruk av en tillatelsesliste basert på indirekte Microsoft 365 FQDN-er anbefales ikke og støttes ikke av Microsoft. De er kjent for å forårsake problemer med kundetilkoblingen. DNS-løsninger som blokkerer på CNAME-omadressering, eller som ellers feilaktig løser DNS-oppføringer i Microsoft 365, kan løses via DNS-videresendinger med DNS-rekursjon aktivert eller ved hjelp av DNS-rothint. Mange tredjeparts nettverksperimeterprodukter integrerer anbefalt Microsoft 365-endepunkt for å inkludere en tillatelsesliste i konfigurasjonen ved hjelp av Microsoft 365 IP-adresse og nettadressewebtjeneste.

Hvorfor ser jeg navn som nsatc.net eller akadns.net i Microsoft-domenenavnene?

Microsoft 365 og andre Microsoft-tjenester bruker flere tredjepartstjenester som Akamai og MarkMonitor for å forbedre Microsoft 365-opplevelsen. For å fortsette å gi deg den beste opplevelsen som er mulig, kan vi endre disse tjenestene i fremtiden. Tredjepartsdomener kan være vert for innhold, for eksempel en CDN, eller de kan være vert for en tjeneste, for eksempel en geografisk trafikkbehandlingstjeneste. Noen av tjenestene som for øyeblikket er i bruk, omfatter:

MarkMonitor er i bruk når du ser forespørsler som inkluderer *.nsatc.net. Denne tjenesten gir beskyttelse og overvåking av domenenavn for å beskytte mot skadelig atferd.

ExactTarget er i bruk når du ser forespørsler til *.exacttarget.com. Denne tjenesten tilbyr administrasjon og overvåking av e-postkoblinger mot skadelig atferd.

Akamai er i bruk når du ser forespørsler som inkluderer ett av følgende FQDN-er. Denne tjenesten tilbyr geo-DNS og nettverkstjenester for innholdslevering.

*.akadns.net
*.akam.net
*.akamai.com
*.akamai.net
*.akamaiedge.net
*.akamaihd.net
*.akamaized.net
*.edgekey.net
*.edgesuite.net

Jeg må ha minimum tilkoblingsmulighet for Microsoft 365

Siden Microsoft 365 er en pakke med tjenester som er bygget for å fungere via Internett, er pålitelighets- og tilgjengelighetsløftene basert på at mange standard Internett-tjenester er tilgjengelige. Standard Internett-tjenester som DNS, CRL og CDN-er må for eksempel kunne nås for å kunne bruke Microsoft 365 på samme måte som de må kunne nås for å bruke de fleste moderne Internett-tjenester.

Microsoft 365-pakken er delt inn i store tjenesteområder. Disse områdene kan selektivt aktiveres for tilkobling, og det finnes et felles område, som er en avhengighet for alle og alltid er nødvendig.

Tjenesteområde	Beskrivelse
Exchange	Exchange Online og Exchange Online Protection
SharePoint	SharePoint Online og OneDrive for Business
Skype for Business Online og Microsoft Teams	Skype for Business og Microsoft Teams
Vanlige	Microsoft 365 Pro Plus, Office i en nettleser, Microsoft Entra-ID og andre vanlige nettverksendepunkter

I tillegg til grunnleggende Internett-tjenester finnes det tredjepartstjenester som bare brukes til å integrere funksjonalitet. Selv om disse tjenestene er nødvendige for integrering, er de merket som valgfrie i endepunktartikkelen for Microsoft 365. Dette betyr at kjernefunksjonaliteten til tjenesten fortsetter å fungere hvis endepunktet ikke er tilgjengelig. Alle nettverksendepunkter som kreves, har det nødvendige attributtet satt til sann. Alle nettverksendepunkter som er valgfrie, har det nødvendige attributtet satt til usann, og notatattributtet beskriver den manglende funksjonaliteten du bør forvente hvis tilkoblingen er blokkert.

Hvis du prøver å bruke Microsoft 365 og finner at tredjepartstjenester ikke er tilgjengelige, vil du sikre at alle FQDN-er merket som obligatoriske eller valgfrie i denne artikkelen er tillatt gjennom proxyen og brannmuren.

Hvordan blokkere tilgangen til Microsofts forbrukertjenester?

Funksjonen for leierbegrensninger støtter nå blokkering av bruken av alle Microsoft-forbrukerprogrammer (MSA-apper), for eksempel OneDrive, Hotmail og Xbox.com. Denne funksjonen bruker en egen topptekst til det login.live.com endepunktet. Hvis du vil ha mer informasjon, kan du se Bruke leierbegrensninger for å administrere tilgang til SaaS-skyprogrammer.

Brannmuren krever IP-adresser og kan ikke behandle URL-adresser. Hvordan konfigurere den for Microsoft 365?

Microsoft 365 oppgir ikke IP-adresser for alle nødvendige nettverksendepunkter. Noen leveres bare som NETTADRESSEr og kategoriseres som standard. URL-adresser i standardkategorien som kreves, må tillates via en proxy-server. Hvis du ikke har en proxy-server, kan du se på hvordan du har konfigurert nettforespørsler for nettadresser som brukere skriver inn i adresselinjen i en nettleser. brukeren oppgir heller ikke en IP-adresse. Nettadressene for standardkategorien for Microsoft 365 som ikke angir IP-adresser, bør konfigureres på samme måte.

Relaterte artikler

Microsoft 365 IP-adresse og nettadressewebtjeneste

IP-områder for Microsoft Azure Datacenter

Microsoft – Offentlig IP-område

Krav til nettverksinfrastruktur for Microsoft Intune

Nettadresser og IP-adresseområder for Microsoft 365

Prinsipper for nettverkstilkobling for Microsoft 365