Microsoft AZ-140: Identität, Zugriff und Governance — Lernleitfaden

By Laurynas Brazys · 12 August 2026 · #microsoft #az-140 #certification #exam-prep #study-guide

Teil des Microsoft Azure Virtual Desktop Specialty AZ-140 — Lernleitfaden. Üben Sie mit verifizierten Antworten im Microsoft-Prüfungscenter, oder absolvieren Sie zeitlich begrenzte Übungstests auf ExamRoll.io.

Überblick

Identität, Zugriff und Governance definieren, wie Benutzer, Geräte und Automatisierung mit Azure Virtual Desktop-Ressourcen interagieren. Ein robustes Design richtet Microsoft Entra ID als Identitäts-Steuerungsebene aus, wendet Berechtigungen nach dem Prinzip der geringsten Rechte mit Azure RBAC an, die auf AVD-Ressourcen beschränkt sind, erzwingt bedingten Zugriff und Multi-Faktor-Authentifizierung und operationalisiert die Automatisierung mit verwalteten Identitäten. Entscheidungen, ob Sitzungshosts in Microsoft Entra eingebunden (joined) oder hybrid in Microsoft Entra eingebunden sind, bestimmen nachgelagerte Anforderungen für DNS, Authentifizierung, Profilspeicherung und das Verhalten des bedingten Zugriffs.

Identitäts- und Verzeichnisdesign

Microsoft Entra ID-Mandanten, -Benutzer und -Gruppen
- Die AVD-Steuerungsebene ist nativ in Microsoft Entra ID. Benutzer müssen in dem Mandanten existieren, dem die AVD-Ressourcen gehören, oder B2B-Gastbenutzer mit entsprechenden Zuweisungen sein.
- Verwenden Sie Microsoft Entra-Sicherheitsgruppen – statisch oder dynamisch – für Zuweisungen zu Anwendungsgruppen und für die rollenbasierte Verwaltung. Vermeiden Sie verschachtelte Gruppen für AVD-Rollenzuweisungen; Azure RBAC wertet verschachtelte Mitgliedschaften für Rollenzuweisungen nicht aus.
Gruppenbasierte Zuweisung zu AVD-Anwendungsgruppen
- Benutzer erhalten Berechtigungen für Remote-Apps oder Desktops, indem Benutzer oder Gruppen der Anwendungsgruppe zugewiesen werden. Zum Zeitpunkt der Autorisierung wendet Azure eine Rollenzuweisung von „Desktop Virtualization User“ auf dem Geltungsbereich der Anwendungsgruppe auf diese Prinzipale an.
- Bevorzugen Sie Gruppenzuweisungen gegenüber einzelnen Benutzern, um das Lebenszyklusmanagement und Zugriffsüberprüfungen zu vereinfachen. Verwenden Sie dynamische Gruppen, die auf Benutzerattributen oder Abteilungen basieren, um Benutzer den korrekten RemoteApp- oder Desktop-Anwendungsgruppen zuzuordnen.
In Microsoft Entra eingebundene versus hybrid in Microsoft Entra eingebundene Sitzungshosts
- In Microsoft Entra eingebunden (joined): Keine direkte Sichtverbindung zu traditionellen Domänencontrollern. Ideal für Cloud-First-Bereitstellungen. Unterstützt moderne Authentifizierung und SSO zur Sitzung mit Microsoft Entra ID. Verwenden Sie für FSLogix Azure Files mit Microsoft Entra Kerberos, damit sich Hosts bei Profilen ohne AD DS authentifizieren.
- Hybrid in Microsoft Entra eingebunden (in AD DS domänengebunden und in Entra ID registriert): Erforderlich, wenn Sie bestehende Gruppenrichtlinien, lokales Kerberos/NTLM oder SMB-Ziele verwenden müssen, die AD DS erfordern. Stellen Sie sicher, dass das VNET-DNS auf Domänencontroller verweist, die die Domäne auflösen und bedienen können. Wenn Sie Azure AD DS (verwaltete Domäne) verwenden, stellen Sie die VNET-DNS-Server auf die IPs der verwalteten Domäne ein, bevor Sie die Sitzungshosts in die Domäne aufnehmen.
Hybride Identität, Microsoft Entra Connect, Kennworthash-Synchronisierung und nahtloses SSO
- Verwenden Sie Microsoft Entra Connect, um Benutzeridentitäten aus AD DS zu synchronisieren. Die Kennworthash-Synchronisierung ist die einfachste und widerstandsfähigste Anmeldemethode und unterstützt cloudseitigen bedingten Zugriff.
- Aktivieren Sie nahtloses SSO, damit Unternehmensgeräte im internen Netzwerk ein Kerberos-basiertes Single Sign-On bei Entra ID erhalten können, ohne zur Eingabe von Anmeldeinformationen aufgefordert zu werden. Dies verbessert die Benutzererfahrung beim Starten von AVD aus verwalteten Netzwerken, während die Durchsetzung des bedingten Zugriffs weiterhin möglich ist.

