Dela via

Mandat för multifaktorautentisering (MFA) för din partnerklientorganisation

  • Artikel

Lämpliga roller: Administratörsagent | Försäljningsagent | Supportavdelningens agent | Faktureringsadministratör | Säkerhetsadministratör

Bättre säkerhet och kontinuerliga säkerhets- och sekretessskydd hör till våra främsta prioriteringar, och vi fortsätter att hjälpa partner att skydda sina kunder och klienter.

För att hjälpa partner att skydda sina företag och kunder från identitetsstöld och obehörig åtkomst aktiverade vi fler säkerhetsskydd för partnerklientorganisationer. Dessa skydd kräver och verifierar MFA. Att ge MFA mandat hjälper partner att skydda sin åtkomst till kundresurser mot autentiseringsuppgifter som komprometteras.

Den här artikeln innehåller detaljerade exempel och vägledning för att ge tillstånd till multifaktorautentisering (MFA) i Partnercenter.

Partner som deltar i programmet Molnlösningsleverantör (CSP), Kontrollpanelen Vendors (CPV) och Advisors måste implementera partnersäkerhetskraven för att hålla sig kompatibla.

Partner måste framtvinga MFA för alla användarkonton i sin partnerklientorganisation, inklusive gästanvändare. Användarna måste slutföra MFA-verifieringen för följande områden:

Partnercenter

