Azure Virtual Desktop mit MFA und Conditional Access schützen

Mit diesem Beitrag setze ich meine kleine AVD-Serie fort. Ziel ist, dass du den Zugriff auf deine AVD-Umgebung dadurch schützen/verbessern kannst, indem du ihn von deinem AVD-Client oder dem AVD-Web-Client nur dann gestattest, wenn dein Client-PC Mitglied deiner ADDS-Domäne und außerdem deinem Entra ID-Verzeichnis beigetreten ist (Entra ID Hybrid Joined). (Hier gelangst du zu unseren Microsoft Azure Schulungen) Dies erlaubt es dir mittels Entra ID Conditional Access den Zugriff mit einer MFA-Richtlinie zu verknüpfen. Deine Benutzer müssen dann für den Zugriff auf ihren virtuellen Desktops explizit ein Unternehmensgerät verwenden. Dass der Zugriff nur über einem Organisationskonto erfolgen kann, gehört ohnehin zu den essenziellen AVD-Voraussetzungen. Dann verschärft du die Zugriffsanforderung zusätzlich noch durch das Verwenden von Multi-Factor-Authentication (MFA).

Der in der Einleitung geschilderte Sachverhalt ist insbesondere dann von Bedeutung, wenn der Zugriff auf deine AVD-Umgebung nicht über ein VPN oder eine Express-Route erfolgt, also über das öffentliche Internet, was ja problemlos möglich ist. Dein Client kommuniziert über eine HTTPS-Verbindung (blau im Bild), welche den TCP-basierten RDP-Reverse-Connection-Transport kapselt, mit dem Remote Desktop Gateway. Die nächstgelegene RD-Gateway-Instanz wird über den Azure-Dienst Frontdoor ermittelt. Ebenfalls über öffentliche Leitungen übertragen werden die Entra-ID-Authentifizierungsdaten (in der Abbildung violett) und die Feed-Subscription-Daten für das Abonnieren des jeweiligen Workspaces (rot). Die eigentlich Session-Host sind so oder so in keinem Fall über das öffentliche Internet zugänglich. Nebenstehenden Grafik von Microsoft verdeutlicht die Zusammenhänge.

Die verschiedenen Netzwerkkommunikationspfade in einer AVD-Umgebung

Verzichtest du also auf die private Leitung oder ein VPN können sich deine Benutzer von überall auf der Welt und mit unterschiedlichen Geräten und Clients bei Azure Virtual Desktop anmelden, wenn du hier nicht einschränkend eingreifst. Daher solltest du erwägen, zur Absicherung zusätzliche Maßnahmen zu ergreifen. Mit überschaubarem Aufwand realisieren lässt sich das in der Einleitung skizzierte Szenario, den Zugriff auf Unternehmensgeräte zu beschränken und die für AVD ohnehin zwingend erforderlichen Unternehmen-Benutzer (Organisationskonen, bzw, „School- or Work-Accounts) an MFA zu knüpfen. Mit MFA werden deine Benutzer im Verlauf des Anmeldevorgangs nach der Eingabe ihres Benutzernamen und Kennworts zu einer weiteren Methode zur Identifikation aufgefordert. Während das Passwort lediglich etwas darstellt, was dein Benutzer „weiss“ (und da das Passwort letztlich auch übertragen werden muss, kann es von Angreifern entweder an der Quelle, z. B. durch Einsatz eines Keyloggers oder auf deinen Weg durchs Internet auch abgefangen werden), stellt der zweite Faktor ein Element dar, welches dein Benutzer „hat“ (z. B. Software-Authenticator oder hardware-Token) oder „ist“, also ein biometrisches Merkmal. Am komfortabelsten ist es, wenn du MFA für Azure Virtual Desktop mithilfe von bedingtem Zugriff (Conditional Access) erzwingst. Du kannst MFA so konfigurieren, dass die zugrunde liegenden MFA-Richtlinie für den Webclient, mobile Anwendungen, Desktopclients oder alle Clients gilt.

