Vyžádání vícefaktorového ověřování (MFA) pro partnerského tenanta

Odpovídající role: Agent pro správu | Sales agent | Agent helpdesku | Správce fakturace | Globální správce

Tento článek obsahuje podrobné příklady a pokyny pro vyžádání vícefaktorového ověřování (MFA) v Partnerské centrum. Účelem této funkce je pomoct partnerům zabezpečit jejich přístup k prostředkům zákazníků před ohrožením přihlašovacích údajů. Partneři musí vynucovat více ověřování pro všechny uživatelské účty ve svém partnerském tenantovi, včetně uživatelů hostů. Uživatelé budou mít oprávnění k dokončení více ověřování v následujících oblastech:

Mezi naše hlavní priority patří větší a průběžná ochrana zabezpečení a ochrany osobních údajů a pomáháme partnerům chránit jejich zákazníky a tenanty. Všichni partneři, kteří se účastní programu Cloud Solution Provider (CSP), Ovládací panely Vendors (CPV) a Advisors, by měli implementovat požadavky na zabezpečení partnerů, aby zůstali v souladu s předpisy.

Aby partneři ochránili své firmy a zákazníky před krádeží identity a neoprávněným přístupem, aktivovali jsme pro partnerské tenanty další bezpečnostní opatření, která umisťují a ověřují MFA.

Partnerské centrum řídicí panel

Některé stránky na řídicím Partnerské centrum budou chráněné MFA, mezi které patří:

Následující tabulka uvádí, které typy uživatelů mají oprávnění pro přístup k těmto stránkám chráněným více ověřováním (a proto jsou touto funkcí ovlivněny).

Stránka s ochranou MFA Agenti pro správu Agenti prodeje Agenti helpdesku Globální správce Správce fakturace
Všechny stránky na kartě Zákazníci x x x
Všechny stránky na kartě Support > Customer Requests (Žádosti zákazníků) x x
Stránka fakturace x x x

Pokud se pokusíte získat přístup k kterékoli z těchto stránek a ještě jste dříve neskončili ověřování MFA, budete k tomu muset použít . Další stránky na Partnerské centrum, jako je například stránka Přehled, Service Health kontrola stavu nevyžadují MFA.

Příklady ověřování

Pokud chcete ilustrovat, jak ověřování funguje Partnerské centrum řídicím panelu, zvažte následující příklady.

Příklad 1: Partner implementovali Azure AD MFA

  1. Jana pracuje pro CSP Contoso. Contoso implementovali MFA pro všechny své uživatele v partnerském tenantovi Společnosti Contoso pomocí Azure Active Directory (Azure AD) MFA.

  2. Jana spustí novou relaci prohlížeče a přejde na stránku Partnerské centrum řídicího panelu (která není chráněná MFA). Partnerské centrum přesměruje Jane do Azure AD, aby se přihlašuje.

  3. Kvůli stávajícímu nastavení Azure AD MFA od společnosti Contoso je Jana nutná k dokončení ověřování MFA. Po úspěšném přihlášení a ověření MFA se Jana přesměruje zpět na Partnerské centrum řídicího panelu.

  4. Jana se pokusí získat přístup k jedné ze stránek chráněných více ověřováním v Partnerské centrum. Vzhledem k tomu, že Jana už dříve dokončila ověřování MFA při přihlašování, může získat přístup na stránku chráněnou vícefainem, aniž by se vyžadovalo, aby znovu prošla ověřením MFA.