Vissa sidor i Partnercenter är MFA-skyddade, inklusive:

  • Alla sidor under fliken Kunder (d.s. alla sidor med en URL som börjar med https://partner.microsoft.com/commerce/*)
  • Alla sidor under fliken Support>customer requests (till exempel alla sidor som nås med en URL som börjar med )https://partner.microsoft.com/dashboard/v2/support/customers/*
  • Alla sidor på fliken Fakturering

Andra sidor i Partnercenter, till exempel sidan Översikt och Kontrollsidan för tjänsthälsa , kräver inte MFA.

I följande tabell visas vilka användartyper som har behörighet att komma åt dessa MFA-skyddade sidor (och påverkas av den här funktionen).

MFA-skyddad sida Administratörsagenter Försäljningsagenter Supportagenter Säkerhetsadministratör Faktureringsadministratör
Alla sidor under fliken Kunder x x x
Alla sidor under fliken Kundförfrågningar för support > x x
Faktureringssida x x x
Säkerhetsarbetsyta x x

För att få åtkomst till dessa sidor måste du först slutföra MFA-verifieringen.

MFA-alternativ som stöds

Viktigt!

Partner måste använda en autentiseringsprovider som är kompatibel med Microsoft Entra-ID:ts integrerade MFA-anspråk. Det integrerade anspråket anger den faktiska typ av autentiseringsuppgifter som angavs under autentiseringen. Partner måste använda integrerad MFA för att hantera kundklientorganisationer med GDAP.

Partnercenter och API:er

För följande Partnercenter-API:er krävs App+Användaråtkomst och Microsoft Entra ID Support MFA:

  • Upptäck (pris/katalog/befordran)
  • Transact och hantera
  • Fakturering och avstämning
  • Hantera kunder med delegerad åtkomst/AOBO
  • Användar- och licenstilldelning (endast med DAP)
  • Användar- och licenstilldelning (med GDAP)
  • Detaljerad begäran och åtkomsttilldelning för administratörsrelationer

Följande alternativ är tillgängliga för partner:

Verifieringsexempel

Tänk på följande exempel för att illustrera hur verifiering fungerar i Partnercenter.

Exempel 1: Partner har implementerat Microsoft Entra multifaktorautentisering

  1. Alejandra fungerar för en CSP med namnet Contoso. Contoso har implementerat MFA för alla sina användare under Contoso-partnerklientorganisationen med hjälp av Microsoft Entra multifaktorautentisering.

  2. Alejandra startar en ny webbläsarsession och går till översiktssidan för Partnercenter (som inte är MFA-skyddad). Partnercenter omdirigerar Alejandra till Microsoft Entra-ID för att logga in.

  3. På grund av contosos befintliga konfiguration av multifaktorautentisering i Microsoft Entra krävs Alejandra för att slutföra MFA-verifieringen. Vid lyckad inloggning och MFA-verifiering omdirigeras Alejandra tillbaka till översiktssidan för Partnercenter.

  4. Alejandra försöker komma åt en av de MFA-skyddade sidorna i Partnercenter. Eftersom Alejandra slutförde MFA-verifieringen under inloggningen tidigare kan Alejandra komma åt den MFA-skyddade sidan utan att behöva gå igenom MFA-verifieringen igen.

Exempel 2: Partner har implementerat icke-Microsoft MFA med hjälp av identitetsfederation

  1. Prashob fungerar för en CSP med namnet Wingtip. Wingtip har implementerat MFA för alla sina användare under Wingtip-partnerklientorganisationen med hjälp av icke-Microsoft MFA, som är integrerat med Microsoft Entra-ID via identitetsfederation.

  2. Prashob startar en ny webbläsarsession och går till översiktssidan för Partnercenter (som inte är MFA-skyddad). Partnercenter omdirigerar Prashob till Microsoft Entra-ID för att logga in.

  3. Eftersom Wingtip har konfigurerat identitetsfederation omdirigerar Microsoft Entra-ID Prashob till den federerade identitetsprovidern för att slutföra inloggningen och MFA-verifieringen. Vid lyckad inloggning och MFA-verifiering omdirigeras Prashob tillbaka till Microsoft Entra-ID och sedan till översiktssidan för Partnercenter.

  4. Prashob försöker komma åt en av de MFA-skyddade sidorna i Partnercenter. Eftersom Prashob redan har slutfört MFA-verifieringen under inloggningen tidigare kan han komma åt den MFA-skyddade sidan utan att behöva gå igenom MFA-verifieringen igen.

  5. Prashob går sedan till sidan för tjänsthantering för att lägga till användare i Contosos Microsoft Entra-ID. Eftersom Prashob har använt den Entra-kompatibla autentiseringsprovidern med stark autentisering kan de komma åt kundklientorganisationen utan problem.

Rekommendationen för Prashob i det här exemplet är att använda multifaktorautentiseringslösningen Microsoft Entra eller en Entra-kompatibel autentiseringsprovider, så att de kan hantera kundens klientorganisation.

Exempel 3: Partnern har inte implementerat MFA

  1. En CSP-partner med namnet Fabrikam har ännu inte implementerat MFA. Microsoft rekommenderar att de implementerar en MFA-lösning som stöds av Microsoft Entra.

  2. John arbetar för Fabrikam. Fabrikam har inte implementerat MFA för några användare under Fabrikam-partnerklientorganisationen.

  3. John startar en ny webbläsarsession och går till översiktssidan för Partnercenter (som inte är MFA-skyddad). Partnercenter omdirigerar John till Microsoft Entra-ID för att logga in.

  4. När john har loggat in omdirigeras han tillbaka till översiktssidan för Partnercenter eftersom han inte har slutfört MFA-verifieringen.

  5. John försöker komma åt en av de MFA-skyddade sidorna i Partnercenter. Eftersom John inte har slutfört MFA-verifiering omdirigerar Partnercenter John till Microsoft Entra-ID för att slutföra MFA-verifieringen. Eftersom det är första gången John krävs för att slutföra MFA, uppmanas John också att registrera sig för MFA. Efter lyckad MFA-registrering och MFA-verifiering kan John komma åt den MFA-skyddade sidan.

  6. En annan dag, innan Fabrikam implementerar MFA för alla användare, startar John en ny webbläsarsession och går till översiktssidan för Partnercenter (som inte är MFA-skyddad). Partnercenter omdirigerar John till Microsoft Entra-ID för att logga in utan MFA-fråga.

  7. John försöker komma åt en av de MFA-skyddade sidorna i Partnercenter. Eftersom John inte har slutfört MFA-verifiering omdirigerar Partnercenter John till Microsoft Entra-ID för att slutföra MFA-verifieringen. Eftersom John har registrerat MFA uppmanas han den här gången bara att slutföra MFA-verifieringen.

Exempel 4: Partner har implementerat icke-Microsoft MFA som inte är kompatibelt med Microsoft Entra

  1. Trent arbetar för en CSP med namnet Wingtip. Wingtip har implementerat MFA för alla sina användare under Wingtip-partnerklientorganisationen med icke-Microsoft MFA i sin molnmiljö med villkorlig åtkomst.

  2. Trent startar en ny webbläsarsession och går till översiktssidan för Partnercenter (som inte är MFA-skyddad). Partnercenter omdirigerar Trent till Microsoft Entra-ID för att logga in.

  3. Eftersom Wingtip använde en icke-Microsoft MFA-integrering som inte är kompatibel med Microsoft Entra-ID:t och inte har någon stark autentisering blockeras Trent från att komma åt alla MFA-skyddade sidor och API:er i Partnercenter.

Eftersom Trent har åtkomst till MFA-skyddade sidor måste han presentera MFA med stark autentisering för att få åtkomst till MFA-skyddade sidor.

Partner måste använda en autentiseringsprovider som är kompatibel med Microsoft Entra-ID som stöder autentiseringsmetodens anspråk ("amr-anspråk" i referens för åtkomsttokenanspråk – Microsofts identitetsplattform, vilket återspeglar den faktiska typ av autentiseringsuppgifter som angavs under autentiseringen.

Vi rekommenderar starkt CSP-partner att implementera MFA som är kompatibelt med Microsoft Entra-ID omedelbart för att höja säkerhetsbaslinjen för din klientorganisation.

Api för Partnercenter

Partnercenter-API:et stöder både appautentisering och app- och användarautentisering (App+Användare).

När App+User-autentisering används kräver Partnercenter MFA-verifiering. Mer specifikt, när ett partnerprogram skickar en API-begäran till Partnercenter, måste den innehålla en åtkomsttoken i auktoriseringshuvudet för begäran.

Kommentar

Ramverket för säker programmodell är ett skalbart ramverk för att autentisera CSP-partner och CPV:er via Microsoft Azure MFA-arkitekturen när du anropar Api:er för Partnercenter. Du måste implementera det här ramverket när du använder MFA i tjänstautomation.

När Partnercenter tar emot en API-begäran med en åtkomsttoken som hämtats med app+användarautentisering, kontrollerar Partnercenter-API:et att MFA-värdet finns i AMR-anspråket (Authentication Method Reference). Du kan använda en JWT-avkodare för att verifiera om en åtkomsttoken innehåller det förväntade amR-värdet (authentication method reference) eller inte:

{
  "aud": "https://api.partnercenter.microsoft.com",
  "iss": "https://sts.windows.net/df845f1a-7b35-40a2-ba78-6481de91f8ae/",
  "iat": 1549088552,
  "nbf": 1549088552,
  "exp": 1549092452,
  "acr": "1",
  "amr": [
    "pwd",
    "mfa"
  ],
  "appid": "00001111-aaaa-2222-bbbb-3333cccc4444",
  "appidacr": "0",
  "family_name": "Adminagent",
  "given_name": "CSP",
  "ipaddr": "127.0.0.1",
  "name": "Adminagent CSP",
  "oid": "aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb",
  "scp": "user_impersonation",
  "tenant_region_scope": "NA",
  "tid": "aaaabbbb-0000-cccc-1111-dddd2222eeee",
  "unique_name": "Adminagent.csp@testtestpartner.onmicrosoft.com",
  "upn": "Adminagent.csp@testtestpartner.onmicrosoft.com",
  "ver": "1.0"
}

  • Om värdet finns drar Partnercenter slutsatsen att MFA-verifieringen har slutförts och bearbetar API-begäran.

  • Om värdet inte finns avvisar Partnercenter-API:et begäran med följande svar:

    HTTP/1.1 401 Unauthorized - MFA required
Transfer-Encoding: chunked
Request-Context: appId=cid-v1:11112222-bbbb-3333-cccc-4444dddd5555
WWW-Authenticate: Bearer error="invalid_token"
Date: Thu, 14 Feb 2019 21:54:58 GMT

När du anropar API:er för Partnercenter stöds endast åtkomsttoken för appar för åtgärder som inte kräver GDAP-rolltilldelningar i en kundklientorganisation.

Mer information om metodtips finns i API-autentisering och auktorisering – Översikt.

Partnerdelad administration

Partnerklientorganisationer bör använda detaljerade delegerade administratörsprivilegier (GDAP) för att hantera kundresurser via Microsoft Online Services-portaler (portal.azure.com eller admin.microsoft.com), kommandoradsgränssnitt (CLI) och API:er (med app+användarautentisering). Mer information finns i MFA-alternativ som stöds.

Använda tjänstportaler

CSP-partner kan administrera sina kunder från Partnercenter-portalen via servicehanteringsgränssnittet. Partner kan navigera till kunden och välja Tjänsthantering för att kunna administrera en specifik tjänst för kunden. Partner måste följa GDAP-rollvägledningen för att få rätt GDAP-roll med minsta behörighet för att hantera sina kunder.

Vid åtkomst till Microsoft Online Services-portaler med partner delegerade administratörsprivilegier (admin-on-behalf-of) för att hantera kundresurser, kräver många av dessa portaler att partnerkontot autentiseras interaktivt, med kunden Microsoft Entra-klient som autentiseringskontext. Partnerkontot krävs för att logga in på kundens klientorganisation.

Microsoft Entra ID-autentisering kräver att en användare slutför MFA-verifieringen om det finns en princip som kräver MFA. Det finns två möjliga användarupplevelser, beroende på om partnerkontot är en hanterad eller federerad identitet:

  • Om partnerkontot är en hanterad identitet uppmanar Microsoft Entra-ID direkt användaren att slutföra MFA-verifieringen. Om partnerkontot inte har registrerats för MFA med Microsoft Entra-ID tidigare uppmanas användaren att slutföra MFA-registreringen först.

  • Om partnerkontot är en federerad identitet beror upplevelsen på hur partneradministratören har konfigurerat federation i Microsoft Entra-ID. När du konfigurerar federation i Microsoft Entra-ID kan partneradministratören ange för Microsoft Entra-ID om den federerade identitetsprovidern stöder MFA eller inte.

    • I så fall omdirigerar Microsoft Entra-ID användaren till den federerade identitetsprovidern för att slutföra MFA-verifieringen.
    • Annars uppmanar Microsoft Entra-ID användaren att slutföra MFA-verifieringen direkt. Om partnerkontot inte har registrerats för MFA med Microsoft Entra-ID tidigare uppmanas användaren att slutföra MFA-registreringen först.

Den övergripande upplevelsen är som det scenario där en slutkundsklient har implementerat MFA för sina administratörer. Kundklientorganisationen har till exempel aktiverat Microsoft Entra-säkerhetsstandarder, vilket kräver att alla konton med administrativ behörighet loggar in på kundklientorganisationen med MFA-verifiering, inklusive administratörsagenter och supportagenter.

I testsyfte kan partner aktivera Microsoft Entra-säkerhetsstandarderna i kundklientorganisationen och sedan försöka använda GDAP (Partner Granular Delegated Administration Privileges) för att få åtkomst till kundklientorganisationen.

Kommentar

Alla Microsoft Online Service-portaler kräver inte att partnerkonton loggar in på kundklientorganisationen vid åtkomst till kundresurser med hjälp av GDAP. I stället kräver vissa bara att partnerkontona loggar in på partnerklientorganisationen. Ett exempel är Administrationscenter för Exchange. Med tiden förväntar vi oss att dessa portaler kräver att partnerkonton loggar in på kundklientorganisationen när du använder GDAP.

MFA-registrering

Om partnerkontot inte har registrerats för MFA tidigare under MFA-verifieringen uppmanar Microsoft Entra-ID användaren att slutföra MFA-registreringen först.

Läs mer om Microsoft Authenticator-metoden:

Skärmbild av det första steget i MFA-registrering.

När användaren har valt Nästa uppmanas de att välja från en lista över verifieringsmetoder.

Skärmbild av det andra steget i MFA-registrering.

Efter lyckad registrering måste användaren slutföra MFA-verifieringen med hjälp av den valda verifieringsmetoden.

Vanliga problem

Om du vill veta om din begäran är giltig läser du listan över vanliga problem som rapporterats av andra partner.

Problem 1: Partnern behöver mer tid för att implementera MFA för sina partneragenter

En partner har inte startat eller håller fortfarande på att implementera MFA för sina partneragenter som behöver åtkomst till Microsoft Online Services-portaler med hjälp av privilegier för partnerdelad administration för att hantera kundresurser. Partnern behöver mer tid för att slutföra MFA-implementeringen. Är detta ett giltigt skäl till tekniskt undantag?

Svar: Nej. En partner måste planera att implementera MFA för sina användare för att undvika störningar.

Kommentar

Även om en partner inte har implementerat MFA för sina partneragenter kan partneragenterna fortfarande komma åt Microsoft Online Services-portaler med hjälp av privilegier för partnerdelad administration om de kan slutföra MFA-registrering och MFA-verifiering när de uppmanas att logga in på kundklientorganisationen. Att slutföra MFA-registreringen aktiverar inte automatiskt användaren för MFA.

Problem 2: Partnern har inte implementerat MFA eftersom de inte behöver åtkomst för att hantera kunder

En partner har vissa användare i sina partnerklienter som inte behöver åtkomst till Microsoft Online Services-portaler för att hantera kundresurser med hjälp av delegerade administratörsbehörigheter för partner. Partnern håller på att implementera MFA för dessa användare och behöver mer tid att slutföra. Är detta ett giltigt skäl till tekniskt undantag?

Svar: Nej. Eftersom dessa användarkonton inte använder partner delegerade administrationsprivilegier för att hantera kundresurser behöver de inte logga in på kundens klientorganisation. De påverkas inte av Microsoft Entra-ID som kräver MFA-verifiering under inloggningen till kundklientorganisationen. Alla användare måste ha MFA-åtkomst till Partnercenter eller kundens arbetsbelastningar för att hantera kundresurserna.

Problem 3: Partnern har inte implementerat MFA för användarkonton

En partner har vissa användarkonton i sina partnerklientorganisationer, som används av enheter som tjänstkonton. Dessa lågprivilegierade konton kräver inte åtkomst till Partnercenter eller Microsoft Online Services-portaler för att hantera kundresurser med hjälp av delegerade administratörsbehörigheter för partner. Är detta ett giltigt skäl till ett tekniskt undantag?

Svar: Nej. Eftersom dessa användarkonton inte använder privilegier för partnerdelad administration för att hantera kundresurser behöver de inte logga in på kundens klientorganisation. De påverkas inte av Microsoft Entra-ID som kräver MFA-verifiering under inloggningen till kundklientorganisationen. Om API:et eller portalen kräver app+användarautentisering måste varje användare använda MFA för autentisering.

Problem 4: Partner kan inte implementera MFA med hjälp av Microsoft Authenticator-appen

En partner har en policy för "rent skrivbord", vilket inte tillåter anställda att ta med sina personliga mobila enheter till sitt arbetsområde. Utan åtkomst till sina personliga mobila enheter kan de anställda inte installera Microsoft Authenticator-appen, vilket är den enda MFA-verifieringen som stöds av Microsoft Entra-säkerhetsstandarder. Är detta ett giltigt skäl till tekniskt undantag?

Svar: Nej. Partnern bör överväga följande alternativ så att deras anställda fortfarande kan slutföra MFA-verifieringen vid åtkomst till Partnercenter:

  • Partner kan också registrera sig för Microsoft Entra ID P1 eller P2, eller använda MFA-lösningar som inte är Microsoft MFA-lösningar som är kompatibla med Microsoft Entra-ID som kan tillhandahålla fler verifieringsmetoder. Mer information finns i Autentiseringsmetoder som stöds.

Problem 5: Partner kan inte implementera MFA på grund av användning av äldre autentiseringsprotokoll

En partner har vissa partneragenter som fortfarande använder äldre autentiseringsprotokoll, som inte är MFA-kompatibla. Användarna använder till exempel fortfarande Outlook 2010, som baseras på äldre autentiseringsprotokoll. Om du aktiverar MFA för dessa partneragenter störs användningen av äldre autentiseringsprotokoll. Är detta ett giltigt skäl till tekniskt undantag?

Svar: Nej. Partner uppmuntras att flytta från användningen av äldre autentiseringsprotokoll på grund av potentiella säkerhetskonsekvenser eftersom dessa protokoll inte kan skyddas med MFA-verifiering och är mycket mer mottagliga för komprometterande av autentiseringsuppgifter. Vi rekommenderar att du tar bort all äldre autentisering och använder standardinställningar för säkerhet eller villkorsstyrd åtkomst. Om du vill förbereda dig för att gå bort från äldre autentisering läser du inloggningar med äldre autentiseringsarbetsbok och vägledningen om hur du blockerar äldre autentisering.

Om du vill förstå den senaste planen för att stödja äldre autentisering för Outlook läser du inlägget om Basic Auth och Exchange Online och följer Exchange-teamets blogg för att få de kommande nyheterna.

Problem 6: Partnern har implementerat en MFA som inte är Microsoft Entra-ID

En partner har implementerat MFA för sina användare med hjälp av en MFA-lösning som inte kommer från Microsoft. Partnern kan dock inte konfigurera MFA-lösningen från andra länder än Microsoft för att vidarebefordra till Microsoft Entra-ID:t att MFA-verifieringen har slutförts under användarautentiseringen. Är detta ett giltigt skäl till tekniskt undantag?

Svar: Nej, Partner måste använda en autentiseringsprovider som är kompatibel med Microsoft Entra-ID som stöder autentiseringsmetodanspråket ("AMR"), referens för åtkomsttokenanspråk – Microsofts identitetsplattform, vilket återspeglar den faktiska typ av autentiseringsuppgift som angavs under autentiseringen.

Vi rekommenderar starkt att du implementerar MFA som är kompatibelt med Microsoft Entra-ID omedelbart för att höja säkerhetsbaslinjen för din klientorganisation.

Relaterat innehåll