Microsoft Entra ID: Tenant, Tokens und Hybrididentität

Microsoft Entra ID ist ein Cloudverzeichnis, Identity Provider und Policy Enforcement Point für Microsoft- und Drittanwendungen. Es speichert Benutzer, Gruppen, Geräte, Anwendungen, Service Principals und Rollen; sein Security Token Service stellt nach erfolgreicher Authentisierung und Policyprüfung signierte Tokens aus. Microsoft Graph bildet die Verwaltungs-Control-Plane. Diese Rollen müssen getrennt betrachtet werden: Ein vorhandenes Benutzerobjekt garantiert keine erfolgreiche Anmeldung, ein gültiges Token keine fachliche Objektberechtigung und ein synchronisiertes Attribut keine sofortige Wirkung in jedem Zielservice.

Für Messaging-Admins liegt Entra an mehreren kritischen Pfaden: Benutzer und proxyAddresses speisen Exchange Online, Gruppen steuern Verteiler und Zugriff, Appberechtigungen erlauben automatisierten Postfach- oder Graphzugriff, Conditional Access beeinflusst Admin- und Clientanmeldungen, und Hybrid-Synchronisation verbindet Active Directory Domain Services mit der Cloud. Der Tenant ist damit nicht einfach «AD im Internet», sondern eine eigenständige Identitäts- und Autorisierungsplattform.

Die Erklärung folgt einer Identität von der Anmeldung bis zum Zugriff auf eine konkrete Ressource. Zuerst werden Tenant, Verzeichnis und Token erklärt, danach Rollen, Anwendungen, Geräte, Hybridanbindung, Protokolle und Recovery.

Microsoft Entra ID verbindet ein Verzeichnis mit Tokenausstellung und Richtlinienprüfung. Ein Benutzer greift nicht «auf Entra» zu, sondern fordert für eine konkrete Ressource ein Token an; Entra prüft dabei Identität, Anwendung, Gerät und Policy.

Architektur: Directory, STS, Policy und Resource

Microsoft beschreibt Entra ID als cloudbasierten Identity- und Access-Managementdienst. Seine Hauptflächen sind:

1. Directory: Objekte, Attribute, Beziehungen, Rollen, Domains und tenantlokale Konfiguration.
2. Security Token Service (STS): Protokollendpunkte, Authentisierung, Tokenausstellung und Schlüsselveröffentlichung.
3. Policy Engines: Conditional Access, Identity Protection, Authentication Methods, Consent und weitere Zugriffsentscheidungen.
4. Provisioning/Sync: Replikation oder Bereitstellung zu und von AD DS, SaaS und HR-Quellen.
5. Microsoft Graph: API für Verzeichnis-, Identitäts-, Audit- und Policyverwaltung.
6. Resource Services: Exchange Online, Graph, eigene APIs und SaaS validieren Tokens und erzwingen ihre Autorisierung.

Entra ist mandantenfähig. Ein Tenant bildet eine administrative und Policygrenze, nicht automatisch eine vollständige Daten- oder Netzwerkisolation aller konsumierten SaaS-Services (Microsoft Entra fundamentals – What is Microsoft Entra ID?).

Technologiestack aus Adminsicht

Bei einem mandantenfähigen SaaS-Dienst ist der interne Programmiersprachen-, Datenbank- und Orchestrierungsstack keine vom Kunden kontrollierbare Produkteigenschaft. Ihn aus Hostnamen, Clientbibliotheken oder Stellenanzeigen abzuleiten, wäre für Betrieb und Recovery wertlos. Der belegbare Technologiestack aus Adminsicht besteht aus den veröffentlichten Verträgen: HTTPS als Transport, OAuth 2.0, OpenID Connect, SAML und WS-Federation für Identität, JWT/JWS und JWKS für Tokens und Schlüssel, Microsoft Graph als REST-/OData-Control-Plane sowie agentenbasierte Synchronisation für Hybrididentitäten. Microsoft dokumentiert diese Protokolle und Graph ausdrücklich als unterstützte Schnittstellen (Microsoft identity platform protocols, Microsoft Graph overview).