Příklad 2: Partner implementovali vícefabové ověřování třetích stran pomocí federace identit

  1. Ve společnosti CSP Wingtip funguje Takét. Wingtip implementovali MFA pro všechny své uživatele v rámci partnerského tenanta Wingtip pomocí MFA třetích stran, které je integrované se službou Azure AD prostřednictvím federace identit.

  2. Spustí novou relaci prohlížeče a přejde na stránku Partnerské centrum přehledu řídicího panelu (která není chráněná MFA). Partnerské centrum přesměruje Nat do Azure AD, aby se přihlašuje.

  3. Vzhledem k tomu, že Wingtip má nastavení federace identit, Azure AD přesměruje Nat na federovaného zprostředkovatele identity, aby se dokončilo přihlášení a ověření MFA. Po úspěšném přihlášení a ověření MFA se Procest přesměruje zpět do Azure AD a potom Partnerské centrum přehledu řídicího panelu.

  4. Při pokusu o přístup k jedné ze stránek chráněných více ověřováním v Partnerské centrum. Vzhledem k tomu, že Již dříve dokončil ověření MFA během přihlašování, může Mít přístup na stránku s ochranou MFA, aniž by se vyžadovalo, aby znovu prošel ověřením MFA.

Příklad 3: Partner ne implementovali MFA

  1. Jan pracuje pro CSP Fabrikam. Společnost Fabrikam ne implementovaná MFA pro žádného uživatele v partnerském tenantovi společnosti Fabrikam.

  2. Jan spustí novou relaci prohlížeče a přejde na Partnerské centrum řídicího panelu (která není chráněná více ověřováním). Partnerské centrum přesměruje Johna do Azure AD, aby se přihlašuje.

  3. Vzhledem k tomu, že společnost Fabrikam ne implementovali MFA, není Jan k dokončení ověřování MFA nutný. Po úspěšném přihlášení se Jan přesměruje zpět na Partnerské centrum přehledu řídicího panelu.

  4. Jan se pokusí získat přístup k jedné ze stránek chráněných více ověřováním v Partnerské centrum. Vzhledem k tomu, že Jan nedokončil ověřování MFA, Partnerské centrum přesměruje Johna do Azure AD, aby dokončil ověření MFA. Vzhledem k tomu, že k dokončení MFA je Jan potřeba ještě poprvé, musí se jan také zaregistrovat k MFA. Po úspěšné registraci MFA a ověření MFA teď může Jan získat přístup na stránku s ochranou MFA.

  5. Další den před implementací MFA pro libovolného uživatele ve společnosti Fabrikam Jan spustí novou relaci prohlížeče a přejde na stránku přehledu řídicího panelu Partnerské centrum (která není chráněná více ověřováním). Partnerské centrum přesměruje Johna do Azure AD, aby se přihlašuje bez výzvy KFA.

  6. Jan se pokusí získat přístup k jedné ze stránek chráněných více ověřováním v Partnerské centrum. Vzhledem k tomu, že Jan nedokončil ověřování MFA, Partnerské centrum přesměruje Johna do Azure AD, aby dokončil ověření MFA. Vzhledem k tomu, že Jan zaregistroval MFA, je tentokrát požádán pouze o dokončení ověřování MFA.

Poznámka

Akce: Správci společnosti mají tři možnosti implementace MFA.

Rozhraní API partnerského centra

Rozhraní Partnerské centrum API podporuje ověřování pouze pro aplikace i ověřování aplikací a uživatelů.

Při použití ověřování aplikací a uživatelů bude Partnerské centrum ověřování MFA. Konkrétněji řečeno, pokud partnerská aplikace chce odeslat požadavek rozhraní API do Partnerské centrum, musí v autorizační hlavičce požadavku obsahovat přístupový token.

Poznámka

Architektura Model zapezpečených aplikací je škálovatelná architektura pro ověřování partnerů CSP a procesorů prostřednictvím architektury Microsoft Azure MFA při volání rozhraní PARTNERSKÉ CENTRUM API. Toto rozhraní musíte implementovat před povolením MFA ve vašem tenantovi.

Když Partnerské centrum obdrží požadavek rozhraní API s přístupový token získaný pomocí ověřování aplikací a uživatelů, rozhraní Partnerské centrum API zkontroluje přítomnost hodnoty MFA v deklaraci identity odkazu na metodu ověřování (AMR). Dekodér JWT můžete použít k ověření, jestli přístupový token obsahuje očekávanou hodnotu odkazu na metodu ověřování (AMR):

