Běžné aspekty správy víceklientských uživatelů

Tento článek je třetí v řadě článků, které poskytují pokyny pro konfiguraci a poskytování správy životního cyklu uživatelů v prostředích Microsoft Entra s více tenanty. Následující články v řadě obsahují další informace, jak je popsáno.

• Úvod ke správě víceklientských uživatelů je první v řadě článků, které poskytují pokyny pro konfiguraci a poskytování správy životního cyklu uživatelů v prostředích Microsoft Entra s více tenanty.
• Scénáře správy víceklientských uživatelů popisují tři scénáře, pro které můžete používat funkce pro správu víceklientských uživatelů: koncové uživatelem iniciované, skriptované a automatizované.
• Běžná řešení pro správu víceklientských uživatelů, když pro váš scénář nefunguje jedna tenantská architektura, tento článek obsahuje pokyny k těmto výzvám: automatická správa životního cyklu uživatelů a přidělování prostředků napříč tenanty a sdílení místních aplikací mezi tenanty.

Pokyny vám pomůžou dosáhnout konzistentního stavu správy životního cyklu uživatelů. Správa životního cyklu zahrnuje zřizování, správu a rušení zřizování uživatelů napříč tenanty pomocí dostupných nástrojů Azure, které zahrnují spolupráci Microsoft Entra B2B (B2B) a synchronizaci mezi tenanty.

Požadavky na synchronizaci jsou jedinečné pro konkrétní potřeby vaší organizace. Při návrhu řešení, které splňuje požadavky vaší organizace, vám následující aspekty v tomto článku pomůžou identifikovat nejlepší možnosti.

• Synchronizace mezi tenanty
• Objekt adresáře
• Podmíněný přístup Microsoft Entra
• Další řízení přístupu
• Office 365

Synchronizace mezi tenanty

Synchronizace mezi tenanty může řešit problémy spolupráce a přístupu víceklientských organizací. Následující tabulka uvádí běžné případy použití synchronizace. Synchronizaci mezi tenanty i vývoj zákazníků můžete použít k uspokojení případů použití, pokud je důležité zvážit více než jeden vzor spolupráce.

Případ použití	Synchronizace mezi tenanty	Vlastní vývoj
Správa životního cyklu uživatelů
Sdílení souborů a přístup k aplikacím
Podpora synchronizace do suverénních cloudů nebo z suverénních cloudů
Řízení synchronizace z tenanta prostředků
Synchronizovat objekty skupiny
Odkazy správce synchronizace
Zdroj autority na úrovni atributu
Microsoft Entra zpětný zápis do služby Microsoft Windows Server Active Directory

Důležité informace o objektech adresáře

Pozvání externího uživatele s upN a adresou SMTP

Microsoft Entra B2B očekává, že user's UserPrincipalName (UPN) je primární adresa SMTP (Simple Mail Transfer Protocol) (Email) pro odesílání pozvánek. Pokud je hlavní název uživatele (UPN) stejný jako primární adresa SMTP, B2B funguje podle očekávání. Pokud se ale hlavní název uživatele (UPN) liší od primární adresy SMTP externího uživatele, může selhat, když uživatel přijme pozvánku. Tento problém může být problém, pokud neznáte skutečný hlavní název uživatele (UPN) uživatele. Při odesílání pozvánek pro B2B je potřeba zjistit hlavní název uživatele (UPN) a použít ho.

Část Microsoft Exchange Online tohoto článku vysvětluje, jak u externích uživatelů změnit výchozí primární smtp. Tato technika je užitečná, pokud chcete, aby všechny e-maily a oznámení pro externí tok toku na skutečnou primární adresu SMTP místo hlavního názvu uživatele (UPN). Může se jednat o požadavek, pokud hlavní název uživatele (UPN) není směrovaný pro tok pošty.

Převod typu UserType externího uživatele

Když konzolu použijete k ručnímu vytvoření pozvánky pro externí uživatelský účet, vytvoří objekt uživatele s typem uživatele typu host. Použití jiných technik k vytváření pozvánek umožňuje nastavit typ uživatele na něco jiného než externí účet hosta. Pokud například používáte rozhraní API, můžete nakonfigurovat, jestli je účet externím členem nebo externím účtem hosta.

