Teilen über

Auswirkungen der mehrstufigen Authentifizierung auf Azure CLI in Automatisierungsszenarien

  • Artikel

In diesem Artikel wird erläutert, wie sich die mehrstufige Authentifizierung (MFA) auf Automatisierungsaufgaben auswirkt, die Microsoft Entra-Benutzeridentitäten verwenden, und enthält Anleitungen zu alternativen Ansätzen für die unterbrechungsfreie Automatisierung.

Wichtig

Die Aktion ist erforderlich, wenn Sie Microsoft Entra-Benutzeridentitäten für die Automatisierung verwenden. MFA-Anforderungen verhindern, dass Sie Microsoft Entra-Benutzeridentitäten für die Authentifizierung in Automatisierungsszenarien verwenden. Organisationen müssen zu Authentifizierungsmethoden wechseln, die für die Automatisierung entwickelt wurden, z. B. verwaltete Identitäten oder Dienstprinzipale, die nicht interaktive Automatisierungsanwendungsfälle unterstützen.

Einschränkungen von Benutzeridentitäten mit MFA in der Automatisierung

Anmerkung

Möglicherweise tritt die Fehlermeldung auf: Interaktive Authentifizierung ist erforderlich, wenn Sie eine Benutzeridentität mit Automatisierung verwenden.

  • interaktive Authentifizierung: MFA wird bei verwendung einer Microsoft Entra-Benutzeridentität während interaktiver Anmeldungen ausgelöst. Für Automatisierungsskripts, die auf eine Benutzeridentität vertrauen, stört MFA den Prozess, da es zusätzliche Überprüfungsschritte erfordert. Beispiel: Authentifikator-App, Telefonanruf usw., die Sie nicht automatisieren können. Diese Überprüfung verhindert, dass die Automatisierung ausgeführt wird, es sei denn, die Authentifizierung wird nicht interaktiv behandelt, z. B. mit einer verwalteten Identität oder einem Dienstprinzipal.

  • Skript-Anmeldefehler: In Automatisierungsszenarien wie dem unbeaufsichtigten Ausführen von Azure CLI-Skripts führt eine MFA-fähige Benutzeridentität dazu, dass das Skript fehlschlägt, wenn versucht wird, sich zu authentifizieren. Da MFA eine Benutzerinteraktion erfordert, ist sie nicht mit nicht interaktiven Skripts kompatibel. Dies bedeutet, dass Sie zu einer verwalteten Identität oder einem Service-Prinzipal wechseln müssen, die beide eine nicht-interaktive Authentifizierung verwenden.

  • Sicherheitsüberlegungen: Während MFA eine zusätzliche Sicherheitsebene hinzufügt, kann sie die Automatisierungsflexibilität einschränken, insbesondere in Produktionsumgebungen, in denen die Automatisierung ohne manuelle Eingriffe ausgeführt werden muss. Die Umstellung auf verwaltete Identitäten, Dienstprinzipale oder Verbundidentitäten, die für Automatisierungszwecke entwickelt wurden und keine MFA erfordern, ist in solchen Umgebungen praktischer und sicherer.

Szenarien, die Updates erfordern

Die folgende Liste enthält Beispielszenarien, in denen Kunden eine Microsoft Entra-Benutzeridentität für die Automatisierung mit Azure CLI verwenden können. Diese Liste ist nicht vollständig für alle Szenarien.

Warnung

