Povinné vícefaktorové ověřování pro portály Azure a pro správu

V Microsoftu se zavazujeme poskytovat našim zákazníkům nejvyšší úroveň zabezpečení. Jedním z nejúčinnějších dostupných bezpečnostních opatření je vícefaktorové ověřování (MFA). Výzkum od Microsoftu ukazuje, že vícefaktorové ověřování může blokovat více než 99,2% útoků na ohrožení účtu.

Proto od roku 2024 zavedeme povinné vícefaktorové ověřování (MFA) pro všechny pokusy o přihlášení do Azure. Další informace o tomto požadavku najdete v blogových příspěvcích Azure povinné vícefaktorové ověřování: Fáze 2 počínaje říjnem 2025 a Nastavení povinného vícefaktorového ověřování pro Azure přihlášení. Toto téma popisuje, které aplikace a účty jsou ovlivněné, jak se vynucuje tenantům, a další běžné otázky a odpovědi.

Pokud už vaše organizace vynucuje vícefaktorové ověřování pro ně, nebo pokud se přihlašují pomocí silnějších metod, jako je bez hesla nebo klíč (FIDO2), neexistuje žádná změna. Pokud chcete ověřit, že je vícefaktorové ověřování povolené, přečtěte si, jak ověřit, jestli jsou uživatelé nastaveni pro povinné vícefaktorové ověřování.

Rozsah vynucování

Rozsah vynucování se týká načasování vynucení, ovlivněných aplikací a požadavků na účet.

Fáze vynucení

Note

Datum vynucení pro fázi 2 se změnilo na 1. října 2025.

Vynucení vícefaktorového ověřování pro aplikace se provádí ve dvou fázích.

Aplikace fáze 1

Od října 2024 se vyžaduje vícefaktorové ověřování pro účty, které se přihlašují k Azure portal, Centru pro správu Microsoft Entra a centru pro správu Microsoft Intune k provedení jakékoli operace vytvoření, čtení, aktualizace nebo odstranění (CRUD). Zavádění se postupně uplatní u všech nájemců po celém světě. Od února 2025 začne vynucování vícefaktorového ověřování postupně pro přihlášení k Centrum pro správu Microsoftu 365. Fáze 1 nebude mít vliv na jiné klienty Azure, jako jsou Azure CLI, Azure PowerShell, Azure mobilní aplikace nebo nástroje IaC.

Aplikace fáze 2

Od 1. října 2025 začne vynucování vícefaktorového ověřování postupně u účtů, které se přihlašují k Azure CLI, Azure PowerShell, Azure mobilních aplikací, nástrojů IaC a koncových bodů rozhraní REST API pro provádění jakékoli operace vytvoření, aktualizace nebo odstranění. Operace čtení nevyžadují vícefaktorové ověřování.

Někteří zákazníci můžou jako účet služby používat uživatelský účet v Microsoft Entra ID. Doporučujeme migrovat tyto uživatelské účty služeb do bezpečných cloudových účtů služeb s identitou zátěže.

ID a adresy URL aplikací

Následující tabulka uvádí ovlivněné aplikace, ID aplikací a adresy URL pro Azure.

Název aplikace ID aplikace Vynucení začíná.
Azure Portal c44b4083-3bb0-49c1-b47d-974e53cbdf3c Druhá polovina roku 2024
Centrum pro správu Microsoft Entra c44b4083-3bb0-49c1-b47d-974e53cbdf3c Druhá polovina roku 2024
Centrum pro správu Microsoft Intune c44b4083-3bb0-49c1-b47d-974e53cbdf3c Druhá polovina roku 2024
Azure rozhraní příkazového řádku (Azure CLI) 04b07795-8ddb-461a-bbee-02f9e1bf7b46 1. října 2025
Azure PowerShell 1950a258-227b-4e31-a9cf-717495945fc2 1. října 2025
mobilní aplikace Azure 0c1307d4-29d6-4389-a11c-5cbe7f65d7fa 1. října 2025
Nástroje infrastruktury jako kódu (IaC) Použijte Azure CLI nebo ID Azure PowerShell 1. října 2025
REST API (řídicí rovina) N/A 1. října 2025
Azure SDK N/A 1. října 2025