• Některá omezení funkcí hosta je možné odebrat.
• Účty hostů můžete převést na typ uživatele člena.

Pokud převedete z externího uživatele typu host na uživatelský účet externího člena, může dojít k problémům s tím, jak Exchange Online zpracovává účty B2B. Nemůžete povolit e-mailové účty, které jste pozvali jako externí uživatele. Pokud chcete povolit e-mail externího člena účtu, použijte následující nejlepší přístup.

• Pozvěte uživatele z více organizací jako externí uživatelské účty typu host.
• Zobrazí účty v globálním adresáři.
• Nastavte userType na člena.

Při použití tohoto přístupu se účty zobrazují jako objekty MailUser v Exchangi Online a v Office 365. Všimněte si také, že existuje výzva k načasování. Ujistěte se, že je uživatel viditelný v globálním adresáři tak, že zkontroluje, zda vlastnost Microsoft Entra user ShowInAddressList odpovídá vlastnosti Exchange Online PowerShell HiddenFromAddressListsEnabled (které jsou vzájemně obrácené). Další informace o změně viditelnosti najdete v části Microsoft Exchange Online tohoto článku.

Je možné převést člena uživatele na uživatele typu host, což je užitečné pro interní uživatele, které chcete omezit na oprávnění na úrovni hosta. Interní uživatelé typu host jsou uživatelé, kteří nejsou zaměstnanci vaší organizace, ale pro které spravujete jejich uživatele a přihlašovací údaje. Může vám to umožnit vyhnout se licencování interního uživatele typu host.

Problémy s používáním objektů poštovních kontaktů místo externích uživatelů nebo členů

Uživatele z jiného tenanta můžete reprezentovat pomocí tradiční synchronizace globálního adresáře. Pokud provádíte synchronizaci globálního adresáře místo spolupráce Microsoft Entra B2B, vytvoří objekt poštovního kontaktu.

• Objekt kontaktu pošty a externí člen pošty nebo uživatel typu host nemůžou současně existovat ve stejném tenantovi se stejnou e-mailovou adresou.
• Pokud objekt poštovního kontaktu existuje pro stejnou e-mailovou adresu jako pozvaný externí uživatel, vytvoří externího uživatele, ale není povolený.
• Pokud externí uživatel s povolenou poštou existuje se stejnou poštou, při vytváření vyvolá pokus o vytvoření objektu poštovního kontaktu výjimku.

Důležité

Použití poštovních kontaktů vyžaduje službu Active Directory Services (AD DS) nebo Exchange Online PowerShell. Microsoft Graph neposkytuje volání rozhraní API pro správu kontaktů.

Následující tabulka zobrazuje výsledky objektů poštovních kontaktů a stavů externích uživatelů.

Existující stav	Scénář zřízení	Efektivní výsledek
Nic	Pozvat člena B2B	Neposlaný uživatel člena. Podívejte se na důležitou poznámku.
Nic	Pozvat hosta B2B	Povolte externího uživatele pošty.
Objekt poštovního kontaktu existuje.	Pozvat člena B2B	Error. Konflikt adres proxy serveru
Objekt poštovního kontaktu existuje.	Pozvat hosta B2B	Externí uživatel s povoleným poštovním kontaktem a nesílanou poštou Podívejte se na důležitou poznámku.
Externí uživatel typu host s povolenou poštou	Vytvoření objektu poštovního kontaktu	Chyba
Uživatel externího člena s povoleným e-mailem existuje.	Vytvoření poštovního kontaktu	Chyba

Microsoft doporučuje použít spolupráci Microsoft Entra B2B (místo tradiční synchronizace globálních adresářů) k vytvoření:

• Externí uživatelé, které povolíte zobrazit v globálním adresáři
• Uživatelé externího člena, kteří se ve výchozím nastavení zobrazují v globálním adresáři, ale nejsou povoleni poštou.

K zobrazení uživatelů v globálním adresáři můžete použít objekt poštovního kontaktu. Tento přístup integruje globální adresář bez poskytnutí dalších oprávnění, protože poštovní kontakty nejsou objekty zabezpečení.