Zugriffskontrolle und Prinzip der geringsten Rechte

Integrierte Azure RBAC-Rollen für AVD
- Desktop Virtualization Administrator: Volle administrative Kontrolle über AVD-Ressourcen.
- Desktop Virtualization Contributor: AVD-Ressourcen verwalten, ohne Endbenutzern Zugriff zu gewähren.
- Desktop Virtualization Reader: AVD-Ressourcen anzeigen.
- Desktop Virtualization Host Pool Contributor: Hostpool-Einstellungen und Registrierungsschlüssel verwalten; keine volle Kontrolle über andere AVD-Ressourcen.
- Desktop Virtualization Workspace Contributor: Anwendungsgruppen in einem Arbeitsbereich veröffentlichen oder daraus entfernen.
- Desktop Virtualization Application Group Contributor: Eigenschaften von Anwendungsgruppen und veröffentlichte Apps verwalten; gewährt keinen Benutzerzugriff.
- Desktop Virtualization Session Host Operator: Helpdesk-orientiert; Sitzungshosts und Benutzersitzungen anzeigen, Nachrichten senden, Sitzungen trennen oder abmelden.
- Desktop Virtualization User: Wird Benutzern/Gruppen auf dem Geltungsbereich der Anwendungsgruppe zugewiesen, um Starts zu autorisieren.
Geltungsbereiche und Muster für Rollenzuweisungen
- Beschränken Sie Berechtigungen so eng wie möglich:
  - Weisen Sie „Desktop Virtualization User“ nur auf dem Geltungsbereich der Anwendungsgruppe Benutzern/Gruppen zu.
  - Weisen Sie „Application Group Contributor“ der App-Gruppe, „Workspace Contributor“ dem Arbeitsbereich und „Host Pool Contributor“ dem Hostpool zu.
  - Weisen Sie „Virtual Machine Contributor“ und zugehörige Compute/Storage/Network-Rollen auf der Ressourcengruppe zu, die die Sitzungshost-VMs enthält, wenn das Betriebspersonal den Energiezustand, die Größen oder die Netzwerkschnittstellen der Gäste verwalten muss.
- Separate Ressourcengruppen für Objekte der Steuerungsebene (Arbeitsbereiche, Hostpools, Anwendungsgruppen) und Sitzungshost-VMs verbessern die Geltungsbereichsdefinition und die Überprüfbarkeit.
Verwaltete Identitäten, Dienstprinzipale und delegierte Automatisierung
- Bevorzugen Sie system- oder benutzerseitig zugewiesene verwaltete Identitäten für AVD-Autoskalierung und operative Runbooks. Weisen Sie nur die benötigten Rollen mit dem minimalen Geltungsbereich zu, um die Zielressourcen zu bearbeiten (z. B. „Virtual Machine Contributor“ auf der Ressourcengruppe des Sitzungshosts und „Desktop Virtualization Contributor“ auf dem Hostpool).
- Verwenden Sie Dienstprinzipale mit Zertifikatsanmeldeinformationen für DevOps-Pipelines, die App-Gruppen veröffentlichen oder RDP-Eigenschaften aktualisieren. Beschränken Sie deren Berechtigungen auf die spezifischen AVD-Ressourcen, die sie verwalten.
Privileged Identity Management und Notfallzugriff
- Verwenden Sie Microsoft Entra Privileged Identity Management sowohl für Azure RBAC- als auch für Microsoft Entra-Rollen. Machen Sie hochriskante Rollen wie „Desktop Virtualization Administrator“ und „Subscription Owner“ anspruchsberechtigt (eligible) und fordern Sie MFA, Genehmigungen und eine Begründung.
- Unterhalten Sie mindestens zwei „Global Administrator“-Konten für den Notfallzugriff (Break-Glass), die von bedingtem Zugriff und PIM ausgeschlossen sind, offline gespeichert, regelmäßig getestet und nur zur Wiederherstellung verwendet werden.

