Upravit

Share via

Infrastruktura hybridního zasílání zpráv s rozšířeným zabezpečením – mobilní přístup

Microsoft Entra ID
Microsoft 365
Office 365

Článek ukazuje, jak implementovat vícefaktorové ověřování pro mobilní klienty Outlooku, kteří přistupují k serveru Microsoft Exchange. Existují dvě architektury, které odpovídají dvěma různým možnostem serveru Microsoft Exchange, který má poštovní schránku uživatele:

Architektura (Exchange Online)

Diagram that shows an architecture for enhanced security in an Outlook mobile access scenario. The user's mailbox is in Exchange Online.

V tomto scénáři musí uživatelé používat mobilního klienta, který podporuje moderní ověřování. Doporučujeme Outlook Mobile (Outlook pro iOS nebo Outlook pro Android), který podporuje Microsoft. Následující pracovní postup používá mobilní aplikaci Outlook.

Stáhněte si soubor Visia se všemi diagramy v tomto článku.

Pracovní postup (Exchange Online)

  1. Uživatel spustí konfiguraci profilu Outlooku zadáním e-mailové adresy. Outlook Mobile se připojuje ke službě Automatické rozpoznávání.
  2. Služba AutoDetect vytvoří anonymní požadavek automatické konfigurace V2 na Exchange Online, aby poštovní schránku získala. Odpovědi Exchange Online s odpovědí přesměrování 302, která obsahuje adresu URL activesync pro poštovní schránku odkazující na Exchange Online. Tady vidíte příklad tohoto typu požadavku.
  3. Když teď služba AutoDetect obsahuje informace o koncovém bodu obsahu poštovní schránky, může bez ověřování volat ActiveSync.
  4. Jak je popsáno v tomto toku připojení, Exchange odpoví odpovědí na výzvu 401. Obsahuje autorizační adresu URL, která identifikuje koncový bod Microsoft Entra, který musí klient použít k získání přístupového tokenu.
  5. Služba AutoDetect vrátí klientovi koncový bod autorizace Microsoft Entra.
  6. Klient se připojí k Microsoft Entra ID a dokončí ověřování a zadá přihlašovací údaje (e-mail).
  7. Pokud je doména federovaná, požadavek se přesměruje na webovou proxy aplikací.
  8. Webové proxy aplikací proxy serverem požadavek na ověření do služby AD FS. Uživatel uvidí přihlašovací stránku.
  9. Uživatel zadá přihlašovací údaje pro dokončení ověřování.
  10. Uživatel se přesměruje zpět na MICROSOFT Entra ID.
  11. Microsoft Entra ID používá zásady podmíněného přístupu Azure.
  12. Tato zásada může vynutit omezení na základě stavu zařízení uživatele, pokud je zařízení zaregistrované v Microsoft Endpoint Manageru, vynucuje zásady ochrany aplikací nebo vynucuje vícefaktorové ověřování. Podrobný příklad tohoto typu zásady najdete v krocích implementace popsaných zde.
  13. Uživatel implementuje všechny požadavky na zásady a dokončí žádost o vícefaktorové ověřování.
  14. Id Microsoft Entra vrátí klientovi přístup a obnovovací tokeny.
  15. Klient používá přístupový token pro připojení k Exchangi Online a načtení obsahu poštovní schránky.

Konfigurace (Exchange Online)

Pokud chcete blokovat pokusy o přístup k Exchangi Online ActiveSync prostřednictvím starší verze ověřování (červená přerušovaná čára v diagramu), musíte vytvořit zásadu ověřování, která zakáže starší ověřování pro protokoly, které používá mobilní služba Outlooku. Konkrétně je potřeba zakázat službu AutoDiscover, ActiveSync a Outlook. Tady je odpovídající konfigurace zásad ověřování:

AllowBasicAuthAutodiscover: False

AllowBasicAuthActiveSync: False

AllowBasicAuthOutlookService: False

Po vytvoření zásady ověřování ji můžete přiřadit pilotní skupině uživatelů. Po otestování pak můžete zásadu rozbalit pro všechny uživatele. Pokud chcete zásady použít na úrovni organizace, použijte Set-OrganizationConfig -DefaultAuthenticationPolicy <name_of_policy> tento příkaz. Pro tuto konfiguraci musíte použít Exchange Online PowerShell.