Pokud chcete dosáhnout cíle, postupujte podle tohoto doporučeného přístupu:

• Pozvěte uživatele typu host.
• Zobrazte je od globálního adresáře.
• Zakažte je tím, že je zablokujte v přihlášení.

Objekt poštovního kontaktu nemůže převést na objekt uživatele. Vlastnosti přidružené k objektu poštovního kontaktu proto nemůžou přenášet (například členství ve skupinách a další přístup k prostředkům). Použití objektu poštovního kontaktu k reprezentaci uživatele přináší následující výzvy.

• Skupiny Office 365 Zásady podpory skupin Office 365 určují typy uživatelů, kteří můžou být členy skupin a pracovat s obsahem přidruženým ke skupinám. Skupina například nemusí uživatelům typu host povolit, aby se připojili. Tyto zásady nemůžou řídit objekty poštovních kontaktů.
• Samoobslužná správa skupin Microsoft Entra (SSGM). Objekty poštovních kontaktů nemají nárok na členy ve skupinách pomocí funkce SSGM. Možná budete potřebovat další nástroje pro správu skupin s příjemci reprezentovanými jako kontakty místo uživatelských objektů.
• Zásady správného řízení MICROSOFT Entra ID, kontroly přístupu. Pomocí funkce kontroly přístupu můžete zkontrolovat a potvrdit členství ve skupině Office 365. Kontroly přístupu jsou založené na uživatelských objektech. Členové reprezentované objekty poštovních kontaktů jsou mimo rozsah kontrol přístupu.
• Zásady správného řízení pro Microsoft Entra ID, správa nároků (EM). Když pomocí EM povolíte samoobslužné žádosti o přístup externím uživatelům na portálu EM společnosti, vytvoří objekt uživatele v době požadavku. Nepodporuje objekty poštovních kontaktů.

Důležité informace o podmíněném přístupu Microsoft Entra

Stav uživatele, zařízení nebo sítě v domovském tenantovi uživatele nepředá tenantovi prostředku. Externí uživatel proto nemusí splňovat zásady podmíněného přístupu, které používají následující ovládací prvky.

Pokud je to povolené, můžete toto chování přepsat nastavením přístupu mezi tenanty (CTAS), které dodržují vícefaktorové ověřování a dodržování předpisů zařízením z domovského tenanta.

• Vyžadovat vícefaktorové ověřování. Bez konfigurace CTAS se externí uživatel musí zaregistrovat nebo reagovat na vícefaktorové ověřování v tenantovi prostředků (i když bylo vícefaktorové ověřování v domovském tenantovi splněno). Výsledkem tohoto scénáře je několik problémů s vícefaktorovým ověřováním. Pokud potřebují resetovat vícefaktorové ověřovací doklady, nemusí si být vědomi vícefaktorové registrace ověřování napříč tenanty. Nedostatek povědomí může vyžadovat, aby uživatel kontaktoval správce v domovském tenantovi, tenantovi prostředků nebo obojím.
• Vyžadovat, aby zařízení bylo označeno jako vyhovující Bez konfigurace CTAS není identita zařízení zaregistrovaná v tenantovi prostředků, takže externí uživatel nemá přístup k prostředkům, které vyžadují tento ovládací prvek.
• Vyžadování hybridně připojených zařízení Microsoft Entra Bez konfigurace CTAS není identita zařízení zaregistrovaná v tenantovi prostředků (nebo místní Active Directory připojená k tenantovi prostředku). Externí uživatel proto nemůže získat přístup k prostředkům, které vyžadují tento ovládací prvek.
• Vyžadovat schválenou klientskou aplikaci nebo Vyžadovat zásady ochrany aplikací Bez konfigurace CTAS nemůžou externí uživatelé použít zásadu správy mobilních aplikací Intune (MAM), protože vyžaduje také registraci zařízení. Zásady podmíněného přístupu tenanta prostředků pomocí tohoto ovládacího prvku neumožňují ochranu MAM domovského tenanta, aby tyto zásady splňovaly. Vylučte externí uživatele ze všech zásad podmíněného přístupu založeného na MAM.

