ADSync mit CloudOnly-User

Auf der Seite ADSync User Matching habe ich beschrieben wie ADSync lokale AD-Objekte mit AzureAD-Objekte verknüpft. Es gibt mittlerweile immer mehr Kunden, die schon Benutzer und Gruppen in der Cloud angelegt haben aber bislang ohne ADSync gearbeitet haben. Die Folge sind nun zwei komplett getrennte Konten im lokale Active Directory und AzureAD, die man irgendwann doch zusammenführen möchte oder sogar muss. Ich denke hier an die vielen Tenants, die durch Covid-19 mal schnell angelegt und mit einer Teams Exploratory License versehen wurden.

Ausgangssituationen

Ihre Umgebung könnte also so aussehen, dass es Konten im AzureAD gibt, die aber reine "Cloud Only"-Konten sind. Im lokalen Active Directory kann es eventuell passende Konten geben, aber das muss auch nicht sein. Schon mehrfach habe ich bei Kunden erlebt, dass es CloudOnly-Konten z.B. für Shared Mailboxen oder Konferenzraumsysteme gibt, für die es keine entsprechenden Objekte im lokalen AD gibt. Das funktioniert mit der Cloud meist noch gut aber da diese Objekte für lokale Exchange und Skype for Business Server quasi "unbekannt" sind, knirscht es an einigen Stellen.

Match und Feldupdate

Für eine saubere Umgebung mit einem stabilen Betrieb in der Zukunft ist es erforderlich, dass es zu jedem Objekte in der Cloud auch ein passendes lokales AD-Objekt mit den passenden Feldinhalten gibt. Damit stellt sich die Frage, wie man..

  • ... ein vorhandenes AD-Objekt entsprechend vorbereitet,
    damit bei der Installation von ADSync auch die Objekte zugeordnet werden
  • ... fehlende Objekte korrekt angelegt werden
    damit sie bei schon aktivem ADSync nicht doppelte Objekte erzeugen.
  • Cloud User zukünftig direkte anlegen
    Wie können sie zukünftig verhindern, dass sie mit "Cloud Only"-Objekten starten?

Auf diese drei Fragen will diese Seite entsprechende Antworten geben.

Hard-Match

Zuerst benötigen Sie etwas Grundlagenwissen zur Funktion von ADSync in Verbindung mit bestehenden "CloudOnly"-Konten. ADSync synchronisiert Objekte aus dem lokalen Active Directory mit dem AzureAD/Office 365. Dabei muss ADSync natürlich auch Änderungen erkennen und nachhalten. Es wäre daher ungeschickt, wenn ADSync z.B. Felder wie CN, DN; SamAccountName o.ä. als "Anker" nutzen würde, denn auch die können sich ändern. Seit einigen Jahren hat daher jedes Objekte im AzureAD eine ObjectID, sie sich nicht ändert. Dieses Feld, oft auch als "SourceAnchor" oder "ImmutableID" bezeichnet, schreibt ADSync in das Feld "ms-ds-consistencyGUID" im lokalen Active Directory zurück. Wenn sie also ein neues Objekt im lokalen AD anlegen, dann sieht der Prozess wie folgt aus:

  • AD-Objekt wird angelegt
  • ADSync legt Ein AzureAD-Object an
  • ADSync liest die ObjectID aus dem AzureAD aus
  • ADSync schreibt die Information "base64-codiert" in das Feld "mS-DS-ConsistencyGuid" im lokalen AD

In AzureAD sieht das Objekt wie folgt aus:

