Sdílet prostřednictvím

Dopad vícefaktorového ověřování na Azure CLI ve scénářích automatizace

Tento článek popisuje, jak vícefaktorové ověřování (MFA) ovlivňuje úlohy automatizace, které používají identity uživatelů Microsoft Entra, a poskytuje pokyny k alternativním přístupům pro nepřerušenou automatizaci.

Důležité

Akce se vyžaduje, pokud pro automatizaci používáte identity uživatelů Microsoft Entra. Požadavky vícefaktorového ověřování vám brání v používání identit uživatelů Microsoft Entra pro ověřování ve scénářích automatizace. Organizace musí přejít na metody ověřování navržené pro automatizaci, jako jsou spravované identity nebo instanční objekty, které podporují neinteraktivní případy použití automatizace.

Omezení identit uživatelů s vícefaktorovým ověřováním v automatizaci

Poznámka:

Může se zobrazit chybová zpráva: je vyžadováno interaktivní ověřování při použití identity uživatele v rámci automatizace.

  • interaktivní ověřování: Vícefaktorové ověřování se aktivuje při interaktivním přihlašování při použití identity uživatele Microsoft Entra. U automatizačních skriptů, které spoléhají na identitu uživatele, MFA proces přeruší, protože vyžaduje další ověřovací kroky. Například ověřovací aplikace, telefonní hovor atd., které nemůžete automatizovat. Toto ověření brání automatizaci ve spuštění, pokud není ověřování zpracováno neinteraktivním způsobem, jako je spravovaná identita nebo aplikační identita.

  • Selhání skriptovaného přihlášení: Ve scénářích automatizace, jako je bezobslužné spouštění skriptů Azure CLI, způsobí uživatelská identita s povoleným vícefaktorovým ověřováním selhání skriptu při pokusu o ověření totožnosti. Vzhledem k tomu, že vícefaktorové ověřování vyžaduje interakci uživatele, není kompatibilní s neinteraktivními skripty. To znamená, že musíte přepnout na spravovanou identitu nebo služební principál, které obě používají neinteraktivní ověřování.

  • aspekty zabezpečení: Zatímco vícefaktorové ověřování přidává další vrstvu zabezpečení, může omezit flexibilitu automatizace, zejména v produkčních prostředích, kde musí automatizace běžet bez ručního zásahu. Přechod na spravované identity, instanční objekty nebo federované identity, které jsou navržené pro účely automatizace a nevyžadují vícefaktorové ověřování, je v takových prostředích praktičtější a bezpečnější.

Scénáře, které vyžadují aktualizace

Následující seznam obsahuje ukázkové scénáře, ve kterých zákazníci můžou pro automatizaci pomocí Azure CLI použít identitu uživatele Microsoft Entra. Tento seznam není vyčerpávající pro všechny scénáře.

Výstraha

Jakýkoli scénář automatizace, který používá identitu uživatele Microsoft Entra, vyžaduje aktualizaci.

  • Individuální nebo specifická oprávnění: Úlohy automatizace, které vyžadují oprávnění specifická pro uživatele, například akce vázané na roli jednotlivce nebo konkrétní atributy ID Microsoft Entra.

  • tok OAuth 2.0 ROPC: Tok udělení tokenu pomocí hesla vlastníka prostředku OAuth 2.0 (ROPC) není vhodný pro vícefaktorové ověřování. Scénáře automatizace využívající ROPC pro ověřování selžou, když je potřeba vícefaktorové ověřování, protože vícefaktorové ověřování nejde dokončit v neinteraktivním toku.

  • Přístup k prostředkům externím pro Azure: Scénáře automatizace, které vyžadují přístup k prostředkům Microsoftu 365. Například SharePoint, Exchange nebo jiné cloudové služby vázané na účet Microsoft jednotlivého uživatele.

  • Účty služby synchronizované z Active Directory do Microsoft Entra ID: Organizace používající účty služeb synchronizované ze služby Active Directory (AD) do Microsoft Entra ID. Je důležité si uvědomit, že tyto účty podléhají také požadavkům na vícefaktorové ověřování a aktivují stejné problémy jako jiné identity uživatelů.

  • kontext uživatele pro auditování nebo dodržování předpisů: Případy, kdy je potřeba provádět auditování na úrovni jednotlivých uživatelů z důvodů dodržování předpisů.

  • Jednoduchá konfigurace pro automatizaci s malými nebo nízkými riziky: Pro úlohy automatizace s malými nebo nízkými riziky. Například skript, který spravuje několik prostředků.

  • Automatizace řízená uživatelem v neprodukčních prostředích: Pokud je automatizace určená pro osobní nebo neprodukční prostředí, kde je za úkol zodpovědný jednotlivý uživatel.

  • Automatizace v rámci vlastního předplatného Azure uživatele: Pokud potřebuje automatizovat úlohy ve svém předplatném Azure, kde již má dostatečná oprávnění.

Přepnutí na spravovanou identitu nebo služební objekt se vyžaduje pro scénáře automatizace kvůli povinnému vynucení vícefaktorového ověřování pro uživatelské identity Microsoft Entra.

Jak začít

