Azure AD / Entra ID – Grundlagen

Was ist Microsoft Entra ID?

Microsoft Entra ID – bis Juli 2023 unter dem Namen Azure Active Directory (Azure AD) bekannt – ist Microsofts cloudbasierter Identitaets- und Zugriffsverwaltungsdienst. Einfach gesagt: Es ist das Verzeichnis, das weiss, wer du bist, und entscheidet, worauf du zugreifen darfst.

Wenn du dich bei Outlook, Teams oder SharePoint anmeldest, laeuft die Authentifizierung im Hintergrund immer ueber Entra ID. Kein Entra ID, kein M365.

Entra ID ist nicht dasselbe wie das klassische On-Premise Active Directory (AD DS), das du vielleicht aus deiner Serverumgebung kennst. Die beiden koennen aber zusammenarbeiten – mehr dazu im Abschnitt Hybrid-Szenarien.

On-Premise AD vs. Entra ID – der Vergleich

Das ist die Frage, die am haeufigsten fuer Verwirrung sorgt. Hier die Unterschiede auf einen Blick:

Kurze Faustregel:

• Hast du nur M365 und keine eigenen Server? Dann lebst du rein in Entra ID (Cloud-only).
• Hast du einen Windows Server mit Active Directory? Dann kannst du beides verbinden: Hybrid.
• Grosse Unternehmen haben oft Hybrid, KMU wechseln zunehmend zu Cloud-only.

Die Entra ID Lizenz-Stufen

Entra ID gibt es in drei Stufen – je nach M365-Abo ist eine davon bereits enthalten:

Wichtige Konzepte im Alltag

Benutzer und Gruppen

Benutzer in Entra ID entsprechen den User-Accounts, die du aus dem On-Premise AD kennst. Gruppen funktionieren gleich – mit einem Unterschied: Es gibt dynamische Gruppen, die sich automatisch befuellen, basierend auf User-Attributen (z.B. alle User mit department = Buchhaltung).

Im Entra Admin Center: entra.microsoft.com → Identitaet → Benutzer

Per PowerShell (Microsoft Graph Modul):

# Modul installieren (einmalig)
Install-Module Microsoft.Graph -Scope CurrentUser

# Anmelden
Connect-MgGraph -Scopes "User.Read.All", "Group.Read.All"

# Alle Benutzer auflisten
Get-MgUser -All | Select DisplayName, UserPrincipalName, AccountEnabled

# Gesperrte Accounts finden
Get-MgUser -Filter "accountEnabled eq false" | Select DisplayName, UserPrincipalName

# Einen User deaktivieren
Update-MgUser -UserId "max.muster@firma.ch" -AccountEnabled:$false

# Benutzer einer Gruppe hinzufuegen
$user = Get-MgUser -UserId "max.muster@firma.ch"
$group = Get-MgGroup -Filter "displayName eq 'IT-Team'"
New-MgGroupMember -GroupId $group.Id -DirectoryObjectId $user.Id

Entra ID Rollen

Rollen steuern, wer was im Admin Center darf. Das Prinzip “Least Privilege” gilt hier besonders – niemand sollte Globaler Administrator sein, der es nicht wirklich braucht.

# Aktuelle Rollenzuweisungen anzeigen
Connect-MgGraph -Scopes "RoleManagement.Read.Directory"
Get-MgRoleManagementDirectoryRoleAssignment -All |
  Select PrincipalId, RoleDefinitionId |
  ForEach-Object {
    $user = Get-MgUser -UserId $_.PrincipalId -ErrorAction SilentlyContinue
    $role = Get-MgRoleManagementDirectoryRoleDefinition -UnifiedRoleDefinitionId $_.RoleDefinitionId
    [PSCustomObject]@{ User = $user.DisplayName; Role = $role.DisplayName }
  }

App-Registrierungen und Enterprise Apps – SSO fuer SaaS

Sobald du nicht nur M365 selbst, sondern auch andere Cloud-Dienste (Salesforce, ein HR-Tool, eine Zeiterfassung, ein Kundenportal) an Entra ID anbinden willst, kommst du an zwei Objekttypen nicht vorbei: App-Registrierungen und Enterprise Apps. Die beiden werden staendig verwechselt, obwohl sie zwei Seiten derselben Medaille sind.