Následující tabulka uvádí ovlivněné aplikace a adresy URL pro Microsoft 365.

Název aplikace URL Vynucení začíná.
Centrum pro správu Microsoft 365 https://portal.office.com/adminportal/home Únor 2025
Centrum pro správu Microsoft 365 https://admin.cloud.microsoft Únor 2025
Centrum pro správu Microsoft 365 https://admin.microsoft.com Únor 2025

Accounts

Všechny účty, které se přihlašují k provádění operací uvedených v sekci aplikací, musí po zahájení vynucení dokončit vícefaktorové ověřování. Uživatelé nemusí používat vícefaktorové ověřování, pokud přistupují k jiným aplikacím, webům nebo službám hostovaným na Azure. Každá aplikace, web nebo vlastník služby uvedené výše řídí požadavky na ověřování pro uživatele.

Účty pro použití v nouzi se po zahájení vynucení rovněž vyžadují přihlašovat pomocí vícefaktorového ověřování. Doporučujeme, abyste tyto účty aktualizovali tak, aby používaly klíč (FIDO2) nebo nakonfigurovali ověřování na základě certifikátů pro vícefaktorové ověřování. Obě metody splňují požadavek vícefaktorového ověřování.

Identity úloh, jako jsou spravované identity a služební principály, nejsou ovlivněny ani jednou fází tohoto vynucení vícefaktorového ověřování. Pokud se uživatelské identity používají k přihlášení jako servisní účet ke spuštění automatizace (včetně skriptů nebo jiných automatizovaných úloh), musí se tyto uživatelské identity po zahájení vynucení přihlásit pomocí vícefaktorové autentizace. Pro automatizaci se nedoporučují identity uživatelů. Tyto identity uživatelů byste měli migrovat do identit úloh.

Klientské knihovny

Metoda udělení tokenu pomocí hesla vlastníka zdroje OAuth 2.0 (ROPC) není kompatibilní s vícefaktorovým ověřováním. Po povolení vícefaktorového ověřování ve vašem tenantovi Microsoft Entra mohou ve vašich aplikacích rozhraní API založená na ROPC vyvolat výjimky. Další informace o migraci z rozhraní API založených na ROPC v Microsoft Authentication Libraries (MSAL) najdete v části Postup migrace z ROPC. Pokyny pro MSAL specifické pro jednotlivé jazyky najdete na následujících kartách.

Změny se vyžadují, pokud ve své aplikaci použijete balíček Microsoft.Identity.Client a jedno z následujících rozhraní API. Rozhraní API veřejného klienta je zastavenood verze 4.74.0:

Stejné obecné pokyny MSAL platí pro knihovny identit Azure. Třída UsernamePasswordCredential poskytovaná v těchto knihovnách používá rozhraní API založená na MSAL ROPC. Pokyny pro konkrétní jazyk najdete na následujících kartách.

Pokud použijete balíček Azure.Identity a provedete jednu z následujících akcí ve vaší aplikaci, jsou vyžadovány změny.

Migrace uživatelských účtů služeb do identit úloh

Doporučujeme zákazníkům zjistit uživatelské účty, které se používají jako účty služeb, a začít je migrovat na identity úloh. Migrace často vyžaduje aktualizaci skriptů a procesů automatizace pro použití identit úloh.

Přečtěte si , jak ověřit, že jsou uživatelé nastaveni pro povinné vícefaktorové ověřování k identifikaci všech uživatelských účtů, včetně uživatelských účtů používaných jako účty služeb, které se přihlašují k aplikacím.

Další informace o tom, jak migrovat z uživatelských účtů služeb na identity úloh pro ověřování pomocí těchto aplikací, najdete tady:

