Entra cross-tenant synchronizace: propojení tenantů bez falešného pocitu sjednocení

Po akvizici se obvykle objeví stejný požadavek: lidé mají rychle najít kolegy, vstoupit do Teams a SharePointu druhé společnosti a přitom se ještě nemají stěhovat schránky, zařízení ani data. Entra cross-tenant synchronization tento mezistav umí výrazně zjednodušit. Nevytváří však jeden tenant a není migračním nástrojem. Automatizuje životní cyklus B2B identit mezi zdrojovým a cílovým tenantem. Kdo tuto hranici přehlédne, může sice získat hezčí people search, ale zároveň si vyrobit druhý adresář s nejasným vlastnictvím atributů, chybami v adresáři Exchange a rizikovým odchodem uživatelů.

Nejdřív rozhodněte, zda řešíte spolupráci, nebo konsolidaci

Cross-tenant synchronization je určena pro organizace, které vlastní více tenantů a potřebují mezi nimi automaticky vytvářet, aktualizovat a odstraňovat B2B collaboration objekty. Uživatel se stále ověřuje ve svém domovském tenantovi a data zůstávají tam, kde jsou. Microsoft výslovně uvádí, že služba nemigruje mailbox, OneDrive ani SharePoint a že zdrojový tenant zůstává pro přihlášení nezbytný. Pokud je cílem jeden adresář, jedna schránka a jedna sada zařízení po carve-inu, synchronizace je přechodná spolupráce, ne náhrada migračního programu.

Co se skutečně děje mezi zdrojem a cílem

Proces je jednosměrný push ze zdrojového tenantu. Zdroj určuje scope, mapování atributů a transformační pravidla; cílový tenant povoluje příchozí synchronizaci a může ji zastavit. Automatické vykoupení pozvánky musí být nastavené na obou stranách ve správném směru, jinak uživatel narazí na consent nebo test spojení skončí chybou, která zavádějícím způsobem připomíná neplatné přihlašovací údaje. Synchronizační interval podle aktuální dokumentace startuje přibližně po 40 minutách a první běh může trvat podstatně déle než přírůstkové cykly.

Multitenant organization přidává kontext pro Microsoft 365

Multitenant organization (MTO) je vrstva nad vztahy tenantů a cross-tenant synchronizací. Pro Teams vytváří uživatele jako externí členy typu Member místo běžného Guest, aby Microsoft 365 mohl nabídnout ucelenější zkušenost mezi tenanty. V Microsoft 365 admin centru se stejná skupina uživatelů synchronizuje do všech tenantů MTO; rozdílné scope pro jednotlivé cíle nastavíte až v Entra ID. MTO proto pomáhá se spoluprací a vyhledáváním osob, ale nezavádí centrální správu Exchange, Intune ani Conditional Access za všechny tenanty.

Licenční pravidlo není stejné pro uživatele a skupiny

Pro synchronizaci uživatelů ve stejném cloudu potřebuje každý synchronizovaný člověk Entra ID P1 ve svém domovském zdrojovém tenantovi; cílový tenant nepotřebuje licenci pouze kvůli samotné synchronizaci. Synchronizace skupin a cross-cloud scénáře vyžadují v domovském tenantovi Entra ID Governance nebo Entra Suite. Cílové funkce mohou mít vlastní licence a External ID billing může ovlivnit jiné externí scénáře. Rozpočet proto počítejte podle osob a funkcí, nikoli podle počtu vytvořených B2B objektů.

Párování stávajících účtů je nejrizikovější část pilotu

Entra páruje interní zdrojový účet s externím cílovým objektem přes interní alternativeSecurityIdentifier. Stávající B2B účet může převzít do správy, ale neumí spojit dva interní Member účty, které už existují v obou tenantech. Výchozí mapování navíc automaticky nezmění historický Guest na Member, pokud userType výslovně nenastavíte s odpovídajícím chováním. Před startem proto vytvořte matici: domovský účet, existující objekt v cíli, mailbox, UPN, primární SMTP, object ID a zamýšlený výsledek. Pilot bez této tabulky může vytvořit duplicitu, kterou uživatel pozná až v people pickeru nebo Teams.

Exchange atributy nejsou běžné Entra atributy