Technisch gesehen ist eine Enterprise App der Service Principal einer App-Registrierung in deinem Tenant. Jede App-Registrierung erzeugt automatisch einen Service Principal im eigenen Tenant; bei Multi-Tenant-Apps (z.B. fertige SaaS-Loesungen anderer Hersteller) entsteht der Service Principal erst, wenn du die App aus dem Katalog hinzufuegst oder ein User/Admin sie erstmalig freigibt.

Faustregel fuer die Praxis:

• Willst du eine eigene App (z.B. eine intern entwickelte Web-App) anbinden? Start bei den App-Registrierungen.
• Willst du ein fertiges SaaS-Produkt per SSO anbinden (Salesforce, Zoom, Jira, ein HR-Tool)? Start bei den Unternehmensanwendungen, entweder aus dem App-Katalog oder als “Nicht-Katalog-Anwendung”.

SAML vs. OIDC – welches Protokoll fuer welchen Fall

Praxis-Szenario: Ein SaaS-Tool per SAML anbinden

1. Entra Admin Center → Identitaet → Anwendungen → Unternehmensanwendungen → + Neue Anwendung
2. App im Katalog suchen (viele grosse Anbieter sind vorkonfiguriert) oder “Eigene Anwendung erstellen” fuer Nicht-Katalog-Apps waehlen
3. Unter Single Sign-On die Methode SAML waehlen
4. Basis-SAML-Konfiguration eintragen: Identifier (Entity-ID) und Reply-URL (ACS-URL) – diese Werte liefert der Anbieter des SaaS-Tools
5. Attribute & Claims pruefen/anpassen (z.B. emailaddress, name, ggf. eigene Rollen-Claims)
6. Signaturzertifikat herunterladen und beim SaaS-Anbieter hochladen
7. Unter Benutzer und Gruppen die berechtigten User/Gruppen zuweisen – ohne Zuweisung kann sich niemand anmelden, wenn “Zuweisung erforderlich” aktiv ist

# Service Principals (Enterprise Apps) auflisten – Microsoft Graph
Connect-MgGraph -Scopes "Application.Read.All"
Get-MgServicePrincipal -All |
  Select DisplayName, AppId, SignInAudience |
  Sort-Object DisplayName

# App-Registrierungen mit bald ablaufenden Secrets/Zertifikaten finden
Get-MgApplication -All | ForEach-Object {
  $app = $_
  ($app.PasswordCredentials + $app.KeyCredentials) | ForEach-Object {
    if ($_.EndDateTime -lt (Get-Date).AddDays(30)) {
      [PSCustomObject]@{ App = $app.DisplayName; Ablauf = $_.EndDateTime }
    }
  }
}

Hybrid-Szenarien

Viele KMU haben noch einen lokalen Windows Server mit Active Directory. Entra ID kann damit verbunden werden – das nennt sich Hybrid Identity.

Azure AD Connect / Entra Connect

Das Kernstueck jeder Hybrid-Umgebung ist Microsoft Entra Connect (frueherer Name: Azure AD Connect). Es ist ein Dienst, der auf einem Windows Server laeuft und User, Gruppen und Passwoerter von On-Premise AD nach Entra ID synchronisiert.

So laeuft die Synchronisation:

1. User wird in On-Premise AD angelegt
2. Entra Connect synchronisiert ihn alle 30 Minuten nach Entra ID
3. Der User kann sich jetzt mit demselben Account bei M365 anmelden
4. Single Sign-On: Login am Windows-PC reicht, kein zweites Passwort noetig

Synchronisations-Methoden im Vergleich:

Sync-Status pruefen:

# Auf dem Entra Connect Server
Import-Module ADSync
Get-ADSyncScheduler          # Zeigt Sync-Intervall und letzten Lauf
Start-ADSyncSyncCycle -PolicyType Delta   # Manuelle Delta-Synchronisation starten
Start-ADSyncSyncCycle -PolicyType Initial # Vollstaendige Synchronisation (selten noetig)

Geraete-Szenarien