Get-MsolUser -UserPrincipalName aduser2@msxfaq.de `
| fl UserPrincipalName,ObjectId,immutableid,proxyaddresses,lastdirsynctime

UserPrincipalName : ADUser2@msxfaq.de
ObjectId          : df30efef-afe7-421a-b577-e3be83171d1e
ImmutableId       : aLzH9/zNpEeXdIxL6G0NWw==
ProxyAddresses    : {smtp:ADUser2@msxfaq.onmicrosoft.com, SMTP:ADUser2@msxfaq.de}
LastDirSyncTime   : 22.04.2020 11:06:54

Das lokale AD-Objekt hat die Felder.

Get-ADUser "CN=ADUser2,OU=Firma,DC=msxfaq,DC=de" `
   -Properties * `
| fl userprincipalname,mail,mS-DS-ConsistencyGuid

userprincipalname     : ADUser2@msxfaq.de
mail                  : ADUser2@msxfaq.de
mS-DS-ConsistencyGuid : {104, 188, 199, 247...}

Sie sehen aber hier, dass das Feld "mS-DS-ConsistencyGuid" kein String ist, sondern ein Byte-Array. die ImmutableID ist "Base64-codiert und kann einfach konvertiert werden

[system.convert]::FromBase64String("aLzH9/zNpEeXdIxL6G0NWw==")| %{write-host "$($_) " -NoNewline}
104 188 199 247 252 205 164 71 151 116 140 75 232 109 13 91

Hier ist gut zu sehen. dass der Anfang 104, 188, 199, 247 übereinstimmt. Allerdings ist das Feld nur bei Objekten vorhanden, die den Status "DirSync" haben. Das Feld ist im "Desaster-Fall" wichtig, wenn ihre ADSync-Instanz verloren geht. Wenn Sie eine neue ADSync-Installation durchführen, dann versucht ADSync zuerst die Objekte anhand dieses Felds wieder zu verbinden. Das ist der "HardMatch" und ist eine Möglichkeit, Objekte zuzuordnen. Wird, warum auch immer, das Objekt in der Cloud gelöscht, dann geht ADSync von einem Fehler aus und legt kein neues Objekt an.

Da ein "Cloud-Only"-Objekt aber keine ImmutableID hat, können wir Hard-Match" nicht für die initale Zuordnung von lokalen Konten zu CloudOnly-Benutzern nutzen sondern nur für früher bereits synchronisierte Objekte.

Soft-Match

Daher gibt es noch einen "Soft-Match". Wenn ein lokale AD-Objekt keinen Wert im Feld "ms-ds-consistencyGUID" hat, dann nutzt ADSync den Inhalt des Felds "Mails" um ein passendes Objekt in der Cloud zu suchen, welches noch keine ImmutableID hat. Früher hat ADSync auch noch weitere Felder, z.B. CN, SamAccountName, etc.) geprüft aber das ist heute nicht mehr so.

Wenn ADSync in der Cloud ein Objekt findet, welches die gleiche primäre Mailadresse hat dann ist dies ein "Soft-Match".

Dazu nutzt ADSync folgende Schritte

  1. ADSync importiert Objekte aus dem lokalen AD (DeltaImport aus AD)
  2. ADSync importiert die Objekte aus dem AzureAD (DeltaImport aus AzureAD)
  3. ADSync macht ein "UserJoin" (DirSyn c)
    Dabei werden "neue" lokale Konten ohne ms-ds-consistencyguid und mit "Mail"-Adresse auf "CloudOnly"-Benutzer gematched.
  4. ADSync exportiert "ms-ds-consistencyGUID" ins lokale AD (Export ins AD)
  5. ADSync exportiert ImmutableID in die Cloud (Export ins AzureAD)
    Zudem überträgt er auch alle anderen "On-Premises" Felder in die Cloud, die lokal gesetzt sind

All diese Schritt können Sie in ADSync auch manuell durchführen indem Sie den ADSync-Scheduler auf "disabled" stellen und dann die Schritte im MISClient nacheinander durchführen.

Die Details habe ich auf ADSync User Matching beschrieben und auch Microsoft hat einige Links dazu

Tipp: Staging-OU

Ehe Sie nun vorschnell ein paar AD-Konten anlegen und dann eine Mailadresse verpassen, sollten Sie kurz innehalten. Es gibt da ein kleines Zeitfenster, welches ihnen Probleme bereiten kann. Stellen Sie sich folgendes vor:

  • Es gibt ein Cloud Only Konto mit Postfach
  • ADSync ist schon installiert
  • Sie legen ein neues AD-Konto an
  • Zufällig läuft ADSync los
    d.h. da das neue AD-Konto noch keine Mailadresse hat, wird ADSync ein zweites Konto anlegen
  • Sie vergeben eine Mailadresse
    ADSync wird auch diese Änderung übertragen aber kann dies nicht, da es schon ein anderen Postfach gibt

Sie haben hier nun zwei Optionen:

  1. Sie deaktivieren ADSync temporär
    Und starten ADSync erst wieder, wenn die neuen AD-Konten angelegt und komplett provisioniert sind. Das geht bei kleinen Firmen einfacher als bei großenn Firmen
  2. StagingOU / ADSync Filter
    Sie nutzen eine OU zur Anlage der Benutzer oder einen Filter, damit ADSync die Konten erst dann einliest, wenn diese "fertig" sind

Ich plädiere hier immer für den zweiten Weg. Das kann ein LDAP-Filter sein, den Sie in ADSync auch nutzen, um andere Konten generell aus dem Abgleich auszuschließen. Sie können aber auch eine eigene OU-Nutzen, die von ADSync ausgeschlossen ist. Dort können Sie die neue Konten anlegen, mit Exchange und Skype-Eigenschaften versehen und wenn dann alles "Fertig" ist, dann verschieben Sie das Objekt an den "richtigen Platz". Damit ersparen sie sich die Abstimmung mit ADSync-Läufen und Probleme beim "matching"

Felder überschreiben

Beachten Sie, dass ADSync viele Felder des lokalen AD-Kontos in die Cloud schreibt. Ein Vorname, Nachname, Displaynamer aber auch ProxyAddresse und Skype for Business Felder werden ebenfalls kopiert, wenn ADSync z.B. für den Exchange Hybrid Mode konfiguriert ist. Es könnte also sein, dass Inhalte in der Cloud überschrieben werden.

Ein Sonderfall ist der UPN, welcher nur dann überschrieben wird, wenn es ein Wechsel von einer @<tenantname>.onmicrosoft.com-Adresse zu einer eigenen Domain betrifft. Der Wechsel von einer selbst definierte Domäne zu einer anderen Domäne ist standardmäßig nicht vorgenommen, da dies durchaus umfangreiche Auswirkungen hätte. Sie können aber ADSync so einstellen, dass er auch diese Änderung vornimmt.

Zuletzt sollten Sie wissen, dass nicht gefüllte Felder im lokalen AD auch nicht in die Cloud repliziert werden. Solche Felder werden in der Cloud also nicht gelöscht. ADSync löscht nur Inhalte, wenn das Feld vorher im lokalen AD einen Inhalt hatte und der dann entfernt wurde. Es kann also sein, dass das Objekt in der Cloud noch Inhalte hat, die das lokale AD-Objekt nicht hat. Sorgen Sie beim Provisioning daher dafür, dass möglichst alle Werte des früheren "Cloud Only"-Objekts auch im lokalen AD-Objekt gepflegt werden.

Neue Cloud"-Objekte

Die Existenz von "CloudOnly"-Objekten gilt es mit ADSync zu vermeiden. Nun ist es aber so, dass es einen Grund gegeben hat, in der Cloud Benutzer anzulegen ohne lokale AD-Konten einzurichten. Vielleicht hatten sie keinen ADSync oder Sie wussten es einfach noch nicht besser. Wann immer Sie aber mit ADSync arbeiten, sollten Sie alle Benutzer immer erst im lokalen AD anlegen und ADSync die Arbeit machen lassen. Allerdings ist noch etwas mehr zu tun, als nur ein AD-Konto anzulegen und dieses ggfls. in Gruppen aufzunehmen.

Objekt

Beschreibung

Basis-AD-Konto

Sie können natürlich erst einmal einen lokalen AD-Benutzer oder eine AD-Gruppe anlegen und diese in die Cloud replizieren lassen. Wenn Sie aber den HybridMode (Exchange oder Skye for Business) nutzen, sollten Sie diesem Objekte auf keinen Fall eine Lizenz zuweisen. Ansonsten vergibt die Cloud schon Einstellungen, die sie eigentlich zuerst im lokalen Active Directory vornehmen müssen.

Exchange

Um einen Empfänger direkt mit einem Postfach in der Cloud zu versehen, müssen Sie im Exchange Hybrid Mode das lokale AD-Konto mit "Enable-RemoteMailbox" unter Nutzung einer TargetAddress für Exchange aktivieren, z.B.

Enable-RemoteMailbox `
   -identity <us   -RemoteRoutingAddress "user@<tenant>.mail.onmicrosoft.com"