Für die Administration zählt daher nicht eine vermutete Serversprache, sondern die konkrete Kombination aus Tenant, Authority, Protokollversion, Tokenformat, Graph-Endpunkt, SDK- oder PowerShell-Modul, Synchronisationsagent und Resource Service. Jede dieser Schichten besitzt eigene Versionierungs-, Berechtigungs-, Logging- und Fehlergrenzen.

Tenant, Domains und Objektanker

Jeder Tenant besitzt eine unveränderliche Tenant-ID. Verifizierte Domainnamen bieten lesbare Anmeldenamen und Routingbezug, ersetzen aber die Tenant-ID nicht. Ein Domainwechsel oder Multi-Tenant-Setup darf deshalb nicht allein anhand des UPN-Suffixes identifiziert werden.

Objekte besitzen tenantlokale IDs. Benutzer können Member oder Guest sein; ein B2B-Gast ist ein Objekt im Resource Tenant mit Bezug zu einer externen Identität. Application Objects besitzen eine globale Client-/Application-ID, Service Principals zusätzlich eine eigene Object-ID im jeweiligen Tenant. Für Join und Synchronisation werden weitere Anker wie onPremisesImmutableId, Geräte-IDs und Quellattribute relevant.

Admins dokumentieren mindestens:

• Tenant-ID, primäre und verifizierte Domains;
• Objekt-ID statt nur Anzeigename oder UPN;
• Home Tenant versus Resource Tenant;
• Quellsystem und Source of Authority je Attribut;
• Soft-Delete-/Restorezustand und Lebenszyklus;
• Lizenz-, Rollen- und Gruppenbeziehungen als getrennte Objekte.

Microsoft unterscheidet Single-Tenant- und Multi-Tenant-Anwendungen danach, welche Verzeichnisse Konten und Service Principals verwenden dürfen (Microsoft identity platform – Single- and multi-tenant apps).

Entra ID ist nicht Active Directory Domain Services

AD DS verwendet Domänen, Forests, Domain Controller, LDAP, Kerberos, NTLM, DNS-Integration, Gruppenrichtlinien und Replikation. Entra ID verwendet Tenantobjekte, HTTPS-Endpunkte, moderne Federation-/Tokenprotokolle und cloudbasierte Policy. Es exponiert keinen allgemeinen LDAP- oder Kerberos-Endpunkt für Anwendungen.

Microsofts Vergleich weist ausdrücklich auf die unterschiedlichen Protokoll- und Verwaltungsmodelle hin (Microsoft Learn – Compare Active Directory to Microsoft Entra ID). Eine Appliance mit LDAP-Bind kann nicht ohne Gateway oder Domain Services direkt gegen Entra ID authentisieren; eine OAuth-API versteht umgekehrt kein Kerberos-Ticket.

Protokollendpunkte und Metadaten

Der OpenID-Connect-Discovery-Endpunkt veröffentlicht Issuer, Authorization Endpoint, Token Endpoint, JWKS URI und unterstützte Funktionen. Clients verwenden tenantbezogene Authorities wie eine konkrete Tenant-ID; common, organizations oder consumers erlauben breitere Kontotypen und verändern Issuerprüfung und Tenantzulassung.

$tenant = $env:ENTRA_TENANT_ID
$metadata = Invoke-RestMethod "https://login.microsoftonline.com/$tenant/v2.0/.well-known/openid-configuration"
$metadata | Select-Object issuer,authorization_endpoint,token_endpoint,jwks_uri
Invoke-RestMethod $metadata.jwks_uri | Select-Object -ExpandProperty keys | Select-Object kid,kty,use

metadata="https://login.microsoftonline.com/$ENTRA_TENANT_ID/v2.0/.well-known/openid-configuration"
curl --silent --show-error --fail "$metadata" | jq '{issuer,authorization_endpoint,token_endpoint,jwks_uri}'
jwks_uri="$(curl --silent --show-error --fail "$metadata" | jq -r .jwks_uri)"
curl --silent --show-error --fail "$jwks_uri" | jq '.keys[] | {kid,kty,use}'

