Source of Authority für Benutzer zu Entra ID verschieben

• SOA definiert die Schreibhoheit über Benutzerobjekte. In hybriden Setups ist bei aktiviertem Sync standardmäßig AD DS autoritativ.
• Mit dem SOA-Transfer wird Entra ID zur führenden Quelle. Dadurch werden Cloud-Schreibvorgänge erlaubt und AD-Änderungen blockiert.
• Voraussetzungen, Rollback-Möglichkeiten und Auditfunktionen machen den Prozess steuerbar und die Verwaltung zukunftsfähig.

Euer Active Directory schreibt vor, wie Benutzer verwaltet werden – obwohl eure Prozesse längst in der Cloud leben? Dann steht ihr vor einem typischen Bruch: Ihr nutzt moderne Microsoft-365-Funktionen, müsst Identitäten aber weiter lokal pflegen. Genau hier setzt Microsoft mit einer neuen Funktion an: Dem Wechsel der Source of Authority (SOA) zu Microsoft Entra ID.

Die Source of Authority bezeichnet die Instanz, die autoritativ über Benutzerobjekte entscheidet. In hybriden Umgebungen ist das standardmäßig das lokale Active Directory. Änderungen dort werden in die Cloud gespiegelt; Änderungen in der Cloud sind für viele Attribute gesperrt. Über den gezielten Wechsel der SOA könnt ihr diese Steuerung benutzergenau umdrehen: Entra ID wird führend, AD DS verliert für diese Benutzer die Schreibrechte.

Warum Microsoft auf Cloud-SOA setzt

Microsoft verfolgt mit dem SOA-Wechsel eine strategische Vision: Identitäten sollen dort verwaltet werden, wo auch die Kontrolle, die Sicherheitsrichtlinien und die Anwendungen liegen – in der Cloud.

Die bisherigen hybriden Modelle mit Active Directory als Quelle funktionieren, stehen aber zunehmend im Widerspruch zu modernen Anforderungen:

• Cloud-Anwendungen benötigen flexible, cloudbasierte Identitätsprozesse
• Klassische AD-basierte Authentifizierungsmodelle behindern die Einführung passwortloser Verfahren
• Die zentrale Verwaltung von Identitäten durch IT-Abteilungen wird durch dezentrale Cloud-Szenarien (z. B. Self-Service, HR-getriebene Prozesse) abgelöst

Microsoft bietet mit dem Wechsel der Source of Authority nun einen klar definierten, reversiblen Weg, Benutzerobjekte aus der klassischen AD-Abhängigkeit zu lösen. Der Wechsel ist kein harter Bruch, sondern eine technisch kontrollierbare Umstellung pro Benutzerkonto. Damit wird ein wichtiger Baustein für Cloud-first-Strategien geschaffen.

Mit Cloud-SOA lassen sich unter anderem folgende Ziele realisieren:

• Identitäten über Entra ID provisionieren, pflegen und löschen
• Passwortlose Authentifizierung mit FIDO2 oder Windows Hello for Business umsetzen
• Conditional Access auch für on-premises Ressourcen durchsetzen
• Joiner-Mover-Leaver-Prozesse automatisieren
• Microsoft Identity Governance durchgängig einsetzen (z. B. PIM, Access Packages, Reviews)

Die Funktion ist aktuell in der Public Preview. Microsoft definiert klare Voraussetzungen, auditierbare Abläufe und einen jederzeit möglichen Rollback.

Welche Authentifizierungsszenarien sind unter Cloud-SOA unterstützt?

1) Passwortlose Authentifizierung (empfohlen)

Cloud-SOA funktioniert optimal mit Cloud Kerberos Trust und passwortlosen Methoden wie FIDO2, Passkeys oder Windows Hello for Business. Damit sind sogar on-premises Ressourcen erreichbar – per Kerberos-Ticket, ausgestellt durch Entra ID.

Technischer Hintergrund: Entra ID stellt in diesem Szenario ein Kerberos-Ticket im Namen des Benutzers aus. Voraussetzung ist, dass ein AD-Konto existiert, das mit dem Cloud-Konto verknüpft ist. Benutzer benötigen keinen Zugriff auf ein AD-Passwort, wodurch dieser Weg phishing-resistent und wartungsarm ist.

2) Cloud-only Authentifizierung

In reinen Cloud-Umgebungen ohne lokale Systeme ist Cloud-SOA uneingeschränkt einsetzbar. Benutzer können mit allen modernen Auth-Methoden arbeiten, inklusive klassischem Passwort (sofern nicht deaktiviert). Auch Self-Service- oder Lifecycle-getriebene Bereitstellungen lassen sich so einfacher realisieren.

3) Kennwortabhängige Pfade / ADFS

Nicht unterstützt! ADFS, Password Writeback oder direkte Abhängigkeiten vom lokalen AD-Kennwort funktionieren unter Cloud-SOA nicht. Solche Umgebungen müssen zuvor modernisiert werden. Microsoft betont: Passwortabhängige Anwendungen sind mit Cloud-SOA technisch inkompatibel.

Besonders kritisch sind:

• Federation über ADFS
• AD-basierte HR-Prozesse, die Benutzerobjekte im AD erzeugen oder ändern
• Ältere Applikationen mit zwingender LDAP/AD-Anbindung

