ADSync Softmatch Adminkonten

Diese Seite beschreibt eine Besonderheit von ADSync, wenn AD-Konten mit bereits bestehenden CloudOnly-Konten verknüpft werden sollen, die schon administrative Rollen in Office 365 besitzen.

Standardmäßig matched ADSync keine CloudOnly-Benutzer, die eine administrativ Rolle haben!

Ausgangssituation

Die meisten Office 365 Umgebungen beginnen mit einem Tenant, indem es einen Administrator gibt und eine Trial-Version von Office 365 oder Microsoft 365 genutzt wird. Sehr schnell werden dann weitere Benutzer in Office 365 angelegt, die für Demo- und Test-Fälle eingesetzt werden. Irgendwann möchten Sie dann aber die vorhandenen Benutzer im lokalen Active Directory mit ADSync in der Cloud verwalten und natürlich kennen Sie die folgenden Seite, wie ADSync bei dem ersten Abgleich eines lokalen AD-Objekts in der Cloud passende AzureAD-Objekte sucht. Auf mehreren Seiten habe ich beschrieben, wie ADSync ein passendes Objekt sucht:

Eine wichtige Rolle spielt dabei auch der SourceAnchor.

Nun ist es aber bei einem Kunden passiert, dass bei dem ersten Abgleich einer Pilotgruppe ein nicht vorhandenes Konto wie erwartet neu angelegt wurde aber zwei vorhandene Konten nicht "gematched" wurden. Natürlich haben wir geprüft, dass ein Matching per UPN aktiviert war:

PS C:\>Connect-MsolService
PS C:\>Get-MsolDirSyncFeatures -Feature EnableSoftMatchOnUpn

ExtensionData                                    DirSyncFeature       Enabled
-------------                                    --------------       -------
System.Runtime.Serialization.ExtensionDataObject EnableSoftMatchOnUpn    True

Wir haben dann zuerst einen neuen Test-Benutzer in der Cloud (AzureAD) mit einem eindeutigen UPN angelegt und darauf einen Benutzer im lokalen AD mit dem gleichen UPN. Beim nächsten Durchlauf von ADSync wurde aus dem CloudOnly-Benutzer ein "DirSync"-Benutzer.

Nach einigen Prüfungen haben wird als einzigen Unterschied bemerkt, dass die Problembenutzer im AzureAD zusätzlich eine administrative Rolle hatten. Wenn Sie in der Cloud schon Benutzer angelegt haben, die in der Cloud "Administrative Rolle" besitzen, dann wär es natürlich gefährlich, wenn ADSync ein lokales Konto mit seinem Kennwort (Password Hash Sync (PHS)) matchen.

Vielleicht war es die gute Vorbereitung bei früheren Projekten, dass ich noch nie in diese Situation gekommen bin. Normalerweise trenne ich Benutzer und Administratoren streng voneinander und in der Anfangszeit eines Office 365 Projekts oder eines Pilotbetriebs nutze ich getrennte CloudOnly-Konten für Benutzer und Administratoren. Aber hier war es dann noch mal anders und es hat genau die beiden ersten Konten erwischt, die schon in der Cloud waren und per ADSync abgeglichen werden sollten

Microsoft Dokumentation

Es ist aber keineswegs so, dass Microsoft das Verhalten nicht dokumentiert hätte:


Quelle: Überlegungen zu Administratorrollen https://docs.microsoft.com/de-de/azure/active-directory/hybrid/how-to-connect-install-existing-tenant#admin-role-considerations

Man möchte damit einfach verhindern, dass quasi "aus Versehen" ein AD-Benutzer unbeabsichtigt einen Cloud-Benutzer mit administrativen Berechtigungen bekommt.

Überprüfung

Dennoch habe die Situation erst einmal in meiner Testumgebung nachgestellt. Ich wollte wissen, was denn passiert, wenn es schon ein Adminkonto gibt und dann aus dem lokalen AD ein Konto mit dem gleichen UPN kommt. Folgende Schritte habe ich durchgeführt:

  1. Anlegen eines Cloud-Only Users
    UPN=matchtestadmin@msxfaq.de

    Lizenz: Keine Produktlizenz
    Adminrolle: GlobalAdmin
  2. Anlegen eines lokalen AD-Users
  3. ADSync laufen lassen
  4. Ergebnis kontrollieren

Sie können sehen, dass ADSync trotz Übereinstimmung beim UPN (und Mailadressen) das Konto nicht gematched hat und stattdessen ein zweites Konto angelegt hat. Normalerweise passiert das natürlich nicht, wenn Sie in der Cloud vor der Einrichtung von ADSync nur wenige Pilot/Test-Anwender haben und Administratoren auch noch separate Konten sind. Wenn es aber doch passiert ist, dann stellt sich die Frage der Heilung. Es gibt hier zwei Wege.

Heilung 1: Neu matchen