{
  "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": "23ec45a3-5127-4185-9eff-c8887839e6ab",
  "appidacr": "0",
  "family_name": "Adminagent",
  "given_name": "CSP",
  "ipaddr": "127.0.0.1",
  "name": "Adminagent CSP",
  "oid": "4988e250-5aee-482a-9136-6d269cb755c0",
  "scp": "user_impersonation",
  "tenant_region_scope": "NA",
  "tid": "df845f1a-7b35-40a2-ba78-6481de91f8ae",
  "unique_name": "Adminagent.csp@testtestpartner.onmicrosoft.com",
  "upn": "Adminagent.csp@testtestpartner.onmicrosoft.com",
  "ver": "1.0"
}

Pokud je hodnota k dispozici, Partnerské centrum k závěru, že se dokončilo ověřování MFA, a zpracuje požadavek rozhraní API. Pokud hodnota neexistuje, rozhraní API Partnerské centrum požadavek zamítne s následující odpovědí:

HTTP/1.1 401 Unauthorized - MFA required
Transfer-Encoding: chunked
Request-Context: appId=cid-v1:03ce8ca8-8373-4021-8f25-d5dd45c7b12f
WWW-Authenticate: Bearer error="invalid_token"
Date: Thu, 14 Feb 2019 21:54:58 GMT

Při App-Only ověřování budou rozhraní API, která podporují ověřování App-Only, nepřetržitě fungovat bez vyžadování MFA.

Delegovaná správa partnerů

Partnerské účty, včetně agentů pro správu a agentů helpdesku, můžou používat svá delegovaná oprávnění správce partnera ke správě prostředků zákazníků prostřednictvím portálů služeb Microsoft Online Services, rozhraní příkazového řádku (CLI) a rozhraní API (pomocí ověřování aplikací a uživatelů).

Použití portálů služeb

Při přístupu k portálům služeb Microsoft Online Services pomocí oprávnění delegovaného partnera (Admin-On-Behalf-Of) ke správě prostředků zákazníků vyžaduje mnoho z těchto portálů interaktivní ověření partnerského účtu s tenantem Azure AD zákazníka nastaveným jako kontext ověřování – k přihlášení k zákaznickému tenantovi se vyžaduje partnerský účet.

Když Azure AD obdrží takové žádosti o ověření, bude vyžadovat, aby partnerský účet dokončil ověření MFA. V závislosti na tom, jestli je partnerský účet spravovaná nebo federovaná identita, existují dvě možná uživatelská prostředí:

  • Pokud je partnerským účtem spravovaná identita, Azure AD přímo vyzve uživatele k dokončení ověřování MFA. Pokud se partnerský účet ještě nezaregistruje k MFA ve službě Azure AD, uživatel se nejprve zobrazí s dotazem, jestli musí dokončit registraci MFA.

  • Pokud je partnerským účtem federovaná identita, závisí prostředí na tom, jak správce partnera nakonfiguroval federaci v Azure AD. Při nastavování federace ve službě Azure AD může správce partnera službě Azure AD indikovat, jestli zprostředkovatel federované identity podporuje MFA, nebo ne. Pokud ano, Azure AD přesměruje uživatele na zprostředkovatele federované identity, aby dokončil ověření MFA. V opačném případě Azure AD přímo vyzve uživatele k dokončení ověřování MFA. Pokud se partnerský účet ještě nezaregistruje k MFA ve službě Azure AD, uživatel se nejprve zobrazí s dotazem, jestli musí dokončit registraci MFA.

Celkové prostředí je podobné scénáři, ve kterém tenant koncového zákazníka implementovali MFA pro své správce. Například tenant zákazníka povolil výchozí nastavení zabezpečení Azure AD,což vyžaduje, aby se všechny účty s právy správce přihlašují k tenantovi zákazníka s ověřováním MFA, včetně agentů pro správu a agentů helpdesku. Pro účely testování mohou partneři povolit výchozí nastavení zabezpečení Azure AD v tenantovi zákazníka a pak se pokusit použít oprávnění delegované správy partnera pro přístup k tenantovi zákazníka.