Conditional Access – das Herzstueck der Sicherheit

Conditional Access (Bedingter Zugriff) ist das wichtigste Sicherheitsfeature von Entra ID P1. Die Grundidee: Zugriff wird nicht pauschal erlaubt, sondern nur unter bestimmten Bedingungen.

Die Logik ist simpel: WENN [Bedingung] → DANN [Steuerung]

Typische Bedingungen (WENN):

• User gehoert zu Gruppe X
• Zugriff von einem unbekannten Geraet (nicht compliant)
• Anmeldung aus einem riskanten Land (z.B. Nigeria, Russland)
• Anmeldung ausserhalb der Geschaeftszeiten
• Zugriff auf eine bestimmte App (z.B. Azure Portal)

Moegliche Steuerungen (DANN):

• MFA verlangen
• Zugriff blockieren
• Nur von compliant-Geraeten erlauben
• Passwort-Aenderung erzwingen

Typische Conditional Access Policies fuer ein KMU:

Policy 1: MFA fuer alle externen Zugriffe
  WENN:  Anmeldung von ausserhalb des Firmennetzwerks
  DANN:  MFA verlangen

Policy 2: Adminzugriff immer MFA
  WENN:  User hat eine Admin-Rolle
  DANN:  MFA verlangen (egal wo)

Policy 3: Blockierung aus Hochrisiko-Laendern
  WENN:  Anmeldung aus Land-Liste (z.B. alle ausser CH/DE/AT)
  DANN:  Zugriff blockieren

Policy 4: Nur compliant-Geraete fuer Exchange
  WENN:  Zugriff auf Exchange Online
  DANN:  Entra ID Joined oder Compliant Device verlangen

Konfiguriert im Entra Admin Center unter: Schutz → Bedingter Zugriff → Richtlinien → + Neue Richtlinie

Named Locations – Standorte als Bedingung

Named Locations (benannte Standorte) sind ein eigener Baustein unter Schutz → Named Locations, den du danach in Conditional-Access-Policies als Bedingung verwendest. Du definierst dort feste IP-Bereiche oder Laender/Regionen und gibst ihnen einen Namen – z.B. “Buero Zuerich” oder “Vertrauenswuerdige Laender”.

Markierst du eine Named Location als vertrauenswuerdig (Trusted), kannst du sie in Policies gezielt ausschliessen (“MFA ausser von vertrauenswuerdigen Standorten”) oder als Positivliste nutzen (“Zugriff nur aus diesen Laendern erlauben”).

# Named Locations auflisten
Connect-MgGraph -Scopes "Policy.Read.All"
Get-MgIdentityConditionalAccessNamedLocation | Select DisplayName, "@odata.type"

Authentication Strength – nicht jede MFA ist gleich stark

Klassische Conditional-Access-Policies kannten frueher nur die grobe Steuerung “MFA verlangen”. Mit Authentication Strength kannst du praezise festlegen, welche MFA-Methoden fuer eine bestimmte Policy akzeptiert werden – das ist besonders fuer Admin-Rollen und sensible Anwendungen wichtig.

Du kannst zusaetzlich eigene, benutzerdefinierte Authentication-Strength-Kombinationen erstellen, falls die drei eingebauten Stufen nicht passen.

Beispiel-Policy: Phishing-resistente MFA fuer Admin-Rollen
  WENN:  User hat eine privilegierte Rolle (Globaler Admin, Sicherheitsadmin, ...)
  DANN:  Authentifizierungsstaerke "Phishing-resistente MFA" verlangen

Beispiel-Policy: Named Location + Authentication Strength kombiniert
  WENN:  Zugriff von ausserhalb "Vertrauenswuerdige Standorte" (Named Location)
  DANN:  Authentifizierungsstaerke "Passwortlose MFA" verlangen

Konfiguriert wird das im selben Conditional-Access-Assistenten unter Grant → Zugriff gewaehren → Authentifizierungsstaerke erfordern, als Alternative zur einfachen Option “Multi-Faktor-Authentifizierung erfordern”.

Multi-Faktor-Authentifizierung (MFA)