ADSync kann dann die Information in die Cloud übertragen und dann sollten Sie innerhalb von 30 Tagen auch eine Exchange Online Lizenz zuweisen. Denken Sie dran, dass Sie auch im Dez 2020 noch keine Exchange Online Eigenschaften verändern können, wenn ADSync das Objekt verwaltet.

Skype/Teams

Für Skype for Business gilt ein ähnliches Vorgehen im Hybrid-Mode. Auch hier müssen Sie in der lokalen Umgebung den Benutzer für "Skype for Business Online" aktivieren, damit das Objekte den lokalen SfB-Servern bekannt ist und Sie SIP-Pakete richtig routen.

Enable-CsUser `
   -Identity “username@domain.com” `
   -SipAddressType “EmailAddress" `
   -HostingProviderProxyFqdn “sipfed.online.lync.com” 

Dann hat das Objekt auch in der Cloud schon die SfB Eigenschaften. Sie müssen aber noch eine Lizenz zuweisen, damit der Anwender in der Cloud arbeiten kann. Nur wenn alle Anwender schon "Teams Only" sind und es keinen lokalen SfB-Server mehr gibt und die SIP-Adresse mit dem UPN übereinstimmt, können Sie auf die lokale Verwaltung verzichten.

In beiden Fällen müssen Sie natürlich in der Cloud dann noch Einstellungen vornehmen, für die es im lokalen Active Directory keine Konfiguration gibt, z.B. Teams Richtlinien, Dialpläne etc.

Damit sollten Sie dann auch "neue "Anwender direkt in der Cloud richtig anlegen und damit auf "Cloud Only"-Konten verzichten. Dann müssen Sie auch nicht mehr "matchen".

Weitere Links