Kurze Beispiele für die Geltungsbereiche von Rollen:

# End-user entitlement to one application group
az role assignment create \
  --assignee <groupObjectId> \
  --role "Desktop Virtualization User" \
  --scope /subscriptions/<subId>/resourceGroups/rg-avd-control/providers/Microsoft.DesktopVirtualization/applicationGroups/ag-fin-remoteapps

# Help-desk session operations on a host pool
az role assignment create \
  --assignee <helpdeskGroupId> \
  --role "Desktop Virtualization Session Host Operator" \
  --scope /subscriptions/<subId>/resourceGroups/rg-avd-control/providers/Microsoft.DesktopVirtualization/hostPools/hp-fin

Bedingter Zugriff, MFA und Sitzungssteuerungen

Ziel-Cloud-Apps
- Wenden Sie den bedingten Zugriff sowohl auf Azure Virtual Desktop als auch auf Azure Virtual Desktop Azure Resource Manager an, um Endbenutzerverbindungen und administrative Aktionen zu schützen. Schließen Sie Notfallkonten (Break-Glass-Accounts) und nicht-interaktive Workload-Identitäten aus.
Multifaktor-Authentifizierung und Authentifizierungsstärken
- Fordern Sie MFA für alle externen Anmeldungen oder Anmeldungen mit hohem Risiko an. Nutzen Sie Authentifizierungsstärken, um Phishing-resistente Methoden vorzuschreiben (z. B. FIDO2-Sicherheitsschlüssel, gerätegebundene Passkeys in Microsoft Authenticator oder zertifikatbasierte Authentifizierung).
- Für die beste Benutzererfahrung mit dem Windows-Client kombinieren Sie Phishing-resistente MFA mit AVD Single Sign-On, damit sich Benutzer einmal bei Entra ID authentifizieren und nahtlos bei der Windows-Sitzung angemeldet werden.
Gerätekonformität und Intune-Signale
- Um den Zugriff auf verwaltete Endpunkte zu beschränken, verwenden Sie den bedingten Zugriff mit der Anforderung „Gerät muss als konform markiert sein“ (Require device to be marked as compliant). Dies wertet den Konformitätsstatus von Microsoft Intune von Windows-, macOS-, iOS- und Android-Geräten aus, die den Remote Desktop-Client verwenden.
- Für BYOD- oder nicht verwaltete Geräte verwenden Sie alternative Kontrollen wie MFA, risikobasierte Anmelderichtlinien, Nutzungsbedingungen und Sitzungsbeschränkungen. Erwägen Sie separate Anwendungsgruppen für BYOD mit eingeschränkten Apps.
Sitzungssteuerungen und Anmeldehäufigkeit
- Konfigurieren Sie eine für Produktivität und Risiko angemessene Anmeldehäufigkeit (z. B. 12 Stunden), um wiederholte Anmeldeaufforderungen bei Wiederverbindungen zu vermeiden. Eine persistente Browsersitzung ist auf native Remote Desktop-Clients nicht anwendbar. Nutzen Sie Continuous Access Evaluation, wo unterstützt, für schnelle Richtlinienänderungen und den Widerruf bei Risiken.
Netzwerk- und Standortüberlegungen
- Verwenden Sie benannte Standorte (Named Locations), um Reibungsverluste für vertrauenswürdige Büronetzwerke zu reduzieren. Kombinieren Sie für Remote-Mitarbeiter MFA und Gerätekonformität, um eine starke Sicherheitslage aufrechtzuerhalten.

Operative Identitätsaspekte für Hosts