Někteří zákazníci používají zásady podmíněného Access pro uživatelské účty služeb. Licenci založenou na uživatelích můžete uvolnit a přidat licenci pro použití Conditional Access pro identity pracovního zatížení.

Migrace poskytovatele federované identity na externí vícefaktorovou autentizaci (MFA)

Podpora externích řešení vícefaktorového ověřování je k dispozici u externího vícefaktorového ověřování a dá se použít ke splnění požadavku na vícefaktorové ověřování. Starší verze podmíněného přístupu ve verzi Preview vlastních ovládacích prvků nesplňuje požadavek na vícefaktorové ověřování. Pokud chcete použít externí řešení s ID Microsoft Entra, měli byste provést migraci na externí vícefaktorové ověřování.

Pokud používáte federovaného zprostředkovatele identity (IDP), jako je Služby Active Directory Federation, a váš zprostředkovatel MFA je integrovaný přímo s tímto federovaným zprostředkovatelem identity, musí být federovaný zprostředkovatele identity nakonfigurovaný tak, aby odeslal deklaraci vícefaktorového ověřování. Další informace naleznete v tématu Očekávaná příchozí tvrzení pro Microsoft Entra MFA.

Připravte se na povinné vynucení vícefaktorového ověřování

Pokud se chcete připravit na vynucování vícefaktorového ověřování, nakonfigurujte zásadu Conditional Access, která vyžaduje, aby se uživatelé přihlásili pomocí vícefaktorového ověřování. Pokud jste v zásadách nakonfigurovali výjimky nebo vyloučení, nebudou už platit. Pokud máte více omezující zásady podmíněného přístupu, které cílí na Azure a vyžadují silnější ověřování, například vícefaktorové ověřování odporující phishingu, zůstanou vynucené.

Podmíněný Access vyžaduje licenci Microsoft Entra ID P1 nebo P2. Pokud nemůžete použít podmíněný přístup, povolte bezpečnostní výchozí nastavení .

Vícefaktorové ověřování můžete vynutit sami pomocí předdefinovaných definic v Azure Policy. Další informace a podrobný přehled použití těchto přiřazení zásad ve vašem prostředí najdete v tématu Tutorial: Použití samoobslužného vynucování vícefaktorového ověřování prostřednictvím Azure Policy. Azure Policy podporuje Audit účinek (který hlásí nedodržování předpisů ve výsledcích dodržování zásad) i Deny účinek, který blokuje požadavky nesplňující požadavky.

Pro zajištění co nejlepší kompatibility zajistěte, aby uživatelé ve vašem tenantovi používali Azure CLI verze 2.76 a Azure PowerShell verze 14.3 nebo novější. V opačném případě můžete očekávat, že se zobrazí chybové zprávy, jak je vysvětleno v těchto tématech:

Note

Uživatelé, kteří se přihlašují bez vícefaktorového ověřování, můžou používat aplikaci fáze 2. Pokud se ale pokusí vytvořit, aktualizovat nebo odstranit prostředek, aplikace vrátí chybu s informací, že se musí přihlásit pomocí vícefaktorového ověřování a výzvy deklarací identity. Někteří klienti používají výzvu pro ověřování nároků k pobídnutí uživatele ke zvýšení úrovně zabezpečení a provedení vícefaktorového ověřování. Ostatní klienti vrátí pouze chybu bez výzvy vícefaktorového ověřování. Před zobrazením chyby se doporučuje použít zásady podmíněného přístupu nebo výchozí nastavení zabezpečení, které uživatelům pomůže splnit požadavky na vícefaktorové ověřování.

Žádost o více času na přípravu na vynucování vícefaktorového ověřování fáze 1

Chápeme, že někteří zákazníci můžou potřebovat více času na přípravu na tento požadavek vícefaktorového ověřování. Microsoft umožňuje zákazníkům se složitými prostředími nebo technickými bariérami odložit vynucení fáze 1 pro své tenanty do 30. září 2025.

Pro každého tenanta, u kterého chce odložit počáteční datum vynucení, může Global Administrator přejít na https://aka.ms/managemfaforazure a vybrat počáteční datum.

Caution

Když odložíte počáteční datum vynucování, riskujete, protože účty, které mají přístup ke službám Microsoftu, jako je Azure portál, jsou vysoce cenné cíle pro kybernetické útočníky. Doporučujeme, aby všichni tenanti nastavili vícefaktorové ověřování pro zabezpečení cloudových prostředků.

Požádejte o více času na přípravu na zavedení fáze 2 vícefaktorového ověřování.

Microsoft umožňuje zákazníkům se složitými prostředími nebo technickými překážkami odložit vynucení fáze 2 pro své tenanty do 1. července 2026. Můžete požádat o více času na přípravu na vynucení vícefaktorového ověřování ve fázi 2 na adrese https://aka.ms/postponePhase2MFA. Zvolte jiné počáteční datum a vyberte Použít. Po zahájení vynucování fáze 2 můžete odeslat žádost do nápovědy a podpory Microsoftu, které dočasně pozastaví vynucování. Požadavek musí provést Global Administrator kvůli dopadům na zabezpečení.

Note

Pokud jste odložili začátek fáze 1, začátek fáze 2 se také odloží na stejné datum. Pro fázi 2 můžete zvolit pozdější počáteční datum.

Snímek obrazovky o tom, jak odložit povinné vícefaktorové ověřování pro fázi dvě

Potvrďte povinné vynucení vícefaktorového ověřování

Potvrzení vynucení fáze 1

Ověření vynucení povinného vícefaktorového ověřování ve fázi 1 pro vašeho nájemce:

  1. Přihlaste se k webu Azure Portal jako globální správce.

  2. Přejděte na https://aka.ms/managemfaforazure.

  3. Ověřte, že se na stránce Vícefaktorové ověřování (fáze 1) zobrazuje banner, který potvrzuje, že pro vašeho tenanta začalo vynucování.

    Snímek obrazovky se stránkou Vícefaktorové ověřování fáze 1 na webu Azure Portal zobrazující vynucení vícefaktorového ověřování pro všechny uživatele v adresáři

Potvrzení vynucení fáze 2

Chcete-li ověřit, že je pro vašeho nájemce vynucována povinná vícefaktorová autentizace fáze 2:

  1. Přihlaste se k webu Azure Portal jako globální správce.

  2. Přejděte na https://aka.ms/postponePhase2MFA.

  3. Ověřte, že se na stránce Vícefaktorové ověřování (fáze 2) zobrazuje banner, který potvrzuje, že pro vašeho tenanta začalo vynucování.

    Snímek obrazovky se stránkou Vícefaktorové ověřování fáze 2 na Azure portálu, která ukazuje, že vynucení vícefaktorového ověřování začalo 20. února 2026 nebo později.

Microsoft Entra ID přihlašovací záznamy zobrazují aplikaci, která vynucuje vícefaktorové ověřování jako zdroj požadavku na něj.

FAQs

Otázka: Které účty mají vliv na vynucení vícefaktorového ověřování fáze 2?

Answer: vynucení Azure fáze 2 platí pro všechny uživatelské účty, které provádějí Azure akce správy prostředků prostřednictvím libovolného klienta Azure, včetně PowerShellu, rozhraní příkazového řádku, sad SDK nebo rozhraní REST API. Toto vynucení je na straně serveru Azure Resource Manager, takže všechny požadavky, které cílí na https://management.azure.com, spadají do rozsahu vynucení. Automatizační účty nejsou relevantní, pokud používají spravovanou identitu nebo službu principal. Všechny účty automatizace, které jsou nastavené jako identity uživatelů, budou podléhat vynucení.

Question: Jak mohu porozumět dopadu vynucení vícefaktorového ověřování bez Conditional Access?