Poznámka

Ne všechny portály služeb Microsoft Online Service vyžadují, aby se partnerské účty při přístupu k prostředkům zákazníků k zákaznickému tenantovi přihlašují pomocí oprávnění delegovaného správce partnera. Místo toho vyžadují jenom, aby se partnerské účty přihlašují k partnerského tenantovi. Příkladem je centrum Exchange pro správu. V průběhu času očekáváme, že tyto portály budou při použití delegovaných oprávnění správce partnerů vyžadovat, aby se partnerské účty přihlašují k tenantovi zákazníka.

Použití rozhraní API služby

Některá rozhraní API služeb Microsoft Online Services (například Azure Resource Manager, Azure AD Graph, Microsoft Graph atd.) podporují partnery pomocí oprávnění delegovaného správce partnerů k programové správě zákaznických prostředků. Pokud partnerská delegovaná oprávnění správce s těmito rozhraními API chcete používat, partnerská aplikace musí v hlavičce autorizace požadavku rozhraní API obsahovat přístupový token, kde se přístupový token získá tak, že má uživatelský účet partnera pro ověřování pomocí Azure AD a zákazník azure AD nastaví jako kontext ověřování. Partnerská aplikace musí mít k tenantovi zákazníka přihlášení pomocí partnerského uživatelského účtu.

Když Azure AD obdrží takovou žádost o ověření, Azure AD bude vyžadovat, aby uživatelský účet partnera dokončil ověření MFA. Pokud se uživatelský účet partnera ještě nezaregistroval pro MFA, bude tento uživatelský účet vyzván k dokončení registrace MFA jako první.

Tato funkce ovlivňuje všechny partnerské aplikace integrované s těmito rozhraními API pomocí oprávnění delegovaného správce partnera. Zajištění, aby partnerské aplikace i nadále fungovaly s těmito rozhraními API bez přerušení:

  • Partner se musí vyhnout použití neinteraktivní metody ověřování uživatelů se službou Azure AD k získání přístupového tokenu. Pokud používáte neinteraktivní metodu ověřování uživatelů, jako je password Flow, Azure AD nebude moct vyzvat uživatele k dokončení ověřování MFA. Partner musí místo toho přepnout na použití interaktivní metody ověřování uživatelů, jako Připojení OpenID.

  • Během interaktivní metody ověřování uživatelů by partner měl používat partnerský uživatelský účet, který je už povolený pro MFA. Případně po zobrazení výzvy azure AD může partner dokončit registraci MFA a ověření MFA během přihlašování.

  • Je to podobné scénáři, ve kterém tenant koncového zákazníka implementovali MFA pro své správce. Tenant zákazníka například povolil výchozí nastavení zabezpečení Azure AD,což vyžaduje, aby se všechny uživatelské účty s právy správce přihlašují k tenantovi zákazníka s ověřováním MFA, včetně agentů pro správu a agentů helpdesku. Pro účely testování mohou partneři povolit výchozí nastavení zabezpečení Azure AD v tenantovi zákazníka a pak se pokusí použít oprávnění delegované správy partnera k programovému přístupu k tenantovi zákazníka.

Prostředí registrace MFA

Pokud se během ověřování MFA partnerský účet ještě nezaregistrl pro MFA, Azure AD vyzve uživatele nejprve k dokončení registrace MFA:

Registrace MFA – krok 1.

Po kliknutí na Další se uživateli zobrazí dotaz, jestli si má vybrat ze seznamu metod ověřování.

Registrace MFA – krok 2.

Po úspěšné registraci se po uživateli vyžaduje dokončení více ověřování na základě ověření zvoleného uživatelem.

Seznam běžných problémů

Než začnete zažádat o technickou výjimku z požadavku na MFA, zkontrolujte seznam běžných problémů hlášených jinými partnery a zkontrolujte, jestli je vaše žádost platná.

Problém 1: Partner potřebuje více času na implementaci MFA pro své partnerské agenty

