Principy uživatelů a kontaktů ve službě Azure Active Directory Sync
Aktualizováno: 22. července 2015
Důležitý
Toto téma bude brzy archivováno.
Existuje nový produkt s názvem "Azure Active Directory Connect", který nahrazuje AADSync a DirSync.
Azure AD Connect zahrnuje komponenty a funkce, které byly dříve vydány jako Dirsync a AAD Sync.
V budoucnu skončí podpora nástroje Dirsync a AAD Sync.
Tyto nástroje se už neaktualizují jednotlivě pomocí vylepšení funkcí a všechna budoucí vylepšení budou součástí aktualizací služby Azure AD Connect.
Existuje několik různých důvodů, proč byste měli více doménových struktur služby Active Directory a existuje několik různých topologií nasazení. Mezi běžné modely patří nasazení prostředků účtu a synchronizované doménové struktury globálního adresáře po sloučení & získání. I když existují čisté modely, jsou hybridní modely také běžné. Výchozí konfigurace v AADSync nepředpokládá žádný konkrétní model, ale v závislosti na tom, jak byla v průvodci instalací vybrána shoda uživatelů, je možné pozorovat různé chování.
V tomto dokumentu si projdeme, jak se výchozí konfigurace chová v určitých topologiích. Projdeme konfiguraci a editor synchronizačních pravidel se dá použít k pohledu na konfiguraci.
Konfigurace předpokládá několik obecných pravidel:
Bez ohledu na pořadí, ve kterém čteme zdrojové adresáře Active Directory, by měl být konečný výsledek vždy stejný.
Aktivní účet bude vždy přispívat přihlašovacími informacemi, včetně userPrincipalName a sourceAnchor.
Zakázaný účet bude přispívat userPrincipalName a sourceAnchor, pokud se nejedná o propojenou poštovní schránku.
Účet s propojenou poštovní schránkou se nikdy nepoužije pro userPrincipalName a sourceAnchor. Předpokládá se, že se později najde aktivní účet.
Objekt kontaktu může být ve službě Azure AD zřízený jako kontakt nebo jako uživatel. Opravdu nevíte, dokud se nezpracují všechny zdrojové doménové struktury služby Active Directory.
Kontakty
Kontakty představující uživatele v jiné doménové struktuře jsou společné po sloučení & získání, kdy řešení GALSync přemostí dvě nebo více doménových struktur Exchange. Objekt kontaktu se vždy připojuje z prostoru konektoru k metaverse pomocí atributu pošty. Pokud už existuje objekt kontaktu nebo objekt uživatele se stejnou e-mailovou adresou, objekty se spojí dohromady. To je nakonfigurováno v pravidle In z AD – kontakt join. Existuje také pravidlo s názvem In z AD – Kontakt Common s tokem atributu k atributu metaverse sourceObjectType s konstantou Contact. Toto pravidlo má velmi nízkou prioritu, takže pokud je jakýkoli objekt uživatele připojený ke stejnému objektu metaverse, pak pravidlo z AD – User Common bude přispívat hodnotu Uživatel do tohoto atributu. S tímto pravidlem bude mít tento atribut hodnotu Kontakt, pokud nebyl připojen žádný uživatel, a hodnota Uživatel, pokud byl nalezen alespoň jeden uživatel.
Pokud chcete zřídit objekt pro AAD, odchozí pravidlo Out to AAD – Contact Join vytvoří objekt kontaktu, pokud je atribut metaverse sourceObjectType nastaven na Contact. Pokud je tento atribut nastavený na User, pravidlo Out to AAD – User Join místo toho vytvoří objekt uživatele. Je možné, že objekt je povýšen z kontaktu na uživatele, když se importují a synchronizují další zdrojové adresáře Active Directory.
Například v topologii GALSync při importu první doménové struktury najdeme kontaktní objekty pro všechny v druhé doménové struktuře. Tím se připraví nové objekty kontaktů v konektoru AAD. Při pozdějším importu a synchronizaci druhé doménové struktury najdeme skutečné uživatele a připojíme je k existujícím objektům metaverse. Potom odstraníme objekt kontaktu v AAD a místo toho vytvoříme nový objekt uživatele.
Pokud máte topologii, ve které jsou uživatelé a reprezentovaní jako kontakty, ujistěte se, že jste v průvodci instalací vybrali, aby odpovídaly uživatelům atributu pošty. Pokud vyberete jinou možnost, budete mít konfiguraci závislá na objednávce. Kontaktní objekty se vždy připojí k atributu pošty, ale objekty uživatelů se připojí pouze k atributu pošty, pokud byla tato možnost vybrána v průvodci instalací. Pokud byl objekt kontaktu importován před objektem uživatele, mohli byste v metaverzi skončit se dvěma různými objekty v metaverzi se stejným atributem pošty. Během exportu do Azure AD se vyvolá chyba. Toto chování je záměrně a značí chybná data nebo že topologie nebyla během instalace správně identifikována.
Zakázané účty
Zakázané účty se synchronizují i se službou Azure AD. Zakázané účty představují prostředky v Exchangi, například konferenční místnosti. Výjimkou jsou uživatelé s propojenou poštovní schránkou; jak jsme už zmínili, nikdy nezřídí účet pro Azure AD.
Předpokladem je, že pokud se najde zakázaný uživatelský účet, pak později nenajdeme další aktivní účet a objekt se zřídí pro Azure AD pomocí userPrincipalName a sourceAnchor nalezen. V případě, že se jiný aktivní účet připojí ke stejnému objektu metaverse, použije se jeho userPrincipalName a sourceAnchor.
Chaning sourceAnchor
Když je objekt exportován do Azure AD, už není možné změnit sourceAnchor. Když byl objekt exportován atribut metaverse cloudSourceAnchor je nastaven s hodnotou sourceAnchor přijatou službou Azure AD. Pokud se sourceAnchor změní a neshoduje cloudSourceAnchor , pravidlo Out to AAD – User Join vyvolá chybu atribut sourceAnchor se změnil. V takovém případě musí být konfigurace nebo data opravena, takže stejný sourceAnchor je opět k dispozici v metaverse, aby bylo možné objekt znovu synchronizovat.