Kromě toho, i když můžete použít následující podmínky podmíněného přístupu, mějte na paměti možné důsledky.

• Riziko přihlášení a riziko uživatele Chování uživatele ve svém domovském tenantovi určuje částečně riziko přihlášení a riziko uživatele. Domovský tenant ukládá data a skóre rizika. Pokud zásady tenanta prostředků blokují externího uživatele, správce tenanta prostředku možná nebude moct povolit přístup. Uživatelé Microsoft Entra ID Protection a B2B vysvětlují, jak Microsoft Entra ID Protection detekuje ohrožené přihlašovací údaje pro uživatele Microsoft Entra.
• Místa. Definice pojmenovaného umístění v tenantovi prostředků určují rozsah zásad. Rozsah zásad nevyhodnocuje důvěryhodná umístění spravovaná v domovském tenantovi. Pokud vaše organizace chce sdílet důvěryhodná umístění mezi tenanty, definujte umístění v každém tenantovi, kde definujete prostředky a zásady podmíněného přístupu.

Zabezpečení víceklientských prostředí

Zabezpečení víceklientských prostředí začíná tím, že zajistí, aby každý tenant dodržoval osvědčené postupy zabezpečení. Projděte si kontrolní seznam zabezpečení a osvědčené postupy, které vám poradit se zabezpečením tenanta. Ujistěte se, že jsou tyto osvědčené postupy dodrženy, a projděte si je s libovolnými tenanty, se kterými úzce spolupracujete.

Ochrana účtů správců a zajištění nejnižších oprávnění

• Vyhledání a řešení mezer v pokrytí silného ověřování pro správce
• Zvyšte zabezpečení principem nejnižšího oprávnění pro uživatele i aplikace. Zkontrolujte role s nejnižšími oprávněními podle úkolu v MICROSOFT Entra ID.
• Minimalizujte trvalý přístup správce povolením Privileged Identity Management.

Monitorování víceklientských prostředí

• Monitorujte změny zásad přístupu mezi tenanty pomocí uživatelského rozhraní protokolů auditu, rozhraní API nebo integrace služby Azure Monitor (proaktivní upozornění). Události auditu používají kategorie CrossTenantAccessSettings a CrossTenantIdentitySyncSettings. Monitorováním událostí auditu v těchto kategoriích můžete identifikovat všechny změny zásad přístupu mezi tenanty a provést akci. Při vytváření upozornění ve službě Azure Monitor můžete vytvořit dotaz, například následující dotaz, který identifikuje všechny změny zásad přístupu mezi tenanty.

AuditLogs
| where Category contains "CrossTenant"

• Monitorujte všechny nové partnery přidané do nastavení přístupu mezi tenanty.

AuditLogs
| where OperationName == "Add a partner to cross-tenant access setting"
| where parse_json(tostring(TargetResources[0].modifiedProperties))[0].displayName == "tenantId"
| extend initiating_user=parse_json(tostring(InitiatedBy.user)).userPrincipalName
| extend source_ip=parse_json(tostring(InitiatedBy.user)).ipAddress
| extend target_tenant=parse_json(tostring(TargetResources[0].modifiedProperties))[0].newValue
| project TimeGenerated, OperationName,initiating_user,source_ip, AADTenantId,target_tenant
| project-rename source_tenant= AADTenantId

• Monitorujte změny zásad přístupu mezi tenanty, které povolují nebo neumožňují synchronizaci.

AuditLogs
| where OperationName == "Update a partner cross-tenant identity sync setting"
| extend a = tostring(TargetResources)
| where a contains "true"
| where parse_json(tostring(TargetResources[0].modifiedProperties))[0].newValue contains "true"

• Monitorování přístupu k aplikacím ve vašem tenantovi pomocí řídicího panelu aktivit přístupu mezi tenanty Monitorování umožňuje zjistit, kdo přistupuje k prostředkům ve vašem tenantovi a odkud tito uživatelé přicházejí.

Dynamické skupiny členství

Pokud vaše organizace používá podmínku dynamické skupiny členství všech uživatelů ve stávajících zásadách podmíněného přístupu, ovlivní tato zásada externí uživatele, protože jsou v rozsahu všech uživatelů.