Invoke-RestMethod, curl und jq lesen öffentliche Metadaten. Sie führen keine Tokenvalidierung durch. OIDC Discovery und JWKS-Formate sind standardisiert (OpenID Connect Discovery 1.0, RFC 7517 – JSON Web Key).

Sind Tenant, Domain und Objektanker geklärt, folgt der eigentliche Anmeldeweg. OAuth 2.0, OpenID Connect und SAML erfüllen dabei unterschiedliche Aufgaben und liefern unterschiedliche Artefakte.

OAuth 2.0, OpenID Connect und SAML

OAuth 2.0 delegiert Autorisierung für Resource APIs. OpenID Connect ergänzt eine Authentisierungsschicht mit ID Token und UserInfo. SAML transportiert signierte Assertions zwischen Identity Provider und Service Provider. Microsoft veröffentlicht die unterstützten Protokollvarianten der Identity Platform (Microsoft identity platform protocols, OpenID Connect Core 1.0, OASIS SAML 2.0 Technical Overview).

Die gebräuchlichen OAuthpfade unterscheiden Identität und Clienttyp:

• Authorization Code mit PKCE: interaktiver Benutzer, Public oder Confidential Client.
• Client Credentials: Workload ohne Benutzer; Application Permissions/App Roles.
• On-Behalf-Of: mittlere API tauscht ein Benutzertoken für eine nachgelagerte API.
• Device Code: Gerät ohne bequemen Browser; Code wird an einem zweiten Gerät bestätigt.
• Refresh Token: erneuert Zugriff ohne vollständige interaktive Anmeldung, bleibt aber Policy- und Revocationereignissen unterworfen.

Microsoft dokumentiert jeden Flow mit eigenen Request-, Credential- und Sicherheitsgrenzen (Authorization Code Flow, Client Credentials Flow, On-Behalf-Of Flow, Device Authorization Grant).

Tokenarten und Claims

Ein ID Token ist für den Client bestimmt und belegt eine Authentisierung. Ein Access Token ist für eine Resource API bestimmt; nur diese Resource soll es validieren. Ein Refresh Token ist ein Credential gegenüber dem Authorization Server und wird nie an eine Resource API gesendet (Microsoft identity platform – Security tokens).

Bei JWT-basierten Tokens sind unter anderem relevant:

Validierung prüft Signatur, Algorithmus, Issuer, Audience, Zeit und anwendungsspezifische Claims. JWT Best Current Practices warnen vor Algorithmusverwechslung, Cross-JWT-Confusion und blindem Vertrauen in empfangene Claims (RFC 8725 – JWT Best Current Practices, Microsoft – Validate tokens).

Ein Token kann für Diagnose lokal dekodiert werden; echte Tokens werden weder in fremde Webseiten noch in Tickets kopiert. Dekodieren ist keine Signaturprüfung.

$parts = $env:ACCESS_TOKEN -split '\.'
$payload = $parts[1].Replace('-','+').Replace('_','/')
$payload += '=' * ((4 - $payload.Length % 4) % 4)
$claims = [Text.Encoding]::UTF8.GetString([Convert]::FromBase64String($payload)) | ConvertFrom-Json
$claims | Select-Object iss,aud,tid,oid,sub,scp,roles,iat,nbf,exp