Pokud chcete migrovat skripty Azure CLI od používání az login s uživatelským účtem Microsoft Entra ID a heslem, postupujte následovně:

  1. Určete, která identita pracovního zatížení je pro vás nejvhodnější.

    • Hlavní služba
    • Spravovaná identita
    • Federovaná identita

  2. Získejte potřebná oprávnění k vytvoření nové identity úlohy nebo požádejte o pomoc správce Azure.

  3. Vytvořte identitu úlohy.

  4. Přiřaďte nové identitě role. Další informace o přiřazení rolí Azure najdete v tématu Kroky přiřazení role Azure. Pokud chcete přiřadit role pomocí Azure CLI, přečtěte si Přiřazení rolí Azure pomocí Azure CLI.

  5. Aktualizujte skripty Azure CLI tak, abyste se přihlašovali pomocí služebního objektu nebo spravované identity.

Klíčové koncepty hlavního objektu služby

  • Nelidská identita, která má přístup k více prostředkům Azure. Servisní principal se používá mnoha prostředky Azure a není svázán s jedním prostředkem Azure.
  • Podle potřeby můžete změnit vlastnosti a přihlašovací údaje objektu služby.
  • Ideální pro aplikace, které potřebují přístup k více prostředkům Azure napříč různými předplatnými.
  • Zvažované flexibilnější než spravované identity, ale méně bezpečné.
  • Často se označuje jako "objekt aplikace" v tenantovi Azure nebo v adresáři Microsoft Entra ID.

Další informace o aplikačních objektech viz:

Informace o tom, jak se přihlásit do Azure pomocí Azure CLI a služebního principála, najdete v tématu Přihlášení k Azure pomocí služebního principála pomocí Azure CLI

Klíčové koncepty spravovaných identit

  • Svázaná s konkrétním prostředkem Azure, který umožňuje, aby tento jeden prostředek přistupoval k jiným aplikacím Azure.
  • Přihlašovací údaje nejsou pro vás viditelné. Azure zpracovává tajné kódy, přihlašovací údaje, certifikáty a klíče.
  • Ideální pro prostředky Azure, které potřebují přístup k dalším prostředkům Azure v rámci jednoho předplatného.
  • Považuje se za méně flexibilní než služební principy, ale bezpečnější.
  • Existují dva typy spravovaných identit:
    • Systém přiřazený: Tento typ je 1:1 (jeden na jednoho) přístupový spoj mezi dvěma prostředky Azure.
    • Přiřazen uživatelem: Tento typ má vztah 1:M (jeden k mnoha), ve kterém má spravovaná identita přístup k více prostředkům Azure.

Další informace o spravovaných identitách najdete v tématu Spravované identity pro prostředky Azure.

Informace o tom, jak se přihlásit k Azure pomocí Azure CLI a spravované identity, najdete v tématu Přihlášení k Azure pomocí spravované identity pomocí Azure CLI

Klíčové koncepty federované identity

  • Federovaná identita umožňuje instančním objektům (registrace aplikací) a spravovaným identitám přiřazeným uživatelem důvěřovat tokenům od externího zprostředkovatele identity (IDP), jako je GitHub nebo Google.
  • Po vytvoření důvěryhodného vztahu vaše externí softwarové úlohy vyměňují si důvěryhodné tokeny od externího poskytovatele identity za přístupové tokeny z platformy Microsoft Identity.
  • Vaše softwarová úloha používá tento přístupový token pro přístup k prostředkům chráněným Microsoft Entra, ke kterým má úloha udělený přístup.
  • Federované identity jsou často nejlepším řešením pro následující scénáře:
    • Úloha spuštěná v jakémkoli clusteru Kubernetes
    • Akce na GitHubu
    • Úlohy spuštěné na výpočetních platformách Azure s využitím identit aplikací
    • Google Cloud
    • Amazon Web Services (AWS)
    • Úloha spuštěná na výpočetních platformách mimo Azure

Další informace o federovaných identitách najdete tady:

Řešení problémů

Chyba ROPC: Kvůli změně konfigurace provedené správcem

Když se pokusíte přihlásit do Azure pomocí hesla, jde o tok ROPC (Resource Owner Password Credential). Tato metoda ověřování není u vícefaktorového ověřování podporována. Tady je příklad:

az login --username $username –password $password

Pokud se pro uživatele vyžaduje vícefaktorové ověřování, výše uvedený příkaz selže s následující chybovou zprávou:

AADSTS50076: Due to a configuration change made by your administrator, or because you moved to a new location, you must use multi-factor authentication to access ‘’. Trace ID Correlation ID: Timestamp:

Řešení: Přepněte na metodu ověřování kompatibilní s vícefaktorovým ověřováním.

Upozornění mezi tenanty: Ověřování selhalo u tenanta

Pokud máte přístup k několika tenantům a jeden z nich vyžaduje vícefaktorové ověřování, azure CLI může zobrazit upozornění podobné této:

Authentication failed against tenant 00000000-0000-0000-0000-000000000000 'Tenant Name': AADSTSXXXXX: Due to a configuration change made by your administrator, or because you moved to a new location, you must use multi-factor authentication to access '00000000-0000-0000-0000-000000000000'. Trace ID: 00000000-0000-0000-0000-000000000000 Correlation ID: 00000000-0000-0000-0000-000000000000 Timestamp: yyyy-mm-dd hh:mm:ss.

Během fáze přihlášení se Azure CLI pokusí přihlásit pomocí prvního nalezeného tenantu. Zatímco pracujeme na řešení tohoto problému, zadejte tenanta, kterého chcete použít s parametrem --tenant.

az login --tenant 00000000-0000-0000-0000-000000000000

Další informace o vícefaktorové ověřování

Další podrobnosti o vícefaktorovém ověřování najdete na webu dokumentace k Microsoft Entra ID.

Viz také

  • Last updated on