Dela via

Effekten av multifaktorautentisering på Azure PowerShell i automatiseringsscenarier

I den här artikeln beskrivs hur multifaktorautentisering (MFA) påverkar automatiseringsuppgifter som använder Microsoft Entra användaridentiteter och ger vägledning om alternativa metoder för oavbruten automatisering.

Viktigt!

Du måste vidta åtgärder om du använder Microsoft Entra användaridentiteter för automatisering.

MFA-krav hindrar dig från att använda Microsoft Entra användaridentiteter för autentisering i automatiseringsscenarier. Organisationer måste byta till autentiseringsmetoder som är utformade för automatisering, till exempel hanterade identiteter eller tjänstens huvudnamn, som stöder användningsfall för icke-interaktiv automatisering.

Begränsningar för användaridentiteter med MFA i automatisering

Anmärkning

Du kan stöta på felmeddelandet: Interaktiv autentisering krävs när du använder en användaridentitet med automatisering.

  • Interactive authentication: MFA utlöses under interaktiva inloggningar när du använder en Microsoft Entra användaridentitet. För automatiseringsskript som förlitar sig på en användaridentitet stör MFA processen eftersom den kräver extra verifieringssteg. Till exempel autentiseringsapp, telefonsamtal osv. som du inte kan automatisera. Den här verifieringen förhindrar att automatisering körs om inte autentisering hanteras på ett icke-interaktivt sätt, till exempel med en hanterad identitet eller tjänstens huvudnamn.

  • Scripted login failures: I automationsscenarier som att köra Azure PowerShell skript obevakade, gör en MFA-aktiverad användaridentitet att skriptet misslyckas när du försöker autentisera. Eftersom MFA kräver användarinteraktion är det inte kompatibelt med icke-interaktiva skript. Det innebär att du måste växla till en hanterad identitet eller tjänstehuvudnamn, vilka båda använder icke-interaktiv autentisering.

  • Säkerhetsöverväganden: Även om MFA lägger till ett extra säkerhetslager kan det begränsa automatiseringsflexibiliteten, särskilt i produktionsmiljöer där automatisering måste köras utan manuella åtgärder. Att växla till hanterade identiteter, tjänstens huvudnamn eller federerade identiteter, som är utformade för automatisering och inte kräver MFA, är mer praktiskt och säkert i sådana miljöer.

Scenarier som kräver uppdateringar

Följande lista innehåller exempelscenarier där kunder kan använda en Microsoft Entra användaridentitet för automatisering med Azure PowerShell. Den här listan är inte fullständig för alla scenarier.

Varning

Alla automatiseringsscenarion som använder en Microsoft Entra användaridentitet kräver uppdatering.

  • Personligare eller specifika behörigheter: Automation-uppgifter som kräver användarspecifika behörigheter, till exempel åtgärder som är knutna till en individs roll eller specifika Microsoft Entra ID attribut.

  • OAuth 2.0 ROPC-flöde: OAuth 2.0 Resursägarlösenordsuppgifter (ROPC) token beviljningsflöde är inte kompatibelt med MFA. Automatiseringsscenarier som använder ROPC för autentisering misslyckas när MFA krävs, eftersom MFA inte kan slutföras i ett icke-interaktivt flöde.

  • Åtkomst till resurser utanför Azure: Automation-scenarier som kräver åtkomst till Microsoft 365 resurser. Till exempel SharePoint, Exchange eller andra molntjänster som är knutna till en enskild användares Microsoft-konto.

  • Service-konton synkroniserade från Active Directory till Microsoft Entra ID: Organisationer som använder tjänstkonton som synkroniserats från Active Directory (AD) till Microsoft Entra ID. Det är viktigt att observera att dessa konton också omfattas av MFA-krav och utlöser samma problem som andra användaridentiteter.

  • Användarkontext för granskning eller efterlevnad: Fall där åtgärderna måste vara granskningsbara på enskild användarnivå av efterlevnadsskäl.

  • Enkel konfiguration för automatisering i liten skala eller med låg risk: För automatiseringsuppgifter i liten skala eller med låg risk. Till exempel ett skript som hanterar några resurser.

  • Användardriven automatisering i icke-produktionsmiljöer: Om automatiseringen är avsedd för personliga miljöer eller icke-produktionsmiljöer där en enskild användare ansvarar för en uppgift.

  • Automation i en användares egen Azure-prenumeration: Om en användare behöver automatisera uppgifter i sin egen Azure prenumeration där användaren redan har tillräcklig behörighet.