U federovaných domén můžete službu AD FS nakonfigurovat tak, aby místo použití zásad podmíněného přístupu aktivovala vícefaktorové ověřování. Doporučujeme ale řídit připojení a používat omezení na úrovni zásad podmíněného přístupu.

Architektura (místní Exchange)

Diagram that shows an architecture for enhanced security in an Outlook mobile access scenario. The user's mailbox is in Exchange on-premises.

Stáhněte si soubor Visia se všemi diagramy v tomto článku.

V tomto scénáři musí uživatelé používat mobilního klienta, který podporuje moderní ověřování, jak je popsáno v tématu Použití hybridního moderního ověřování. Doporučujeme Outlook Mobile (Outlook pro iOS nebo Outlook pro Android), který podporuje Microsoft. Následující pracovní postup používá mobilní aplikaci Outlook.

Pracovní postup (místní Exchange)

  1. Uživatel spustí konfiguraci profilu Outlooku zadáním e-mailové adresy. Outlook Mobile se připojuje ke službě Automatické rozpoznávání.
  2. Služba AutoDetect vytvoří anonymní požadavek automatické konfigurace V2 na Exchange Online, aby poštovní schránku získala.
  3. Jakmile se poštovní schránka nachází místně, Exchange Online odpoví odpovědí s odpovědí přesměrování 302, která obsahuje místní adresu URL automatické konfigurace, kterou může funkce AutoDetect použít k načtení adresy URL activesync pro poštovní schránku.
  4. Funkce AutoDetect používá místní adresu URL, kterou přijala v předchozím kroku, k vytvoření anonymního požadavku AutoDiscover v2 na místní Exchange, aby se poštovní schránka získala. Místní Exchange vrátí adresu URL ActiveSync pro poštovní schránku, která odkazuje na místní Exchange. Tady vidíte příklad tohoto typu požadavku.
  5. Když teď služba AutoDetect obsahuje informace o koncovém bodu obsahu poštovní schránky, může bez ověřování volat místní koncový bod ActiveSync. Jak je popsáno v tomto toku připojení, Exchange odpoví odpovědí na výzvu 401. Obsahuje autorizační adresu URL, která identifikuje koncový bod Microsoft Entra, který musí klient použít k získání přístupového tokenu.
  6. Služba AutoDetect vrátí klientovi koncový bod autorizace Microsoft Entra.
  7. Klient se připojí k Microsoft Entra ID a dokončí ověřování a zadá přihlašovací údaje (e-mail).
  8. Pokud je doména federovaná, požadavek se přesměruje na webovou proxy aplikací.
  9. Webové proxy aplikací proxy serverem požadavek na ověření do služby AD FS. Uživatel uvidí přihlašovací stránku.
  10. Uživatel zadá přihlašovací údaje pro dokončení ověřování.
  11. Uživatel se přesměruje zpět na MICROSOFT Entra ID.
  12. Microsoft Entra ID používá zásady podmíněného přístupu Azure.
  13. Tato zásada může vynutit omezení na základě stavu zařízení uživatele, pokud je zařízení zaregistrované v Microsoft Endpoint Manageru, vynucuje zásady ochrany aplikací nebo vynucuje vícefaktorové ověřování. Podrobný příklad tohoto typu zásady najdete v krocích implementace popsaných zde.
  14. Uživatel implementuje všechny požadavky na zásady a dokončí žádost o vícefaktorové ověřování.
  15. Id Microsoft Entra vrátí klientovi přístup a obnovovací tokeny.
  16. Klient používá přístupový token pro připojení k Exchangi Online a načtení obsahu místní poštovní schránky. Obsah by měl být poskytnut z mezipaměti, jak je popsáno zde. Aby toho dosáhl, klient vydá žádost o zřízení, která zahrnuje přístupový token uživatele a místní koncový bod ActiveSync.
  17. Rozhraní API pro zřizování v Exchangi Online přebírá zadaný token jako vstup. Rozhraní API získá druhý pár tokenů přístupu a aktualizace pro přístup k místní poštovní schránce prostřednictvím volání služby Active Directory jménem. Tento druhý přístupový token je vymezen klientem jako Exchange Online a cílovou skupinou místního koncového bodu oboru názvů ActiveSync.
  18. Pokud poštovní schránka není zřízená, rozhraní API pro zřizování vytvoří poštovní schránku.
  19. Rozhraní API pro zřizování vytvoří zabezpečené připojení k místnímu koncovému bodu ActiveSync. Rozhraní API synchronizuje data zasílání zpráv uživatele pomocí druhého přístupového tokenu jako ověřovacího mechanismu. Obnovovací token se pravidelně používá k vygenerování nového přístupového tokenu, aby se data mohly synchronizovat na pozadí bez zásahu uživatele.
  20. Data se vrátí klientovi.