Stellt also einer deiner Benutzer eine Verbindung mit einer Remote-Session her, muss er sich wie auch bisher schon beim Azure Virtual Desktop-Dienst und dem Sitzungshost authentifizieren. Mit aktiviertem MFA wird dein Benutzer zum Eingeben der Anmeldeinformationen seines Benutzerkontos sowie einer weiteren (zweiten) Authentifizierungsmethode aufgefordert, genauso wie das bei aktivierter MFA auch beim Zugriff auf andere Dienste ablaufen würde. Mit zusätzlich aktiviertem Seamless SingleSignOn kannst du sogar erreichen, dass dein Benutzer beim Starten einer Remotesitzung nicht erneut nach dem Kennwort gefragt wird.

Von den Konfigurationseinstellungen der Microsoft Entra-Sitzungslebensdauer hängt es schließlich ab, wie häufig deine Benutzer aufgefordert werden, sich erneut zu authentifizieren. Ist der Windows-Clientgerät deines Benutzers beispielsweise bei Microsoft Entra ID registriert ist, erhält es ein primäres Aktualisierungstoken (Primary Refresh Token, PRT), das für einmaliges Anmelden (Single Sign-On, SSO) für alle Anwendungen verwendet wird. Dieses ist nach dem Ausstellen 14 Tage gültig und wird fortlaufend verlängert, solange das Gerät vom Benutzer aktiv genutzt wird. Übrigens enthält eine Browsersitzung überhaupt keine persistenten Cookies, sofern du keine Einstellungen für die Sitzungslebensdauer konfigurierst, d. h. jedes Mal, wenn dein Benutzer den Browser schließt und öffnet, erhält dieser eine Aufforderung zur erneuten Authentifizierung.

Das Speichern von Anmeldeinformationen verbessert zwar die Usability birgt aber auch Sicherheitsrisiken. Du solltest zum Schutz deiner Benutzer daher sicherstellen, dass der Client häufiger zur Eingabe von Anmeldeinformationen für die Microsoft Entra-Multi-Faktor-Authentifizierung auffordert. Hierzu bietet sich wiederum das Andocken an den bedingten Zugriff (Conditional Access).

Voraussetzung für die folgenden Ausführungen ist, dass deine Sitzungshosts „Active-Directory-Joined“ sind und dass dein lokalen Benutzerentitäten mittels „Azure-AD-Connect“ in dein Entra-ID synchronisiert sind.

