blog.atwork.at

news and infos about microsoft, technology, cloud and more

How the UserProfile in Azure Active Directory and how a Mailbox in Exchange Online looks like

Wednesday, February 17, 2016 3:30 PM Toni Pohl
When using a federated scenario where on prem users are synchronized to the cloud with Dirsync or AAD Connect, it’s important to know which user properties are transported into the Azure Active Directory (AAD). In the Microsoft Sync Tool you can define which fields shall be transported. In the cloud world, we can use the user properties in AAD in different ways... see all the user properties here!
Azure | Cloud | English | Microsoft | Office365
mehr

To Sync or Not to Sync?

Wednesday, February 3, 2016 12:39 PM Christoph Wilfing
Ich bin heute wieder einmal über ein Problem bei AAD Connect gestossen, das ich kurz erklären will. Speziell deshalb, weil nicht immer AAD Connect schuld ist, wenn mal ein Sync nicht funktioniert, Manchmal tut AAD Connect genau das was man ihm sagt, man muss halt nur wissen was in der Default Konfiguration für Regeln und Sicherheitsmechanismen eingebaut wurden. Mein Problem hat sich ganz simpel geäussert. Ein User im Active Directory soll per AAD Connect synchronisiert werden. Egal ob er vorher per Attributelevel Filter oder einfach durch OU Folder Filter nicht synchronisiert wurde oder auch einfach nicht aufgefallen ist, dass er online nicht existiert hat. Plötzlich fällt auf, der User fehlt. Step 1: Was fehlt? Im ersten Schritt müssen wir mal nachsehen ob der User überhaupt gefunden wird. Überprüfen können wir das ganz einfach. Wir öffnen den Synchronization Service und suchen im Metaverse ob der User aus dem Active Directory gelesen wird. unter 'Metaverse Search' entweder per 'Add Clause' die Suche einschränken oder einfach alle User suchen. Im Idealfall ist der betroffene User in der Liste enthalten. In meinem Beispiel ist der User zu finden. Sollte das nicht so sein, ist der Filter für den Import fehlerhaft. Mein User findet sich in der Liste und die Attribute schauen eigentlich ganz gut aus. Auf dem Tab 'Connectors' ist aber etwas seltsam. Der Inbound Connector genannt '2und40.at' liest aus meinem Active Directory, seltsam ist aber, es gibt keinen Outbound Connector. Den sollte es aber geben, sonst wird der User zwar aus dem Active Directory gelesen, aber niemals in unser AAD exportiert. Vergleichen wir das mit einem User bei dem es funktioniert, dann schaut das Ganze etwas anders aus, ein Beispiel wie unten: Man erkennt sofort, der Connector aus dem Active Directory und der Outbound Connector schreibt ins AAD. Perfekt, aber was verhindert, dass unser User im Metaverse ins AAD geschrieben wird? Step 2: Warum fehlt es? Um herauszufinden was hier schief geht, müssen wir den Rules Editor bemühen. Hier finden sich die Synchronzation Rules. Diese zeigen uns, was mit welchen Parametern synchronisiert wird. Nachdem unser User zwar hinein in unser MetaVerse kommt, ist der Teil 'inbound' für uns uninteressant. Spannend ist Outbound. Dort finden wir Rules die entscheiden ob ein Person Object aus dem Metaverse auf ein Cloud object gejoined wird und natürlich auch welche Attribute synchronisiert werden. Schaun wir dort etwas genauer rein, finden wir gleich die erste Rule 'User Join' Im Scoping Filter der User Join Rule wird entschieden, ob diese Rule zutrifft oder nicht. Diese Attribute sind verantwortlich ob ein User angelegt wird oder weggefiltert wird. Diese Filter sind auch Default, also da ist nichts customized. Simples Beispiel - ist der User nicht enabled, dann wird das 'AccountEnabled' Attribute entsprechend geändert. Ist das beim User leer, kann ich den User nicht synchronisieren. Ebenso wenn es sich nicht um User handelt und / oder das CloudMastered Attribute auf TRUE steht. (Damit wird zum Beispiel User Write Back realisiert, aber dazu später mal mehr) Wenn wir diese Attribute jetzt hernehmen und mal auf unserem User ansehen finden wir folgendes: Wie man sieht, fehlt unserem User der SourceAnchor. Fehlt dieses Attribute, kann der User nicht synchronisiert werden. Wer sich jetzt kurz meinen Artikel zum Thema ImmutableIDs ins Gedächtnis ruft, (Forever Immutable - ID gefällig - oder - Dirsync extended) wird feststellen, dass dieses Attribute eigentlich recht wesentlich ist und vor allem nicht fehlen kann. Es gibt keinen User im ActiveDirectory ohne ObjectGUID. ABER - das Attribute muss irgendwo befüllt werden bzw. beim Import aus dem ActiveDirectory entsprechend auf unser Metaverse geschrieben werden. Schaun wir uns daher die 'Inbound Rule' zum Erzeugen eines Users einmal genau an. Leider muss man da jetzt etwas suchen, aber das 'sourceAnchor' Attribute wird in der 'User AccountEnabled' Rule unter Transformations befüllt. Dort ist aber als Source eine Query angegeben die wir jetzt etwas genauer untersuchen: IIF(IsPresent([msExchRecipientTypeDetails]),   IIF([msExchRecipientTypeDetails]=2,     NULL,     IIF(IsString([objectGUID]),       CStr([objectGUID]),       ConvertToBase64([objectGUID]))),   IIF(IsString([objectGUID]),     CStr([objectGUID]),     ConvertToBase64([objectGUID]))) Etwas übersichtlicher dargestellt ist der wesentliche Teil für uns, dass hier per IF Abragen geprüft wird ob gewisse Attribute befüllt sind und welche Werte sie haben. Entsprechend wird als Result der SourceAnchor gesetzt. Wie man sieht, wird geprüft ob das msExchRecipientTypeDetails Feld existiert und ob es den Wert 2 hat.  Ist das der Fall - wird SourceAnchor auf' NULL gesetzt. Unser SourceAnchor ist null. also .. welchen Wert hat unser msExchangeRecipientTypeDetails? Jo, das ist natürlich blöd. Laut einem BlogArtikel (Recipient Type Details) ist der Wert eigentlich nur ein optisches Thema und sorgt dafür, dass die Mailbox anders angezeit wird. In dem Fall ist sie als 'Linked Mailbox' markiert. Also eigentlich eine Mailbox, die jemand anderem zugeordnet ist. In meinem konkreten Fall ist das aber eher 'passiert' als bewusst gesetzt worden. Es handelt sich um einen User, der aus einer anderen Domäne per ADMT migriert wurde. Daher wurde der Zugriff auf die Mailbox einige Zeit über External Accounts berechtigt. Damit wird der User als Linked Mailbox markiert. Step 3: Fehler ausbessern! Also.. machen wir einfach mal eine 1 aus den Details und.. Voila - beim nächsten Anstossen per DirSyncClientCmd.exe und einem Delta Sync wird der SourceAnchor befüllt und unser User ab sofort korrekt synchronisiert. Fazit Falls es also mal Probleme bei einzelnen Usern gibt und die Synchronisation muss man sich immer ansehen ob der User ins Metaverse kommt, ob er dort alle Attribute hat und natürlich auch die Synchronization Rules kennen. Hat man diese einmal verstanden, ist es ein leichtes zu erkennen warum ein User nicht gesynct wird oder sehr wesentliche Attribute einfach fehlen. Happy Syncing! LG Christoph
Azure | Cloud | Office365 | Windows | Tools
mehr