Konfigurace (místní Exchange)

Pokud chcete blokovat pokusy o přístup k místní službě ActiveSync exchange prostřednictvím starší verze ověřování (červené přerušované čáry v diagramu), musíte vytvořit zásadu ověřování, která zakáže starší ověřování pro protokoly, které používá mobilní služba Outlooku. Konkrétně je potřeba zakázat funkci AutoDiscover a ActiveSync. Tady je odpovídající konfigurace zásad ověřování:

BlockLegacyAuthAutodiscover: True

BlockLegacyAuthActiveSync: True

Tady je příklad příkazu pro vytvoření této zásady ověřování:

New-AuthenticationPolicy -Name BlockLegacyActiveSyncAuth -BlockLegacyAuthActiveSync -BlockLegacyAuthAutodiscover

Po vytvoření zásady ověřování ji můžete nejprve přiřadit pilotní skupině uživatelů pomocí Set-User user01 -AuthenticationPolicy <name_of_policy> příkazu. Po testování můžete zásadu rozšířit tak, aby zahrnovala všechny uživatele. Pokud chcete zásady použít na úrovni organizace, použijte Set-OrganizationConfig -DefaultAuthenticationPolicy <name_of_policy> tento příkaz. Pro tuto konfiguraci musíte použít místní Prostředí PowerShell pro Exchange.

Musíte také podniknout kroky, abyste dosáhli konzistence a povolili přístup jenom z klienta Outlooku. Pokud chcete aplikaci Outlook Mobile povolit jako jediného schváleného klienta v organizaci, musíte zablokovat pokusy o připojení od klientů, kteří nejsou mobilními klienty Outlooku, kteří podporují moderní ověřování. Tyto pokusy na místní úrovni Exchange je potřeba zablokovat provedením těchto kroků:

  • Blokovat ostatní klienty mobilních zařízení:

    Set-ActiveSyncOrganizationSettings -DefaultAccessLevel Block

  • Povolení připojení k místnímu Exchangi Online:

    If ((Get-ActiveSyncOrganizationSettings).DefaultAccessLevel -ne "Allow") {New-ActiveSyncDeviceAccessRule -Characteristic DeviceType -QueryString "OutlookService" -AccessLevel Allow}

  • Blokování základního ověřování pro Outlook pro iOS a Android:

    New-ActiveSyncDeviceAccessRule -Characteristic DeviceModel -QueryString "Outlook for iOS and Android" -AccessLevel Block

Další informace o těchto krocích najdete v tématu Použití hybridního moderního ověřování v Outlooku pro iOS a Android.

U federovaných domén můžete službu AD FS nakonfigurovat tak, aby místo použití zásad podmíněného přístupu aktivovala vícefaktorové ověřování. Doporučujeme ale řídit připojení a používat omezení na úrovni zásad podmíněného přístupu.

Součásti

  • Microsoft Entra ID. Microsoft Entra ID je cloudová služba pro správu identit a přístupu Od Microsoftu. Poskytuje moderní ověřování, které je v podstatě založené na EvoSTS (služba tokenů zabezpečení používaná Microsoft Entra ID). Používá se jako ověřovací server pro místní Exchange Server.
  • Vícefaktorové ověřování Microsoft Entra Vícefaktorové ověřování je proces, při kterém se uživatelům během procesu přihlašování zobrazí výzva k zadání jiné formy identifikace, například kódu na mobilním telefonu nebo při skenování otisku prstu.
  • Podmíněný přístup Microsoft Entra. Podmíněný přístup je funkce, kterou Microsoft Entra ID používá k vynucení zásad organizace, jako je vícefaktorové ověřování.
  • AD FS. Služba AD FS umožňuje správu federovaných identit a přístupu sdílením práv k digitálním identitám a nárokům napříč hranicemi zabezpečení a podniku s lepším zabezpečením. V těchto architekturách se používá k usnadnění přihlašování uživatelů s federovanou identitou.
  • Webová proxy aplikací Webové proxy aplikací předem ověří přístup k webovým aplikacím pomocí služby AD FS. Funguje také jako proxy služby AD FS.
  • Microsoft Intune. Intune je naše cloudová sjednocená správa koncových bodů, správa koncových bodů v operačních systémech Windows, Android, Mac, iOS a Linux.
  • Exchange Server. Exchange Server hostuje místní poštovní schránky uživatelů. V těchto architekturách používá tokeny vystavené uživateli microsoft Entra ID k autorizaci přístupu k poštovním schránkám.
  • Služby Active Directory. Služba Active Directory services ukládá informace o členech domény, včetně zařízení a uživatelů. V těchto architekturách uživatelské účty patří ke službám Active Directory a synchronizují se s Microsoft Entra ID.