Partner ještě nezahájí nebo stále provádí implementaci MFA pro partnerskou agenty, kteří ke správě prostředků zákazníků vyžadují přístup k portálům služeb Microsoft Online Services pomocí oprávnění delegované správy pro partnery. Partner potřebuje více času k dokončení implementace MFA. Je tento problém platným důvodem pro technickou výjimku?

Odpověď: Ne. Aby se zabránilo přerušení služeb, partner musí pro své uživatele vytvořit plány na implementaci MFA.

Poznámka

I když partner ne implementoval MFA pro své partnerské agenty, partnerská agenti mají stále přístup k portálům Microsoft Online Services pomocí oprávnění pro delegovanou správu partnera za předpokladu, že po zobrazení výzvy při přihlášení k zákaznickému tenantovi mohou dokončit registraci MFA a ověření MFA. Dokončením registrace MFA se uživateli automaticky nepomáhá MFA.

Problém 2: Partner ne implementovali MFA pro uživatelské účty, které nevyu používají delegovaná oprávnění správce

Partner má některé uživatele ve svých partnerských tenantech, kteří nepožadují přístup k portálům služeb Microsoft Online Services, aby bylo možné spravovat prostředky zákazníků pomocí oprávnění delegované správy pro partnery. Partner je v procesu implementace MFA pro tyto uživatele a potřebuje více času k dokončení. Je tento problém platným důvodem pro technickou výjimku?

Odpověď: Ne. Vzhledem k tomu, že tyto uživatelské účty ke správě prostředků zákazníků používají oprávnění delegované správy partnera, nebudou se muset přihlašovat k tenantovi zákazníka. Nebudou ovlivněny službou Azure AD, která během přihlašování k tenantovi zákazníka vyžaduje více ověřování.

Problém 3: Partner ne implementovali MFA pro účty uživatelských služeb

Partner má ve svých partnerských tenantech několik uživatelských účtů, které zařízení používají jako účty služeb. Jedná se o účty s nízkými oprávněními, které nevyžadují přístup k Partnerské centrum ani portálům služeb Microsoft Online Services ke správě prostředků zákazníků pomocí oprávnění delegované správy pro partnery. Je tento problém platným důvodem pro technickou výjimku?

Odpověď: Ne. Vzhledem k tomu, že tyto uživatelské účty ke správě prostředků zákazníků používají oprávnění delegované správy partnera, nebudou se muset přihlašovat k tenantovi zákazníka. Nebudou ovlivněny službou Azure AD, která během přihlašování k tenantovi zákazníka vyžaduje více ověřování.

Problém 4: Partner nemůže implementovat více ověřování pomocí aplikace MS Authenticator App

Partner má zásady "čistého stolu", které zaměstnancům neumožnují přinášet svá osobní mobilní zařízení do jejich pracovní oblasti. Bez přístupu ke svým osobním mobilním zařízením zaměstnanci nemohou nainstalovat aplikaci MS Authenticator App, což je jediné ověřování MFA podporované výchozím nastavením zabezpečení Azure AD. Je tento problém platným důvodem pro technickou výjimku?

Odpověď: Ne, toto není platný důvod pro technickou výjimku. Partner by měl zvážit následující alternativy, aby jejich zaměstnanci mohli při přístupu k více Partnerské centrum:

  • Partner se také může zaregistrovat k Azure AD Premium řešení MFA třetích stran (kompatibilní s Azure AD), která mohou poskytovat další metody ověřování.
Problém 5: Partner nemůže implementovat MFA kvůli použití starších ověřovacích protokolů

Partner má několik partnerských agentů, kteří stále používají starší ověřovací protokoly, které nejsou kompatibilní s MFA. Uživatelé například stále používají verzi Outlook 2010, která je založená na starších protokolech ověřování. Povolení MFA pro tyto partnerské agenty naruší používání starších ověřovacích protokolů.