Achtung: Auf dem Server oder Domain Controller (die Installation auf einem Domain Controller empfiehlt sich gemeinhin nicht), auf dem das Werkzeug installiert ist, heißt die Software „Azure AD Connect“. Das gilt für alle Komponenten, wie z. B. das Desktop-Icon oder den Startmenüeintrag. Suchst du hingegen im Internet nach den Downloadquellen (https://www.microsoft.com/en-us/download/details.aspx?id=47594) oder der Produktseite heißt es „Microsoft Entra Connect“. Die Installationsdatei heißt aber „AzureADConnect.msi“. Ich gehe aber davon aus, dass die Software bei dir bereits installiert und im Einsatz ist. Beginne daher jetzt damit, die bestehende Azure-AD-Connect-Konfiguration anzupassen, indem Du Azure-AD-Connect startest. Dadurch wird übrigens der Scheduler für den Synchronisationsdienst angehalten, d. h. solange du dich in der Konfiguration befindest, findet keine Synchronisation statt. Klicke dann auf „Konfigurieren“.

Während der Konfiguration von Azure AD Connect findet keine Synchronisation statt

Hier wählst du nun den Eintrag „Geräteoptionen konfigurieren“.

Für den hybriden Geräte-Join musst du die Geräteoptionen anpassen

Wie du siehst, geht es hier um die gesuchte Funktion „Hybrid-Azure AD-Einbindung“. Diese ermöglicht es dir, dass sich „Geräte“ aus deiner ADDS-Gesamtstruktur für die Zugriffsverwaltung von Entra ID registrieren können. Möchtest du zusätzlich auch bedingten Zugriff für ADFS oder „Windows Helo for Business“ aktivieren, brauchst du auch die Funktion „Gerätezurückschreiben“. Damit werden alle in Entra ID registrierten Geräte wieder lokal synchronisiert. Außerdem braucht dein AD mindestens die Schema-Version „Windows Server 2012 R2“.

Einrichten der hybriden Azure-AD-Einbindung

Klicke auf „Weiter“ und melde dich mit einem „Globaler Administrator“-Konto im Entra ID an.

In den Geräteoption findest du die „Hybride-Azure-AD-Einbindung“.

Idealerweise hast du für diesen Zweck extra ein eigenes Konto erstellt und verwendest nicht deinen regulären globalen Administrator dafür. Du landest nun im Dialog „Geräteoptionen“ und kannst die Option „Hybrid-Azure-AD-Einbindung konfigurieren“ auswählen (Default). Klicke erneut auf „Weiter“ und wähle im nächsten Schritt „Gerätebetriebssysteme“ die Option „In die Domäne eingebundene Geräte mit Windows 10 oder höher" (Default). Auf die Option, auch ältere Windows-OS-Versionen verwenden zu können solltest du aus Sicherheitsgründen verzichten.

Wähle Mindest-OS-Version deiner Client-Betriebssysteme aus

Klicke auf „Weiter“ und wähle im Schritt „SCP-Konfiguration“ (steht für Service Connection Point) deine lokale ADDS-Domäne aus und klicke auf „Hinzufügen“. Deine Geräte nutzen diesen SCP, um die EntraID-Mandanteninformationen zu ermitteln. Du musst dich daraufhin mit einem lokalen ADDS-Konto mit Enterprise-Admin-Status „ausweisen“.

Die SCP-Konfiguration erfordert ein lokales Domänenkonto mit Enterprise-Rechten

Klicke auf „Weiter“ und schließe im nächsten Schritt die Konfiguration mit einem finalen Klick auf „Konfigurieren“ ab.

Das Konfigurieren der Geräteoptionen ist abgeschlossen

Das war nur der erste Schritt. Bevor du den Azure-AD-Connect-Assistenten ein weiteres Mal starten musst, lege in „Active Directory Benutzer&Computer“ eine neue OU (Organisationeinheit) an, die sämtliche Computerkonten deine ADDS-Domäne enthält, welche du nach EntraID synchronisieren möchtest. Du kannst die OU nennen wie du möchtest. Im Beispiel habe ich die OU einfach „Workstations“ genannt, weil für dieses Artikel das primäre Ziel ist, Computerkonten von Winddows-10/11-„Clients“ nach Entra zu synchronisieren, um  an diese beim Zugriff AVD eine CA-Richtlinie knüpfen zu können. Auch für deren Onboarding in Intune wäre das z. B. der richtige Weg. In der Abbildung habe ich angedeutet, dass du „in“ der OU zusätzlich noch eine Gruppe für die Computerkonten (hier „dit-workstations“) anlegen könntest. Da die Gruppe dann als Ganzes mit synchronisiert würde, würdest du dann im Entra ID eine Gruppe vorfinden, welche die entsprechenden Computerkonten enthält.

Die zu synchronisierende OU kann, muss aber keine Extra-Gruppe mit den Computerkonten enthalten

Ohne diese Extra-Gruppe, liefert die die Synchronisation „nur“ den Gerätestatus „Enta ID Hybrid Joined“ in der Entra-ID-Geräteverwaltung:

Synchronisierte Computerkonten erscheinen in der EntraID-Geräteverwaltung

Für unseren Zweck ist das momentan ausreichend. Hättest du dagegen die Computer-Konten auch in einer Entra-ID-Gruppe, hast du damit auch eine Identität, die du auf Azure-Dienste wie z. B. ein Speicherkonto berechtigen kannst. Das kommt beispielsweise zum Tragen, wenn deine Session-Hosts über eine VPN oder Express-Route deinem ADDS beigetreten sind. Synchronisierst du sie dann als Computerkonten zurück ins Entra-ID, kanns du ihnen RBAC-Berechtigungen zuweisen. Das ist z. B. im Kontext von AVD bei MSIX AppAttach hilfreich. Dazu aber mehr in einem späteren Beitrag. Jetzt musst du nur noch dafür sorgen, dass deine neue OU auch synchronisiert wird. Daher muss den Azure-.AD-Connect-Konfigurator jetzt ein weiteres Mal aufrufen. Diesmal klickst du allerdings auf „Synchronisationsoptionen anpassen“ genauso, wie du es vermutlich bei der Erstkonfiguration getan hast.

Im zweiten Durchgang musst du die Synchronisationsoptionen anpassen

Die nächsten Schritte sind die Gleichen, wie oben bei den Geräteoptionen: Gib im Dialog „Mit Azure AD verbinden“ deinen EntraID-Account mit Global-Admin-Rechten an: Füge im nächsten Schritt „Verzeichnisse verbinden“ wieder dein ADDS-Verzeichnis an, sofern es nicht noch verbunden ist. Dazu brauchst du wieder einen Unternehmens-Admin-Konto aus deinem ADDS: Nun kannst im Dialog „Filter von Domänen und Organisationseinheiten“ deine neu angelegte OU für die Computerkonten zusätzlich zu der bereits ausgewählten OU deiner zu synchronisierenden Benutzeridentitäten auswählen.

Die OU- und Domain-Filterung erfasst nun auch deine Computerkonten

Klicke auf „Weiter“ und prüfe bei „Optionale Features“ deine bereits von der Erstkonfiguration gesetzten Optionen, ggf. erweitert und das „Gerätezurückschreiben“.

Das Gerätezurückschreiben ist ein weiteres optionales Feature von Azure AD Connect

Ein Klick auf „Weiter“, dann auf „Konfigurieren“ und schließlich auf „Beenden“ schließt den zweiten Teil unserer Vorbereitungen ab. Nun können wir uns um die gewünschten bedingten Zugriffsrichtlinien kümmern, sobald du geprüft hast, dass dein Windows-Client-Systeme jetzt in der Entra-ID-Geräteverwaltung mit dem Typ „Hybrid-Joined“ auftauchen (siehe oben).

Jetzt können wir eine Richtlinie für den bedingten Zugriff einrichten, welche den Zugriff auf deine AVD-Infrastruktur nur mit einem Unternehmenskonto, mittels MFA und nur von einem Unternehmensgerät erlaubt, das Mitglied deiner lokalen Domäne ist, und über eine Identität im Entra ID verfügt. Bedenke, dass das Verwenden von Richtlinien für den bedingten Zugriff eine Entra-ID-Premium-P2-Lizenz für jeden Benutzer benötigt, auf den diese Richtlinie angewendet werden soll. Um Richtlinien für den bedingten Zugriff anlegen zu können, benötigts du im Entra ID einer der Rollen „Globaler Administrator“, „Sicherheitsadministrator“ oder „Administrator für den bedingten Zugriff“. Navigiere im Azure Portal zu Eintra ID und dort zum Abschnitt „Verwalten / Sicherheit“. Dort findest du die Funktion unter „Schützen / Bedingter Zugriff“. Alternativ findest du die Funktion im Entra-Admin-Center unter „Schutz / Bedingter Zugriff“. So oder so klickst du dann auf „Richtlinien“.

Startpunkt für das Einrichten von Richtlinien für den bedingten Zugriff

Klicke auf „neue Richtlinie“, gib deiner Richtlinie einen Namen und wähle dann bei „Zuweisungen“ aus, für welche Benutzeridentitäten oder Gruppen die Richtlinie gelten soll und welche von der Richtlinie ausgenommen sein sollten. In der Praxis empfiehlt sich hier immer mit Sicherheitsgruppen zu arbeiten, auch wenn ich in der Abbildung nur einen einzelnen Demo-User in die Richtlinie aufnehme:

Die Benutzer oder Gruppen, für welche die Richtlinie gelten soll

Auf einen Ausnahme-User kannst du für dieses einfache Beispiel verzichten. Je größer aber der Scope deine Policy (maximale „alles User), desto wichtiger wird es, wenn du eine Ausnahmeregelung vorsiehst, um dich nicht selbst auszusperren. Navigiere weiter zum Abschnitt „Zielressourcen“ und wähle bei „Wählen Sie aus, worauf die Richtlinie angewendet werden soll", statt des Default-Eintrags „Cloud-Apps“ im Tab „Einschießen die Option „Apps auswählen“. Klicke dann im Abschnitt „Auswählen“ auf „Kein“, um die gewünschten Apps gezielt auswählen zu können. Die Apps, welche du für AVD zwingend benötigst, sind „Azure Virtual Desktop“ und „Microsoft Remote Desktop“.

Das Auswählen der Ziel-Applikationen für das Beschränken des Zugriffs

Du musst die beiden genannten Apps nacheinander heraussuchen und jeweils auf „Auswählen“ klicken. Das Ergebnis sollte so aussehen:

Für AVD sind diese beiden Ziel-Applikationen erforderlich

Weiter geht es im Abschnitt “Bedingungen“. Hier gibt es mehrere Abschnitt wie „Benutzerrisiko“, „Anmelderisiko“,  „Insiderrisiko“, „Geräteplattform“, „Nach Geräten filtern“ und „Authentifizierungsworkflows“. Bedenke, dass jede Bedingung, die du in einer CA-Policy konfigurierst, logisch UND-verknüpft ist. Wir benötigen für unsere Szenario die Bedingung „Client-Apps“. Klicke daher auf den gleichnamigen Link.

Die Client-Apps sind diejenigen, von denen aus du den Zugriff gestatten möchtest

Für AVD benötigst du „Browser“ sowie „Mobile Apps und Desktopclients“, wenn deine Benutzer auf ihren Arbeitsstationen sowohl mit dem nativen AVD-Client, als auch mit dem Web-Client arbeiten können sollen. Klicke dann auf „Fertig“.

Für AVD musst du die Client-Apps „Browser“ und/oder „Mobile Apps und Desktopclients“

Weiter geht es mit dem Abschnitt „Gewähren“, denn du möchtest ja den Zugriff auf deine AVD-Umgebung letztendlich gewähren, wenn die oben genannten Bedingungen zutreffen. Klicke also bei „Gewähren“ auf den Link „0 Steuerelemente ausgewählt“. Hier aktivierst du nun die Optionen „Mult-Faktor-Authentifizieren anfordern“, sowie „In Microsoft Entra hybrid eingebundenes Gerät erforderlich“.

Nun verknüpfst du die Anforderung „MFA erforderlich“ mit „Unternehmensgerät erforderlich“.

Bedenke auch hier, dass sämtliche gewählten Steuerelemente logisch UND-verknüpft sind. Abschließend kannst du mit dem Schiebeschalter „Richtlinie aktivieren“ noch entscheiden, ob du deine neue Richtlinie sofort scharf schalten möchtest (Ein), die Richtlinie speichern aber noch nicht anwenden (Aus) oder nur im Berichtsmodus aktivieren (Nur Bericht) möchtest. In letzterem Fall wird sich dein Test-Benutzer zwar trotzdem ohne MFA anmelden können, die „Verletzung deiner Richtlinie taucht dann aber in den Conditional-Access-Logs auf. Wir gehen im Beispiel gleich in den aktiven Feldversuch. Vergiss nicht, auf „Erstellen“ zu klicken. Deine neue Richtlinie ist nun aktiv.

Melde dich nun testweise mit deinem ausgewählten Benutzer mit dem AVD-Client oder dem Web-Client bei deiner AVD-Umgebung an. Dazu musst du den Benutzer selbstverständlich zuvor auch den passenden AVD-Anwendungsgruppe zugewiesen haben, damit er überhaupt Zugriff auf seinen AVD-Workspace erhalten kann.

Wie du an der finalen Abbildung erkennst, wird der Benutzer beim Abonnieren seines AVD-Feeds aufgefordert, einen zweiten Faktor zu verwenden, was vorrausetzt, dass der betreffende Benutzer wenigsten eine AVD-Methode (hier SMS an Smartphone) in seinem Kontoprofil konfiguriert hat:

Der Benutzer wird erfolgreich zur Eingabe eines zweiten Faktors aufgefordert

Hat er den zweiten Faktor angegeben, kann er auf seinen Session-Desktops oder seine Remote-Apps zugreifen:

Erfolgreich beim AVD-Client mittels MFA authentifiziert