Das Problem tritt nur auf, wenn das AzureAD-Konto auch Admin ist. Es ist aber kein Problem dieses Recht temporär zu entfernen und das Soft-Match per UPN erneut zu starten. Allerdings muss dazu erst das alte Konto entfernt und ADSync überzeugt werden. Die Schritte sind aber einfach, da das zweite Konto ja eh keine Funktion hat.

  1. Sie schließen das lokale AD-Objekt aus der ADSync-Replikation aus
     Je nach ADSync-Konfiguration können Sie das Konto temporär in eine nicht betrachtete OU verschieben oder das Filter-LDAP-Feld oder die Mitgliedschaft in der Filtergruppe ändern. Das Objekt wird von ADSync dann als "gelöscht" angesehen, aus dem Metaverse entfernt und auch im AzureAD gelöscht..
  2. Löschen Sie das von ADSync nach "gelöschte Objekte" verschobene "Konto im AzureAD Portal komplett
    ADSync macht nur ein "Soft-Delete" und es landet im AzureAD Papierkorb. Es muss aber ganz weg, da ansonsten ADSync eventuell ein "undelete" versucht.
  3. Entfernen Sie das CloudOnly Konto temporär aus den Adminrollen
    Das ist die Vorbereitung für das nächste Matching.
  4. Stellen Sie das AD-Konto wieder so ein, dass es durch ADSync "gefunden" wird.
    ADSync wird das aus seiner Sicht "neue" AD-Konto wieder einlesen und beim Schreiben ins AzureAD nach dem bestehenden Konto suchen. Diesmal ist das Ziel kein Admin mehr un der Match gelingt.
  5. Weisen Sie dem Konto die vorher entfernten Admin-Rollen zu
    Nun können Sie die Adminrollen wieder zuweisen. Wobei ich normalen Anwendern ungern auch Adminrollen zuweise oder nur in Verbindung mit PIM

Dies ist aber nur ein Weg die Inkonsistenz zu lösen.

Heilung 2: Hardmatch über ImmutableID

Eine zweite Option besteht in der Vorgabe der Zuordnung über "Hard matching". Dieses Verfahren kommt eigentlich nur zum Einsatz, wenn eine ADSync-Installation verloren geht und ein neuer Server mit ADSync installiert wird. Damit hier eine saubere und sichere 1:1-Zuordnung erfolgt, speichert ADSync beim Objekt einen SourceAnchor ab. In der Regel ist das die BASE64-codierte ObjectGUID des AD-Objekts. Diese Feld kann aber auch manuell im AzureAD vorbelegt werden.

  1. Pausieren Sie ADSync
    Wir möchten ja nicht, dass während der nächsten Aktionen ein ADSync-Lauf dazwischenfunkt. Sie könnten den Dienst beenden oderpausieren, den Scheduler per PowerShell beenden oder das ADSync-Setup starten, welche nach dem ersten "Weiter" auch den Scheduler anhängt. Hier die Powershell-Version:
  2. Exportieren Sie den SourceAnchor des lokalen AD-Objekts. Wenn ADSync schon ein zweites Objekt angelegt hat, dann nutzen sie einfach die AzureAD-PowerShell mit einem "Get-AzureADUser"

    Die ImmutableID brauchen wir gleich. Es gibt noch weitere Wege, Siehe SourceAnchor und SourceAnchor User
  3. Löschen sie diese Konto permanent
    Das geht am einfachsten im AzureAD-Portal auf https://portal.azure.com und löschen Sie das Objekt auch aus "Deleted users".
  4. Setzen Sie die gesicherte ImmutableID an das richtige Konto
    Das vorhandene "Admin-Konto" ist ja ein "CloudOnly"-Konto. Hier können Sie die ImmutableID einfach anheften mit:

    Sollten Sie den Fehler "Message: Another object with the same value for property immutableId already exists." bekommen, dann ist das vorherige Objekt noch nicht gelöscht.
  5. ADSync wieder laufen lassen.
    Den am Anfang angehaltenen Scheduler reaktivieren wir und starten Delta-Replikation

    Der SourceAnchor sollte nun dafür sorgen, dass ADSync das AD-Objekte auf das neue bestehende Objekt anbindet, die Felder aktualisiert und ein "DirSync"-Objekt raus macht.

Auch dieser Weg führt letztlich zu einer Lösung.

Einschätzung

Bis ich das erste mal mit dem Problem konfrontiert wurde, habe ich nichts über das besondere Verhalten des ADSync beim Matching in Verbindung mit AzureAD-Konten und Administrativen Berechtigungen gewusst. Es war daher schon überraschend, aber beschreibt auch einen eher seltenen Fall. Zumindest wenn Sie sich an die Grundregel halten, dass Benutzerkonten für Benutzer sind und Adminkonten für Administratoren, die zumindest am Anfang als "CloudOnly"-Konten angelegt werden und vielleicht eher nicht über ein Matching nachträglich mit einem lokalen AD-Konto verbunden werden.

Aus meiner Sicht macht es sogar Sinn, Admin-Konten beim Matching auszunehmen, um die Funktion der CloudOnly-Konten nicht zu gefährden. Mit Password Hash Sync (PHS) würde hier auch da Kennwort des bisherigen "Cloud Only"-Admins überschrieben, was unterwünscht sein könnte. Zumindest könnte der betroffene Admin sich vielleicht nicht mehr anmelden. In Forests mit mehreren Domains könnte es auch ein anderes Konto mit dem gleichen UPN geben und damit jemand unberechtigter Weise zu Admin-Rechten kommen.
Das sind alles zwar unwahrscheinliche Szenarien aber eben auch nicht ausgeschlossen.

Wir nehmen für die nächsten ADSync-Installationen mit, dass CloudOnly-Konten mit administrativen Berechtigungen in der Cloud durch ADSync nicht mit lokalen AD-Konten verknüpft werden.

Weitere Links