Växling till en hanterad identitet eller tjänstens huvudnamn krävs för automatiseringsscenarier på grund av obligatorisk MFA-tillämpning för Microsoft Entra användaridentiteter.

Så här börjar du

Så här migrerar du dina Azure PowerShell-skript från att använda Connect-AzAccount med ett Microsoft Entra ID mänskligt användarkonto och lösenord:

  1. Ta reda på vilken arbetsbelastningsidentitet som är bäst för dig.

    • Service Principal
    • Hanterad identitet
    • Federerad identitet

  2. Skaffa de behörigheter som krävs för att skapa en ny arbetsbelastningsidentitet eller kontakta din Azure administratör om du behöver hjälp.

  3. Skapa arbetsbelastningsidentiteten.

  4. Tilldela roller till den nya identiteten. Mer information om Azure rolltilldelningar finns i Steg för att tilldela en Azure roll. Information om hur du tilldelar roller med hjälp av Azure PowerShell finns i Tilldela Azure roller med hjälp av Azure PowerShell.

  5. Uppdatera dina Azure PowerShell-skript för att logga in med tjänstens huvudnamn eller hanterade identitet.

Viktiga begrepp för tjänstens huvudnamn

  • En icke-mänsklig identitet som kan komma åt flera Azure resurser. Ett huvudnamn för tjänsten används av många Azure resurser och är inte kopplat till en enda Azure resurs.
  • Du kan ändra egenskaper och autentiseringsuppgifter för ett huvudnamn för tjänsten efter behov.
  • Perfekt för program som behöver åtkomst till flera Azure resurser i olika prenumerationer.
  • Anses vara mer flexibelt än hanterade identiteter men mindre säkert.
  • Kallas ofta för ett "programobjekt" i en Azure-klient eller Microsoft Entra ID-katalog.

Mer information om tjänstens huvudprincip finns i:

För att lära dig hur du loggar in på Azure med Azure PowerShell och en tjänstens huvudnamn, se Logga in på Azure med en tjänstens huvudnamn med hjälp av Azure PowerShell

Nyckelbegrepp för hanterad identitet

  • Knuten till en specifik Azure resurs som gör att den enskilda resursen kan komma åt andra Azure program.
  • Autentiseringsuppgifter visas inte för dig. Azure hanterar hemligheter, autentiseringsuppgifter, certifikat och nycklar.
  • Perfekt för Azure resurser som behöver komma åt andra Azure resurser i en enda prenumeration.
  • Anses vara mindre flexibelt än tjänstens principer men säkrare.
  • Det finns två typer av hanterade identiteter:
    • Systemtilldelat: Den här typen är en 1:1-åtkomstlänk (en till en) mellan två Azure resurser.
    • Användare tilldelad: Den här typen har en 1:M-relation (en till många) där den hanterade identiteten kan komma åt flera Azure resurser.

Mer information om hanterade identiteter finns i Hanterade identiteter för Azure resurser.

Information om hur du loggar in på Azure med hjälp av Azure PowerShell och en hanterad identitet finns i Tilldela i Azure med en hanterad identitet med hjälp av Azure PowerShell

Federerade identitetsnyckelbegrepp

  • Med en federerad identitet kan tjänstens huvudansvarig (appregistreringar) och användartilldelade hanterade identiteter lita på tokens från en extern identitetsleverantör (IdP), till exempel GitHub eller Google.
  • När förtroenderelationen har skapats utbyter din externa programvaruarbetsbelastning betrodda token från den externa IdP:t för åtkomsttoken från Microsofts identitetsplattform.
  • Din programvaruarbetsbelastning använder den åtkomsttoken för att få åtkomst till de Microsoft Entra skyddade resurser som arbetsbelastningen beviljas åtkomst till.
  • Federerade identiteter är ofta den bästa lösningen för följande scenarier:
    • Arbetsbelastning som körs på alla Kubernetes-kluster
    • GitHub Actions
    • Arbetsbelastning som körs på Azure beräkningsplattformar med hjälp av programidentiteter
    • Google Cloud
    • Amazon Web Services (AWS)
    • Arbetsbelastning som körs på beräkningsplattformar utanför Azure

Mer information om federerade identiteter finns i:

Läs mer om multifaktorautentisering

Den Microsoft Entra ID dokumentationswebbplatsen innehåller mer information om MFA.

Se även

  • Last updated on