Ve výchozím stavu ji odepírejte.

• Vyžadovat přiřazení uživatele pro aplikace. Pokud má aplikace požadované přiřazení Uživatele? Vlastnost Je nastavena na Ne, mohou k aplikaci přistupovat externí uživatelé. Správci aplikací musí rozumět dopadům řízení přístupu, zejména pokud aplikace obsahuje citlivé informace. Omezení aplikace Microsoft Entra na sadu uživatelů v tenantovi Microsoft Entra vysvětluje, jak jsou registrované aplikace v tenantovi k dispozici všem uživatelům tenanta, kteří se úspěšně ověřili. Toto nastavení je ve výchozím nastavení zapnuté.

Hloubková ochrana

Podmíněný přístup.

• Definujte zásady řízení přístupu pro řízení přístupu k prostředkům.
• Navrhujte zásady podmíněného přístupu s ohledem na externí uživatele.
• Vytvořte zásady speciálně pro externí uživatele.
• Vytvořte vyhrazené zásady podmíněného přístupu pro externí účty. Pokud vaše organizace používá podmínku dynamické skupiny členství všech uživatelů ve stávajících zásadách podmíněného přístupu, ovlivní tato zásada externí uživatele, protože jsou v rozsahu všech uživatelů.

Omezené jednotky správy

Při použití skupin zabezpečení k řízení rozsahu synchronizace mezi tenanty omezte, kdo může provádět změny ve skupině zabezpečení. Minimalizujte počet vlastníků skupin zabezpečení přiřazených k úloze synchronizace mezi tenanty a zahrňte skupiny do omezené jednotky pro správu. Tento scénář omezuje počet lidí, kteří můžou přidávat nebo odebírat členy skupiny a zřizovat účty napříč tenanty.

Další aspekty řízení přístupu

Podmínky a ujednání

Podmínky použití Microsoft Entra poskytují jednoduchou metodu, kterou mohou organizace použít k prezentaci informací koncovým uživatelům. Podmínky použití můžete použít k tomu, aby externí uživatelé před přístupem k vašim prostředkům schvalovali podmínky použití.

Aspekty licencování pro uživatele typu host s funkcemi Microsoft Entra ID P1 nebo P2

Microsoft Entra Externí ID ceny jsou založené na měsíčních aktivních uživatelích (MAU). Počet aktivních uživatelů je počet jedinečných uživatelů s ověřovací aktivitou v kalendářním měsíci. Fakturační model pro Microsoft Entra Externí ID popisuje, jak jsou ceny založené na MAU.

Důležité informace o Office 365

Následující informace řeší Office 365 v kontextu scénářů tohoto dokumentu. Podrobné informace jsou k dispozici ve spolupráci Microsoftu 365 pro spolupráci mezi klienty 365. Tento článek popisuje možnosti, které zahrnují použití centrálního umístění pro soubory a konverzace, sdílení kalendářů, používání rychlých zpráv, hlasových volání a videohovorů pro komunikaci a zabezpečení přístupu k prostředkům a aplikacím.

Microsoft Exchange Online

Exchange Online omezuje určité funkce pro externí uživatele. Omezení můžete zmenšit vytvořením externích uživatelů členů místo externích uživatelů typu host. Podpora externích uživatelů má následující omezení.

• Externímu uživateli můžete přiřadit licenci Exchange Online. Nemůžete jim ale vydat token pro Exchange Online. Výsledky jsou, že nemají přístup k prostředku.
  • Externí uživatelé nemůžou používat sdílené ani delegovaná poštovní schránky Exchange Online v tenantovi prostředků.
  • Externímu uživateli můžete přiřadit sdílenou poštovní schránku, ale nemůže k ní získat přístup.
