Wpływ uwierzytelniania wieloskładnikowego na interfejs wiersza polecenia platformy Azure w scenariuszach automatyzacji

W tym artykule opisano, jak uwierzytelnianie wieloskładnikowe (MFA) wpływa na zadania automatyzacji, które korzystają z tożsamości użytkowników firmy Microsoft Entra i zawiera wskazówki dotyczące alternatywnych metod nieprzerwanej automatyzacji.

Ograniczenia tożsamości użytkowników stosujących uwierzytelnianie wieloskładnikowe w automatyzacji

• Interakcyjne uwierzytelnianie: Uwierzytelnianie wieloskładnikowe jest wyzwalane podczas logowania interakcyjnego przy użyciu tożsamości użytkownika Microsoft Entra. W przypadku skryptów automatyzacji opartych na tożsamości użytkownika uwierzytelnianie wieloskładnikowe zakłóca proces, ponieważ wymaga dodatkowych kroków weryfikacji. Na przykład aplikacja uwierzytelniająca, połączenie telefoniczne itp., których nie można zautomatyzować. Ta weryfikacja uniemożliwia uruchomienie automatyzacji, chyba że uwierzytelnianie jest obsługiwane w sposób nieinterakcyjny, taki jak za pomocą tożsamości zarządzanej lub głównego elementu usługi.

• Błędy logowania w skryptach: w scenariuszach automatyzacji, takich jak uruchamianie nienadzorowanych skryptów Azure CLI, tożsamość użytkownika z włączonym uwierzytelnianiem wieloskładnikowym powoduje niepowodzenie skryptu podczas próby uwierzytelnienia. Ponieważ uwierzytelnianie wieloskładnikowe wymaga interakcji z użytkownikiem, jest niezgodne ze skryptami nieinterakcyjnymi. Oznacza to, że musisz przełączyć się na tożsamość zarządzaną lub główną jednostkę usługi, obie korzystające z uwierzytelniania nieinterakcyjnego.

• Zagadnienia dotyczące zabezpieczeń: Chociaż uwierzytelnianie wieloskładnikowe dodaje dodatkową warstwę zabezpieczeń, może ograniczyć elastyczność automatyzacji, zwłaszcza w środowiskach produkcyjnych, w których automatyzacja musi działać bez ręcznej interwencji. Przejście do tożsamości zarządzanych, jednostek usługi lub tożsamości federacyjnych, które są przeznaczone do celów automatyzacji i nie wymagają uwierzytelniania wieloskładnikowego, jest bardziej praktyczne i bezpieczne w takich środowiskach.

Scenariusze wymagające aktualizacji

Poniższa lista zawiera przykładowe scenariusze, w których klienci mogą używać tożsamości użytkownika firmy Microsoft Entra do automatyzacji za pomocą interfejsu wiersza polecenia platformy Azure. Ta lista nie wyczerpuje wszystkich możliwych scenariuszy.

• Spersonalizowane lub określone uprawnienia: zadania automatyzacji wymagające uprawnień specyficznych dla użytkownika, takie jak akcje powiązane z rolą osoby lub określone atrybuty identyfikatora Entra firmy Microsoft.

• Przepływ OAuth 2.0 ROPC: Przepływ przyznawania tokenów przy użyciu hasła właściciela zasobu OAuth 2.0 (ROPC) jest niezgodny z uwierzytelnianiem wieloskładnikowym. Scenariusze automatyzacji korzystające z uwierzytelniania ROPC kończą się niepowodzeniem, gdy uwierzytelnianie wieloskładnikowe jest wymagane, ponieważ nie można go ukończyć w przepływie nieinteraktywnym.

• Dostęp do zasobów zewnętrznych do usługi Azure: scenariusze automatyzacji, które wymagają dostępu do zasobów platformy Microsoft 365. Na przykład programy SharePoint, Exchange lub inne usługi w chmurze powiązane z kontem Microsoft pojedynczego użytkownika.

• Konta usług zsynchronizowane z Active Directory do Microsoft Entra ID: organizacje używające kont usługowych synchronizowanych z Active Directory do Microsoft Entra ID. Należy pamiętać, że te konta podlegają również wymaganiom uwierzytelniania wieloskładnikowego i wyzwalają te same problemy co inne tożsamości użytkowników.

• Kontekst użytkownika na potrzeby audytu lub zgodności: Przypadki, w których działania muszą być możliwe do audytu na poziomie indywidualnego użytkownika ze względów zgodności.