MFA ist die effektivste Einzelmassnahme gegen Account-Kompromittierung. Gestohlene Passwoerter nuetzen einem Angreifer nichts, wenn er keinen Zugriff auf den zweiten Faktor hat.

MFA-Methoden in Entra ID (von sicher zu weniger sicher):

Per-User MFA vs. Conditional Access MFA:

• Per-User MFA: Alte Methode, MFA wird pauschal fuer einzelne User aktiviert. Unflexibel, nicht empfohlen.
• Security Defaults: Kostenlos, MFA fuer alle – aber keine Ausnahmen moeglich. Gut fuer sehr kleine Teams ohne P1.
• Conditional Access: Empfohlen ab P1. Flexibel, steuerbar, kombinierbar mit anderen Bedingungen.

Cross-Tenant Access Settings – Zusammenarbeit zwischen Tenants

Sobald Externe (Partnerfirmen, Kunden, ein anderer Tenant nach einer Firmenuebernahme) auf Ressourcen in deinem Tenant zugreifen sollen oder deine User mit einem fremden Tenant zusammenarbeiten (z.B. geteilte Teams-Kanaele), greifen nicht die normalen Conditional-Access-Policies allein, sondern zusaetzlich die Cross-Tenant Access Settings unter Entra Admin Center → Identitaet → Externe Identitaeten → Cross-Tenant-Zugriffseinstellungen.

Diese Einstellungen sind zweigeteilt:

Beide Richtungen lassen sich als Standardeinstellung fuer alle unbekannten Tenants konfigurieren und zusaetzlich pro Partner-Tenant ueberschreiben (“Organisationseinstellungen”). Standardmaessig ist B2B-Zusammenarbeit (Gasteinladungen) erlaubt, waehrend B2B Direct Connect (z.B. fuer geteilte Teams-Kanaele ohne klassische Gasteinladung) standardmaessig blockiert ist und pro Partner explizit freigeschaltet werden muss.

Trust Settings sind ein oft uebersehener Teil davon: Du kannst festlegen, dass deine Conditional-Access-Policies MFA-, Compliant-Device- und Hybrid-Join-Nachweise aus dem Heimat-Tenant des Gastes akzeptieren. Ohne diese Vertrauenseinstellung muss sich ein Gast-User bei jedem Zugriff erneut per MFA in deinem Tenant verifizieren, obwohl er sich zuhause bereits per MFA angemeldet hat.

# Cross-Tenant Access Policy (Standardeinstellungen) auslesen
Connect-MgGraph -Scopes "Policy.Read.All"
Get-MgPolicyCrossTenantAccessPolicyDefault | Select -ExpandProperty B2bCollaborationInbound
Get-MgPolicyCrossTenantAccessPolicyDefault | Select -ExpandProperty InboundTrust

Identity Protection – risikobasierter Conditional Access

Identity Protection (Teil von Entra ID P2) bewertet jede Anmeldung und jeden Benutzer fortlaufend anhand von Risikosignalen – z.B. geleakte Zugangsdaten im Darknet, Anmeldung von einer als boesartig bekannten IP, unmoegliche Reisegeschwindigkeit zwischen zwei Anmeldungen oder ungewoehnliches Verhalten. Daraus berechnet Entra ID zwei Risikoarten:

Diese Risikostufen (niedrig, mittel, hoch) bindest du direkt als Bedingung in eine Conditional-Access-Policy ein – die frueher separate Identity-Protection-Risikorichtlinien wandern zunehmend in ganz normale CA-Policies mit der Bedingung “Anmelderisiko” bzw. “Benutzerrisiko”. Typisch:

Policy: Risikobasierte MFA
  WENN:  Anmelderisiko = Mittel oder Hoch
  DANN:  MFA verlangen

Policy: Risikobasierter Passwort-Reset
  WENN:  Benutzerrisiko = Hoch
  DANN:  Sicheren Passwort-Wechsel erzwingen

Self-Service Password Reset (SSPR)

SSPR erlaubt es Usern, ihr eigenes Passwort zurueckzusetzen – ohne beim IT-Helpdesk anzurufen. Spart enorm viel Zeit.

Einrichten: Entra Admin Center → Schutz → Passwortzuruecksetzung