DNS und Domänenbeitritt
- Bei Hosts, die in AD DS oder Azure AD DS eingebunden sind, müssen die VNET-DNS-Server vor der Bereitstellung auf die IPs der Domänencontroller oder der verwalteten Domänen eingestellt werden. Ohne korrektes DNS schlägt der Domänenbeitritt fehl, und FSLogix, GPO und Kerberos sind nicht funktionsfähig.
- Für in Microsoft Entra eingebundene Hosts benötigen Sie kein AD DS-DNS; SMB-Ziele für Profile erfordern jedoch weiterhin moderne Authentifizierungsfunktionen (Microsoft Entra Kerberos mit Azure Files).
Registrierungsschlüssel und Skalierung
- Das Hinzufügen bestehender oder neuer Sitzungshosts zu einem Hostpool erfordert einen gültigen Registrierungsschlüssel. Begrenzen Sie die Lebensdauer des Schlüssels und beschränken Sie die Bereitstellung der VM-Erweiterung ausschließlich auf die Hostpool-Ressource.
VM bei Verbindung starten und automatische Skalierung
- Für Funktionen zur automatischen Skalierung, die VMs freigeben/zuweisen, weisen Sie der verwalteten Identität des Skalierungsplans die Rolle „Virtual Machine Contributor“ für die Ressourcengruppe der Host-VMs und „Desktop Virtualization Contributor“ für den Hostpool zu. Vermeiden Sie die Vergabe von abonnementweiten Rechten.
Zugriffsüberprüfungen und Berechtigungslebenszyklus
- Implementieren Sie regelmäßige Zugriffsüberprüfungen für Entra-Gruppen, die Anwendungsgruppen zugewiesen sind. Integrieren Sie dies mit Entitlement Management, wenn der Anwendungszugriff mehrere Anwendungsgruppen oder Ressourcen umfasst.
Überwachung
- Überwachen Sie die Anmelde- und Audit-Protokolle von Microsoft Entra auf AVD-App-Zugriffe und die Azure Activity Logs auf Änderungen an AVD-Ressourcen. Streamen Sie die Daten an Log Analytics oder ein SIEM mit Warnmeldungen für anomale Aktivitäten (z. B. massenhafte Sitzungsabmeldungen oder unerwartete Rollenzuweisungen).

Praktisches Problemszenario

Tailwind Traders ermöglicht für 3.000 Benutzer den sicheren Fernzugriff auf Branchenanwendungen über Azure Virtual Desktop. Sie verfügen über eine lokale AD-Gesamtstruktur, die mit Microsoft Entra ID über Kennworthash-Synchronisierung und Seamless SSO synchronisiert wird. Sie werden mit in Microsoft Entra eingebundenen Sitzungshosts für komplett neue Pools modernisieren, während ein älterer hybrider Pool, der GPOs erfordert, beibehalten wird. Sie müssen Phishing-resistente MFA erzwingen, den Zugriff von außerhalb des Unternehmens nur von konformen Geräten aus gestatten, Helpdesk-Sitzungsoperationen delegieren und die automatische Skalierung mit den geringsten Rechten ausführen.

Host-Beitrittsmodelle und DNS festlegen
- Aktion: Bereitstellung eines neuen gepoolten Hostpools mit in Microsoft Entra eingebundenen Windows 11 Enterprise Multi-Session für die meisten Benutzer; Beibehaltung eines kleineren hybrid eingebundenen Pools für eine App, die GPOs erfordert.
- Warum: Der Beitritt zu Entra reduziert die Abhängigkeit von Domänencontrollern und vereinfacht Conditional Access. Der Legacy-Pool behält die erforderlichen GPOs bei. Für den hybriden Pool wird der VNET-DNS auf die IPs der lokalen DCs gesetzt, die über VPN erreichbar sind, um den Domänenbeitritt und Kerberos sicherzustellen.
Profilspeicher mit moderner Authentifizierung
- Aktion: Verwendung von Azure Files mit Microsoft Entra Kerberos für FSLogix für den in Entra eingebundenen Pool. Konfiguration von Freigabe- und Dateiberechtigungen für Benutzer und die verwalteten Identitäten der Sitzungshosts.
- Warum: Ermöglicht domänenlosen SMB-Zugriff über Entra ID, wodurch die Abhängigkeit von AD DS für Profile im Cloud-First-Pool entfällt.
Gruppenbasierte Berechtigungen
- Aktion: Erstellung von Entra-Sicherheitsgruppen pro Persona (z. B. grp-tt-hr-remoteapps, grp-tt-sales-desktop). Zuweisung dieser Gruppen zu den entsprechenden Anwendungsgruppen; verschachtelte Gruppen vermeiden.
- Warum: Zentralisiert die Zugriffskontrolle und ermöglicht Zugriffsüberprüfungen. Direkte Gruppenzuweisungen werden von Azure RBAC für AVD zuverlässig ausgewertet.
Conditional Access mit Authentifizierungsstärken
- Aktion: Erstellung von Richtlinien, die auf Azure Virtual Desktop und Azure Virtual Desktop Azure Resource Manager abzielen:
  - Authentifizierungsstärke „Phishing-resistente MFA“ erfordern.
  - Für Standorte außerhalb vertrauenswürdiger Büros zusätzlich verlangen, dass das Gerät als konform markiert ist.
  - Anmeldehäufigkeit für Endbenutzer auf 12 Stunden festlegen.
  - Zwei Notfallkonten (Break-Glass-Accounts) und die verwaltete Identität für die automatische Skalierung ausschließen.