• Abyste je mohli zahrnout do globálního adresáře, musíte zobrazit externí uživatele. Ve výchozím nastavení jsou skryté.
  • Skrytí externí uživatelé se vytvářejí při pozvání. Vytvoření je nezávislé na tom, jestli uživatel uplatnil pozvánku. Pokud jsou tedy všichni externí uživatelé skrytí, seznam obsahuje objekty uživatelů externích uživatelů, kteří pozvánku neuplatnili. V závislosti na vašem scénáři možná nebo nechcete objekty uvedené v seznamu.
  • Externí uživatelé můžou být skryti pomocí Exchange Online PowerShellu. Spuštěním rutiny Set-MailUser PowerShellu můžete nastavit vlastnost HiddenFromAddressListsEnabled na hodnotu $false.

Příklad:

Set-MailUser [ExternalUserUPN] -HiddenFromAddressListsEnabled:\$false\

Kde ExternalUserUPN je počítaný UserPrincipalName.

Příklad:

Set-MailUser externaluser1_contoso.com#EXT#@fabricam.onmicrosoft.com\ -HiddenFromAddressListsEnabled:\$false

Externí uživatelé se můžou v Centrum pro správu Microsoftu 365 zobrazit.

• Aktualizace vlastností specifických pro Exchange (například PrimarySmtpAddress, ExternalEmailAddress, EmailAddresses a MailTip) můžete nastavit pouze pomocí Exchange Online PowerShellu. Centrum pro správu Exchange Online neumožňuje upravovat atributy pomocí grafického uživatelského rozhraní (GUI).

Jak je znázorněno v příkladu, můžete pro vlastnosti specifické pro poštu použít rutinu PowerShellu Set-MailUser . Existují vlastnosti uživatele, které můžete upravit pomocí rutiny Set-User PowerShellu. Většinu vlastností můžete upravit pomocí rozhraní Microsoft Graph API.