Answer: Pokud licence Microsoft Entra ID neobsahuje podmíněné Access, můžete pomocí Azure Policy zjistit, jak vynucení vícefaktorového ověřování ovlivňuje vašeho tenanta. Během vynucování systému Microsoft nasadí do vašeho tenanta Azure Policy. Pomocí těchto kroků můžete kdykoli nasadit stejný Azure policy sami. Zásady můžete nasadit v režimu auditování a pak převést na režim vynucení. Můžete zvolit datum, kdy chcete tuto zásadu použít ve vašem tenantovi, když jste v režimu vynucení. Až Microsoft vynutí vícefaktorové ověřování, nebude to mít žádný další dopad na váš tenant.

Otázka: Existují nějaké výjimky pro konkrétní účty?

Answer: Vynucení systému platí pro všechny uživatelské účty, bez ohledu na to, jestli se jedná o účet studenta, účet break-glass, účet správce s aktivovanými nebo oprávněnými rolemi, nebo vyloučení uživatelů, které jsou pro ně povolené. Každý z těchto typů účtů může provádět akce správy prostředků v Azure, což představuje stejné bezpečnostní riziko v případě ohrožení zabezpečení.

Question: Jsou rozhraní API Microsoft Graph součástí vynucení fáze 2?

Answer: Obecně platí, že Microsoft Graph API nejsou v rozsahu pro použití Azure MFA. Pouze požadavky odeslané na https://management.azure.com/ jsou předmětem vynucování.

Otázka: Pokud se tenant používá jenom k testování, vyžaduje se vícefaktorové ověřování?

Answer: Ano, každý tenant Azure bude vyžadovat vícefaktorové ověřování bez výjimky pro testovací prostředí.

Požadavek: Jaký vliv má tento požadavek na Centrum pro správu Microsoftu 365?

Answer: Povinné vícefaktorové ověřování se zavede do Centrum pro správu Microsoftu 365 počínaje únorem 2025. Přečtěte si další informace o povinném požadavku na vícefaktorové ověřování pro Centrum pro správu Microsoftu 365 v blogovém příspěvku Požádání povinného vícefaktorového ověřování pro Centrum pro správu Microsoftu 365.

Otázka: Musím dokončit MFA, pokud zvolím možnost Zůstat přihlášen?

Odpověď: Ano, i když zvolíte Zůstat přihlášeni, musíte před přihlášením k těmto aplikacím dokončit vícefaktorové ověřování.

Otázka: Týká se uplatňování i B2B účtů hostů?

Answer: Ano, vícefaktorové ověřování musí být vyžadováno buď z partnerského tenanta, nebo domovského tenanta uživatele, pokud je správně nastaveno odesílání deklarací vícefaktorového ověřování do tenantu prostředku pomocí přístupu mezi tenanty.

Otázka: Platí vynucení pro Azure pro americkou státní správu nebo Azure svrchované cloudy?

Answer: Microsoft vynucuje povinné vícefaktorové ověřování jenom ve veřejném Azure cloudu. Microsoft v současné době nevynucuje vícefaktorové ověřování v Azure pro státní správu USA ani pro jiné suverénní cloudy Azure.

Otázka: Jak můžeme dodržovat, pokud vícefaktorové ověřování vynucujeme pomocí jiného zprostředkovatele identity nebo řešení MFA a nevynucujeme ho pomocí Microsoft Entra MFA?

Answer: Vícefaktorové ověřování třetích stran je možné integrovat přímo s Microsoft Entra ID. Další informace naleznete v tématu Microsoft Entra multifactor authentication external method provider reference. Microsoft Entra ID je možné volitelně nakonfigurovat s zprostředkovatelem federované identity. Pokud ano, musí být řešení zprostředkovatele identity správně nakonfigurované tak, aby se deklarace identity odeslala multipleauthn do Microsoft Entra ID. Další informace najdete v tématu Splnění požadavků Microsoft Entra ID vícefaktorového ověřování (MFA) prostřednictvím MFA deklarací od federovaného IdP.