• Prosta konfiguracja dla automatyzacji o niewielkiej skali lub niskim ryzyku: Dla zadań automatyzacji o niewielkiej skali lub niskim ryzyku. Na przykład skrypt, który zarządza kilkoma zasobami.

• Automatyzacja sterowana przez użytkownika w środowiskach nieprodukcyjnych: jeśli automatyzacja jest przeznaczona dla środowisk osobistych lub nieprodukcyjnych, w których pojedynczy użytkownik jest odpowiedzialny za zadanie.

• : Automatyzacja w ramach własnej subskrypcji Azure użytkownika: Jeśli użytkownik musi zautomatyzować zadania w ramach własnej subskrypcji Azure, gdzie użytkownik ma już wystarczające uprawnienia.

Przejście na tożsamość zarządzaną lub usługę główną jest wymagane w scenariuszach automatyzacji z powodu obowiązkowego wymuszania uwierzytelniania wieloskładnikowego dla tożsamości użytkowników w Microsoft Entra.

Jak rozpocząć

pl-PL: Aby przeprowadzić migrację skryptów Azure CLI z używania az login przy użyciu konta użytkownika Microsoft Entra ID i hasła, wykonaj następujące kroki:

1. Określ, która tożsamość związana z pracą jest dla Ciebie najlepsza.

   • Główny obiekt usługi
   • Tożsamość zarządzana
   • Tożsamość federacyjna

2. Uzyskaj wymagane uprawnienia do utworzenia nowej tożsamości obciążenia lub skontaktuj się z administratorem platformy Azure, aby uzyskać pomoc.

3. Utwórz tożsamość zadania.

4. Przypisz role nowej tożsamości. Aby uzyskać więcej informacji na temat przypisań ról platformy Azure, zobacz Kroki przypisywania roli platformy Azure. Aby przypisać role przy użyciu interfejsu wiersza polecenia platformy Azure, zobacz Przypisywanie ról platformy Azure przy użyciu interfejsu wiersza polecenia platformy Azure.

5. Zaktualizuj skrypty Azure CLI, aby zalogować się przy użyciu jednostki usługi lub tożsamości zarządzanej.

Kluczowe pojęcia dotyczące głównej usługi

• Nieludzkia tożsamość, która może uzyskiwać dostęp do wielu zasobów platformy Azure. Jednostka usługi jest używana przez wiele zasobów platformy Azure i nie jest powiązana z pojedynczym zasobem platformy Azure.
• W razie potrzeby można zmieniać właściwości i poświadczenia głównego użytkownika usługi.
• Idealne rozwiązanie dla aplikacji, które muszą uzyskiwać dostęp do wielu zasobów platformy Azure w różnych subskrypcjach.
• Uznawane za bardziej elastyczne niż tożsamości zarządzane, ale mniej bezpieczne.
• Często określany jako "obiekt aplikacji" w dzierżawie platformy Azure lub w katalogu usługi Microsoft Entra ID.

Aby dowiedzieć się więcej o zasadach usługowych, zobacz:

• Aplikacje & zasady usług w usłudze Microsoft Entra ID
• Zabezpieczanie zasad usługi w usłudze Microsoft Entra ID

Aby dowiedzieć się, jak zalogować się do platformy Azure przy użyciu Azure CLI i głównej usługi, zobacz Logowanie się do platformy Azure przy użyciu głównej usługi z wykorzystaniem Azure CLI

Kluczowe pojęcia dotyczące tożsamości zarządzanej

• Powiązane z określonym zasobem platformy Azure, dzięki czemu pojedynczy zasób może uzyskiwać dostęp do innych aplikacji platformy Azure.
• Poświadczenia nie są widoczne dla Ciebie. Platforma Azure obsługuje wpisy tajne, poświadczenia, certyfikaty i klucze.
• Idealne rozwiązanie dla zasobów platformy Azure, które muszą uzyskiwać dostęp do innych zasobów platformy Azure w ramach jednej subskrypcji.
• Uważane za mniej elastyczne niż service principals, ale bardziej bezpieczne.
• Istnieją dwa typy tożsamości zarządzanych:
  • System przypisany: Ten typ to łącze dostępu 1:1 (jeden do jednego) pomiędzy dwoma zasobami platformy Azure.
  • Użytkownik przypisany: ten typ ma relację 1:M (od jednej do wielu), w której tożsamość zarządzana może uzyskiwać dostęp do wielu zasobów platformy Azure.