Jedes Automatisierungsszenario, das eine Microsoft Entra-Benutzeridentität verwendet, erfordert eine Aktualisierung.

  • personalisierte oder bestimmte Berechtigungen: Automatisierungsaufgaben, die benutzerspezifische Berechtigungen erfordern, z. B. Aktionen, die an die Rolle einer Person oder bestimmte Microsoft Entra-ID-Attribute gebunden sind.

  • OAuth 2.0 ROPC-Fluss: Der OAuth 2.0 Resource Owner Password Credentials (ROPC)-Tokenzuteilungsfluss ist mit MFA nicht kompatibel. Automatisierungsszenarien, die ROPC für die Authentifizierung verwenden, schlagen fehl, wenn MFA erforderlich ist, da MFA nicht in einem nicht interaktiven Fluss abgeschlossen werden kann.

  • Zugriff auf Ressourcen außerhalb von Azure: Automatisierungsszenarien, die Zugriff auf Microsoft 365-Ressourcen erfordern. Beispielsweise SharePoint, Exchange oder andere Clouddienste, die an das Microsoft-Konto eines einzelnen Benutzers gebunden sind.

  • Dienstkonten, die von Active Directory zu Microsoft Entra ID synchronisiert wurden: Organisationen, die Dienstkonten verwenden, die aus Active Directory (AD) in Microsoft Entra ID synchronisiert wurden. Es ist wichtig zu beachten, dass diese Konten auch den MFA-Anforderungen unterliegen und dieselben Probleme wie andere Benutzeridentitäten auslösen.

  • Benutzerkontext für die Prüfung oder Compliance-: Fälle, in denen die Aktionen aus Compliance-Gründen auf Ebene einzelner Benutzer geprüft werden müssen.

  • Einfache Konfiguration für kleine oder risikoarme Automatisierung: Für kleine oder risikoarme Automatisierungsaufgaben. Beispielsweise ein Skript, das einige Ressourcen verwaltet.

  • Benutzergesteuerte Automatisierung in Nichtproduktionsumgebungen: Wenn die Automatisierung für persönliche oder nichtproduktion Umgebungen vorgesehen ist, in denen ein einzelner Benutzer für eine Aufgabe verantwortlich ist.

  • Automatisierung innerhalb des eigenen Azure-Abonnements eines Benutzers: Wenn ein Benutzer Aufgaben in seinem eigenen Azure-Abonnement automatisieren muss, in dem der Benutzer bereits über ausreichende Berechtigungen verfügt.

Für Automatisierungsszenarien ist der Wechsel zu einer verwalteten Identität oder einem Dienstprinzipal erforderlich, da die Durchsetzung der obligatorischen MFA für Microsoft Entra-Benutzeridentitäten notwendig ist.

So beginnen Sie

Führen Sie die folgenden Schritte aus, um Ihre Azure CLI-Skripts von der Verwendung von az login mit einem menschlichen Microsoft Entra-ID-Benutzerkonto und -Kennwort zu migrieren:

  1. Ermitteln Sie, welche Arbeitslastidentität für Sie am besten geeignet ist.

    • Dienstprinzipal
    • Verwaltete Identität
    • Verbundidentität

  2. Rufen Sie die erforderlichen Berechtigungen zum Erstellen einer neuen Workload-Identität ab, oder wenden Sie sich an Ihren Azure-Administrator, um Unterstützung zu erhalten.

  3. Erstellen Sie die Workload-Identität.

  4. Weisen Sie der neuen Identität Rollen zu. Weitere Informationen zu Azure-Rollenzuweisungen finden Sie unter Schritte zum Zuweisen einer Azure-Rolle. Informationen zum Zuweisen von Rollen mithilfe der Azure CLI finden Sie unter Zuweisen von Azure-Rollen mit Azure CLI.

  5. Aktualisieren Sie Ihre Azure CLI-Skripts, um sich mit einem Dienstprinzipal oder einer verwalteten Identität anzumelden.

Schlüsselkonzepte des Dienstprinzipals

  • Eine nicht menschliche Identität, die auf mehrere Azure-Ressourcen zugreifen kann. Ein Dienstprinzipal wird von vielen Azure-Ressourcen verwendet und ist nicht an eine einzelne Azure-Ressource gebunden.
  • Sie können die Eigenschaften und Anmeldeinformationen eines Dienstkontos nach Bedarf ändern.
  • Ideal für Anwendungen, die auf mehrere Azure-Ressourcen in verschiedenen Abonnements zugreifen müssen.
  • Gelten als flexibler als verwaltete Identitäten, jedoch weniger sicher.
  • Wird häufig als "Anwendungsobjekt" in einem Azure-Mandanten oder Microsoft Entra-ID-Verzeichnis bezeichnet.

Weitere Informationen zu Dienstprinzipalen finden Sie unter:

Informationen zum Anmelden bei Azure mithilfe der Azure CLI und eines Dienstprinzipals finden Sie unter Anmelden bei Azure mit einem Dienstprinzipal mithilfe von Azure CLI

