Ověřování a podmíněný přístup pro externí identity
Když externí uživatel přistupuje k prostředkům ve vaší organizaci, je tok ověřování určen metodou spolupráce (spolupráce B2B nebo přímé připojení B2B), zprostředkovatelem identity uživatele (externím tenantem Azure AD, zprostředkovatelem sociální identity atd.), zásadami podmíněného přístupu a nastavením přístupu mezi tenanty nakonfigurovanými v domovském tenantovi uživatele i v tenantovi, který hostuje prostředky.
Tento článek popisuje tok ověřování pro externí uživatele, kteří přistupují k prostředkům ve vaší organizaci. Organizace můžou pro své externí uživatele vynucovat více zásad podmíněného přístupu, které je možné vynutit na úrovni tenanta, aplikace nebo jednotlivých uživatelů stejným způsobem, jakým jsou povolené pro zaměstnance a členy organizace na plný úvazek.
Tok ověřování pro externí uživatele Azure AD
Následující diagram znázorňuje tok ověřování, když Azure AD organizace sdílí prostředky s uživateli z jiných Azure AD organizací. Tento diagram ukazuje, jak nastavení přístupu mezi tenanty fungují se zásadami podmíněného přístupu, jako je vícefaktorové ověřování (MFA), a určuje, jestli má uživatel přístup k prostředkům. Tento tok platí pro spolupráci B2B i přímé připojení B2B, s výjimkou případů uvedených v kroku 6.
| Krok | Description |
|---|---|
| 1 | Uživatel z Fabrikam ( domovský tenant uživatele) zahájí přihlášení k prostředku ve společnosti Contoso ( tenant prostředku). |
| 2 | Během přihlašování služba tokenů zabezpečení (STS) Azure AD vyhodnocuje zásady podmíněného přístupu společnosti Contoso. Také kontroluje, jestli má uživatel Fabrikam povolený přístup, a to vyhodnocením nastavení přístupu mezi tenanty (odchozí nastavení společnosti Fabrikam a příchozí nastavení společnosti Contoso). |
| 3 | Azure AD zkontroluje nastavení příchozí důvěryhodnosti společnosti Contoso a zjistí, jestli společnost Contoso důvěřuje vícefaktorovým ověřováním a deklaracím zařízení (dodržování předpisů zařízením, stav hybridního Azure AD připojení) z Fabrikam. Pokud ne, přejděte ke kroku 6. |
| 4 | Pokud společnost Contoso důvěřuje vícefaktorovým ověřováním a deklaracím identity zařízení od společnosti Fabrikam, Azure AD zkontroluje relaci ověřování uživatele, zda indikuje, že uživatel dokončil vícefaktorové ověřování. Pokud společnost Contoso důvěřuje informacím o zařízení od společnosti Fabrikam, Azure AD v ověřovací relaci vyhledat deklaraci identity označující stav zařízení (kompatibilní nebo hybridní Azure AD připojeno). |
| 5 | Pokud je vícefaktorové ověřování povinné, ale nedokončí se nebo pokud není k dispozici deklarace identity zařízení, Azure AD podle potřeby vystaví problémy s vícefaktorovým ověřováním a zařízeními v domovském tenantovi uživatele. Po splnění požadavků na vícefaktorové ověřování a zařízení ve službě Fabrikam má uživatel povolený přístup k prostředku ve společnosti Contoso. Pokud kontroly nejsou splněné, přístup se zablokuje. |
| 6 | Pokud se nenakonfiguruje žádné nastavení důvěryhodnosti a vyžaduje se vícefaktorové ověřování, zobrazí se uživatelům spolupráce B2B výzva k vícefaktorovém ověřování, které musí splnit v tenantovi prostředků. Přístup je blokovaný pro uživatele přímého připojení B2B. Pokud je dodržování předpisů zařízením povinné, ale nejde ho vyhodnotit, zablokuje se přístup pro spolupráci B2B i pro uživatele s přímým připojením B2B. |
Další informace najdete v části Podmíněný přístup pro externí uživatele .
Tok ověřování pro Azure AD externí uživatele
Když Azure AD organizace sdílí prostředky s externími uživateli s jiným zprostředkovatelem identity, než je Azure AD, tok ověřování závisí na tom, jestli se uživatel ověřuje pomocí zprostředkovatele identity nebo pomocí jednorázového ověřování hesla e-mailu. V obou případech tenant prostředků identifikuje, kterou metodu ověřování použít, a pak buď přesměruje uživatele na jeho zprostředkovatele identity, nebo vydá jednorázové heslo.
Příklad 1: Tok ověřování a token pro externího uživatele, který není Azure AD
Následující diagram znázorňuje tok ověřování, když se externí uživatel přihlásí pomocí účtu z jiného než Azure AD zprostředkovatele identity, jako je Google, Facebook nebo federovaný zprostředkovatel identity SAML/WS-Fed.
| Krok | Description |
|---|---|
| 1 | Uživatel typu host B2B požádá o přístup k prostředku. Prostředek přesměruje uživatele do tenanta prostředků, důvěryhodného zprostředkovatele identity. |
| 2 | Tenant prostředků identifikuje uživatele jako externího a přesměruje ho na zprostředkovatele identity uživatele typu host B2B. Uživatel provádí primární ověřování v zprostředkovateli identity. |
| 3 | Zásady autorizace se vyhodnocují v zprostředkovateli identity uživatele typu host B2B. Pokud uživatel splňuje tyto zásady, zprostředkovatele identity uživatele typu host B2B uživateli vydá token. Uživatel se přesměruje zpět do tenanta prostředků s tokenem. Tenant prostředku token ověří a pak vyhodnotí uživatele podle jeho zásad podmíněného přístupu. Tenant prostředků může například vyžadovat, aby uživatel provedl vícefaktorové ověřování Azure Active Directory (AD). |
| 4 | Vyhodnocují se příchozí nastavení přístupu mezi tenanty a zásady podmíněného přístupu. Pokud jsou všechny zásady splněné, tenant prostředku vydá vlastní token a přesměruje uživatele na svůj prostředek. |
Příklad 2: Tok ověřování a token pro uživatele jednorázového hesla
Následující diagram znázorňuje tok, když je povolené ověřování pomocí jednorázového hesla e-mailu a externí uživatel není ověřený jinými způsoby, jako je Azure AD, účet Microsoft (MSA) nebo poskytovatel sociální identity.
| Krok | Description |
|---|---|
| 1 | Uživatel požádá o přístup k prostředku v jiném tenantovi. Prostředek přesměruje uživatele do tenanta prostředků, důvěryhodného zprostředkovatele identity. |
| 2 | Tenant prostředků identifikuje uživatele jako externího e-mailového uživatele s jednorázovým heslem a odešle uživateli e-mail s jednorázovým heslem. |
| 3 | Uživatel načte jednorázové heslo a odešle kód. Tenant prostředku vyhodnocuje uživatele podle jeho zásad podmíněného přístupu. |
| 4 | Jakmile jsou všechny zásady podmíněného přístupu splněné, tenant prostředku vydá token a přesměruje uživatele na svůj prostředek. |
Podmíněný přístup pro externí uživatele
Organizace můžou vynucovat zásady podmíněného přístupu pro externí spolupráci B2B a uživatele přímého připojení B2B stejným způsobem, jakým jsou povolené pro zaměstnance a členy organizace na plný úvazek. Se zavedením nastavení přístupu mezi tenanty můžete také důvěřovat vícefaktorovým ověřováním a deklaracím deklaracím zařízení od externích Azure AD organizací. Tato část popisuje důležité aspekty použití podmíněného přístupu na uživatele mimo vaši organizaci.
Poznámka
Vlastní ovládací prvky s podmíněným přístupem nepodporují vztahy důvěryhodnosti mezi tenanty.
Přiřazení zásad podmíněného přístupu k externím typům uživatelů
Při konfiguraci zásad podmíněného přístupu máte podrobnou kontrolu nad typy externích uživatelů, na které chcete zásady použít. Externí uživatelé jsou rozděleni do kategorií podle toho, jak se ověřují (interně nebo externě) a jejich vztahu k vaší organizaci (host nebo člen).
- Uživatelé typu host spolupráce B2B – do této kategorie spadá většina uživatelů, kteří jsou běžně považováni za hosty. Tento uživatel pro spolupráci B2B má účet v externí Azure AD organizaci nebo externím zprostředkovateli identity (například sociální identita) a ve vaší organizaci má oprávnění na úrovni hosta. Objekt uživatele vytvořený v adresáři Azure AD má Typ uživatele hosta. Tato kategorie zahrnuje uživatele spolupráce B2B, kteří byli pozváni a kteří použili samoobslužnou registraci.
- Členové spolupráce B2B – tento uživatel pro spolupráci B2B má účet v externí Azure AD organizaci nebo externího zprostředkovatele identity (například sociální identitu) a přístup k prostředkům ve vaší organizaci na úrovni člena. Tento scénář je běžný v organizacích, které se skládají z více tenantů, kde jsou uživatelé považováni za součást větší organizace a potřebují přístup na úrovni člena k prostředkům v ostatních tenantech organizace. Objekt uživatele vytvořený v adresáři prostředků Azure AD má UserType člen.
- Uživatelé přímého připojení B2B – externí uživatelé, kteří mají přístup k vašim prostředkům prostřednictvím přímého připojení B2B, což je vzájemné obousměrné připojení s jinou Azure AD organizací, které umožňuje přístup k určitým aplikacím Microsoftu (v současné době Propojení Microsoft Teams sdíleným kanálům). Uživatelé S přímým připojením B2B nejsou ve vaší Azure AD organizaci, ale spravují se z aplikace (například vlastníkem sdíleného kanálu Teams).
- Místní uživatelé typu host – místní uživatelé typu host mají přihlašovací údaje, které jsou spravované ve vašem adresáři. Před Azure AD spolupráce B2B bylo běžné spolupracovat s distributory, dodavateli, dodavateli a dalšími osobami tak, že pro ně nastavili interní přihlašovací údaje a označili je jako hosty nastavením uživatelského objektu UserType na Host.
- Uživatelé poskytovatele služeb – organizace, které slouží jako poskytovatelé cloudových služeb pro vaši organizaci (vlastnost isServiceProvider v konfiguraci specifické pro partnera Microsoft Graphu platí).
- Ostatní externí uživatelé – platí pro všechny uživatele, kteří nespadají do výše uvedených kategorií, ale nejsou považováni za interní členy vaší organizace, což znamená, že se neověřili interně prostřednictvím Azure AD a objekt uživatele vytvořený v adresáři prostředku Azure AD nemá typ uživatele člena.
Poznámka
Výběr Všichni uživatelé typu host a externí uživatelé byl nyní nahrazen možnostmi Host a externí uživatelé a všechny jeho podtypy. Pro zákazníky, kteří dříve měli zásadu condtional přístupu s vybranou možností Všichni uživatelé typu host a externí uživatelé, se teď zobrazí možnost Host a externí uživatelé spolu se všemi podtypy, které jsou vybrané. Tato změna v uživatelském prostředí nemá žádný funkční vliv na to, jak back-end podmíněného přístupu vyhodnocuje zásady. Nový výběr poskytuje zákazníkům potřebnou členitost, aby mohli zvolit konkrétní typy hosta a externích uživatelů, které se mají zahrnout nebo vyloučit z oboru uživatele při vytváření zásad podmíněného přístupu.
Přečtěte si další informace o přiřazeních uživatelů podmíněného přístupu.
Porovnání zásad podmíněného přístupu k externím identitám
Následující tabulka poskytuje podrobné porovnání zásad zabezpečení a možností dodržování předpisů v Azure AD externích identit. Zásady zabezpečení a dodržování předpisů spravuje hostitelská/zvoucí organizace v rámci zásad podmíněného přístupu.
| Zásady | Uživatelé spolupráce B2B | Uživatelé přímého připojení B2B |
|---|---|---|
| Udělení ovládacích prvků – blokování přístupu | Podporováno | Podporováno |
| Udělení kontrolních mechanismů – Vyžadovat vícefaktorové ověřování | Podporuje se | Podporuje se, vyžaduje konfiguraci nastavení příchozího vztahu důvěryhodnosti pro příjem deklarací vícefaktorového ověřování z externí organizace. |
| Udělení kontrolních mechanismů – Vyžadovat zařízení dodržující předpisy | Podporuje se, vyžaduje konfiguraci nastavení příchozího vztahu důvěryhodnosti tak, aby přijímalo vyhovující deklarace identity zařízení od externí organizace. | Podporuje se, vyžaduje konfiguraci nastavení příchozího vztahu důvěryhodnosti tak, aby přijímalo vyhovující deklarace identity zařízení od externí organizace. |
| Udělení ovládacích prvků – vyžadování zařízení připojeného službou Hybrid Azure AD | Podporuje se, vyžaduje konfiguraci nastavení příchozího vztahu důvěryhodnosti pro příjem deklarací identity zařízení připojených službou Hybrid Azure AD join od externí organizace. | Podporuje se, vyžaduje konfiguraci nastavení příchozího vztahu důvěryhodnosti pro příjem deklarací identity zařízení připojených službou Hybrid Azure AD join od externí organizace. |
| Řízení udělení – Vyžadovat schválenou klientskou aplikaci | Nepodporováno | Nepodporováno |
| Udělení ovládacích prvků – Vyžadovat zásady ochrany aplikací | Nepodporováno | Nepodporováno |
| Udělení ovládacích prvků – Vyžadovat změnu hesla | Nepodporováno | Nepodporováno |
| Ovládací prvky udělení – podmínky použití | Podporováno | Nepodporováno |
| Řízení relací – použití omezení vynucených aplikací | Podporováno | Nepodporováno |
| Řízení relací – použití řízení podmíněného přístupu k aplikacím | Podporováno | Nepodporováno |
| Řízení relací – frekvence přihlašování | Podporováno | Nepodporováno |
| Řízení relací – trvalá relace prohlížeče | Podporováno | Nepodporováno |
Vícefaktorové ověřování pro Azure AD externí uživatele
V Azure AD scénáři mezi tenanty může organizace prostředků vytvořit zásady podmíněného přístupu, které vyžadují vícefaktorové ověřování nebo dodržování předpisů zařízením pro všechny hostované a externí uživatele. Obecně platí, že uživatel spolupráce B2B, který přistupuje k prostředku, musí nastavit Azure AD vícefaktorové ověřování s tenantem prostředků. Azure AD teď ale nabízí možnost důvěřovat deklaracím vícefaktorového ověřování z jiných tenantů Azure AD. Povolení vztahu důvěryhodnosti vícefaktorového ověřování u jiného tenanta zjednodušuje proces přihlašování pro uživatele spolupráce B2B a umožňuje přístup uživatelům s přímým připojením B2B.
Pokud jste nakonfigurovali nastavení příchozího vztahu důvěryhodnosti tak, aby přijímalo deklarace vícefaktorového ověřování z domovského tenanta uživatele s přímým připojením B2B nebo z domovského tenanta uživatele s přímým připojením B2B, Azure AD zkontroluje relaci ověřování uživatele. Pokud relace obsahuje deklaraci identity, která značí, že zásady vícefaktorového ověřování už byly splněny v domovském tenantovi uživatele, uživateli se udělí bezproblémové přihlášení k vašemu sdílenému prostředku.
Pokud není povolený vztah důvěryhodnosti vícefaktorového ověřování, liší se uživatelské prostředí pro uživatele spolupráce B2B a uživatele s přímým připojením B2B:
Uživatelé spolupráce B2B: Pokud organizace prostředků nepovolila vztah důvěryhodnosti vícefaktorového ověřování u domovského tenanta uživatele, zobrazí se uživateli výzva vícefaktorového ověřování od organizace prostředků. (Tok je stejný jako tok MFA pro Azure AD externí uživatele.)
Uživatelé s přímým připojením B2B: Pokud organizace prostředků nepovolila vztah důvěryhodnosti vícefaktorového ověřování u domovského tenanta uživatele, bude mít uživatel zablokovaný přístup k prostředkům. Pokud chcete povolit přímé připojení B2B k externí organizaci a zásady podmíněného přístupu vyžadují vícefaktorové ověřování, musíte nakonfigurovat nastavení příchozího vztahu důvěryhodnosti tak, aby přijímalo deklarace vícefaktorového ověřování od organizace.
Přečtěte si další informace o konfiguraci nastavení příchozího vztahu důvěryhodnosti pro MFA.
Vícefaktorové ověřování pro externí uživatele bez Azure AD
V případě Azure AD externích uživatelů je za vícefaktorové ověřování vždy zodpovědný tenant prostředků. Následuje příklad typického toku MFA. Tento scénář funguje pro jakoukoli identitu, včetně účtu Microsoft (MSA) nebo ID sociální sítě. Tento tok platí také pro Azure AD externí uživatele, pokud jste nenakonfigurovali nastavení důvěryhodnosti s jejich domovskou Azure AD organizací.
Správce nebo informační pracovník ve společnosti Fabrikam pozve uživatele z jiné společnosti s názvem Contoso, aby použil aplikaci společnosti Fabrikam.
Aplikace společnosti Fabrikam je nakonfigurovaná tak, aby při přístupu vyžadovala vícefaktorové ověřování Azure AD.
Když se uživatel spolupráce B2B ze společnosti Contoso pokusí o přístup k aplikaci společnosti Fabrikam, zobrazí se výzva k dokončení Azure AD výzvy vícefaktorového ověřování.
Uživatel typu host pak může nastavit Azure AD vícefaktorové ověřování pomocí Fabrikam a vybrat možnosti.
Společnost Fabrikam musí mít dostatek licencí premium Azure AD, které podporují vícefaktorové ověřování Azure AD. Uživatel společnosti Contoso pak tuto licenci od společnosti Fabrikam spotřebuje. Informace o licencování B2B najdete v tématu model fakturace pro Azure AD externích identit.
Poznámka
Vícefaktorové ověřování se dokončí na tenantech prostředků, aby byla zajištěna předvídatelnost. Když se uživatel typu host přihlásí, zobrazí se mu na pozadí přihlašovací stránka tenanta prostředku a v popředí se zobrazí přihlašovací stránka a logo společnosti s vlastním domovským tenantem.
Azure AD resetování vícefaktorového ověřování pro uživatele spolupráce B2B
Následující rutiny PowerShellu jsou k dispozici k ověření nebo vyžádání registrace vícefaktorového ověřování od uživatelů spolupráce B2B.
Připojte se k Azure AD:
$cred = Get-Credential Connect-MsolService -Credential $credZískání všech uživatelů pomocí metod kontroly pravopisu:
Get-MsolUser | where { $_.StrongAuthenticationMethods} | select UserPrincipalName, @{n="Methods";e={($_.StrongAuthenticationMethods).MethodType}}Příklad:
Get-MsolUser | where { $_.StrongAuthenticationMethods} | select UserPrincipalName, @{n="Methods";e={($_.StrongAuthenticationMethods).MethodType}}Resetujte metodu Azure AD vícefaktorového ověřování pro konkrétního uživatele, aby uživatel znovu nastavil metody kontroly, například:
Reset-MsolStrongAuthenticationMethodByUpn -UserPrincipalName gsamoogle_gmail.com#EXT#@ WoodGroveAzureAD.onmicrosoft.com
Zásady síly ověřování pro externí uživatele
Síla ověřování je podmíněné řízení přístupu, které umožňuje definovat konkrétní kombinaci metod vícefaktorového ověřování (MFA), kterou musí externí uživatel dokončit při přístupu k vašim prostředkům. Toto řízení je zvlášť užitečné pro omezení externího přístupu k citlivým aplikacím ve vaší organizaci, protože pro externí uživatele můžete vynutit konkrétní metody ověřování, jako je metoda odolná proti útokům phishing.
Můžete také použít sílu ověřování na různé typy hosta nebo externích uživatelů , se kterými spolupracujete nebo se s nimi připojujete. To znamená, že můžete vynutit požadavky na sílu ověřování, které jsou jedinečné pro vaši spolupráci B2B, přímé připojení B2B a další scénáře externího přístupu.
Azure AD poskytuje tři předdefinované síly ověřování:
- Síla vícefaktorového ověřování
- Síla vícefaktorového ověřování bez hesla
- Síla vícefaktorového ověřování odolného proti útokům phishing
Můžete použít některou z těchto předdefinovaných silných stránek nebo vytvořit vlastní zásady síly ověřování založené na metodách ověřování, které chcete vyžadovat.
Poznámka
V současné době můžete zásady síly ověřování použít jenom u externích uživatelů, kteří se ověřují pomocí Azure AD. U uživatelů s jednorázovým přístupovým kódem, SAML/WS-Fed a federací Google použijte řízení udělení vícefaktorového ověřování, které vyžaduje vícefaktorové ověřování.
Když použijete zásadu síly ověřování u externích uživatelů Azure AD, ve spolupráci s nastavením důvěryhodnosti vícefaktorového ověřování v nastavení přístupu mezi tenanty určí, kde a jak musí externí uživatel provést vícefaktorové ověřování. Uživatel Azure AD se nejprve ověří pomocí vlastního účtu ve svém domovském tenantovi Azure AD. Když se pak tento uživatel pokusí o přístup k vašemu prostředku, Azure AD použije zásadu podmíněného přístupu síly ověřování a zkontroluje, jestli jste povolili vztah důvěryhodnosti vícefaktorového ověřování.
Ve scénářích externích uživatelů se metody ověřování, které jsou přijatelné pro splnění síly ověřování, liší v závislosti na tom, jestli uživatel provádí vícefaktorové ověřování ve svém domovském tenantovi, nebo v tenantovi prostředků. Následující tabulka uvádí přijatelné metody v každém tenantovi. Pokud se tenant prostředků rozhodl důvěřovat deklaracím identity od externích organizací Azure AD, bude pro plnění vícefaktorového ověřování přijímat jenom ty deklarace identity uvedené níže ve sloupci Domovský tenant. Pokud tenant prostředků zakázal vztah důvěryhodnosti vícefaktorového ověřování, musí externí uživatel dokončit vícefaktorové ověřování v tenantovi prostředků pomocí jedné z metod uvedených ve sloupci Tenant prostředků.
Tabulka 1. Metody vícefaktorového ověřování síly ověřování pro externí uživatele
| Metoda ověřování | Domovský tenant | Tenant prostředku |
|---|---|---|
| SMS jako druhý faktor | ✅ | ✅ |
| Hlasový hovor | ✅ | ✅ |
| Nabízené oznámení Microsoft Authenticatoru | ✅ | ✅ |
| Přihlášení přes telefon v Microsoft Authenticatoru | ✅ | ✅ |
| Softwarový token OATH | ✅ | ✅ |
| Hardwarový token OATH | ✅ | |
| Klíč zabezpečení FIDO2 | ✅ | |
| Windows Hello pro firmy | ✅ |
Pokud chcete nakonfigurovat zásadu podmíněného přístupu, která u externích uživatelů nebo hostů uplatňuje požadavky na sílu ověřování, přečtěte si téma Podmíněný přístup: Vyžadování ověřovací síly pro externí uživatele.
Uživatelské prostředí pro externí uživatele Azure AD
Zásady síly ověřování spolupracují s nastavením důvěryhodnosti vícefaktorového ověřování v nastavení přístupu mezi tenanty a určují, kde a jak musí externí uživatel provádět vícefaktorové ověřování.
Nejprve se uživatel Azure AD ověří pomocí vlastního účtu ve svém domovském tenantovi. Když se pak tento uživatel pokusí o přístup k vašemu prostředku, Azure AD použije zásadu podmíněného přístupu s ověřovací silou a zkontroluje, jestli jste povolili vztah důvěryhodnosti vícefaktorového ověřování.
- Pokud je povolený vztah důvěryhodnosti vícefaktorového ověřování, Azure AD zkontroluje v relaci ověřování uživatele deklaraci identity označující splnění vícefaktorového ověřování v domovském tenantovi uživatele. (V tabulce 1 najdete metody ověřování, které jsou přijatelné pro splnění vícefaktorového ověřování po dokončení v domovském tenantovi externího uživatele.) Pokud relace obsahuje deklaraci identity označující, že zásady vícefaktorového ověřování již byly splněny v domovském tenantovi uživatele a že metody splňují požadavky na sílu ověřování, bude mít uživatel povolený přístup. V opačném případě Azure AD zobrazí uživateli výzvu k dokončení vícefaktorového ověřování v domovském tenantovi pomocí přijatelné metody ověřování. V domovském tenantovi musí být povolená metoda MFA a uživatel se k ní musí mít možnost zaregistrovat.
- Pokud je důvěryhodnost vícefaktorového ověřování zakázaná, Azure AD zobrazí uživateli výzvu k dokončení vícefaktorového ověřování v tenantovi prostředků pomocí přijatelné metody ověřování. (V tabulce 1 najdete metody ověřování, které jsou přijatelné pro splnění vícefaktorového ověřování externím uživatelem.)
Pokud uživatel nemůže dokončit vícefaktorové ověřování nebo pokud mu v registraci brání zásady podmíněného přístupu (například vyhovující zásady zařízení), přístup se zablokuje.
Dodržování předpisů zařízením a zásady hybridního Azure AD připojených zařízení
Organizace můžou pomocí zásad podmíněného přístupu vyžadovat, aby zařízení uživatelů spravoval Microsoft Intune. Tyto zásady můžou blokovat přístup externích uživatelů, protože externí uživatel nemůže zaregistrovat své nespravované zařízení v organizaci prostředků. Zařízení může spravovat jenom domovský tenant uživatele.
Můžete ale použít nastavení důvěryhodnosti zařízení k odblokování externích uživatelů, ale přesto vyžadovat spravovaná zařízení. V nastavení přístupu mezi tenanty se můžete rozhodnout důvěřovat deklaracím z domovského tenanta externího uživatele o tom, jestli zařízení uživatele splňuje zásady dodržování předpisů zařízení nebo jestli je hybridní Azure AD připojené. Nastavení důvěryhodnosti zařízení můžete nastavit pro všechny Azure AD organizace nebo jednotlivé organizace.
Když je nastavení důvěryhodnosti zařízení povolené, Azure AD zkontroluje relaci ověřování uživatele na deklaraci identity zařízení. Pokud relace obsahuje deklaraci identity zařízení označující, že zásady už byly splněny v domovském tenantovi uživatele, externímu uživateli se udělí bezproblémové přihlášení k vašemu sdílenému prostředku.
Důležité
- Pokud nechcete důvěřovat deklaracím týkajícím se dodržování předpisů zařízením nebo stavu hybridního připojení Azure AD z domovského tenanta externího uživatele, nedoporučujeme používat zásady podmíněného přístupu, které vyžadují, aby externí uživatelé používali spravovaná zařízení.
Filtry zařízení
Při vytváření zásad podmíněného přístupu pro externí uživatele můžete zásady vyhodnotit na základě atributů zařízení zaregistrovaného zařízení v Azure AD. Pomocí filtru podmínky zařízení můžete cílit na konkrétní zařízení pomocí podporovaných operátorů a vlastností a dalších dostupných podmínek přiřazení v zásadách podmíněného přístupu.
Filtry zařízení je možné použít společně s nastavením přístupu mezi tenanty a založit zásady na zařízeních spravovaných v jiných organizacích. Předpokládejme například, že chcete blokovat zařízení z externího tenanta Azure AD na základě konkrétního atributu zařízení. Zásady založené na atributech zařízení můžete nastavit takto:
- Nakonfigurujte nastavení přístupu mezi tenanty tak, aby důvěřovala deklaracím identity zařízení z dané organizace.
- Atribut zařízení, který chcete použít k filtrování, přiřaďte k jednomu z podporovaných atributů rozšíření zařízení.
- Vytvořte zásadu podmíněného přístupu s filtrem zařízení, který blokuje přístup k zařízením obsahujícím tento atribut.
Přečtěte si další informace o filtrování zařízení s podmíněným přístupem.
Zásady správy mobilních aplikací
Nedoporučujeme vyžadovat zásady ochrany aplikací pro externí uživatele. Řízení udělení podmíněného přístupu, jako je Vyžadovat schválené klientské aplikace a Vyžadovat zásady ochrany aplikací , vyžadují, aby bylo zařízení zaregistrované v tenantovi prostředků. Tyto ovládací prvky se dají použít jenom na zařízeních s iOSem a Androidem. Vzhledem k tomu, že zařízení uživatele může spravovat pouze jeho domovský tenant, nelze tyto ovládací prvky použít u externích uživatelů typu host.
Podmíněný přístup na základě umístění
Zásady založené na umístění založené na rozsahech IP adres je možné vynutit, pokud zvoucí organizace může vytvořit důvěryhodný rozsah IP adres, který definuje partnerské organizace.
Zásady je také možné vynucovat v závislosti na zeměpisném umístění.
Podmíněný přístup založený na riziku
Zásady rizika přihlášení se vynucují, pokud externí uživatel typu host splňuje řízení udělení. Organizace může například vyžadovat Azure AD Vícefaktorové ověřování kvůli střednímu nebo vysokému riziku přihlášení. Pokud ale uživatel ještě v tenantovi prostředků nezaregistroval službu Azure AD Multi-Factor Authentication, zablokuje se. Cílem je zabránit uživatelům se zlými úmysly v registraci vlastních přihlašovacích údajů Azure AD Multi-Factor Authentication v případě, že by ohrozili heslo legitimního uživatele.
Zásady uživatelských rizik se ale v tenantovi prostředků nedají vyřešit. Pokud například vyžadujete změnu hesla pro vysoce rizikové externí uživatele typu host, zablokují se kvůli nemožnosti resetovat hesla v adresáři prostředků.
Podmínka klientských aplikací podmíněného přístupu
Podmínky klientských aplikací se pro uživatele typu host B2B chovají stejně jako pro jakýkoli jiný typ uživatele. Můžete například zabránit uživatelům typu host v používání starších ověřovacích protokolů.
Řízení relací podmíněného přístupu
Ovládací prvky relace se pro uživatele typu host B2B chovají stejně jako u jiných typů uživatelů.
Zásady ochrany identit a uživatelských rizik
Identity Protection detekuje ohrožené přihlašovací údaje pro uživatele Azure AD a označí uživatelské účty, které mohou být ohroženy, jako ohrožené. Jako tenant prostředků můžete u externích uživatelů použít zásady rizik uživatelů a blokovat tak riziková přihlášení. U externího uživatele se riziko uživatele vyhodnocuje v jeho domovském adresáři. Riziko přihlášení těchto uživatelů v reálném čase se vyhodnocuje v adresáři prostředků při pokusu o přístup k prostředku. Vzhledem k tomu, že identita externího uživatele existuje v jeho domovském adresáři, platí následující omezení:
- Pokud externí uživatel aktivuje zásadu rizik uživatelů služby Identity Protection, aby vynutila resetování hesla, zablokuje se, protože nemůže resetovat heslo v organizaci prostředků.
- Sestava rizikových uživatelů organizace prostředků nebude odrážet externí uživatele, protože vyhodnocení rizik probíhá v domovském adresáři externího uživatele.
- Správci v organizaci prostředků nemůžou rizikového externího uživatele zavřít ani opravit, protože nemají přístup k domovskému adresáři uživatele B2B.
Pokud chcete zabránit tomu, aby zásady založené na rizicích ovlivnily externí uživatele, můžete vytvořit skupinu v Azure AD, která obsahuje všechny externí uživatele vaší organizace. Pak tuto skupinu přidejte jako vyloučení pro předdefinované zásady rizik uživatelů a rizik přihlašování služby Identity Protection a všechny zásady podmíněného přístupu, které jako podmínku používají riziko přihlášení.
Další informace najdete v tématu Identity Protection a uživatelé B2B.
Další kroky
Další informace najdete v následujících článcích: