Office 365 - ADSync Felder

Diese Seite beschreibt, welche Felder durch ADSync mit dem AzureAD verbunden sind.

Felder im DirSync

Ehe ich im folgenden Abschnitt auf die Synchronisation genauer eingehe, sind noch ein paar Wort zu den Werten angebracht, die dabei synchronisiert werden. Es geht ja nicht nur darum, einen Benutzer auf der einen Seite auf der anderen Seite als Identity anzulegen und analog auch Kontakte und Gruppen zu übertragen. Jedes Objekt hat auch Properties wie Vorname, Nachname, UPN, Mailadresse etc. Diese Felder werden ebenfalls mit übernommen. Hier gibt es aber einige:

  • Umfang der Felder
    Wenn Sie glauben, dass ADSync einfach alle Felder aus ihrem lokalen AD in das Azure AD synchronisiert, dann täuschen Sie sich. Was sollte Azure AD z.B.: mit einer ObjectSID, SIDHistory o.ä. anfangen.
  • Feldgruppen und Applikationsfilter
    Aber auch dann ist es nicht einfach eine "Liste" von Feldern, die Synchronisiert werden. Einige Felder werden nur dann synchronisiert, wenn die entsprechenden Produkte installiert sind. Das kann verwirrend sein, denn das Feld "Mail" wird z.B. immer übertragen während ProxyAddresses aber nur bei installiertem Exchange synchronisiert werden. Seltsamerweise ist aber Exchange auch erforderlich, um z.B. das Feld "UserCertificate" mit den S/MIME-Zertifikaten zu übertragen.
  • Richtung
    Fast in allen Fällen können Sie davon ausgehen, dass die Richtung der Synchronisation "Unidirektional" von dem On-Prem-Active Directory in die Cloud ist. Es gibt aber einige Felder, die wirklich auch zurück repliziert werden, z.B. msExchArchiveStatus, MsExchBlockedSendersHash, ProxyAddresses und einige andere. Aktuell (März 2016) sind es aber nur Exchange Attribute.
    Eine echte bidirektionale Synchronisation ist aber ebenfalls möglich, wenn Sie Azure-AD Premium lizenzieren. Dann können Anwender auch in der Cloud z.B. in einem Portal ihre Stammdaten ändern.
  • Inhalt
    Auch die Inhalte der Felder werden nicht immer 1:1 übertragen. ADSync prüft die Gültigkeit bezüglich Office 365 und passt die Inhalte an. das trifft z.B. auf den UPN zu, der nur <tenantname>.onmicrosoft.com oder eine ihrer in Office 365 registrierten Domains sein kann. Auch fehlende Felder im On-Prem-AD werden ggfls. durch andere Werte ersetzt. Ein fehlender UPN wird flugs aus dem immer vorhandenen NT4-SAMAccountName generiert.
  • Konflikte
    Eine Sonderbehandlung gibt es ggfls. für Felder, die in Azure-AD "eindeutig" sein müssen es aber On-Prem nicht sind. Sie können On-Prem durchaus mehreren Objekten z.B. die gleiche Mailadresse vergeben oder sogar den gleichen UPN. Das merkt niemand, solange er sich mit DOMÄNE\SAMACCOUNTNAME anmeldet und die Adresse nicht für den Postempfang genutzt wird.

Welche Felder wie umgesetzt werden, kann sich von Version zu Version natürlich auch mal ändern. Microsoft hat eine umfangreiche Liste veröffentlich, die alle Felder enthält aber keine weiteren Informationen zu Inhaltstransformationen, Konfliktlösungen oder Filterungen bietet.

Mit einem installierten ADSync können Sie aber jederzeit die aktiven Einstellungen selbst nachschauen.

Synchronisationsumfang und Transformationen

Bei der Installation von ADSync können Sie anhand der Domäne OU oder einem Attribut selektieren, welche Objekte in die Synchronisation eingeschlossen werden. zudem sind aber in den "Synchronization Rules" weitere Filter und Bedingungen hinterlegt. Für die folgenden Schritte ist ein grundlegendes Verständnis des DirSync sehr hilfreich

Über den "Synchronization Rules Editor" kommen Sie offiziell an diese Regeln. Es gibt eingehende und ausgehend Regeln.

Eingehende Regeln

Eingehend wird von ADSync der Schritt bezeichnet, die Daten von einer Quelle in die zentrale SQL-Datenbank zu überführen. Sie sehen hier einige Regeln, die Daten aus meinem Active Directory in die ADSync-Datenbank überführen aber auch vier Regeln die aus dem Azure AD Informationen in die ADSync Datenbank übertragen. Auch wenn der Verzeichnisabgleich primär von On-Prem zur Cloud erfolgt, bedeutet dies nicht, dass nicht auch Daten von der Cloud zumindest bis zur ADSync Datenbank kommen.

Sie können aber auch sehen, dass neben Benutzern, Gruppen und Kontakten auch "InetOrgPerson" und sogar Computer und Devices in die Cloud synchronisiert werden.

Schon hier gibt es aber auch Filter und Transformationen. Ich habe als Beispiel die Regel "107 In from AD -Group Common" exemplarisch ausgewählt. Über den "Scoping Filter" ist gut zu sehen, dass der ADSync Gruppen vom Typ "CriticalSystemObject" und auch solche mit einer AdminDescription "Group_" ausschließt.

Bei allen Gruppen, die dann noch übrig bleiben, werden folgende Felder aus dem AD ausgelesen und ggfls. nach einer Umrechnung in den Metastore geschrieben.

Einige der Felder sind also ein "Ausdruck", während andere Felder 1:1 übernommen werden. Am Feld "SourceAnchror" erkennen Sie aber auch, dass im MetaVerse durchaus andere neue Felder bei einem Objekt angelegt werden können.

Auch für Benutzer gibt es zwei Regeln:

  1. "In from AD - User Common"
    Hier werden die "gängigen Felder" eines Benutzers aus dem AD ausgelesen und in das Metaverse übertragen. Auch hier ist zu sehen, dass Microsoft per Default alle User mit einem "User_" in der AdminDescription auslässt

    Das ist gut zu sehen aber ich habe es noch nicht irgendwo prominent beschrieben gesehen.
  2. "In from AD - User Join"
    Diese Regel ist in der Hinsicht interessant, dass Sie ein Feld "CloudFiltered" abhängig von einem größeren Ausdruck.

    Dieses Feld ist später beim Export in die Cloud ein Filterkriterium.

Der Ausdruck ist ziemlich lang aber zeigt wie Microsoft per Default z.B. CAS-Konten, MSOL-Konten, Systemmailboxen etc. zwar noch in das MetaVerse importiert aber nicht mehr in die Cloud exportiert.

IIF(
   IsPresent([isCriticalSystemObject]) 
|| IsPresent(    [sAMAccountName]) = False 
              || [sAMAccountName] = "SUPPORT_388945a0" 
              || Left([mailNickname], 14) = "SystemMailbox{" 
              || Left([sAMAccountName], 4) = "AAD_" 
              || (Left([mailNickname], 4) = "CAS_" && (InStr([mailNickname], "}") > 0)) 
              || (Left([sAMAccountName], 4) = "CAS_" && (InStr([sAMAccountName], "}") > 0))
              || Left([sAMAccountName], 5) = "MSOL_" 
              || CBool(
                    IIF(
                       IsPresent([msExchRecipientTypeDetails]),BitAnd([msExchRecipientTypeDetails],&H21C07000) > 0,NULL)
                       ) 
              || CBool(InStr(DNComponent(CRef([dn]),1),"\\0ACNF:")>0), True, NULL
   )

Ausgehende Synchronisation

Aus dem MetaVerse zu den verschiedenen Verzeichnissen ist die Liste sehr viel mehr Richtung Cloud ausgerichtet. Nur gerade mal eine Regel 140 arbeitet beim ADSync gegen das lokale Active Directory. Alle anderen Regeln beschreiben, wie die Objekte in die Cloud übertragen werden. 

Hier ist aber auch gut zu sehen, dass ein "User" nicht einfach plump übertragen wird. Es gibt allein 8 (acht) Regeln, die Felder Aus dem ADSync Store in die Cloud synchronisieren. Die Tücken sind dabei auch im Details zu suchen, denn nicht immer werden AD-Felder übertragen, die man so erwartet. Ein Beispiel ist z.B. das Feld "UserCertificate", welches bei einem einfachen "User" nicht in die Cloud übertragen wird. Erst wenn das Objekt auch bezüglich Exchange relevant ist, wird auch dieses Feld in das Cloud Azure AD übertragen.

Filter nach Produkten

Beim alten "DirSync" waren in der FIM-Konsole noch umfangreiche Filter und Einstellungen möglich. Das ist mit ADSync nicht mehr per GUI möglich. So gibt es Felder, die nur synchronisiert werden, wenn auch ein bestimmtes Produkt vorhanden ist. Dies trifft z.B. auf das Feld "Mobile" als auch "UserCertificate" zu. Seit ADSync sind die Filtermöglichkeiten aber vereinfacht worden. Welche Felder für den Tenant zutreffen, wird mit der AADConnect-Konsole gesteuert. Einige Dinge können Sie aktivieren, während andere Einstellungen vom installierten Active Directory abhängen. In meinem Setup ist "Exchange Hybrid Deployment" nicht aktivierbar, weil es keine Exchange Installation im Forest dazu gibt.

In den erweiterten Einstellungen sind aber alle schon alle Optionen aktiviert, d.h. eine manuelle Filterung findet nicht statt.

Ohne eine lokale Exchange Installation überträgt der DirSync aber zumindest nicht die Exchange Einstellungen, auch wenn die Regel in ADSync dazu nicht sichtbar ist.

ReadOnly im AdminCenter

Objekte, die durch den Verzeichnisabgleich in der Cloud angelegt und verwaltet werden, sollten auch nur On-Premises geändert werden können. Anhand der Regeln haben Sie schon sehen könnten, dass es keine "Rückreplikation" gibt. Würden Objekte in der Cloud geändert, dann wären die Datenbestände nicht mehr übereinstimmend, was irgendwann zumindest die Outlook Anwender anhand unterschiedlicher Adressbücher bemerken würden. Microsoft hat daher vorgesorgt und bei den Objekten einige Felder "grau" gemacht. So können Sie bei Kontakten im AdminCenter die meisten Felder nicht verändern und der Hinweis auf das lokale Active Directory wird angezeigt.

Das ist natürlich darin begründet, dass beim einfachen DirSync ohne Azure AD Premium die Replikation nur unidirektional erfolgt.

MobileNumber nicht ReadOnly

Interessanterweise sind aber einige Felder dennoch schreibbar, z.B. ist die Mobilfunknummer auch bei einem auf dem AD synchronisierten Kontakt editierbar.

Ich habe dann absichtlich einmal die Mobilfunknummer On-Premises und in der Cloud geändert und die Daten wurden tatsächlich nicht abgeglichen. Ein Blick in die Synchronisationsregeln hat aber dann für Klarheit gesorgt. Die Mobilfunknummer wird vom lokalen AD in das Metaverse synchronisiert.

Ob ein Feld in der Cloud ankommt, ist aber Teil der "Outgoing Synchronization Rule". Hier gibt es ja gleich mehrere Regeln für Benutzer

In den ersten beiden Rules ist aber das Feld "Mobile" nicht eingeschlossen. Das ist erst in "Out to AAD - User Exchange Online" enthalten. Und ohne eine lokale Exchange Installation kommt das Feld dann nur bis zum Metaverse aber eben nicht beim Ziel an. Selbst wenn die Mobile Number dann im Azure-AD steht, muss sie noch nicht zwingend auch in SharePoint Online erscheinen.

Sonderfall Lizenzen

Viele Administratoren würden sich sicher wünschen, dass der ADSync auch die Vergabe von Lizenzen übernehmen könnte. Es wäre ein Wunschtraum, wenn z.B. On-Prem einfach ein LDAP-Feld oder die Mitgliedschaft in Gruppen auch die Lizenz steuern könnte. Dem ist aber nicht so und damit können sie auch im Admin Center die Lizenzen bei einem synchronisierten Objekt verwalten.

Es gibt aber natürlich Skripte, um per PowerShell und z.B. Gruppenmitgliedschaften in der Quelle die passende Lizenz im Ziel zuzuweisen. Wenn Sie diesen Prozess irgendwie automatisieren wollten, dann hilft ihnen dabei wieder ein eigenes Powershell-Script, welches sie neben dem ADSync ebenfalls regelmäßig ausführen lassen.

Sonderfall Office 365 Admin-Rechte

Sie können einen per ADSync angelegten Benutzer natürlich in Office 365 auch entsprechende Admin-Rechte zuweisen.

Weitere Links