Konfigurationspunkte:

• Wer darf SSPR nutzen? (alle User oder bestimmte Gruppen)
• Wie viele Methoden zur Verifikation? (empfohlen: 2)
• Erlaubte Methoden: Authenticator App, E-Mail, Mobilnummer, Sicherheitsfragen

# SSPR-Status fuer alle User pruefen
Connect-MgGraph -Scopes "UserAuthenticationMethod.Read.All"
Get-MgUser -All | ForEach-Object {
  $methods = Get-MgUserAuthenticationMethod -UserId $_.Id
  [PSCustomObject]@{
    User    = $_.DisplayName
    UPN     = $_.UserPrincipalName
    Methods = ($methods.AdditionalProperties.Values | Where-Object { $_ -is [string] }) -join ", "
  }
} | Export-Csv C:\mfa-status.csv -NoTypeInformation

Troubleshooting – haeufige Probleme

User kann sich nicht anmelden

Checkliste:

1. Account gesperrt? → Entra Admin Center → Benutzer → Anmeldungen pruefen
2. Conditional Access blockiert? → Entra → Ueberwachung → Anmeldungen → Filter auf “Fehler”
3. MFA nicht eingerichtet? → User muss unter aka.ms/mfasetup MFA konfigurieren
4. Lizenz fehlt? → Benutzer → Lizenzen pruefen
5. Account deaktiviert? → Kontostatus pruefen

# Anmeldefehler eines Users der letzten 24h anzeigen (Graph)
Connect-MgGraph -Scopes "AuditLog.Read.All"
$since = (Get-Date).AddHours(-24).ToString("yyyy-MM-ddTHH:mm:ssZ")
Get-MgAuditLogSignIn -Filter "userPrincipalName eq 'max.muster@firma.ch' and createdDateTime ge $since and status/errorCode ne 0" |
  Select CreatedDateTime, AppDisplayName, IpAddress, @{N="Error";E={$_.Status.FailureReason}}

Entra Connect Sync-Fehler

# Auf dem Entra Connect Server: Sync-Fehler anzeigen
Get-ADSyncConnectorRunStatus
Get-EventLog -LogName Application -Source "ADSync" -EntryType Error -Newest 20

Haeufige Ursachen:

• Duplicate Attribute: Zwei User haben dieselbe proxyAddresses oder userPrincipalName im On-Premise AD
• Export Errors: Entra ID lehnt ein Objekt ab (oft fehlende Pflichtattribute)
• Connectivity: Der Entra Connect Server hat keinen Internetzugang auf die Entra ID Endpunkte

MFA funktioniert nicht

• Authenticator App sendet keinen Push: App oeffnen und Code manuell eingeben. Danach App und Konto neu konfigurieren.
• User hat neues Handy: Altes Geraet entfernen und MFA neu registrieren unter Entra → Benutzer → [User] → Authentifizierungsmethoden
• Passwort vergessen + MFA-Geraet weg: Admin kann unter Benutzer → Authentifizierungsmethoden alle MFA-Methoden zuruecksetzen, dann SSPR oder manuelles Reset

Weiterlernen

• Was ist Microsoft Entra ID? – Microsoft Learn
• Conditional Access Dokumentation – Microsoft Learn
• Microsoft Entra Connect (Sync) – Ueberblick
• MFA fuer alle User einrichten – Microsoft Learn
• Security Defaults aktivieren – Microsoft Learn
• Microsoft Graph PowerShell SDK – Einstieg
• SAML vs. OIDC – Entscheidungshilfe – Microsoft Learn
• Authentication Strengths im Ueberblick – Microsoft Learn
• Cross-Tenant Access Settings fuer B2B-Zusammenarbeit – Microsoft Learn
• Was ist Microsoft Entra ID Protection? – Microsoft Learn

Verwandte Seiten: Active Directory Grundlagen · AD Benutzer und Gruppen · Intune Grundlagen · M365 Benutzer und Lizenzen · IT-Security Grundlagen KMU · IT Onboarding & Offboarding · Entra PIM und Identity Governance · Entra Connect Sync – Tiefgang

Videos

YouTube

YouTube