Voraussetzungen für den Wechsel der Source of Authority

Bevor ihr Benutzerobjekte auf Cloud-SOA umstellt, müssen folgende Punkte erfüllt sein:

• Exchange Online: Postfächer müssen migriert, Autodiscover und Hybrid-Konfigurationen deaktiviert sein.
• Kein AD-basiertes Provisioning mehr: Benutzer müssen aus der Cloud provisioniert werden (z. B. über HR-Tools, SCIM oder Graph).
• Keine Abhängigkeit von ADFS oder anderen kennwortbasierten Pfaden.
• Cloud Kerberos Trust: Für Hybrid-Auth mit passwortloser Anmeldung (z. B. FIDO2) erforderlich.
• Microsoft Entra Connect >= 2.5.76.0 bzw. Cloud Sync >= 1.1.1370.0.
• Graph-Berechtigungen: User.OnPremisesSyncBehavior.ReadWrite.All muss autorisiert sein.

Der technische Ablauf im Detail: Konfiguration der Source of Authority

Microsoft beschreibt den Wechsel der Source of Authority in Artikeln, die sich teilweise überschneiden.

Grundlegend lässt sich sagen, dass alles über die Graph API gesteuert wird. Zentral ist dabei alles vom Attribut onPremisesSyncBehavior am Benutzerobjekt abhängig. Der darin enthaltene Wert isCloudManaged legt fest, welche Quelle autoritativ ist: Bei false führt weiterhin das lokale AD, bei true liegt die Führung bei Entra ID.

Schritt-für-Schritt-Anleitung

Ich möchte euch hier einmal kurz die Eckpunkte der Anleitung bei Microsoft Learn zusammenfassen.

1. Vorbereitung:

• Stellt sicher, dass alle Voraussetzungen erfüllt sind (Versionen, Rollen, Sync-Scope, Provisioning-Methode).
• Wählt eine oder mehrere Pilotbenutzer aus, idealerweise ohne kritische Abhängigkeiten.

‍2. Source of Authority umstellen:

Nutzt hierfür den Graph-Explorer oder sendet direkte HTTP-Calls.

Sendet folgenden PATCH-Request an Microsoft Graph (beta-Endpunkt):

PATCH https://graph.microsoft.com/beta/users/{user-id}/onPremisesSyncBehavior
Content-Type: application/json
{
 "isCloudManaged": true
}

Stellt sicher, dass ihr die entsprechende Berechtigung besitzt und diese genehmigt wurde.

User.OnPremisesSyncBehavior.ReadWrite.All

3. Validierung der Umstellung:

Überprüft per Graph GET, ob isCloudManaged: true gesetzt ist.

Wenn ihr jetzt am AD Benutzer in eurem AD etwas ändert, und einen Sync startet, werden diese Änderungen nicht mehr synchronisiert.

Das könnt ihr nachvollziehen, indem ihr im Event Log unter "Windows Logs" -> "Application" nach der Event ID 6956 sucht – das zeigt, dass der Export gestoppt wurde.

‍

Zusätzlich könnt ihr  im Sync Service Manager sehen, ob das Objekt im Entra-Connector mit blockOnPremisesSync = true versehen ist.

Details dazu findet ihr hier.

4. Audit-Log prüfen:

• Wechselt ins Entra Admin Center und ruft das Audit-Log auf.
• Filtert nach der Aktivität "Change Source of Authority from AD DS to cloud".
• Dokumentiert den Vorgang für Revisionszwecke.

5. Benutzerverwaltung testen:

• Prüft, ob die Bearbeitung des Benutzerobjekts in Entra ID nun vollständig möglich ist.
• Erstellt oder bearbeitet relevante Attribute (z. B. Telefonnummer, Display Name, Office Location).

6. (Optional) Rollback:

• Falls erforderlich, könnt ihr mit folgendem PATCH wieder zur AD-geführten SOA zurückkehren:

PATCH https://graph.microsoft.com/beta/users/{user-id}/onPremisesSyncBehavior
{
 "isCloudManaged": false
}

• Bestätigt den Vorgang über Eventlog und Audit-Log (Eintrag: "Undo Source of Authority change").

Diese Anleitung bildet den empfohlene Ablauf gemäß Microsoft-Dokumentation und bietet eine praxistaugliche Grundlage für kontrollierte Tests oder erste produktive Umstellungen.

Fazit

Mit dem Wechsel der Source of Authority wird Entra ID zur führenden Identitätsquelle. Microsoft ermöglicht damit erstmals einen kontrollierten Weg zur cloudzentrierten Benutzerverwaltung – inklusive Governance, Lifecycle, Passwortlosigkeit und Zugriffssicherheit.

Die Funktion ist aktuell in der Public Preview und eignet sich ideal für Pilotierung, Migration und langfristige Modernisierung. Wer Cloud-first wirklich leben möchte, sollte die SOA-Führung überdenken.

👉 Wenn ihr einen Pilot plant oder euer Identitätskonzept modernisieren wollt, unterstützen wir euch gerne!

Bucht euch doch direkt einen Workshop, oder meldet euch unverbindlich über unser Kontaktformular.