Nejméně nápadný problém bývá adresář Exchange. Cross-tenant synchronization vytváří B2B uživatele, nikoli mail contact, a nemá obecnou pravomoc zapisovat všechny Exchange atributy. proxyAddresses může být v cíli read-only, targetAddress není běžně dostupný a skrytí v adresáři se nespravuje stejně jako standardní mapování. Hodnota showInAddressList pomáhá people search, ale nezaručuje správný mail routing, free/busy ani jednotnou GAL. Tyto výsledky testujte odděleně a neodvozujte funkci pošty z toho, že účet vidíte v Entra.

Scope navrhněte podle cílových zdrojů, ne podle organizačního schématu

Začněte lidmi, kteří skutečně potřebují aplikace v cílovém tenantovi. Synchronizace všech zaměstnanců může zlepšit vyhledávání osob, ale současně rozšíří populaci pro Conditional Access, reporting, privacy dokumentaci a offboarding. U skupin platí další omezení: cílem jsou statické security groups, ne Microsoft 365 groups, distribuční skupiny nebo mail-enabled security groups; nested groups ani role-assignable groups podporované nejsou. Při zapnutí group sync musí být scope nastavený na „Sync only assigned users and groups“. Dynamická zdrojová skupina může být užitečný vstup, ale cílový objekt je statický.

Deprovisioning je změna přístupu, ne úklid adresáře

Odebrání uživatele ze scope vede k soft-delete cílového objektu. To je bezpečné jen tehdy, když tým zná navázané aplikace, skupiny, vlastnictví a dobu obnovy. Smazaný objekt lze obvykle obnovit do 30 dnů; on-demand provisioning jej však nemusí automaticky zvednout a neuvážené nové vytvoření může vyrobit duplicitu. Příchozí synchronizaci v cíli nevypínejte dřív, než doběhne řízené odprovisionování. Zvlášť testujte scénář „nejdřív block sign-in, potom vyřadit ze scope“ a ověřte, který tenant je autoritou pro accountEnabled.

Topologie hub-and-spoke a mesh mají odlišnou provozní cenu

Jedna konfigurace existuje vždy pro konkrétní směr source–target. Mesh tří tenantů proto není jedna služba, ale několik vztahů, mapování a sad logů. Hub-and-spoke omezuje počet spojení, ale centrální tenant se stává kritickým bodem pro přístup k aplikacím. Při návrhu počítejte konfigurace, vlastníky, break-glass postup a deprovisioning pro každý směr. Synchronizace neumí smyčku, protože dál neposílá externí objekty; to je bezpečnostní vlastnost, ale také důvod, proč se identita nešíří automaticky přes prostřední tenant.

Šest kroků bezpečného nasazení

1. 01

   Definujte domov identity

   U každého člověka určete autoritativní tenant a zákaz vytváření druhého interního účtu

2. 02

   Inventarizujte kolize

   Najděte staré hosty, Member účty, kontakty, mailboxy a duplicitní adresy v cíli

3. 03

   Navrhněte minimální scope

   Vyberte pilot podle aplikací a rizika, ne pouze podle oddělení

4. 04

   Nastavte oboustrannou důvěru

   Ověřte inbound sync, automatic redemption, MFA trust a Conditional Access

5. 05

   Testujte celý životní cyklus

   Proveďte create, update, manager change, block, remove, restore a hard-delete scénář

6. 06

   Teprve potom rozšiřujte

   Měřte provisioning chyby, přihlášení, duplicity a zkušenost v Teams, SharePointu a adresáři

Co měřit po spuštění

Provozní dashboard má oddělit tři vrstvy: stav provisioning jobu, použitelnost Microsoft 365 a bezpečnostní výsledek. Sledujte počet objektů ve scope, úspěchy a chyby na cyklus, stáří poslední změny, duplicity, nečekané reaktivace zablokovaných účtů a soft-delete. Z uživatelského pohledu měřte přihlášení, dohledání kolegy, vstup do Teams a otevření SharePointu. Bezpečnost musí ověřovat skutečný přístup a Conditional Access v cíli. Zelený provisioning job nedokazuje, že je návrh bezpečný ani že funguje mail routing.

Kdy synchronizaci raději nepoužít

Pro externí dodavatele a partnery, kteří nejsou součástí jedné organizace, Microsoft doporučuje spíše entitlement management a klasické B2B procesy; cross-tenant synchronization může přidat právní a privacy povinnosti a neřeší souhlas uživatele. Nevhodná je také jako rychlá náhrada plánu migrace nebo jako pokus spravovat zařízení dceřiné společnosti z centrály bez samostatného Intune návrhu. Přínos má tam, kde jsou vlastnictví tenantů, domov identity a odpovědnost za offboarding jednoznačné.