Vyžadování vícefaktorového ověřování (MFA) pro tenanta partnera
Příslušné role: Agent pro správu | Obchodní agent | Agent helpdesku | Správce fakturace | Správce zabezpečení
Mezi hlavní priority patří lepší zabezpečení a trvalé zabezpečení a ochrana osobních údajů a nadále pomáháme partnerům chránit své zákazníky a tenanty.
Abychom partnerům pomohli chránit 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í. Tyto záruky vyžadují a ověřují vícefaktorové ověřování. Vyžadování vícefaktorového ověřování pomáhá partnerům zabezpečit přístup k prostředkům zákazníků před ohrožením přihlašovacích údajů.
Tento článek obsahuje podrobné příklady a pokyny pro ověřování vícefaktorového ověřování (MFA) v Partnerském centru.
Partneři, kteří se účastní programu Cloud Solution Provider (CSP), Ovládací panely dodavatelé (CPV) a poradci musí implementovat požadavky na zabezpečení partnerů, aby zůstali v souladu.
Partneři musí vynutit vícefaktorové ověřování pro všechny uživatelské účty v partnerském tenantovi, včetně uživatelů typu host. Uživatelé musí provést ověření vícefaktorového ověřování pro následující oblasti:
Partnerské centrum
Některé stránky v Partnerském centru jsou chráněné vícefaktorovým ověřováním, mezi které patří:
- Všechny stránky na kartě Zákazníci (to znamená všechny stránky s adresou URL začínající
https://partner.microsoft.com/commerce/*) - Všechny stránky na kartě Žádosti zákazníků podpory>(například všechny stránky, ke kterým se přistupuje pomocí adresy URL začínající
https://partner.microsoft.com/dashboard/v2/support/customers/*) - Všechny stránky na kartě Fakturace
Jiné stránky v Partnerském centru, jako je stránka Přehled a kontrola stavu služby, nevyžadují vícefaktorové ověřování.
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ícefaktorovým ověřováním (a které jsou touto funkcí ovlivněny).
| Stránka chráněná vícefaktorovým ověřováním | Agenti pro správu | Prodejní agenti | Agenti helpdesku | Správce zabezpečení | Správce fakturace |
|---|---|---|---|---|---|
| Všechny stránky na kartě Zákazníci | linka | x | linka | ||
| Všechny stránky na kartě Žádosti zákazníků podpory > | linka | linka | |||
| Stránka Fakturace | linka | x | linka | ||
| Pracovní prostor zabezpečení | linka | linka |
Pokud chcete získat přístup k těmto stránkám, musíte nejprve dokončit ověření vícefaktorového ověřování.
Podporované možnosti vícefaktorového ověřování
- Partneři, kteří používají microsoft, podporují vícefaktorové ověřování Microsoft Entra. Další informace najdete v tématu Více způsobů povolení vícefaktorového ověřování Microsoft Entra (podporováno vícefaktorové ověřování MFA)
- Partneři, kteří implementovali integrované federované ověřování MFA Tito uživatelé partnerů mají povolený přístup k Partnerskému centru a spravovat zákazníky pomocí GDAP. Podívejte se na integrované poskytovatele MFA s nabídkami MFA dostupnými ve službě AD FS: Konfigurace metod pro službu AD FS.
Důležité
Partneři musí používat zprostředkovatele ověřování, který je kompatibilní s integrovanou deklarací MFA v Microsoft Entra ID. Integrovaná deklarace identity označuje skutečný typ přihlašovacích údajů zadaný během ověřování. Partneři musí používat integrované vícefaktorové ověřování, aby mohli spravovat tenanty zákazníků pomocí GDAP.
Partnerské centrum a rozhraní API
Pro následující rozhraní API Partnerského centra se vyžaduje vícefaktorové ověřování podpory App+User a Microsoft Entra ID:
- Zjistit (cena, katalog nebo propagace)
- Transakce a správa
- Fakturace a odsouhlasení
- Správa zákazníků pomocí delegovaného přístupu nebo AOBO
- Přiřazení uživatelů a licencí (pouze s DAP)
- Přiřazení uživatelů a licencí (s GDAP)
- Podrobné žádosti o vztahy správy a přiřazení přístupu
Pro partnery jsou k dispozici následující možnosti:
- K splnění požadavků na vícefaktorové ověřování použijte integrované metody ověřování Od Microsoftu.
- Pokud používáte zprostředkovatele federované identity, ujistěte se, že je federace nakonfigurovaná tak, aby přijímala federované vícefaktorové ověřování.
- Pokud chcete použít ADFS ke konfiguraci externího druhého faktoru, projděte si poskytovatele třetích stran s nabídkami MFA dostupnými ve službě AD FS: Konfigurace metod ověřování pro službu AD FS
- Implementace vícefaktorového ověřování: Okamžitě povolte vícefaktorové ověřování prostřednictvím výchozích hodnot zabezpečení nebo podmíněného přístupu podle pokynů k výchozím nastavením zabezpečení.
Příklady ověření
Pokud chcete ilustrovat, jak funguje ověřování v Partnerském centru, zvažte následující příklady.
Příklad 1: Partner implementoval vícefaktorové ověřování Microsoft Entra
Alejandra pracuje pro CSP s názvem Contoso. Společnost Contoso implementovala vícefaktorové ověřování pro všechny uživatele v rámci partnerského tenanta Společnosti Contoso pomocí vícefaktorového ověřování Microsoft Entra.
Alejandra spustí novou relaci prohlížeče a přejde na stránku s přehledem Partnerského centra (která není chráněná vícefaktorovým ověřováním). Partnerské centrum přesměruje Alejandra na ID Microsoft Entra a přihlásí se.
Vzhledem k existujícímu nastavení vícefaktorového ověřování Microsoft Entra od společnosti Contoso se k dokončení ověření vícefaktorového ověřování vyžaduje Alejandra. Po úspěšném přihlášení a ověření vícefaktorového ověřování se Alejandra přesměruje zpět na stránku s přehledem Partnerského centra.
Alejandra se pokusí získat přístup k některé ze stránek chráněných vícefaktorovým ověřováním v Partnerském centru. Vzhledem k tomu, že Alejandra dokončila vícefaktorové ověřování během přihlášení dříve, alejandra má přístup ke stránce chráněné vícefaktorovým ověřováním, aniž by bylo nutné znovu projít ověřením vícefaktorového ověřování.
Příklad 2: Partner implementoval vícefaktorové ověřování jiných společností než Microsoft s využitím federace identit
Prashob pracuje pro CSP s názvem Wingtip. Wingtip implementoval vícefaktorové ověřování pro všechny uživatele v rámci partnerského tenanta Wingtip pomocí MFA jiného než Microsoftu, který je integrovaný s Microsoft Entra ID prostřednictvím federace identit.
Prashob spustí novou relaci prohlížeče a přejde na stránku s přehledem Partnerského centra (která není chráněná vícefaktorovým ověřováním). Partnerské centrum přesměruje Prashob na ID Microsoft Entra a přihlásí se.
Vzhledem k tomu, že Wingtip má nastavení federace identit, Microsoft Entra ID přesměruje Prashob na zprostředkovatele federované identity, aby se dokončilo ověřování vícefaktorového ověřování a přihlášení. Po úspěšném přihlášení a vícefaktorovém ověření se Prashob přesměruje zpět na ID Microsoft Entra a pak na stránku s přehledem Partnerského centra.
Prashob se pokusí získat přístup k některé ze stránek chráněných vícefaktorovým ověřováním v Partnerském centru. Vzhledem k tomu, že Prashob už během přihlašování dokončil vícefaktorové ověřování, má přístup ke stránce chráněné vícefaktorovým ověřováním, aniž by musel znovu projít ověřením vícefaktorového ověřování.
Prashob pak přejde na stránku správy služeb a přidá uživatele do MICROSOFT Entra ID společnosti Contoso. Vzhledem k tomu, že Prashob používá zprostředkovatele ověřování kompatibilního s Entra se silným ověřováním, může přistupovat k tenantovi zákazníka bez jakýchkoli problémů.
Doporučením pro Prashob v tomto příkladu je použití vícefaktorového ověřovacího řešení Microsoft Entra nebo zprostředkovatele ověřování kompatibilního s Entra, aby mohl úspěšně spravovat tenanta zákazníka.
Příklad 3: Partner neimplementoval vícefaktorové ověřování
Partner CSP s názvem Fabrikam ještě neimplementoval vícefaktorové ověřování. Microsoft doporučuje implementovat řešení vícefaktorového ověřování podporovaného id Microsoft Entra.
John pracuje pro Fabrikam. Společnost Fabrikam neimplementovala vícefaktorové ověřování pro žádné uživatele v rámci partnerského tenanta Fabrikam.
Jan spustí novou relaci prohlížeče a přejde na stránku s přehledem Partnerského centra (která není chráněná vícefaktorovým ověřováním). Partnerské centrum přesměruje Johna na ID Microsoft Entra a přihlásí se.
Po úspěšném přihlášení se Jan přesměruje zpět na stránku s přehledem Partnerského centra, protože nedokončil ověření vícefaktorového ověřování.
Jan se pokusí získat přístup k jedné ze stránek chráněných vícefaktorovým ověřováním v Partnerském centru. Vzhledem k tomu, že Jan nedokončil vícefaktorové ověřování, Partnerské centrum přesměruje Johna na ID Microsoft Entra a dokončí ověření vícefaktorového ověřování. Vzhledem k tomu, že k dokončení vícefaktorového ověřování je potřeba jan poprvé, jan se také požádá o registraci vícefaktorového ověřování. Po úspěšné registraci vícefaktorového ověřování a ověření vícefaktorového ověřování má Jan přístup na stránku chráněnou vícefaktorovým ověřováním.
Jiný den, než Fabrikam implementuje vícefaktorové ověřování pro libovolného uživatele, Jan spustí novou relaci prohlížeče a přejde na stránku s přehledem Partnerského centra (která není chráněná vícefaktorovým ověřováním). Partnerské centrum přesměruje Johna na ID Microsoft Entra a přihlásí se bez výzvy vícefaktorového ověřování.
Jan se pokusí získat přístup k jedné ze stránek chráněných vícefaktorovým ověřováním v Partnerském centru. Vzhledem k tomu, že Jan nedokončil vícefaktorové ověřování, Partnerské centrum přesměruje Johna na ID Microsoft Entra a dokončí ověření vícefaktorového ověřování. Vzhledem k tomu, že Jan zaregistroval vícefaktorové ověřování, tentokrát bude požádán pouze o dokončení ověření vícefaktorového ověřování.
Příklad 4: Partner implementoval vícefaktorové ověřování jiné společnosti než Microsoft, které není kompatibilní s Microsoft Entra
Trent pracuje pro CSP s názvem Wingtip. Wingtip implementoval vícefaktorové ověřování pro všechny uživatele v rámci partnerského tenanta Wingtip s využitím vícefaktorového ověřování jiného než Microsoftu v cloudovém prostředí s podmíněným přístupem.
Trent spustí novou relaci prohlížeče a přejde na stránku s přehledem Partnerského centra (která není chráněná vícefaktorovým ověřováním). Partnerské centrum přesměruje Trent na MICROSOFT Entra ID pro přihlášení.
Vzhledem k tomu, že Wingtip použil integraci MFA jiného než Microsoftu, která není kompatibilní s ID Microsoft Entra a nemá silné ověřování, bude Trent zablokován přístup ke všem stránkám a rozhraním API chráněným vícefaktorovým ověřováním v Partnerském centru.
Protože Trent přistupuje k chráněným stránkám vícefaktorového ověřování, musí předložit vícefaktorové ověřování pomocí silného ověřování, aby získal přístup k chráněným stránkám MFA.
Partneři musí používat zprostředkovatele ověřování kompatibilní s ID Microsoft Entra, které podporuje deklaraci identity metody přihlašovacích údajů (deklarace identity amr v referenčních informacích k deklaracím přístupových tokenů – Microsoft Identity Platform, která odráží skutečný typ přihlašovacích údajů zadaný během ověřování.
Důrazně doporučujeme partnerům CSP implementovat vícefaktorové ověřování, které je kompatibilní s ID Microsoft Entra, aby okamžitě zvýšili standardní hodnoty zabezpečení vašeho tenanta.
Rozhraní API Partnerského centra
Rozhraní API Partnerského centra podporuje ověřování jen pro aplikace i ověřování uživatelů (App+User).
Když se použije ověřování aplikací a uživatelů, Partnerské centrum vyžaduje vícefaktorové ověřování. Konkrétněji platí, že když partnerské aplikace odešle žádost o rozhraní API do Partnerského centra, musí do autorizační hlavičky požadavku zahrnout přístupový token.
Poznámka:
Architektura zabezpečeného aplikačního modelu je škálovatelná architektura pro ověřování partnerů CSP a cpv prostřednictvím architektury Microsoft Azure MFA při volání rozhraní API Partnerského centra. Tuto architekturu musíte implementovat při použití vícefaktorového ověřování v automatizaci služeb.
Když Partnerské centrum obdrží požadavek rozhraní API s přístupovým tokenem získaným pomocí ověřování app+user, rozhraní API Partnerského centra zkontroluje přítomnost hodnoty MFA v deklaraci identity AMR (Authentication Method Reference). 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), nebo ne:
{
"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"
}
Pokud je hodnota k dispozici, Partnerské centrum dospělo k závěru, že ověření vícefaktorového ověřování bylo dokončeno a zpracuje požadavek rozhraní API.
Pokud hodnota není k dispozici, rozhraní API Partnerského centra žádost odmítne s následující odpovědí:
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
Při volání rozhraní API Partnerského centra se přístupové tokeny jenom pro aplikace podporují operace, které nevyžadují přiřazení rolí GDAP v tenantovi zákazníka.
Další osvědčené postupy najdete v tématu Ověřování a autorizace rozhraní API – přehled.
Delegovaná správa partnera
Partnerské tenanty by měli používat podrobná delegovaná oprávnění správce (GDAP) ke správě zákaznických prostředků prostřednictvím portálů služeb Microsoft Online Services (portal.azure.com nebo admin.microsoft.com), rozhraní příkazového řádku (CLI) a rozhraní API (pomocí ověřování aplikací a uživatelů). Další informace najdete v podporovaných možnostech vícefaktorového ověřování.
Použití portálů služeb
Partneři CSP můžou spravovat své zákazníky z portálu Partnerského centra prostřednictvím rozhraní pro správu služeb. Partneři můžou přejít na zákazníka a vybrat Správu služeb, aby mohli spravovat konkrétní službu pro zákazníka. Partneři musí postupovat podle pokynů k roli GDAP, aby získali správnou roli GDAP s nejnižšími oprávněními pro správu svých zákazníků.
Při přístupu k portálům služeb Microsoft Online Services pomocí oprávnění delegovaného správce partnera (admin-on-Behalf-Of) ke správě zákaznických prostředků vyžaduje mnoho z těchto portálů interaktivní ověření s klientem Microsoft Entra nastaveným jako kontext ověřování. K přihlášení k tenantovi zákazníka se vyžaduje partner účet.
Ověřování Microsoft Entra ID vyžaduje, aby uživatel dokončil ověření vícefaktorového ověřování, pokud existují zásady vyžadující vícefaktorové ověřování. Existují dvě možná uživatelská prostředí v závislosti na tom, jestli je partnerovým účtem spravovaná nebo federovaná identita:
Pokud je partnerovým účtem spravovaná identita, Microsoft Entra ID přímo vyzve uživatele k dokončení ověření vícefaktorového ověřování. Pokud partnerský účet ještě není zaregistrovaný pro vícefaktorové ověřování s ID Microsoft Entra, zobrazí se uživateli nejprve výzva k dokončení registrace vícefaktorového ověřování.
Pokud je partnerovým účtem federovaná identita, prostředí závisí na tom, jak správce partnera nakonfiguroval federaci v Microsoft Entra ID. Při nastavování federace v Microsoft Entra ID může správce partnera indikovat Microsoft Entra ID, zda federovaný zprostředkovatel identity podporuje vícefaktorové ověřování, nebo ne.
- Pokud ano, Microsoft Entra ID přesměruje uživatele na zprostředkovatele federované identity a dokončí ověření vícefaktorového ověřování.
- Pokud ne, Microsoft Entra ID přímo vyzve uživatele k dokončení vícefaktorového ověřování. Pokud partnerský účet ještě není zaregistrovaný pro vícefaktorové ověřování s ID Microsoft Entra, zobrazí se uživateli nejprve výzva k dokončení registrace vícefaktorového ověřování.
Celkové prostředí je podobné scénáři, ve kterém tenant koncového zákazníka implementoval vícefaktorové ověřování pro správce. Tenant zákazníka například povolil výchozí nastavení zabezpečení Microsoft Entra, které vyžaduje, aby se všechny účty s právy správce přihlásily k tenantovi zákazníka pomocí ověřování vícefaktorového ověřování, včetně agentů pro správu a agentů helpdesku.
Pro účely testování můžou partneři povolit výchozí nastavení zabezpečení Microsoft Entra v tenantovi zákazníka a pak zkusit použít oprávnění GDAP (Partner Granular Delegated Administration) 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ů pomocí GDAP přihlásily k tenantovi zákazníka. Některé místo toho vyžadují, aby se partnerské účty přihlásily k partnerskému tenantovi. Příkladem je Centrum pro správu Exchange. V průběhu času očekáváme, že tyto portály budou vyžadovat, aby se partnerské účty při použití GDAP přihlásily k tenantovi zákazníka.
Prostředí registrace vícefaktorového ověřování
Pokud se během ověřování vícefaktorového ověřování ještě neregistroval partnerský účet pro vícefaktorové ověřování, Microsoft Entra ID vyzve uživatele, aby nejdřív dokončil registraci vícefaktorového ověřování.
Přečtěte si další informace o metodě Microsoft Authenticator:
Jakmile uživatel vybere možnost Další, zobrazí se mu výzva k výběru ze seznamu metod ověření.
Po úspěšné registraci musí uživatel dokončit ověření vícefaktorového ověřování pomocí zvolené metody ověření.
Běžné problémy
Pokud chcete zjistit, jestli je vaše žádost platná, projděte si seznam běžných problémů nahlášených jinými partnery.
Problém 1: Partner potřebuje více času k implementaci vícefaktorového ověřování pro své partnerské agenty
Partner ještě nezačala nebo je stále v procesu implementace vícefaktorového ověřování pro své partnerské agenty, kteří vyžadují přístup k portálům služeb Microsoft Online Services pomocí oprávnění delegovaných partnerů ke správě zákaznických prostředků. Partner potřebuje více času k dokončení implementace vícefaktorového ověřování. Jedná se o platný důvod technické výjimky?
Odpověď: Ne. Partner musí naplánovat implementaci vícefaktorového ověřování pro své uživatele, aby se vyhnul přerušení.
Poznámka:
I když partner pro své agenty neimplementoval vícefaktorové ověřování, můžou partneři dál přistupovat k portálům služeb Microsoft Online Services pomocí oprávnění delegované správy partnera, pokud můžou dokončit registraci vícefaktorového ověřování a ověření vícefaktorového ověřování po zobrazení výzvy při přihlašování k tenantovi zákazníka. Dokončení registrace vícefaktorového ověřování automaticky nepovoluje uživatele pro vícefaktorové ověřování.
Problém 2: Partner neimplementoval vícefaktorové ověřování, protože nepotřebuje přístup ke správě zákazníků
Partner má některé uživatele ve svých partnerských tenantech, kteří nevyžadují přístup k portálům služeb Microsoft Online Services ke správě zákaznických prostředků pomocí oprávnění delegovaná pro správu partnerů. Partner je v procesu implementace vícefaktorového ověřování pro tyto uživatele a potřebuje více času na dokončení. Jedná se o platný důvod technické výjimky?
Odpověď: Ne. Vzhledem k tomu, že tyto uživatelské účty nepoužívají k správě zákaznických prostředků delegovaná oprávnění pro delegovanou správu partnera, nebudou se muset přihlásit k tenantovi zákazníka. Nebude to mít vliv na ID Microsoft Entra, které během přihlašování k tenantovi zákazníka vyžaduje vícefaktorové ověřování. Všichni uživatelé musí mít vícefaktorové ověřování pro přístup k Partnerskému centru nebo k úlohám zákazníků, aby mohli spravovat prostředky zákazníků.
Problém 3: Partner neimplementoval vícefaktorové ověřování pro účty uživatelských služeb
Partner má ve svých partnerských tenantech uživatelské účty, které zařízení používají jako účty služeb. Tyto účty s nízkou úrovní oprávnění nevyžadují přístup k Partnerskému centru ani portálům služeb Microsoft Online Services ke správě zákaznických prostředků pomocí oprávnění delegované správy partnera. Jedná se o platný důvod technické výjimky?
Odpověď: Ne. Vzhledem k tomu, že tyto uživatelské účty nepoužívají oprávnění delegovaná partnerská správa ke správě zákaznických prostředků, nemusí se přihlašovat k tenantovi zákazníka. Nebude to mít vliv na ID Microsoft Entra, které během přihlašování k tenantovi zákazníka vyžaduje vícefaktorové ověřování. Pokud rozhraní API nebo portál vyžadovalo ověřování aplikací a uživatelů, musí každý uživatel k ověřování používat vícefaktorové ověřování.
Problém 4: Partner nemůže implementovat vícefaktorové ověřování pomocí aplikace Microsoft Authenticator
Partner má "čisté pracovní" zásady, které neumožňují zaměstnancům přivést svoje osobní mobilní zařízení do pracovní oblasti. Bez přístupu k osobním mobilním zařízením nemůžou zaměstnanci nainstalovat aplikaci Microsoft Authenticator, což je jediné ověřování MFA podporované výchozími nastaveními zabezpečení Microsoft Entra. Jedná se o platný důvod technické výjimky?
Odpověď: Ne. Partner by měl při přístupu k Partnerskému centru zvážit následující alternativu, aby jejich zaměstnanci stále mohli dokončit vícefaktorové ověřování:
- Partner se může také zaregistrovat k Microsoft Entra ID P1 nebo P2 nebo použít řešení MFA od jiných společností než Microsoft, která jsou kompatibilní s MICROSOFT Entra ID, která můžou poskytovat více metod ověřování. Další informace najdete v tématu Podporované metody ověřování.
Problém 5: Partner nemůže implementovat vícefaktorové ověřování kvůli použití starších ověřovacích protokolů
Partner má některé partnerské agenty, kteří stále používají starší ověřovací protokoly, které nejsou kompatibilní s vícefaktorovým ověřováním. Uživatelé například pořád používají Outlook 2010, který je založený na starších ověřovacích protokolech. Povolení vícefaktorového ověřování pro tyto partnerské agenty přeruší používání starších ověřovacích protokolů. Jedná se o platný důvod technické výjimky?
Odpověď: Ne. Partneři se doporučuje odejít od použití starších ověřovacích protokolů kvůli potenciálním dopadům na zabezpečení, protože tyto protokoly není možné chránit pomocí ověřování vícefaktorového ověřování a jsou mnohem náchylnější k ohrožení přihlašovacích údajů. Doporučujeme, abyste zastaralí veškeré starší ověřování a použili výchozí nastavení zabezpečení nebo podmíněný přístup. Pokud se chcete připravit na přechod od starší verze ověřování, projděte si přihlašovací údaje pomocí starší verze ověřovacího sešitu a pokyny k blokování starší verze ověřování.
Pokud chcete porozumět nejnovějšímu plánu podpory starší verze ověřování pro Outlook, přečtěte si příspěvek o základním ověřování a Exchangi Online a sledujte blog týmu Exchange a získejte nadcházející novinky.
Problém 6: Partner implementoval vícefaktorové ověřování jiné společnosti než Microsoft, které microsoft Entra ID nerozpoznal
Partner implementoval vícefaktorové ověřování pro své uživatele pomocí řešení MFA jiného než Microsoftu. Partner ale nemůže správně nakonfigurovat řešení MFA jiného společnosti než Microsoft tak, aby předávalo do Microsoft Entra ID, které bylo během ověřování uživatele dokončeno ověření vícefaktorového ověřování. Jedná se o platný důvod technické výjimky?
Odpověď: Ne, partneři musí používat zprostředkovatele ověřování kompatibilního s ID Microsoft Entra, které podporuje deklaraci identity přihlašovacích údajů ("AMR"), referenční informace k deklaracím přístupových tokenů – Microsoft Identity Platform, což odráží skutečný typ přihlašovacích údajů zadaný během ověřování.
Důrazně doporučujeme implementovat vícefaktorové ověřování, které je kompatibilní s ID Microsoft Entra, abyste okamžitě zvýšili standardní hodnoty zabezpečení vašeho tenanta.