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.
Viktig
Åtgärder krävs 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
Not
Du kan stöta på felmeddelandet: Interaktiv autentisering krävs när du använder en användaridentitet med automatisering.
Interaktiv autentisering: 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.
Fel med skriptinloggning: I automatiseringsscenarier som att köra Obevakade Azure PowerShell-skript 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, som 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.
Anpassade eller specifika behörigheter: Automatiseringsuppgifter 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-flödet för resursägares lösenordsautentiseringsuppgifter (ROPC) ä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.
Tjänstkonton som synkroniserats 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.
Byte 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
Följ dessa steg för att migrera dina Azure PowerShell-skript från att använda Connect-AzAccount
med ett mänskligt användarkonto och lösenord för Microsoft Entra-ID:
Ta reda på vilken arbetsbelastningsidentitet som är bäst för dig.
- Tjänstens huvudnamn
- Hanterad identitet
- Federerad identitet
Skaffa de behörigheter som krävs för att skapa en ny arbetsbelastningsidentitet eller kontakta Azure-administratören om du behöver hjälp.
Skapa arbetsflödesidentiteten.
Tilldela roller till den nya identiteten. Mer information om Rolltilldelningar i Azure 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.
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 serviceprincipalens egenskaper och autentiseringsuppgifter 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-klientorganisation eller Microsoft Entra-ID-katalog.
Mer information om tjänsteprinciper finns i:
- Apps & tjänstens huvudprinciper i Microsoft Entra ID
- Skydd av tjänstehuvudprincipaler i Microsoft Entra ID
Information om hur man loggar in i Azure med Azure PowerShell och en tjänsthuvudman finns i Logga in på Azure med en tjänsthuvudman med hjälp av Azure PowerShell
Nyckelbegrepp för hanterad identitet
- Knuten till en specifik Azure-resurs som gör det möjligt för den enskilda resursen att 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 åtkomst till andra Azure-resurser i en enda prenumeration.
- Anses vara mindre flexibla än serviceprincipaler men säkrare.
- Det finns två typer av hanterade identiteter:
- Systemtilldelade: Den här typen är en 1:1-åtkomstlänk (en till en) mellan två Azure-resurser.
- Användartilldelad: 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 Logga in på Azure med en hanterad identitet med hjälp av Azure PowerShell
Nyckelbegrepp för federerad identitet
- Med en federerad identitet kan tjänstehuvuden (appregistreringar) och användartilldelade hanterade identiteter lita på token 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å varje 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:
- Vad är arbetsbelastningsidentitetsfederation?
- Migrera till Microsoft Entra multifaktorautentisering med federationer
Läs mer om multifaktorautentisering
Dokumentationswebbplatsen för Microsoft Entra ID innehåller mer information om MFA.
- Planera för obligatorisk Microsoft Entra-multifaktorautentisering (MFA)
- Så här använder du migreringsverktyget för MFA Server för att migrera till Microsoft Entra multifaktorautentisering
- Distributionsöverväganden för Microsoft Entra multifaktorautentisering
- Migrera från MFA Server till Microsoft Entra multifaktorautentisering
Se även
Azure PowerShell