Odpověď: Ne, toto není platný důvod pro technickou výjimku. Partnerům se důrazně doporučuje, aby se z důvodu možných bezpečnostních důsledků posunuli od používání starších ověřovacích protokolů, protože tyto protokoly není možné chránit pomocí ověřování MFA a jsou mnohem náchylnější k ohrožení přihlašovacích údajů. Pokud se od používání starších ověřovacích protokolů nepřidáte, měli by partneři zvážit registraci do služby Azure AD Premium, která podporuje používání hesel aplikací. Hesla aplikací jsou jednou vygenerovaná systémem a obvykle jsou silnější než hesla generovaná člověkem. Pomocí hesel aplikací mohou partneři implementovat MFA pro své uživatele a zároveň se vracet k hesly aplikací jenom pro starší verze ověřovacích protokolů.

Přečtěte si příspěvek o základní ověřování a ověřování Exchange Online, abyste porozuměli nejnovějšímu plánu podpory starší verze ověřování pro Outlook, a sledujte blog týmu Exchange a získejte chystané novinky.

Poznámka

I když partner ne implementoval MFA pro své partnerské agenty, partnerská agenti mají stále přístup k portálům Microsoft Online Services pomocí oprávnění pro delegovanou správu partnera za předpokladu, že po zobrazení výzvy při přihlášení k zákaznickému tenantovi mohou dokončit registraci MFA a ověření MFA. Dokončením registrace MFA se uživateli automaticky nepomáhá MFA.

Problém 6: Partner implementovali více ověřování třetích stran, které Nerozpoznané službou Azure AD

Partner implementovali MFA pro své uživatele pomocí řešení MFA jiného výrobce. Partner ale nemůže správně nakonfigurovat řešení MFA třetí strany tak, aby předá azure AD, že ověřování MFA bylo dokončeno během ověřování uživatelů. Je toto platným důvodem pro technickou výjimku?

Odpověď: Ano, tento problém se může považovat za platný důvod technické výjimky. Před odesláním žádosti o technickou výjimku u poskytovatele řešení MFA třetí strany ověřte, že řešení MFA není možné nakonfigurovat tak, aby přetékalo deklaraci identity authenticationmethodsreferences (s hodnotou multipleauthn) do Služby Azure AD, aby bylo indikované, že ověřování MFA bylo dokončeno během ověřování uživatelů. Při odesílání žádosti o technickou výjimku musíte zadat podrobnosti o použitém řešení MFA třetí strany a uvést metodu integrace (například prostřednictvím federace identit nebo použití vlastního ovládacího prvku Azure AD) a v žádosti o technickou výjimku zadat následující informace jako podpůrné dokumenty:

  • Konfigurace MFA třetích stran.

  • Výsledek testu požadavků na zabezpečení partnerů spuštěných účtem s povoleným více ověřováním třetích stran

  • Nákupní objednávka řešení MFA třetí strany, které používáte nebo které plánujete použít.

Odeslání žádosti o technickou výjimku

Pokud se partneři setkávají s technickými problémy se službami Microsoft Online Services a neexistují žádné proveditelné řešení nebo alternativní řešení, mohou požádat o technickou výjimku, aby potlačil ověřování MFA. Před tím si prohlédněte seznam běžných problémů v předchozí části.

Odeslání žádosti o technickou výjimku:

  1. Přihlaste se a Partnerské centrum jako globální správce nebo agent pro správu.

  2. Vytvořte novou žádost o partnerskou službu tak, že přejdete na žádosti o podporu partnerů podpory a > vyberete Nová žádost.

  3. Vyhledejte MFA – žádost o výjimku ve vyhledávacím poli. nebo vyberte CSP z kategorie, pak vyberte Účty, Onboarding, Přístup z tématu, pak vyberte MFA – Žádost o výjimku z dílčího tématu a pak vyberte další krok.

  4. Zadejte podrobnosti požadované k odeslání žádosti o služby pro technickou výjimku a vyberte Odeslat.

Poskytnutí odpovědi na žádost o technickou výjimku může Microsoftu trvat až tři pracovní dny.

Další kroky