Alternativy

Mobilní klienti třetích stran, kteří podporují moderní ověřování, můžete použít jako alternativu k Mobilní aplikaci Outlook. Pokud zvolíte tuto alternativu, dodavatel třetí strany zodpovídá za podporu klientů.

Podrobnosti scénáře

Podniková infrastruktura zasílání zpráv (EMI) je klíčovou službou pro organizace. Přechod ze starších, méně zabezpečených metod ověřování a autorizace na moderní ověřování je zásadní výzvou na světě, kde je běžná vzdálená práce. Implementace požadavků na vícefaktorové ověřování pro přístup ke službě zasílání zpráv je jedním z nejúčinnějších způsobů, jak tuto výzvu splnit.

Tento článek popisuje dvě architektury, které vám pomůžou vylepšit zabezpečení ve scénáři mobilního přístupu Outlooku pomocí vícefaktorového ověřování Microsoft Entra.

Tyto scénáře jsou popsány v tomto článku:

  • Mobilní přístup k Outlooku, když je poštovní schránka uživatele v Exchangi Online
  • Mobilní přístup k Outlooku, když je poštovní schránka uživatele v místním Exchangi

Obě architektury pokrývají Outlook pro iOS i Outlook pro Android.

Informace o použití vícefaktorového ověřování v jiných scénářích hybridního zasílání zpráv najdete v těchto článcích:

Tento článek se nezabírá o jiných protokolech, jako je IMAP nebo POP. Tyto scénáře obvykle nepoužívají tyto protokoly.

Obecné poznámky

  • Tyto architektury používají model federované identity Microsoft Entra. Pro synchronizaci hodnot hash hesel a modely předávacího ověřování je logika a tok stejné. Jediný rozdíl souvisí se skutečností, že ID Microsoft Entra nepřesměruje žádost o ověření na službu místní Active Directory Federation Services (AD FS).
  • V diagramech zobrazují černé přerušované čáry základní interakce mezi místními komponentami Active Directory, Microsoft Entra Připojení, Microsoft Entra ID, AD FS a webovou proxy aplikací. O těchto interakcích se dozvíte v portech a protokolech požadovaných pro hybridní identitu.
  • Místní Exchange znamená, že Exchange 2019 s nejnovějšími aktualizacemi a rolí poštovní schránky.
  • Ve skutečném prostředí nebudete mít jenom jeden server. Budete mít pole serverů Exchange s vyrovnáváním zatížení pro zajištění vysoké dostupnosti. Zde popsané scénáře jsou vhodné pro danou konfiguraci.

Potenciální případy použití

Tato architektura je relevantní pro následující scénáře:

  • Vylepšení zabezpečení EMI
  • Přijměte strategii zabezpečení nulová důvěra (Zero Trust).
  • Během přechodu na exchange Online nebo koexistence použijte standardní vysokou úroveň ochrany pro místní službu zasílání zpráv.
  • V uzavřených nebo vysoce zabezpečených organizacích, jako jsou ty z finančního sektoru, vynucujte přísné požadavky na zabezpečení nebo dodržování předpisů.

Požadavky

Tyto aspekty implementují pilíře dobře architektuře Azure, což je sada hlavních principů, které je možné použít ke zlepšení kvality úlohy. Další informace naleznete v tématu Microsoft Azure Well-Architected Framework.

Spolehlivost