Aby dowiedzieć się więcej o tożsamościach zarządzanych, zobacz Tożsamości zarządzane dla zasobów platformy Azure.

Aby dowiedzieć się, jak zalogować się do platformy Azure przy użyciu interfejsu wiersza polecenia platformy Azure i tożsamości zarządzanej, zobacz Logowanie się do platformy Azure przy użyciu tożsamości zarządzanej przy użyciu interfejsu wiersza polecenia platformy Azure

Kluczowe pojęcia dotyczące tożsamości federacyjnej

• Federacyjna tożsamość pozwala jednostkom usługi (rejestracjom aplikacji) oraz użytkownikom przypisanym do zarządzanych tożsamości ufać tokenom od zewnętrznego dostawcy tożsamości, takiego jak GitHub lub Google.
• Gdy już relacja zaufania zostanie utworzona, zewnętrzne obciążenie robocze oprogramowania wymienia zaufane tokeny w imieniu zewnętrznego dostawcy tożsamości na tokeny dostępu z platformy tożsamości firmy Microsoft.
• Zadanie obciążeniowe korzysta z tego tokenu dostępu, aby uzyskać dostęp do chronionych zasobów Microsoft Entra, do których ma przyznany dostęp.
• Tożsamości federacyjne są często najlepszym rozwiązaniem w następujących scenariuszach:
  • Obciążenie uruchomione w dowolnym klastrze Kubernetes
  • Działania GitHub
  • Obciążenie uruchomione na platformach obliczeniowych platformy Azure przy użyciu tożsamości aplikacji
  • Google Cloud
  • Amazon Web Services (AWS)
  • Obciążenie uruchomione na platformach obliczeniowych spoza platformy Azure

Aby dowiedzieć się więcej o tożsamościach federacyjnych, zobacz:

• Czym jest federacja tożsamości pracy?
• Przenieś się na wieloskładnikowe uwierzytelnianie Microsoft Entra z federacjami

Rozwiązywanie problemów

Błąd ROPC: z powodu zmiany konfiguracji wprowadzonej przez administratora

Podczas próby logowania się na platformie Azure przy użyciu hasła, jest to znane jako przepływ ROPC (Resource Owner Password Credential). Ta metoda uwierzytelniania nie jest obsługiwana w przypadku uwierzytelniania wieloskładnikowego. Oto przykład:

az login --username $username –password $password

Jeśli uwierzytelnianie wieloskładnikowe jest wymagane dla użytkownika, powyższe polecenie kończy się niepowodzeniem z następującym komunikatem o błędzie:

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:

Rozwiązanie: Przejdź na metodę uwierzytelniania kompatybilną z MFA.

Ostrzeżenie między tenantami: Uwierzytelnianie nie powiodło się przeciwko tenantowi

Jeśli masz dostęp do kilku dzierżaw, a jeden z nich wymaga uwierzytelniania wieloskładnikowego, Azure CLI może wyświetlić komunikat ostrzegawczy podobny do następującego:

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.

Podczas logowania, Azure CLI próbuje zalogować się przy użyciu pierwszej znalezionej dzierżawy. Proszę określić dzierżawcę, którego chcesz użyć z parametrem --tenant, podczas gdy pracujemy nad rozwiązaniem tego problemu.

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

Dowiedz się więcej na temat uwierzytelniania wieloskładnikowego

Witryna dokumentacji Microsoft Entra ID zawiera więcej szczegółów na temat uwierzytelniania wieloskładnikowego.

• Plan obowiązkowego uwierzytelniania wieloskładnikowego Microsoft Entra (MFA)
• Jak używać narzędzia do migracji serwera MFA, aby przeprowadzić migrację do wieloskładnikowego uwierzytelniania Microsoft Entra
• Zagadnienia dotyczące wdrażania uwierzytelniania wieloskładnikowego Microsoft Entra
• Migracja z serwera MFA do usługi Microsoft Entra multifactor authentication

Zobacz także

• Tożsamości obciążeniowe, inne tożsamości maszynowe i tożsamości ludzkie.
• indeks poleceń Azure CLI dla tożsamości Azure
• Redukcja użycia Osobistego Tokenu Dostępu w Azure DevOps
• Zwiększ poziom zabezpieczeń w połączeniach usługi Azure za pomocą AzurePipelinesCredential