Otázka: Ovlivní povinné vícefaktorové ověřování moji schopnost synchronizovat se službou Microsoft Entra Connect nebo Microsoft Entra Cloud Sync?

Odpověď: Ne. Povinný požadavek na vícefaktorové ověřování nemá vliv na účet synchronizační služby. Pro přihlášení vyžadují vícefaktorové ověřování jenom aplikace uvedené výše.

Otázka: Můžu se odhlásit?

Answer: Neexistuje způsob, jak se odhlásit. Tento pohyb zabezpečení je důležitý pro bezpečnost a zabezpečení platformy Azure a opakuje se napříč dodavateli cloudu. Podívejte se například na téma Zabezpečení podle návrhu: AWS pro vylepšení požadavků na vícefaktorové ověřování v roce 2024.

Pro zákazníky je k dispozici možnost odložit počáteční datum vynucení. Globální správci můžou přejít na Azure portal a odložit datum zahájení vynucení pro svého tenanta. Globální správci musí mít zvýšený přístup před odložením data zahájení povinného vícefaktorového ověřování na této stránce. Musí provést tuto akci pro každého nájemce, který potřebuje odklad.

Otázka: Můžu otestovat MFA, než Azure vynutí zásadu, a ujistit se, že se nic nepokazí?

Answer: Ano, můžete testovat své MFA prostřednictvím ručního nastavení MFA. Doporučujeme vám toto nastavení a testování. Pokud k vynucení vícefaktorového ověřování používáte podmíněný přístup, můžete k otestování zásad použít šablony podmíněného přístupu. Další informace najdete v tématu Požádání vícefaktorového ověřování pro správce přistupující k portálům pro správu Microsoftu. Pokud používáte bezplatnou edici Microsoft Entra ID, můžete povolit výchozí nastavení security.

Otázka: Co když už mám povolené vícefaktorové ověřování, co se stane dál?

Answer: Zákazníci, kteří už vyžadují vícefaktorové ověřování pro uživatele, kteří přistupují k výše uvedeným aplikacím, nevidí žádné změny. Pokud vyžadujete vícefaktorové ověřování jenom pro podmnožinu uživatelů, budou teď muset všichni uživatelé, kteří vícefaktorové ověřování nepoužívají, používat vícefaktorové ověřování, když se přihlásí k aplikacím.

Požadavek: Jak můžu zkontrolovat aktivitu vícefaktorového ověřování v Microsoft Entra ID?

Odpověď: Pokud chcete zkontrolovat podrobnosti o tom, kdy se uživateli zobrazí výzva k přihlášení pomocí vícefaktorového ověřování, použijte protokoly přihlášení Microsoft Entra. Další informace naleznete v tématu Podrobnosti o události přihlášení pro vícefaktorové ověřování Microsoft Entra.

Otázka: Co když mám scénář "rozbitého skla"?

Odpověď: Doporučujeme tyto účty aktualizovat tak, aby používaly klíč (FIDO2) nebo pro vícefaktorové ověřování konfigurovali ověřování na základě certifikátů . Obě metody splňují požadavek vícefaktorového ověřování.

Otázka: Co když jsem neobdržel e-mail o povolení vícefaktorového ověřování předtím, než bylo vynuceno, a pak budu uzamčen. Jak bych to měl vyřešit?

Odpověď: Uživatelé by neměli být uzamčeni, ale může se jim zobrazit zpráva vyzývající k povolení vícefaktorového ověřování, jakmile začne vynucování pro jejich tenant. Pokud je uživatel uzamčený, můžou se zde vyskytovat další problémy. Další informace najdete v tématu Uzamčení účtu.

Související obsah

Další informace o konfiguraci a nasazení vícefaktorového ověřování najdete v následujících tématech:

  • Last updated on