Jednou z nejužitečnějších funkcí Set-MailUser je schopnost manipulovat s vlastností EmailAddresses . Tento atribut s více hodnotami může obsahovat více proxy adres pro externího uživatele (například SMTP, X500, SIP (Session Initiation Protocol). Ve výchozím nastavení má externí uživatel označenou primární adresu SMTP, která se vztahuje k userPrincipalName (UPN). Pokud chcete změnit primární smtp nebo přidat adresy SMTP, můžete nastavit tuto vlastnost. Nemůžete použít Centrum pro správu Exchange. Musíte použít Exchange Online PowerShell. Přidání nebo odebrání e-mailových adres pro poštovní schránku v Exchangi Online ukazuje různé způsoby, jak změnit vlastnost s více hodnotami, jako je EmailAddresses.

Microsoft SharePoint v Microsoftu 365

SharePoint v Microsoftu 365 má vlastní oprávnění specifická pro služby v závislosti na tom, jestli má uživatel (interní nebo externí) typ člena nebo hosta v tenantovi Microsoft Entra. Externí sdílení Microsoftu 365 a spolupráce Microsoft Entra B2B popisuje, jak můžete povolit integraci se SharePointem a OneDrivem ke sdílení souborů, složek, položek seznamu, knihoven dokumentů a webů s lidmi mimo vaši organizaci. Microsoft 365 to dělá při použití Azure B2B k ověřování a správě.

Po povolení externího sdílení v SharePointu v Microsoftu 365 je ve výchozím nastavení možnost vyhledávat uživatele typu host v SharePointu ve výběru osob Microsoftu 365. Toto nastavení zakáže zjistitelnost uživatelů typu host, když jsou skryti v globálním adresáři Exchange Online. Uživatelům typu host můžete povolit, aby se zobrazovali dvěma způsoby (vzájemně se nevylučují):

• Můžete povolit možnost hledat uživatele typu host těmito způsoby:
  • Upravte nastavení ShowPeoplePickerSuggestionsForGuestUsers na úrovni tenanta a kolekce webů.
  • Nastavte tuto funkci pomocí rutin Prostředí PowerShell Set-SPOTenant a Set-SPOSite v rutinách Microsoftu 365 PowerShellu .
• Uživatelé typu host, kteří jsou vidět v globálním adresáři Exchange Online, se také zobrazují ve výběru osob v SharePointu v Microsoftu 365. Účty jsou viditelné bez ohledu na nastavení ShowPeoplePickerSuggestionsForGuestUsers.

Microsoft Teams

Microsoft Teams má funkce pro omezení přístupu a na základě typu uživatele. Změny typu uživatele můžou ovlivnit přístup k obsahu a dostupné funkce. Microsoft Teams vyžaduje, aby uživatelé při práci v Teams mimo svého domácího tenanta změnili svůj kontext pomocí mechanismu přepínání tenanta klienta Teams.

Mechanismus přepínání tenanta pro Microsoft Teams může vyžadovat, aby uživatelé při práci v Teams mimo svého domácího tenanta ručně přepnuli kontext klienta Teams.

Uživatelům Teams z jiné externí domény můžete povolit, aby mohli vyhledávat, volat, chatovat a nastavovat schůzky s uživateli s federací Teams. Správa externích schůzek a chatu s lidmi a organizacemi pomocí identit Microsoftu popisuje, jak uživatelům ve vaší organizaci umožnit chatovat a setkávat se s lidmi mimo organizaci, kteří používají Microsoft jako zprostředkovatele identity.

Aspekty licencování pro uživatele typu host v Teams

Když používáte Azure B2B s úlohami Office 365, mezi klíčové aspekty patří instance, ve kterých uživatelé typu host (interní nebo externí) nemají stejné prostředí jako členové uživatelé.

• Skupiny Microsoftu. Přidání hostů do skupin Office 365 popisuje, jak přístup hostů v Skupiny Microsoft 365 umožňuje vám a vašemu týmu spolupracovat s lidmi mimo vaši organizaci tím, že jim udělíte přístup ke skupinovým konverzacím, souborům, pozvánkám kalendáře a poznámkovému bloku skupiny.
• Microsoft Teams. Možnosti vlastníka, člena a hosta v Teams popisují možnosti účtu hosta v Microsoft Teams. Plně věrné prostředí v Teams můžete povolit pomocí externích uživatelů členů.
  • Pro více tenantů v našem komerčním cloudu můžou uživatelé licencovaní ve svém domovském tenantovi přistupovat k prostředkům v jiném tenantovi ve stejné právnické osobě. Přístup můžete udělit pomocí nastavení externích členů bez dalších licenčních poplatků. Toto nastavení platí pro SharePoint a OneDrive pro Teams a skupiny.
  • Pro více tenantů v jiných cloudech Microsoftu a pro více tenantů v různých cloudech nejsou kontroly licencí členů B2B zatím k dispozici. Použití člena B2B s Teams vyžaduje další licenci pro každého člena B2B. Tento požadavek může mít vliv i na jiné úlohy, jako je Power BI.
  • Použití člena B2B pro tenanty, kteří nejsou součástí stejné právnické osoby, podléhají dodatečným licenčním požadavkům.
• Funkce zásad správného řízení identit Správa nároků a kontroly přístupu můžou vyžadovat další licence pro externí uživatele.
• Další produkty. Produkty, jako je správa vztahů se zákazníky Dynamics (CRM), můžou vyžadovat licencování v každém tenantovi, ve kterém je uživatel reprezentován.

Další kroky

• Úvod ke správě víceklientských uživatelů je první v řadě článků, které poskytují pokyny pro konfiguraci a poskytování správy životního cyklu uživatelů v prostředích Microsoft Entra s více tenanty.
• Scénáře správy víceklientských uživatelů popisují tři scénáře, pro které můžete používat funkce pro správu víceklientských uživatelů: koncové uživatelem iniciované, skriptované a automatizované.
• Běžná řešení pro správu víceklientských uživatelů, když pro váš scénář nefunguje jedna tenantská architektura, tento článek obsahuje pokyny k těmto výzvám: automatická správa životního cyklu uživatelů a přidělování prostředků napříč tenanty a sdílení místních aplikací mezi tenanty.
• Microsoft Collaboration Framework for the US Defense Industrial Base popisuje kandidátské referenční architektury pro identitu pro víceklientské organizace (MTO). Tento scénář se týká konkrétně těch MTO, které mají nasazení v suverénním cloudu USA s Microsoftem 365 US Government (GCC High) a Azure Government. Řeší také externí spolupráci v vysoce regulovaných prostředích včetně organizací, které jsou domovem v komerčním nebo suverénním cloudu USA.