- Warum: Erzwingt starke Faktoren und den Zugriff von verwalteten Geräten ohne übermäßige Abfragen und vermeidet die Blockierung von Notfall- oder Workload-Identitäten.
Delegierung von Operationen mit den geringsten Rechten
- Aktion: Zuweisung von Rollen auf minimalen Geltungsbereichen (Scopes):
  - Desktop Virtualization User für Berechtigungsgruppen auf dem Geltungsbereich ihrer Anwendungsgruppen.
  - Desktop Virtualization Session Host Operator für die Helpdesk-Gruppe auf jedem Hostpool.
  - Desktop Virtualization Workspace Contributor für das App-Publishing-Team auf dem Workspace.
  - Virtual Machine Contributor für das Ops-Team nur auf der Ressourcengruppe der Sitzungshosts.
- Warum: Richtet Aufgaben an den von ihnen verwalteten Geltungsbereichen aus und verhindert so eine übermäßige Rechtevergabe auf Abonnementebene.
Konfiguration der automatischen Skalierung mit einer verwalteten Identität
- Aktion: Aktivierung der automatischen Skalierung auf dem Hostpool mit einer benutzerzugewiesenen verwalteten Identität. Verleihung der Rollen Virtual Machine Contributor auf der Ressourcengruppe der Sitzungshosts und Desktop Virtualization Contributor auf dem Hostpool. Beispiel:

az role assignment create --assignee <miObjectId> --role "Virtual Machine Contributor" --scope /subscriptions/<sub>/resourceGroups/rg-tt-avd-hosts
az role assignment create --assignee <miObjectId> --role "Desktop Virtualization Contributor" --scope /subscriptions/<sub>/resourceGroups/rg-tt-avd-control/providers/Microsoft.DesktopVirtualization/hostPools/hp-tt-prod

Warum: Die automatische Skalierung kann VMs starten und stoppen sowie Hostpool-Metriken aktualisieren, ohne weitreichende Berechtigungen zu benötigen.

Schutz der Administration mit PIM und Notfallkonten
- Aktion: Einbindung administrativer RBAC-Rollen in Microsoft Entra PIM mit Genehmigungsworkflows und MFA. Pflege von zwei Global Administrator Notfallkonten (Break-Glass-Accounts), die von CA und PIM ausgeschlossen sind.
- Warum: Reduziert dauerhafte Berechtigungen und stellt die Wiederherstellbarkeit bei Fehlkonfigurationen von Conditional Access oder Identitätsdiensten sicher.
Regelmäßige Überwachung und Überprüfung des Zugriffs
- Aktion: Streamen der Entra-Anmeldeprotokolle und Azure Activity Logs an Log Analytics. Durchführung vierteljährlicher Zugriffsüberprüfungen für Gruppen, die Anwendungsgruppen zugewiesen sind, und für Helpdesk-Operator-Rollen.
- Warum: Erhält das Prinzip der geringsten Rechte über die Zeit aufrecht und erkennt Anomalien wie unerwartete Anstiege bei verweigerten AVD-Anmeldungen oder massenhafte Sitzungsbeendigungen.

Dieser Ansatz kombiniert eine Cloud-First-Identität mit präzisem Scoping und starken Zugriffsrichtlinien, schafft ein Gleichgewicht zwischen Benutzererfahrung und Sicherheit und stellt sicher, dass Operationen und Automatisierung nur die erforderlichen Rechte delegiert bekommen.

← Azure Virtual Desktop-Architektur und Servicedesign · Alle Domänen · Netzwerk →

Diese Fragen üben → · Zeitlich begrenzte Übung auf ExamRoll.io →