Spolehlivost zajišťuje, že vaše aplikace může splňovat závazky, které uděláte pro vaše zákazníky. Další informace najdete v tématu Přehled pilíře spolehlivosti.

Dostupnost

Celková dostupnost závisí na dostupnosti zahrnutých komponent. Informace o dostupnosti najdete v těchto zdrojích informací:

Dostupnost místních komponent řešení závisí na implementovaném návrhu, dostupnosti hardwaru a vašich interních operacích a rutinách údržby. Informace o dostupnosti některých z těchto komponent najdete v následujících zdrojích informací:

Pokud chcete používat hybridní moderní ověřování, musíte zajistit, aby všichni klienti ve vaší síti měli přístup k Microsoft Entra ID. Musíte také konzistentně udržovat porty brány firewall Office 365 a otevírání rozsahu IP adres.

Informace o požadavcích na protokol a port pro Exchange Server najdete v tématu Požadavky klienta a protokolu Exchange v přehledu hybridního moderního ověřování pro použití s místními Skype pro firmy a servery Exchange.

Pro rozsahy IP adres a porty Office 365 se podívejte na adresy URL a rozsahy IP adres Office 365.

Informace o hybridním moderním ověřování a mobilních zařízeních najdete v článku o koncovém bodu Automatické rozpoznávání v jiných koncových bodech, které nejsou součástí IP adresy a webové služby Office 365.

Odolnost

Informace o odolnosti komponent v této architektuře najdete v následujících zdrojích informací.

Zabezpečení

Obecné pokyny k zabezpečení mobilních zařízení najdete v tématu Ochrana dat a zařízení pomocí Microsoft Intune.

Informace o zabezpečení a hybridním moderním ověřování najdete v tématu Podrobné informace o tom, jak hybridní ověřování skutečně funguje.

U uzavřených organizací, které mají tradiční silnou hraniční ochranu, existují obavy týkající se zabezpečení souvisejících s konfigurací Exchange Hybrid Classic. Hybridní konfigurace Exchange Modern nepodporuje hybridní moderní ověřování.

Informace o Microsoft Entra ID naleznete v průvodci operacemi zabezpečení Microsoft Entra.

Informace o scénářích, které používají zabezpečení služby AD FS, najdete v těchto článcích:

Optimalizace nákladů

Náklady na implementaci závisí na nákladech na licence Microsoft Entra ID a Microsoft 365. Celkové náklady zahrnují také náklady na software a hardware pro místní komponenty, provoz IT, školení a vzdělávání a implementaci projektů.

Tato řešení vyžadují alespoň Microsoft Entra ID P1. Podrobnosti o cenách najdete na stránce s cenami Microsoft Entra.

Informace o službě AD FS a webové proxy aplikací naleznete v tématu Ceny a licencování systému Windows Server 2022.

Další informace o cenách najdete v těchto zdrojích informací:

Efektivita výkonu

Výkon závisí na výkonu komponent, které jsou součástí, a na výkonu sítě vaší společnosti. Další informace najdete v tématu Ladění výkonu Office 365 pomocí standardních hodnot a historie výkonu.

Informace o místních faktorech, které ovlivňují výkon ve scénářích, které zahrnují služby AD FS, najdete v těchto zdrojích informací:

Škálovatelnost

Informace o škálovatelnosti služby AD FS najdete v tématu Plánování kapacity serveru služby AD FS.

Informace o místní škálovatelnosti Exchange Serveru najdete v tématu Upřednostňovaná architektura Exchange 2019.

Nasazení tohoto scénáře

Pokud chcete tuto infrastrukturu implementovat, musíte dokončit kroky popsané v doprovodných materiálech obsažených v následujících článcích. Tady jsou základní kroky:

  1. Zabezpečený mobilní přístup Outlooku, jak je popsáno v těchto krocích implementace pro moderní ověřování.
  2. Zablokujte všechny ostatní starší pokusy o ověření na úrovni ID Microsoft Entra.
  3. Zablokujte starší pokusy o ověření na úrovni služeb zasílání zpráv pomocí zásad ověřování.

Přispěvatelé

Tento článek spravuje Microsoft. Původně byla napsána následujícími přispěvateli.

Hlavní autoři:

Pokud chcete zobrazit neveřejné profily LinkedIn, přihlaste se na LinkedIn.

Další kroky