Entra ID und Active Directory: Was der Unterschied für deine Administration bedeutet

Die wichtigste Konsequenz steckt in der letzten Zeile. Im Active Directory war ein Domänenadministrator eine dauerhafte Eigenschaft eines Kontos, in Entra ID sollte eine hohe Rolle ein Zustand auf Zeit sein. Ebenso wichtig ist die Unterscheidung zwischen Entra-Verzeichnisrollen und Azure-Rollen: Erstere steuern das Verzeichnis, also Benutzer, Gruppen und Anwendungen, Letztere steuern Ressourcen in Abonnements, also virtuelle Maschinen, Netze und Speicher. Beide sind unabhängig voneinander, und wer sie verwechselt, vergibt entweder zu viel oder wundert sich über fehlende Rechte. Wie die entsprechende Trennung bei AWS aussieht, steht in AWS IAM: Berechtigungen sauber schneiden.

Install-Module Microsoft.Graph -Scope CurrentUser
Connect-MgGraph -Scopes "Directory.Read.All","RoleManagement.Read.Directory","AuditLog.Read.All"

# Wie viele aktive Konten, wie viele Gäste?
(Get-MgUser -All -Filter "accountEnabled eq true").Count
(Get-MgUser -All -Filter "userType eq 'Guest'").Count

# Welche Verzeichnisrollen sind überhaupt aktiviert, und wer steckt drin?
Get-MgDirectoryRole | Select-Object DisplayName, Id

$rolle = Get-MgDirectoryRole -Filter "displayName eq 'Global Administrator'"
Get-MgDirectoryRoleMember -DirectoryRoleId $rolle.Id |
  ForEach-Object { (Get-MgUser -UserId $_.Id).UserPrincipalName }

Die Zahl der globalen Administratoren ist der erste Befund jeder Bestandsaufnahme. Microsoft empfiehlt, dauerhaft weniger als fünf Konten mit dieser Rolle zu führen. Alles darüber ist ein Auftrag, kein Zwischenstand.

az login

# Verzeichnisseite: Konten und Anwendungen
az ad user list --filter "accountEnabled eq true" --query 'length(@)'
az ad app list --all --query 'length(@)'
az ad sp list --all --query "length([?servicePrincipalType=='Application'])"

# Ressourcenseite: Azure-Rollen, ausdrücklich inklusive geerbter Zuweisungen
az role assignment list --all --include-inherited \
  --query "[?roleDefinitionName=='Owner'].{prinzipal:principalName,bereich:scope}" -o table

Die beiden Abfragen liefern absichtlich unterschiedliche Welten. Oben stehen Verzeichnisobjekte, unten Rechte auf Ressourcen. Ein Konto kann in Entra ID unauffällig sein und trotzdem Besitzer eines ganzen Abonnements sein, deshalb gehören beide Listen in jede Prüfung.

Import-Module ADSync

# Läuft der Zeitplan, und wann war der letzte Durchlauf?
Get-ADSyncScheduler

# Welche Verbindungen sind eingerichtet, lokal und in die Cloud?
Get-ADSyncConnector | Select-Object Name, Type

# Änderungen sofort übertragen statt auf den Zyklus zu warten
Start-ADSyncSyncCycle -PolicyType Delta

# Vollständiger Abgleich, nur nach Regeländerungen und außerhalb der Kernzeit
# Start-ADSyncSyncCycle -PolicyType Initial

Der Standardzyklus liegt bei 30 Minuten. Wer beim Anlegen neuer Konten ungeduldig wird, sollte den Zyklus nicht verkürzen, sondern die Bereitstellung so gestalten, dass die Wartezeit eingeplant ist. Ein vollständiger Abgleich in der Kernzeit erzeugt spürbare Last und sollte die Ausnahme bleiben.

Unabhängig vom Werkzeug gilt: Synchronisiere nur, was in der Cloud gebraucht wird. Deaktivierte Konten, Dienstkonten ohne Cloud-Bezug und historische Organisationseinheiten haben im Mandanten nichts verloren, weil sie später jede Zugriffsüberprüfung aufblähen und in Berichten für Verwirrung sorgen. Klär außerdem früh, welches Verzeichnis führend ist. Ein Zustand, in dem Konten mal lokal und mal in der Cloud angelegt werden, erzeugt Dubletten, die sich nur mit Aufwand wieder zusammenführen lassen. Wie die Netzanbindung dazu aussieht, wenn beide Welten dauerhaft nebeneinander laufen, beschreibt die Anbindung des eigenen Rechenzentrums.

Connect-MgGraph -Scopes "Policy.Read.All"

Get-MgIdentityConditionalAccessPolicy |
  Select-Object DisplayName, State, Id |
  Sort-Object State, DisplayName

# Welche Konten sind aus einer Regel ausgenommen?
$p = Get-MgIdentityConditionalAccessPolicy -Filter "displayName eq 'MFA fuer alle'"
$p.Conditions.Users.ExcludeUsers

Der Wert im Feld State ist der wichtigste: enabledForReportingButNotEnforced bedeutet Nur-Bericht-Modus, die Regel wird ausgewertet und protokolliert, greift aber nicht. Jede neue Regel gehört mindestens eine Woche in diesen Modus, bevor sie auf enabled gestellt wird.

Connect-MgGraph -Scopes "RoleManagement.Read.Directory"

# Dauerhaft aktive Zuweisungen: das ist die kritische Liste
Get-MgRoleManagementDirectoryRoleAssignment -All |
  Select-Object PrincipalId, RoleDefinitionId, DirectoryScopeId

# Über PIM berechtigte Zuweisungen: Rolle vorhanden, aber nicht aktiv
Get-MgRoleManagementDirectoryRoleEligibilitySchedule -All |
  Select-Object PrincipalId, RoleDefinitionId, Status

Das Ziel ist eine kurze erste Liste und eine längere zweite. Wenn beide Listen fast gleich lang sind, ist Privileged Identity Management zwar eingerichtet, wird aber nicht genutzt, und der Nachweis gegenüber einer Prüfung trägt nicht.

Für die Personalplanung ist die passende Zertifizierung SC-300, Microsoft Certified: Identity and Access Administrator Associate. Sie deckt genau die Themen dieser Seite ab, also Verzeichnis, hybride Identität, bedingter Zugriff, Rollen auf Zeit und Zugriffsüberprüfungen. Wer eher aus der Administration kommt und zunächst die Breite braucht, fängt mit AZ-104 an, denn dort sind Identität und Governance ein eigener Abschnitt. Die Vorbereitung darauf beschreibt die Seite zur AZ-104-Prüfung. Rollenbasierte Microsoft-Zertifizierungen lassen sich jährlich kostenlos online verlängern, der Aufwand für die Aufrechterhaltung ist also überschaubar.