In het artikel wordt beschreven hoe u meervoudige verificatie implementeert voor Outlook-bureaubladclients die toegang hebben tot Microsoft Exchange. Er zijn vier architecturen die overeenkomen met vier verschillende mogelijkheden voor Microsoft Exchange met het gebruikerspostvak:
Notitie
In de diagrammen tonen zwarte stippellijnen basisinteracties tussen lokale Active Directory-, Microsoft Entra Connect-, Microsoft Entra ID-, AD FS- en web-toepassingsproxy onderdelen. U vindt meer informatie over deze interacties in vereiste poorten en protocollen voor hybride identiteiten.
Architectuur (Exchange Online)
Download een Visio-bestand met alle diagrammen in dit artikel.
In dit scenario moeten gebruikers de versie van de Outlook-client gebruiken die moderne verificatie ondersteunt. Zie Hoe moderne verificatie werkt voor Office 2013-, Office 2016- en Office 2019-client-apps voor meer informatie. Deze architectuur omvat zowel Outlook voor Windows als Outlook voor Mac.
Werkstroom (Exchange Online)
- De gebruiker probeert toegang te krijgen tot Exchange Online via Outlook.
- Exchange Online biedt de URL van een Microsoft Entra-eindpunt voor het ophalen van het toegangstoken om toegang te krijgen tot het postvak.
- Outlook maakt verbinding met Microsoft Entra ID met behulp van die URL.
- Zodra het domein federatief is, stuurt Microsoft Entra ID de aanvraag om naar on-premises AD FS.
- De gebruiker voert referenties in op een AD FS-aanmeldingspagina.
- AD FS leidt de sessie terug naar Microsoft Entra-id.
- Microsoft Entra ID past een Beleid voor voorwaardelijke toegang van Azure toe met een vereiste voor meervoudige verificatie voor mobiele apps en desktopclients. Zie de implementatiesectie van dit artikel voor informatie over het instellen van dat beleid.
- Het beleid voor voorwaardelijke toegang roept Meervoudige Verificatie van Microsoft Entra aan. De gebruiker ontvangt een aanvraag om meervoudige verificatie te voltooien.
- De gebruiker voltooit meervoudige verificatie.
- Microsoft Entra ID-problemen met toegang en vernieuwingstokens en retourneert deze naar de client.
- Met behulp van het toegangstoken maakt de client verbinding met Exchange Online en haalt de inhoud op.
Configuratie (Exchange Online)
Als u pogingen wilt blokkeren om toegang te krijgen tot Exchange Online via verouderde verificatie (de rode stippellijn in het diagram), moet u een verificatiebeleid maken waarmee verouderde verificatie wordt uitgeschakeld voor protocollen die door de Outlook-service worden gebruikt. Dit zijn de specifieke protocollen die u moet uitschakelen: Autodiscover, MAPI, OfflineAdresboeken en EWS. Dit is de bijbehorende configuratie:
AllowBasicAuthAutodiscover: False
AllowBasicAuthMapi: False
AllowBasicAuthOfflineAddressBook: False
AllowBasicAuthWebServices: False
AllowBasicAuthRpc: False
Het RPC-protocol (Remote Procedure Call) wordt niet meer ondersteund voor Office 365, dus de laatste parameter heeft geen invloed op clients.
Hier volgt een voorbeeld van een opdracht voor het maken van dit verificatiebeleid:
New-AuthenticationPolicy -Name BlockLegacyOutlookAuth -AllowBasicAuthRpc:$false -AllowBasicAuthMapi:$false -AllowBasicAuthAutodiscover:$false
-AllowBasicAuthWebServices:$false -AllowBasicAuthOfflineAddressBook:$false
Notitie
Na het maken van het beleid is verouderde verificatie voor alle andere protocollen (zoals IMAP, POP en ActiveSync) standaard uitgeschakeld. Als u dit gedrag wilt wijzigen, kunt u protocollen inschakelen met behulp van een PowerShell-opdracht zoals deze:
Set-AuthenticationPolicy -Identity BlockOutlook -AllowBasicAuthImap:$true
Nadat u het verificatiebeleid hebt gemaakt, kunt u het eerst toewijzen aan een testgroep gebruikers met behulp van de Set-User user01 -AuthenticationPolicy <name_of_policy> opdracht. Na het testen kunt u het beleid uitbreiden voor alle gebruikers. Gebruik de Set-OrganizationConfig -DefaultAuthenticationPolicy <name_of_policy> opdracht om beleid toe te passen op organisatieniveau. U moet Exchange Online PowerShell gebruiken voor deze configuratie.
Architectuur (Exchange Online, AD FS)
Download een Visio-bestand met alle diagrammen in dit artikel.
Dit scenario is hetzelfde als het vorige scenario, behalve dat er een andere trigger wordt gebruikt voor meervoudige verificatie. In het vorige scenario hebben we lokale AD FS gebruikt voor verificatie. Vervolgens hebben we informatie omgeleid over geslaagde verificatie naar Microsoft Entra ID, waarbij een beleid voor voorwaardelijke toegang meervoudige verificatie heeft afgedwongen. In dit scenario maken we in plaats van voorwaardelijke toegang om meervoudige verificatie af te dwingen, een toegangsbeheerbeleid op AD FS-niveau en dwingen we daar meervoudige verificatie af. De rest van de architectuur is hetzelfde als de vorige architectuur.
Notitie
We raden dit scenario alleen aan als u de vorige niet kunt gebruiken.
In dit scenario moeten gebruikers de versie van de Outlook-client gebruiken die moderne verificatie ondersteunt. Zie Hoe moderne verificatie werkt voor Office 2013-, Office 2016- en Office 2019-client-apps voor meer informatie. Deze architectuur omvat zowel Outlook voor Windows als Outlook voor Mac.
Werkstroom (Exchange Online, AD FS)
De gebruiker probeert toegang te krijgen tot Exchange Online via Outlook.
Exchange Online biedt de URL van een Microsoft Entra-eindpunt voor het ophalen van het toegangstoken om toegang te krijgen tot het postvak.
Outlook maakt verbinding met Microsoft Entra ID met behulp van die URL.
Als het domein federatief is, stuurt Microsoft Entra ID de aanvraag om naar on-premises AD FS.
De gebruiker voert referenties in op een AD FS-aanmeldingspagina.
Ad FS roept Microsoft Entra multifactor authentication aan om de verificatie te voltooien als reactie op een AF DS-toegangsbeheerbeleid. Hier volgt een voorbeeld van dat type AD FS-toegangsbeheerbeleid:
De gebruiker ontvangt een aanvraag om meervoudige verificatie te voltooien.
De gebruiker voltooit meervoudige verificatie.
AD FS leidt de sessie terug naar Microsoft Entra-id.
Microsoft Entra ID-problemen met toegang en vernieuwingstokens en retourneert deze naar de client.
Met behulp van het toegangstoken maakt de client verbinding met Exchange Online en haalt de inhoud op.
Configuratie (Exchange Online, AD FS)
Notitie
Het beleid voor toegangsbeheer dat in stap 6 is geïmplementeerd, wordt toegepast op het vertrouwensniveau van de relying-party, dus dit is van invloed op alle verificatieaanvragen voor alle Office 365-services die via AD FS gaan. U kunt AD FS-verificatieregels gebruiken om extra filters toe te passen. We raden u echter aan een beleid voor voorwaardelijke toegang te gebruiken (beschreven in de vorige architectuur) in plaats van een AD FS-toegangsbeheerbeleid te gebruiken voor Microsoft 365-services. Het vorige scenario is gebruikelijker en door het te gebruiken kunt u betere flexibiliteit bereiken.
Als u pogingen wilt blokkeren om toegang te krijgen tot Exchange Online via verouderde verificatie (de rode stippellijn in het diagram), moet u een verificatiebeleid maken waarmee verouderde verificatie wordt uitgeschakeld voor protocollen die door de Outlook-service worden gebruikt. Dit zijn de specifieke protocollen die u moet uitschakelen: Autodiscover, MAPI, OfflineAdresboeken en EWS. Dit is de bijbehorende configuratie:
AllowBasicAuthAutodiscover: False
AllowBasicAuthMapi: False
AllowBasicAuthOfflineAddressBook: False
AllowBasicAuthWebServices: False
AllowBasicAuthRpc: False
RPC-protocol wordt niet meer ondersteund voor Office 365, dus de laatste parameter heeft geen invloed op clients.
Hier volgt een voorbeeld van een opdracht voor het maken van dit verificatiebeleid:
New-AuthenticationPolicy -Name BlockLegacyOutlookAuth -AllowBasicAuthRpc:$false -AllowBasicAuthMapi:$false -AllowBasicAuthAutodiscover:$false
-AllowBasicAuthWebServices:$false -AllowBasicAuthOfflineAddressBook:$false
Architectuur (Exchange on-premises)
Download een Visio-bestand met alle diagrammen in dit artikel.
Deze architectuur omvat zowel Outlook voor Windows als Outlook voor Mac.
Werkstroom (Exchange on-premises)
- Een gebruiker met een postvak op Exchange Server start de Outlook-client. De Outlook-client maakt verbinding met Exchange Server en geeft aan dat deze moderne verificatiemogelijkheden heeft.
- Exchange Server verzendt een antwoord naar de client die aanvraagt om een token op te halen van Microsoft Entra-id.
- De Outlook-client maakt verbinding met een Microsoft Entra-URL die wordt geleverd door Exchange Server.
- Azure identificeert dat het domein van de gebruiker federatief is, dus verzendt het aanvragen naar AD FS (via web toepassingsproxy).
- De gebruiker voert referenties in op een AD FS-aanmeldingspagina.
- AD FS leidt de sessie terug naar Microsoft Entra-id.
- Microsoft Entra ID past een Beleid voor voorwaardelijke toegang van Azure toe met een vereiste voor meervoudige verificatie voor mobiele apps en desktopclients. Zie de implementatiesectie van dit artikel voor informatie over het instellen van dat beleid.
- Het beleid voor voorwaardelijke toegang roept Meervoudige Verificatie van Microsoft Entra aan. De gebruiker ontvangt een aanvraag om meervoudige verificatie te voltooien.
- De gebruiker voltooit meervoudige verificatie.
- Microsoft Entra ID-problemen met toegang en vernieuwingstokens en retourneert deze naar de client.
- De gebruiker geeft het toegangstoken voor Exchange Server weer en Exchange autoriseert toegang tot het postvak.
Configuratie (Exchange on-premises)
Als u pogingen tot toegang tot Exchange on-premises wilt blokkeren via verouderde verificatie (de rode stippellijn in het diagram), moet u een verificatiebeleid maken waarmee verouderde verificatie wordt uitgeschakeld voor protocollen die door de Outlook-service worden gebruikt. Dit zijn de specifieke protocollen die u moet uitschakelen: Automatisch opsporen, MAPI, Offlineadresboeken, EWS en RPC. Dit is de bijbehorende configuratie:
BlockLegacyAuthAutodiscover : True
BlockLegacyAuthMapi : True
BlockLegacyAuthOfflineAddressBook : True
BlockLegacyAuthRpc : True
BlockLegacyAuthWebServices : True
Het RPC-protocol biedt geen ondersteuning voor moderne verificatie, dus het biedt geen ondersteuning voor Meervoudige Verificatie van Microsoft Entra. Microsoft raadt HET MAPI-protocol aan voor Outlook voor Windows-clients.
Hier volgt een voorbeeld van een opdracht voor het maken van dit verificatiebeleid:
New-AuthenticationPolicy -Name BlockLegacyOutlookAuth -BlockLegacyAuthAutodiscover -BlockLegacyAuthMapi -BlockLegacyAuthOfflineAddressBook -BlockLegacyAuthRpc
Nadat u het verificatiebeleid hebt gemaakt, kunt u het eerst toewijzen aan een testgroep gebruikers met behulp van de Set-User user01 -AuthenticationPolicy <name_of_policy> opdracht. Na het testen kunt u het beleid uitbreiden om alle gebruikers op te nemen. Gebruik de Set-OrganizationConfig -DefaultAuthenticationPolicy <name_of_policy> opdracht om beleid toe te passen op organisatieniveau. U moet Exchange On-Premises PowerShell gebruiken voor deze configuratie.
Architectuur (Exchange on-premises, AD FS)
Download een Visio-bestand met alle diagrammen in dit artikel.
Dit scenario is vergelijkbaar met de vorige. In dit scenario wordt meervoudige verificatie echter geactiveerd door AD FS. Deze architectuur omvat zowel Outlook voor Windows als Outlook voor Mac.
Notitie
We raden dit scenario alleen aan als u de vorige niet kunt gebruiken.
Werkstroom (Exchange on-premises, AD FS)
De gebruiker start de Outlook-client. De client maakt verbinding met Exchange Server en geeft aan dat deze moderne verificatiemogelijkheden heeft.
Exchange Server verzendt een antwoord naar de client die aanvraagt om een token op te halen van Microsoft Entra-id. Exchange Server biedt de client een URL naar Microsoft Entra ID.
De client gebruikt de URL voor toegang tot Microsoft Entra-id.
In dit scenario is het domein federatief. Microsoft Entra ID leidt de client om naar AD FS via web toepassingsproxy.
De gebruiker voert referenties in op een AD FS-aanmeldingspagina.
AD FS activeert meervoudige verificatie. Hier volgt een voorbeeld van dat type AD FS-toegangsbeheerbeleid:
De gebruiker ontvangt een aanvraag om meervoudige verificatie te voltooien.
De gebruiker voltooit meervoudige verificatie.
AD FS leidt de sessie terug naar Microsoft Entra-id.
Microsoft Entra ID geeft toegang tot en vernieuwingstokens aan de gebruiker.
De client geeft het toegangstoken weer voor de on-premises Exchange-server. Exchange autoriseert toegang tot het postvak van de gebruiker.
Configuratie (Exchange on-premises, AD FS)
Notitie
Het beleid voor toegangsbeheer dat in stap 6 is geïmplementeerd, wordt toegepast op het vertrouwensniveau van de relying party, dus dit is van invloed op alle verificatieaanvragen voor alle Office 365-services die via AD FS gaan. U kunt AD FS-verificatieregels gebruiken om extra filters toe te passen. We raden u echter aan een beleid voor voorwaardelijke toegang te gebruiken (beschreven in de vorige architectuur) in plaats van een AD FS-toegangsbeheerbeleid te gebruiken voor Microsoft 365-services. Het vorige scenario is gebruikelijker en door het te gebruiken kunt u betere flexibiliteit bereiken.
Als u pogingen tot toegang tot Exchange on-premises wilt blokkeren via verouderde verificatie (de rode stippellijn in het diagram), moet u een verificatiebeleid maken waarmee verouderde verificatie wordt uitgeschakeld voor protocollen die door de Outlook-service worden gebruikt. Dit zijn de specifieke protocollen die u moet uitschakelen: Automatisch opsporen, MAPI, Offlineadresboeken, EWS en RPC. Dit is de bijbehorende configuratie:
BlockLegacyAuthAutodiscover : True
BlockLegacyAuthMapi : True
BlockLegacyAuthOfflineAddressBook : True
BlockLegacyAuthRpc : True
BlockLegacyAuthWebServices : True
Het RPC-protocol biedt geen ondersteuning voor moderne verificatie, dus het biedt geen ondersteuning voor Meervoudige Verificatie van Microsoft Entra. Microsoft raadt HET MAPI-protocol aan voor Outlook voor Windows-clients.
Hier volgt een voorbeeld van een opdracht voor het maken van dit verificatiebeleid:
New-AuthenticationPolicy -Name BlockLegacyOutlookAuth -BlockLegacyAuthAutodiscover -BlockLegacyAuthMapi -BlockLegacyAuthOfflineAddressBook -BlockLegacyAuthRpc
Nadat u het verificatiebeleid hebt gemaakt, kunt u het eerst toewijzen aan een testgroep gebruikers met behulp van de Set-User user01 -AuthenticationPolicy <name_of_policy> opdracht. Na het testen kunt u het beleid uitbreiden om alle gebruikers op te nemen. Gebruik de Set-OrganizationConfig -DefaultAuthenticationPolicy <name_of_policy> opdracht om beleid toe te passen op organisatieniveau. U moet Exchange On-Premises PowerShell gebruiken voor deze configuratie.
Onderdelen
- Microsoft Entra-id. Microsoft Entra ID is een cloudservice voor identiteits- en toegangsbeheer van Microsoft. Het biedt moderne verificatie die in feite is gebaseerd op EvoSTS (een beveiligingstokenservice die wordt gebruikt door Microsoft Entra ID). Deze wordt gebruikt als een verificatieserver voor Exchange Server on-premises.
- Meervoudige verificatie van Microsoft Entra. Meervoudige verificatie is een proces waarbij gebruikers tijdens het aanmeldingsproces worden gevraagd om een andere vorm van identificatie, zoals een code op hun mobiele telefoon of een vingerafdrukscan.
- Voorwaardelijke toegang van Microsoft Entra. Voorwaardelijke toegang is de functie die door Microsoft Entra ID wordt gebruikt om organisatiebeleid af te dwingen, zoals meervoudige verificatie.
- AD FS. AD FS maakt federatief identiteits- en toegangsbeheer mogelijk door digitale identiteit en rechtenrechten te delen over de grenzen van beveiliging en ondernemingen met verbeterde beveiliging. In deze architecturen wordt het gebruikt om aanmelding voor gebruikers met federatieve identiteit mogelijk te maken.
- Web toepassingsproxy. Web toepassingsproxy verifieert vooraf de toegang tot webtoepassingen met behulp van AD FS. Het werkt ook als een AD FS-proxy.
- Microsoft Intune. Intune is ons geïntegreerde eindpuntbeheer in de cloud, het beheren van eindpunten in Windows-, Android-, Mac-, iOS- en Linux-besturingssystemen.
- Exchange Server. Exchange Server host gebruikerspostvakken on-premises. In deze architecturen worden tokens gebruikt die zijn uitgegeven aan de gebruiker door Microsoft Entra ID om toegang tot postvakken te autoriseren.
- Active Directory-services. Active Directory-services slaan informatie op over leden van een domein, inclusief apparaten en gebruikers. In deze architecturen behoren gebruikersaccounts tot Active Directory-services en worden ze gesynchroniseerd met Microsoft Entra-id.
- Outlook voor Bedrijven. Outlook is een clienttoepassing die moderne verificatie ondersteunt.
Scenariodetails
Enterprise Messaging Infrastructure (EMI) is een belangrijke service voor organisaties. Overstappen van oudere, minder veilige verificatiemethoden en autorisatie naar moderne verificatie is een kritieke uitdaging in een wereld waarin werken op afstand gebruikelijk is. Het implementeren van meervoudige verificatievereisten voor toegang tot de berichtenservice is een van de meest effectieve manieren om aan die uitdaging te voldoen.
In dit artikel worden vier architecturen beschreven om uw beveiliging in een Outlook-desktopclienttoegangsscenario te verbeteren met behulp van Meervoudige verificatie van Microsoft Entra.
Dit zijn vier architecturen op basis van vier verschillende mogelijkheden voor Microsoft Exchange:
Alle vier de architecturen hebben betrekking op Zowel Outlook voor Windows als Outlook voor Mac.
Zie de volgende artikelen voor meer informatie over het toepassen van meervoudige verificatie in andere scenario's voor hybride berichten:
- Hybride berichteninfrastructuur voor verbeterde beveiliging in een scenario voor webtoegang
- Hybride berichteninfrastructuur voor verbeterde beveiliging in een scenario voor mobiele toegang
In dit artikel worden geen andere protocollen besproken, zoals IMAP of POP. Normaal gesproken gebruiken deze scenario's deze protocollen niet.
Algemene notities
- Deze architecturen maken gebruik van het federatieve Microsoft Entra-identiteitsmodel. Voor de wachtwoord-hashsynchronisatie en passthrough-verificatiemodellen zijn de logica en stroom hetzelfde. Het enige verschil is gerelateerd aan het feit dat Microsoft Entra ID de verificatieaanvraag niet omleidt naar on-premises Active Directory Federation Services (AD FS).
- Door Exchange on-premises bedoelen we Exchange 2019 met de nieuwste updates en een postvakrol.
- In een echte omgeving hebt u niet slechts één server. U hebt een matrix met gelijke taakverdeling van Exchange-servers voor hoge beschikbaarheid. De scenario's die hier worden beschreven, zijn geschikt voor die configuratie.
Potentiële gebruikscases
Deze architectuur is relevant voor de volgende scenario's:
- Verbeter de beveiliging van EMI.
- Een Zero Trust-beveiligingsstrategie aannemen.
- Pas uw standaard hoge beveiligingsniveau toe voor uw on-premises berichtenservice tijdens de overgang naar of co-existentie met Exchange Online.
- Dwing strikte beveiligings- of nalevingsvereisten af in gesloten of zeer beveiligde organisaties, zoals organisaties in de financiële sector.
Overwegingen
Met deze overwegingen worden de pijlers van het Azure Well-Architected Framework geïmplementeerd. Dit is een set richtlijnen die kunnen worden gebruikt om de kwaliteit van een workload te verbeteren. Zie Microsoft Azure Well-Architected Framework voor meer informatie.
Betrouwbaarheid
Betrouwbaarheid zorgt ervoor dat uw toepassing kan voldoen aan de toezeggingen die u aan uw klanten hebt gedaan. Zie Overzicht van de betrouwbaarheidspijler voor meer informatie.
Beschikbaarheid
De algehele beschikbaarheid is afhankelijk van de beschikbaarheid van de betrokken onderdelen. Zie deze resources voor meer informatie over beschikbaarheid:
- Geavanceerde beschikbaarheid van Microsoft Entra
- Cloudservices die u kunt vertrouwen: Beschikbaarheid van Office 365
- Wat is de Microsoft Entra-architectuur?
De beschikbaarheid van on-premises oplossingsonderdelen is afhankelijk van het geïmplementeerde ontwerp, de beschikbaarheid van hardware en uw interne bewerkingen en onderhoudsroutines. Zie de volgende bronnen voor informatie over beschikbaarheid over sommige van deze onderdelen:
- Een AD FS-implementatie instellen met AlwaysOn-beschikbaarheidsgroepen
- Hoge beschikbaarheid en sitetolerantie implementeren in Exchange Server
- Web-toepassingsproxy in Windows Server
Als u hybride moderne verificatie wilt gebruiken, moet u ervoor zorgen dat alle clients in uw netwerk toegang hebben tot Microsoft Entra-id. U moet ook consistent office 365-firewallpoorten en IP-bereikopeningen onderhouden.
Zie 'Exchange-client- en protocolvereisten' in het overzicht van hybride moderne verificatie voor gebruik met on-premises Skype voor Bedrijven en Exchange-servers voor protocol- en poortvereisten voor Exchange Server.
Zie OFFICE 365-URL's en IP-adresbereiken voor OFFICE 365-IP-bereiken.
Lees voor informatie over hybride moderne verificatie en mobiele apparaten het AutoDetectie-eindpunt in Andere eindpunten die niet zijn opgenomen in het IP-adres en url-webservice van Office 365.
Tolerantie
Zie de volgende bronnen voor informatie over de tolerantie van de onderdelen in deze architectuur.
- Voor Microsoft Entra-id: Vooruitgaande beschikbaarheid van Microsoft Entra
- Voor scenario's die AD FS gebruiken: Hoge beschikbaarheid, cross-geographic AD FS-implementatie in Azure met Azure Traffic Manager
- Voor de on-premises Exchange-oplossing: Hoge beschikbaarheid van Exchange
Beveiliging
Beveiliging biedt garanties tegen opzettelijke aanvallen en misbruik van uw waardevolle gegevens en systemen. Zie Overzicht van de beveiligingspijler voor meer informatie.
Zie Deep Dive: How Hybrid Authentication Really Works (Hybride verificatie werkt echt) voor informatie over beveiliging en hybride moderne verificatie.
Voor gesloten organisaties die traditionele sterke perimeterbeveiliging hebben, zijn er beveiligingsproblemen met betrekking tot hybride configuraties van Exchange. De Exchange Hybrid Modern-configuratie biedt geen ondersteuning voor hybride moderne verificatie.
Zie de handleiding microsoft Entra-beveiligingsbewerkingen voor informatie over Microsoft Entra-id.
Zie de volgende artikelen voor informatie over scenario's die ad FS-beveiliging gebruiken:
- Aanbevolen procedures voor het beveiligen van AD FS en web-toepassingsproxy
- AD FS Extranet Smart Lockout configureren
Kostenoptimalisatie
Kostenoptimalisatie gaat over manieren om onnodige uitgaven te verminderen en operationele efficiëntie te verbeteren. Zie Overzicht van de pijler kostenoptimalisatie voor meer informatie.
De kosten van uw implementatie zijn afhankelijk van uw Microsoft Entra-id en microsoft 365-licentiekosten. Totale kosten omvatten ook kosten voor software en hardware voor on-premises onderdelen, IT-bewerkingen, training en onderwijs en projectuitvoering.
Voor deze oplossingen is ten minste Microsoft Entra ID P1 vereist. Zie Prijzen van Microsoft Entra voor meer informatie over prijzen.
Zie Prijzen en licenties voor Windows Server 2022 voor informatie over AD FS en web-toepassingsproxy.
Zie deze informatiebronnen voor meer informatie over prijzen:
Prestatie-efficiëntie
Prestatie-efficiëntie is de mogelijkheid van uw workload om op een efficiënte manier te schalen om te voldoen aan de eisen die uw gebruikers erop stellen. Zie overzicht van de pijler Prestatie-efficiëntie voor meer informatie.
De prestaties van de werkbelasting zijn afhankelijk van de prestaties van de onderdelen die betrokken zijn en van de netwerkprestaties. Zie De prestaties van Office 365 afstemmen met basislijnen en prestatiegeschiedenis voor meer informatie.
Zie de volgende bronnen voor informatie over on-premises factoren die van invloed zijn op de prestaties voor scenario's met AD FS-services:
Zie Planning voor AD FS-servercapaciteit voor informatie over de schaalbaarheid van AD FS.
Zie de voorkeursarchitectuur van Exchange 2019 voor informatie over de schaalbaarheid van Exchange Server on-premises.
Dit scenario implementeren
Dit zijn de stappen op hoog niveau:
- Beveilig Toegang tot Outlook-bureaublad door de hybride exchange-configuratie te configureren en hybride moderne verificatie in te schakelen.
- Blokkeer alle verouderde verificatiepogingen op het niveau van de Microsoft Entra-id. Blokkeer verouderde verificatiepogingen op berichtenservicesniveau met behulp van verificatiebeleid.
Beleid voor voorwaardelijke toegang instellen
Een Beleid voor voorwaardelijke toegang van Microsoft Entra instellen dat meervoudige verificatie afdwingt, zoals beschreven in sommige architecturen in dit artikel:
Selecteer mobiele apps en desktopclients in het venster Clients-apps:
Pas de vereiste voor meervoudige verificatie toe in het venster Verlenen :
Medewerkers
Dit artikel wordt onderhouden door Microsoft. De tekst is oorspronkelijk geschreven door de volgende Inzenders.
Belangrijkste auteurs:
- Pavel Kondrashov | Cloud Solution Architect
- Ella Parkum | Principal Customer Solution Architect-Engineering
Als u niet-openbare LinkedIn-profielen wilt zien, meldt u zich aan bij LinkedIn.
Volgende stappen
- Aankondiging van hybride moderne verificatie voor Exchange On-Premises
- Overzicht van hybride moderne verificatie en vereisten voor gebruik met on-premises Exchange-servers
- Ad FS-verificatie op basis van claims gebruiken met webversie van Outlook
- Procedure voor het configureren van Exchange Server on-premises voor gebruik van Hybride moderne verificatie
- Voorkeursarchitectuur voor Exchange 2019
- AD FS-implementaties met hoge beschikbaarheid in meerdere regio's in Azure met Azure Traffic Manager
- Hybride moderne verificatie gebruiken met Outlook voor iOS en Android
- Account instellen met moderne verificatie in Exchange Online