Schlüsselkonzepte für verwaltete Identitäten

  • Gebunden an eine bestimmte Azure-Ressource, sodass diese einzelne Ressource auf andere Azure-Anwendungen zugreifen kann.
  • Anmeldeinformationen sind für Sie nicht sichtbar. Azure verarbeitet Geheime Schlüssel, Anmeldeinformationen, Zertifikate und Schlüssel.
  • Ideal für Azure-Ressourcen, die innerhalb eines einzigen Abonnements auf andere Azure-Ressourcen zugreifen müssen.
  • Betrachtet als weniger flexibel als Dienstprinzipale, aber sicherer.
  • Es gibt zwei Arten von verwalteten Identitäten:
    • System zugewiesen: Dieser Typ ist eine 1:1-Zugriffsverbindung (eins bis eins) zwischen zwei Azure-Ressourcen.
    • Vom Benutzer zugewiesene: Dieser Typ verfügt über eine 1:M-Beziehung (eine bis viele), in der die verwaltete Identität auf mehrere Azure-Ressourcen zugreifen kann.

Weitere Informationen zu verwalteten Identitäten finden Sie unter Verwaltete Identitäten für Azure-Ressourcen.

Informationen zum Anmelden bei Azure mithilfe der Azure CLI und einer verwalteten Identität finden Sie unter Anmelden bei Azure mit einer verwalteten Identität mithilfe von Azure CLI

Schlüsselkonzepte für Verbundidentitäten

  • Eine Verbundidentität ermöglicht es Diensteprinzipalen (App-Registrierungen) und benutzerzugewiesenen verwalteten Identitäten, Token von einem externen Identitätsanbieter (IdP) zu vertrauen, wie z. B. GitHub oder Google.
  • Nachdem die Vertrauensstellung erstellt wurde, tauscht die externe Softwareauslastung vertrauenswürdige Token vom externen IdP gegen Zugriffstoken von der Microsoft-Identitätsplattform.
  • Ihre Softwarearbeitsauslastung verwendet dieses Zugriffstoken für den Zugriff auf die von Microsoft Entra geschützten Ressourcen, auf die der Workload Zugriff gewährt wird.
  • Verbundidentitäten sind häufig die beste Lösung für die folgenden Szenarien:
    • Eine Workload, die auf jedem Kubernetes-Cluster ausgeführt wird.
    • GitHub-Aktionen
    • Workload, die auf Azure-Computeplattformen mit Anwendungsidentitäten ausgeführt wird
    • Google Cloud
    • Amazon Web Services (AWS)
    • Workload, die auf Computeplattformen außerhalb von Azure ausgeführt wird

Weitere Informationen zu Verbundidentitäten finden Sie unter:

Fehlerbehebung

ROPC-Fehler: Aufgrund einer vom Administrator vorgenommenen Konfigurationsänderung

Wenn Sie versuchen, sich mit einem Kennwort bei Azure anzumelden, wird dies als ROPC-Flow (Resource Owner Password Credential) bezeichnet. Diese Authentifizierungsmethode wird mit MFA nicht unterstützt. Hier ist ein Beispiel:

az login --username $username –password $password

Wenn MFA für den Benutzer erforderlich ist, schlägt der obige Befehl mit der folgenden Fehlermeldung fehl:

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:

Lösung: Wechseln zu einer Authentifizierungsmethode, die mit MFA kompatibel ist.

Mandantenübergreifende Warnung: Fehler bei der Authentifizierung für den Mandanten

Wenn Sie Zugriff auf mehrere Mandanten haben und eine davon MFA erfordert, zeigt die Azure CLI möglicherweise eine Warnmeldung an, die dem folgenden ähnelt:

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.

Während der Anmeldephase versucht Azure CLI, sich mit dem ersten Mandanten anzumelden, dergefunden wurde. Während wir an einer Lösung für dieses Problem arbeiten, geben Sie den Mandanten an, den Sie mit dem Parameter --tenant verwenden möchten.

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

Weitere Informationen zur mehrstufigen Authentifizierung

Die Dokumentationswebsite der Microsoft Entra-ID bietet weitere Details zu MFA.

Siehe auch