payload="$(printf '%s' "$ACCESS_TOKEN" | cut -d. -f2 | tr '_-' '/+')"
case $((${#payload} % 4)) in 2) payload="${payload}==";; 3) payload="${payload}=";; esac
printf '%s' "$payload" | base64 --decode 2>/dev/null | jq '{iss,aud,tid,oid,sub,scp,roles,iat,nbf,exp}'

ConvertFrom-Json, cut, tr und base64 verarbeiten nur eine lokale Kopie. Nach der Analyse wird sie verworfen; Logs und Shell History dürfen das Token nicht speichern.

Application Object und Service Principal

Eine App Registration erzeugt ein Application Object im Home Tenant. Es beschreibt unter anderem Client-ID, Redirect URIs, App Roles, angeforderte APIberechtigungen und Credentials. Wenn die Anwendung in einem Tenant verwendet oder consentiert wird, existiert dort ein Service Principal als tenantlokale Instanz. Managed Identities sind besondere Service Principals, deren Credentiallebenszyklus Azure verwaltet (Application objects and service principals).

Diese IDs werden nicht verwechselt:

• appId/Client-ID identifiziert die Anwendungsdefinition protokollseitig;
• Application Object-ID identifiziert das Registrierungsobjekt im Home Tenant;
• Service-Principal-Object-ID identifiziert die Instanz im Resource Tenant;
• Resource-/API-App-ID beziehungsweise Audience identifiziert das Tokenziel.

Ein Anzeigename ist nicht eindeutig und kein Automationsanker. Löschen und Neuanlegen kann dieselbe Client-ID nicht beliebig reproduzieren und erzeugt neue Objektbeziehungen.

Ein gültiges Token beantwortet noch nicht, was eine Anwendung tun darf. Delegierte und reine Anwendungsberechtigungen unterscheiden sich darin, ob ein Benutzerkontext beteiligt ist und wer die Rechte genehmigt.

Delegated Permissions, Application Permissions und Consent

Delegated Permissions wirken im Kontext eines angemeldeten Benutzers und erscheinen typischerweise als scp. Die App kann nicht automatisch mehr als Benutzer und Tenantpolicy erlauben. Application Permissions wirken ohne Benutzer als App Roles im roles-Claim und können weitreichenden Zugriff ermöglichen (Permissions and consent overview).

Consent erzeugt tenantlokale Grants und App-Role-Zuweisungen. Admin Consent ist keine blosse Bestätigung eines Dialogs, sondern eine Autorisierungsänderung. Inventar und Review enthalten:

• Client- und Resource-Service-Principal;
• delegierte Scope-Grants und Application App-Role-Assignments;
• wer, wann und über welchen Prozess consentiert hat;
• tatsächliche Nutzung, Publisher Verification und Herkunft;
• Objekt-/Mailboxbeschränkung in der Resource, falls verfügbar;
• Widerrufs- und Ausfallwirkung.

In Exchange Online kann eine Application Permission zusätzlich durch Exchange-spezifische Zugriffspolicy oder RBAC for Applications begrenzt werden. Das Graph-/Entra-Consentobjekt allein bildet die fachliche Postfachreichweite nicht vollständig ab (Exchange Online – Role Based Access Control for Applications).

Workload Identities und Credentials

Eine Workload Identity ist eine Softwareidentität, typischerweise Service Principal oder Managed Identity. Credentials können Client Secret, Zertifikat/private Key, Managed-Identity-Plattformcredential oder Federated Identity Credential sein. Secrets sind Bearer Credentials; Zertifikate und Federation verbessern Schlüsselbesitz oder vermeiden gespeicherte langlebige Secrets, benötigen aber eigenen Trustbetrieb (Microsoft Entra Workload ID overview).

Workload Identity Federation vertraut einem externen OIDC-Issuer und bindet Issuer, Subject und Audience an einen Service Principal oder eine User-Assigned Managed Identity. CI-System, Kubernetesserviceaccount oder Cloudworkload tauscht sein kurzlebiges externes Token gegen ein Entra-Token, ohne ein statisches Secret zu speichern (Workload identity federation).

Credentialbetrieb umfasst Aussteller, Ablage, private-Key-Zugriff, NotBefore/Expiry, Überlappung, Rotation, letzte Nutzung und Widerruf. Das Ablaufdatum im Application Object beweist nicht, dass eine Integration dieses Credential tatsächlich verwendet.

Connect-MgGraph -Scopes 'Application.Read.All','Directory.Read.All'
Get-MgContext
$app = Get-MgApplication -Filter "appId eq '$env:CLIENT_ID'"
$sp = Get-MgServicePrincipal -Filter "appId eq '$env:CLIENT_ID'"
$app | Select-Object Id,AppId,DisplayName,SignInAudience,PasswordCredentials,KeyCredentials
$sp | Select-Object Id,AppId,DisplayName,ServicePrincipalType,AccountEnabled

az account show --output json | jq '{tenantId,user,name}'
az ad app list --filter "appId eq '$CLIENT_ID'" --output json | jq '.[] | {id,appId,displayName,signInAudience,passwordCredentials,keyCredentials}'
az ad sp list --filter "appId eq '$CLIENT_ID'" --output json | jq '.[] | {id,appId,displayName,servicePrincipalType,accountEnabled}'

Connect-MgGraph, Get-MgContext, Get-MgApplication und Get-MgServicePrincipal zeigen Graphkontext und beide Objektarten. az account show, az ad app und az ad sp bilden die Azure-CLI-Sicht ab. Ausgaben können Credentialmetadaten und Tenantinventar enthalten.

Conditional Access und Continuous Access Evaluation

Conditional Access verarbeitet Signale wie Benutzer/Workload, Zielresource, Gerät, Standort, Risiko, Clienttyp und Authentisierungsstärke und wendet Grant- oder Sessioncontrols an. Policies wirken zusammen; eine erfolgreiche einzelne Policy ist kein Gesamtergebnis (Conditional Access overview).

Report-only und What If helfen bei Planung, ersetzen aber keine Pilotgruppe mit realen Clients. Messagingrelevante Sonderfälle sind Legacy Authentication, SMTP AUTH, Mobile Clients, Service Accounts, Break-Glass-Konten, Adminportale und non-interactive Sign-ins.

Access Tokens sind normalerweise bis zum Ablauf gültig. Continuous Access Evaluation erlaubt unterstützten Resources und Clients, kritische Ereignisse und Policyänderungen früher zu berücksichtigen (Continuous Access Evaluation). CAE ist kein globaler Sofortwiderruf für jede Anwendung; Resource und Client müssen das Protokoll unterstützen.

MFA, Authentication Methods und Authentication Strengths

MFA ist eine Policyaussage, keine einzelne Produktmethode. Authentication Methods Policies steuern, welche Verfahren registriert und verwendet werden dürfen; Conditional Access Authentication Strengths können konkrete Methodenkombinationen verlangen (Authentication methods overview, Conditional Access authentication strengths).

Phishingresistente Methoden wie FIDO2/Passkeys oder zertifikatbasierte Authentisierung ändern Enrollment-, Recovery- und Geräteprozesse. Temporary Access Pass kann Bootstrap ermöglichen und ist selbst ein zeitlich begrenztes Credential. Helpdesk-Reset, neue Telefonregistrierung und verlorene Geräte sind Hochrisiko-Workflows und gehören in den Auditpfad.

Directory Roles, PIM und Administrative Units

Directory Roles autorisieren Entra- und Microsoft-365-Verwaltungsfunktionen. Rollen können direkt, über Gruppen oder zeitlich über Privileged Identity Management zugewiesen werden. PIM unterscheidet eligible und active, Approval, MFA, Begründung, Dauer und Access Reviews (Microsoft Entra PIM overview).

Administrative Units können den Scope ausgewählter Rollen auf Teilmengen von Objekten beschränken. Nicht jede Rolle oder Operation unterstützt diesen Scope; Graph-, Exchange- und Securityportale besitzen teilweise eigene RBACmodelle (Administrative units).

Privileg wird als Kette dokumentiert: Zuweisungsquelle → Aktivierung → Token/Rolle → Zielservice-RBAC → konkrete Objektaktion. «Global Administrator vorhanden» erklärt nicht automatisch einen 403 in Exchange oder Graph.

Geräteidentität und Primary Refresh Token

Entra Registered, Entra Joined und Hybrid Entra Joined sind verschiedene Gerätebeziehungen. Registered bindet typischerweise ein persönliches oder fremdverwaltetes Gerät; Joined verwendet Entra als primäre Organisationsbindung; Hybrid Joined verbindet AD-DS-Domain Join mit Entra-Registrierung (Microsoft Entra device identity).

Auf Windows unterstützt das Primary Refresh Token Single Sign-On und trägt Geräte- sowie Authentisierungskontext. PRT-Ausstellung und -Erneuerung hängen von Benutzer-, Geräte- und Schlüsselzustand ab; es ist kein gewöhnliches Refresh Token, das Admins kopieren sollten (Primary Refresh Token).

Gerätestatus, MDM-Compliance, Hybrid Join, Zertifikate und Conditional Access können zeitlich auseinanderlaufen. Diagnose prüft daher lokale Joininformationen, Entra-Geräteobjekt, Managementobjekt, Sign-in Log und Policyresultat gemeinsam.

In hybriden Umgebungen beginnt die Identität häufig im lokalen Active Directory. Synchronisation überträgt ausgewählte Objekte und Attribute, macht Entra ID aber nicht zu einem LDAP- oder Kerberos-Ersatz.

Hybrididentität: Connect Sync und Cloud Sync

Microsoft Entra Connect Sync betreibt eine Synchronisierungsengine auf Windows Server und kann umfangreiche Regeln und bestimmte Hybridfeatures abbilden. Cloud Sync verwendet leichtgewichtige Provisioning Agents und cloudgesteuerte Konfiguration; Funktionsumfang und Topologie unterscheiden sich (Microsoft Entra Connect overview, Microsoft Entra Cloud Sync overview).

Ein Synchronisationssystem besitzt drei Ebenen:

1. Connector Spaces oder Quell-/Zielconnector mit importierten Objekten;
2. Metaverse-/Mappinglogik beziehungsweise Cloud-Provisioning-Konfiguration;
3. Export in Entra mit Zielobjekt, Attributfluss und Fehlerzustand.

Matching und Source Anchor verhindern Duplikate. Filter, Joinregeln, Attributpriorität und Writeback definieren Datenhoheit. Ein erfolgreicher Schedulerlauf beweist nicht, dass jedes Objekt exportiert wurde; Quarantäne, Provisioningfehler und Cloudserviceverarbeitung werden separat geprüft.

Authentisierung im Hybridbetrieb

• Password Hash Synchronization (PHS): ein abgeleiteter Hash wird in Entra gespeichert; Cloudauthentisierung bleibt bei On-Prem-Ausfall möglich.
• Pass-through Authentication (PTA): Agents validieren Kennwörter gegen AD DS; der Agentpfad wird betriebsrelevant.
• Federation: Entra leitet Authentisierung zu einem föderierten STS; Zertifikate, Claims Rules und Verfügbarkeit erweitern den Ausfallbereich.

Microsoft beschreibt Auswahl und Trade-offs dieser Sign-in-Methoden (Choose the right authentication method). Seamless SSO und PRT sind zusätzliche Mechanismen und nicht synonym mit der primären Authmethode.

Entra Domain Services

Microsoft Entra Domain Services stellt eine verwaltete Domäne mit Domain Join, Gruppenrichtlinien, LDAP, Kerberos und NTLM bereit. Benutzer, Gruppen und Credentialhashes werden aus Entra in die verwaltete Domäne synchronisiert. Kunden erhalten keine Domain- oder Enterprise-Adminrechte und verwalten Domain Controller nicht selbst (Microsoft Entra Domain Services overview).

Domain Services ist keine bidirektionale Brücke zu AD DS und kein Ersatz für Entra-Tokenprotokolle. Legacyanwendungen sehen LDAP-/Kerberosobjekte in der Managed Domain; moderne SaaS-Anwendungen verwenden weiter Entra. Secure LDAP benötigt Zertifikat, veröffentlichte Netzwerkgrenze, NSG/Firewall und Credentialpolicy.

External Identities und Cross-Tenant-Zugriff

B2B Collaboration erzeugt Gastobjekte im Resource Tenant, während Authentisierung häufig im Home Tenant erfolgt. Cross-Tenant Access Settings steuern inbound und outbound Trust, MFA-/Geräteclaimvertrauen und organisatorische Beziehungen (Microsoft Entra B2B collaboration overview, Cross-tenant access overview).

Der Resource Tenant autorisiert weiterhin seine Daten. Ein gelöschtes oder deaktiviertes Homekonto, ein bestehendes Gastobjekt, Access Packages und Gruppenmitgliedschaften können unterschiedliche Lebenszyklen besitzen. Periodische Access Reviews und Sponsor-/Ownerprozesse schliessen diese Lücke.

Microsoft Graph als Control Plane

Microsoft Graph exponiert Ressourcenpfade wie /users, /groups, /applications, /servicePrincipals, /policies und /auditLogs. Berechtigung, APIversion, Paging, Throttling und eventual consistency bestimmter Abfragen gehören zum Vertrag (Microsoft Graph overview).

Delta Query liefert Änderungen seit einem initialen Zustand über opake Tokens; Change Notifications senden Webhooks, ersetzen aber keinen Reconciliationlauf (Microsoft Graph delta query, Microsoft Graph change notifications). Für APIs gelten Idempotenz, Pagination, 429/Retry-After und Request-ID auch hier.

Connect-MgGraph -Scopes 'User.Read.All','AuditLog.Read.All'
Get-MgContext
Get-MgUser -UserId $env:USER_OBJECT_ID -Property Id,UserPrincipalName,AccountEnabled,OnPremisesSyncEnabled,ProxyAddresses
Invoke-MgGraphRequest -Method GET -Uri "v1.0/auditLogs/signIns?`$filter=userId eq '$env:USER_OBJECT_ID'&`$top=20"

az account get-access-token --resource-type ms-graph --output json | jq '{tenant,expires_on}'
token="$(az account get-access-token --resource-type ms-graph --query accessToken -o tsv)"
curl --silent --show-error --fail \
  --header "Authorization: Bearer $token" \
  "https://graph.microsoft.com/v1.0/users/$USER_OBJECT_ID?%24select=id,userPrincipalName,accountEnabled,onPremisesSyncEnabled,proxyAddresses" | jq .

Get-MgUser und Invoke-MgGraphRequest nutzen den angezeigten Graphkontext. az account get-access-token liefert ein kurzlebiges CLI-Token; es wird nicht geloggt oder persistent gespeichert. Graphantworten enthalten personenbezogene und sicherheitsrelevante Daten.

Netzwerk- und TLS-Abhängigkeiten

Entra ist ein verteilter HTTPS-Dienst. Proxy, Firewall, DNS, TLSinspection, Zeit und Endpointallowlist beeinflussen Authentisierung, Graph, Device Registration, Sync und Revocation. Eine statische IP-Liste ist nicht immer das richtige Modell; Microsoft veröffentlicht Service Tags und URL-/IPkategorien für Microsoft 365 und Entra-bezogene Endpunkte (Microsoft 365 URLs and IP address ranges, Azure service tags overview).

Resolve-DnsName login.microsoftonline.com
Test-NetConnection login.microsoftonline.com -Port 443 -InformationLevel Detailed
Invoke-WebRequest "https://login.microsoftonline.com/$env:ENTRA_TENANT_ID/v2.0/.well-known/openid-configuration" -UseBasicParsing
w32tm /query /status

dig login.microsoftonline.com A
nc -vz login.microsoftonline.com 443
openssl s_client -connect login.microsoftonline.com:443 -servername login.microsoftonline.com -alpn h2,http/1.1 </dev/null
timedatectl show --property=NTPSynchronized --property=TimeUSec

Resolve-DnsName und dig prüfen zuerst die Namensauflösung. Test-NetConnection, nc und openssl s_client trennen TCP und TLS. Invoke-WebRequest prüft HTTP, w32tm und timedatectl die Zeitquelle.

Sign-in Logs, Audit Logs und Provisioning Logs

Sign-in Logs dokumentieren interaktive, non-interactive, Service-Principal- und Managed-Identity-Anmeldungen mit Status, Conditional-Access-Auswertung, Client-, Geräte- und Risikoinformationen. Audit Logs dokumentieren Directory- und Policyänderungen. Provisioning Logs zeigen Bereitstellungsschritte und Mappingfehler (Microsoft Entra sign-in logs, Microsoft Entra audit logs, Provisioning logs).

Correlation ID, Request ID, Zeit in UTC, Tenant, Client-ID, Resource-ID, Benutzer-/Service-Principal-ID und Fehlercode bilden den Mindestnachweis. Portaltexte werden mit Fehlercode und Token-/Protokollphase ergänzt; gleiche UI-Meldungen können unterschiedliche Ursachen haben.

Logaufbewahrung hängt von Lizenz und Exportkonfiguration ab und kann sich ändern. Langfristiger Nachweis wird vor dem Incident über Diagnostic Settings beziehungsweise unterstützte Exportpfade in ein kontrolliertes Logsystem gesendet.

Break Glass, Backup und Recovery

Entra ist ein SaaS-Dienst; Kunden sichern keine Domain-Controller-Datenbank. Sie müssen aber Konfiguration, externe Credentials und administrative Wiederherstellbarkeit schützen:

• mindestens zwei cloud-only Emergency Access Accounts mit unabhängigen starken Methoden;
• Ausschlüsse von Conditional Access nur so weit wie für Recovery nötig und überwacht;
• Tenant-/Domain-/Federation-/Cross-Tenant-Konfiguration und Rollenexport;
• App Registrations, Service Principals, Grants, App Roles und Credentialsmetadaten;
• Conditional-Access-, Authentication-Methods-, PIM- und Lifecycle-Policies;
• Hybrid-Syncregeln, Source Anchors, Agent-/Serverkonfiguration und Stagingpfad;
• externe CA-/KMS-/Federation-/DNS-/Break-Glass-Abhängigkeiten;
• Export von Audit-/Sign-in-Logs und Change-Tickets.

Microsoft empfiehlt dedizierte Emergency Access Accounts, deren Nutzung alarmiert und regelmässig getestet wird (Manage emergency access accounts).

Soft-deleted Objekte besitzen produktspezifische Restorefenster und Einschränkungen, die sich ändern können. Recoveryrunbooks verlinken deshalb die jeweilige Microsoft-Dokumentation und testen Benutzer, Gruppe, App, Service Principal, Conditional-Access-Fehlkonfiguration und verlorenen Federation-/Domainpfad separat.

Die Fehlersuche folgt der Tokenentscheidung: Benutzer und Anwendung identifizieren, Anmeldeverfahren und Conditional Access prüfen, Tokenclaims lesen und zuletzt die Autorisierung an der Ressource auswerten.

Diagnose nach Entscheidungsphase

Ein Entra-Fehler lässt sich schneller eingrenzen, wenn zuerst die Phase bestimmt wird: Anmeldung, Tokenausgabe oder Entscheidung der Zielanwendung. Die Tabelle ordnet jeder Phase die passenden Belege zu.

Ein Entra-Fehler wird nicht durch beliebiges Neuanmelden gelöst. Erst die Phase bestimmt, ob Netzwerk, Clientkonfiguration, Identity, Policy, Token oder Resourceautorisierung korrigiert werden muss.

Technische Geschichte

Microsoft entwickelte Windows Azure Active Directory als mandantenfähigen Cloudverzeichnis- und Federationdienst für Microsoft Online Services und Drittanwendungen. Azure AD übernahm moderne Tokenprotokolle und war architektonisch nie ein gehosteter AD-DS-Domain-Controller. Microsoft Graph löste mehrere ältere APIs als gemeinsame Cloud-Control-Plane ab.

Hybrid Identity entstand aus Synchronisations- und Federationwerkzeugen wie DirSync, Azure AD Sync, AD FS und später Azure AD Connect. Password Hash Sync, Pass-through Authentication, Seamless SSO, Cloud Sync und Workload Federation ergänzten unterschiedliche Betriebsmodelle. Managed Identities verlagerten Credentialrotation für Azureworkloads in die Plattform.

2023 benannte Microsoft Azure Active Directory in Microsoft Entra ID um; Protokollendpunkte, APIs, Tenant- und Lizenzgrundlagen blieben Teil derselben Dienstkontinuität (Microsoft – New name for Azure Active Directory). Die Geschichte erklärt die heutige Mischung aus login.microsoftonline.com, AzureAD-Altbezeichnungen, Microsoft Graph, AD-DS-Hybridbegriffen und Entra-Produktnamen.

Admin-Checkliste auf einen Blick

Zum Abschluss werden Identitäten, Anwendungen, Rollen, Richtlinien und Wiederherstellung gemeinsam betrachtet. Die Checkliste dient als kurzer Betriebsnachweis für diese zusammenhängenden Kontrollen.