Azure Virtual Desktop Teil 5  – FSLogix-Dateifreigaben in ADDS einbinden

Nachdem wir in Teil zwei und drei unserer Azure-Virtual-Desktop-Serie zahlreiche Varianten der FSLogix-Integration- und Konfiguration im Allgemeinen vorgestellt haben, wollen wir diesmal demonstrieren, wie du FSLogix-Profil-Container mit Azure Files nutzt, wenn deine Session-Hosts ADDS-Joined sind.

Die meisten Hintergrundinformationen im Zusammenhang mit Azure-Dateifreigaben als Profilspeicher für FSLogix und der damit einhergehenden Notwendigkeit, eine identitätsbasierende Authentifizierungsmethode zu implementieren, haben wir in den bisherigen Beiträgen dieser Serie bereits erörtert.

Dabei haben wie bisher mit Sessionhosts gearbeitet, die Entra-ID-Joined sind/waren, was die Abhängigkeit von einer vorhandenen ADDS-Struktur angeht, auf ein Minimum reduziert, da keine permanente Sichtverbindung vom Session-Host zu einem Domain-Controller benötigt wird. Hybride Nutzer-Identitäten – also aus dem ADDS mit Hilfe von EntraID-Connect über eine ausgehende HTTTS-Verbindung synchronisierte ADDS-Nutzerkonten – brauchst du bei dieser Methode aber in jedem Fall, weil in diesem Szenario (Entra-ID-Joined) derzeit keine Benutzerkonten zulässig sind, die ausschließlich in Microsoft Entra ID erstellt und verwaltet werden.

Außerdem erlaubt es dieses Feature, dass Benutzer bei „Bezug“ ihres Nutzerprofils via FSLogix von einer Azure-Dateifreigabe das dafür erforderliche Kerberos-Ticket stellvertretend vom EntraID ausgestellt bekommen, wozu dieses mit dem ADDS synchronisiert sein muss. Zum Konfigurieren von Windows-Zugriffssteuerungslisten (Access Control Lists, ACLs) bzw. von Berechtigungen auf Verzeichnis- und Dateiebene jedoch, müssten die Sessionhosts wie schon einmal erwähnt dennoch über eine uneingeschränkte Netzwerkverbindung mit dem lokalen Domänencontroller verfügen, etwa via VPN oder Express Route.

Microsoft empfiehlt für ein solches Szenario – also wenn der Beitritt der Session-Hosts mangels Sichtverbindung via VPN oder Express Route nicht möglich ist – die Verwendung der Entra ID Domain Services. Diese sind aber meiner Meinung nach aufwendiger einzurichten, verursachen höhere Kosten und du brauchst dann mindestens eine weitere Azure-VM zum Verwalten der von Microsoft bereitgestellten Domain Controller. Das EntraID-Kerberos-Szenario bietet aber nicht nur Vorteile. So werden z. B. keine Gastkonten oder externe Nutzer unterstützt. Daher wenden wir uns in diesem Beitrag dem eigentlichen Enterprise-Szenario zuwenden, also mit ins ADDS gejointen Sitzungshosts und einer permanenten privaten Verbindung zu deinem lokalen Standardort.

Session-Host im ADDS

Deine Sessionhosts können über eine bestehende VPN- oder Expressroute-Verbindung direkt deinem Active Directory beitreten. Dies ist die derzeit von Microsoft favorisierte Methode für mittlere und große Unternehmen. Da in diesem Fall ohnehin eine private Verbindung zu Microsoft Azure besteht, erfolgt auch der Client-seitige Zugriff dann meistens aus dem lokalen Unternehmensnetzwerk heraus mit gleichbleibend vorhersehbarer Bandbreite und geringer Latenz, wenngleich die Methode mobile Clients nicht ausschließt. Zwar bietet auch der Zugriff auf die AVD-Gateways über öffentliche Endpunkte dank der smarten RDP-Implementation und der Involvierung der Azure-Frontdoor-Architektur (siehe Artikel Frontdoor) gute Performance, über private Leitungen ist dieser aber immer gleich und daher vorhersagbar:

Profilspeicher für FSLogix

Im direkten Zusammenhang mit der Frage, ob deine Session-Hosts EntraID- oder ADDS-Joined sind, steht auch die Entscheidung, welchen Speicherdienst du für deine FSLogix-Profile nutzen möchtest. Die Varianten hatten wir im Groben schon erläutert. Hier eine Übersicht von Microsoft:

Nur Azure Files und NetApp Files sind PaaS. Der Aufwand, einen eigenen Scaleout-Fileserver mit Hilfe eines Windows-Server-basierten Failover-Clusters mit Azure-VMs und Speichervirtualisierung mittels Storage Spaces Direct auf Basis von Azure-VMs zu betreiben (IaaS), dürften sich in den meisten Fällen nicht lohnen. Für FSLogix empfiehlt sich daher für die meisten Unternehmen ein Premium-Storage-Account mit SMB-Fileshares. Aber Achtung: Die Bedeutung des „Kontingents“ (maximale Kapazität) unterscheidet sich erheblich zwischen Standard und Premium-Speicherkonten. Letztendlich geht es dabei darum, ob du den Fileshare „nutzungsbasiert“ zahlst (Standard) oder „bereitgestellt“ (Premium). Im letzteren Fall hast du eine vorhersagbare Performance, für die du dann aber auch zahlst, unabhängig von der tatsächlich genutzten Speicherkapazität.

Solltest du noch mehr Power und Funktionen benötigen (Low Latency, Mehrfachprtokoll-Support usw.), dann greife zu Azure Net App Files, ein NetApp-Filer aus der Microsoft-Cloud. Allerdings solltest du dann schon allein aufgrund der Kosten eher ein börsennotiertes Unternehmen sein, denn du musst mit einem sechsstelligen Betrag im Monat rechnen. Die größte Flexibilität und das beste Preis/Leistungsverhältnis bietet daher der Speicherkonto (Standard oder ggf. Premium). 

Identität

Für den Zugriff auf deine Azure-Dateifreigabe muss deren Benutzer authentifiziert und für den Zugriff auf die Freigabe autorisiert sein. Dies erfolgt basierend auf der Identität des Benutzers, der auf die Dateifreigabe zugreift. Azure Files unterstützt die folgenden Authentifizierungsmethoden:

1. Lokale Active Directory Domain Services (AD DS): Azure Storage-Konten können mit einer kundeneigenen AD DS-Instanz verknüpft werden. Sobald ein Speicherkonto einer Domäne beigetreten ist, kann der Endbenutzer eine Dateifreigabe mit dem Benutzerkonto einbinden, mit dem er sich bei seinem PC angemeldet hat. Bei der AD-basierten Authentifizierung wird das Kerberos-Authentifizierungsprotokoll verwendet.
2. Microsoft Entra Domain Services: Bietet einen von Microsoft verwalteten Domänencontroller, der für Azure-Ressourcen verwendet werden kann. Diese Bereitstellungsoption ist besonders nützlich für Lift-and-Shift-Anwendungsszenarien, die AD-basierte Berechtigungen erfordern.
3. Microsoft Entra Kerberos für Hybrididentitäten: Ermöglicht die Verwendung von Microsoft Entra ID zum Authentifizieren von Hybridbenutzeridentitäten. Diese Konfiguration verwendet Microsoft Entra ID, um Kerberos-Tickets für den Zugriff auf die Dateifreigabe mit dem SMB-Protokoll auszugeben.
4. Azure-Speicherkontoschlüssel: Azure-Dateifreigaben können auch mit einem Azure-Speicherkontoschlüssel bereitgestellt werden. Bei einer solchen Einbindung einer Dateifreigabe wird der Speicherkontoname als Benutzername und der Speicherkontoschlüssel als Kennwort verwendet.

Wir wollen uns auf die Methode 1 konzentrieren; 4 benötigst du darüber hinaus für die initiale Inbetriebnahme von FSLogix. Leider ist es so, dass die Zusammenarbeit zwischen Active Directory und EntraID (ehemals Azure AD) nicht immer so reibungslos funktioniert, wie man es sich wünschen würde, zumal ja beide Dienste aus dem gleichen Hause stammen. Befolge daher die folgenden Anweisungen genau:

Vorbereitende Maßnahmen im Active Directory (ADDS)

Achtung: Keine der o. g. Authentifizierungsmethoden unterstützt das Zuweisen von Berechtigungen auf Freigabeebene zu Computerkonten mithilfe von Azure RBAC. Das liegt daran, dass Entra ID Connect Computerkonten aus dem ADDS nicht mit einer Identität in Microsoft Entra ID synchronisiert kann.

Das geht auch nicht, wenn du wie für ein hybrides AVD-Szenario unerlässlich im Synchronisationswerkzeug „Microsoft Azure Active Directory Connect“ bei den „Geräteoptionen“ die Option „Hybrid-Azure-AD-Einbindung konfigurieren“ wählst, dann bei „Gerätebetriebssysteme“ den Haken bei „In die Domäne eingebundene Geräte mit Windows 10 oder höher“ setzt und als Synchronisationsquelle die OU mit den passenden Computer-Konten auswählst, wie in der folgenden Abbildung gezeigt.

Das musst du machen, wenn du z. B. später MFA einrichten möchtest, du bekommst damit aber lediglich den passenden hybriden Geräteidentitätsstatus im Entra ID, nicht aber ein echtes Computerkonto im Entra ID. Daher musst du für unser Szenario den umgekehrten Weg gehen und deinem Speicherkonto mit der Azure-AD-Dateifreigabe eine Identität in deinem lokalen ADDS verleihen.

Leider haben aber Computer-Konten im ADDS die nützliche, für unserer Szenario aber unbrauchbare Eigenschaft, dass deren Passwörter vom ADDS per Default nach 30 Tagen automatisch erneuert werden. Dieses Verhalten musst du daher abstellen, was du z. B. mit Hilfe eines Gruppenrichtlinienobjektes machen kannst.

Dazu erstellst du zunächst z. B. im Server-Manager eine neue OU, die stellvertretend für all Computerkonten genutzt wird, bei denen das Passwort nicht ablaufen soll. Diese nimmt später das Computerkonto deines Speicherkontos auf: Du benötigst übrigens für später den „DistingusihedName“ dieser OU, wie z. B. „OU=azure-storage,DC=drilling-it,DC=lan“ . Diesen findest du im Reiter „Attribute Editor“, wenn du die erweiterte Ansicht aktivierst.

Zum hybriden Anbinden deines Storage-Accounts für FSLogix an ADDS stellt Microsoft, bzw. das AVD-Team ein passendes Powershell-Modul auf Github https://github.com/Azure-Samples/azure-files-samples/releases zur Verfügung.

Der Storage Account wird im ADDS anschließend als Computerkonto repräsentiert. Nun kannst du die Windows-seitige automatische Kennwortänderung alle 30 Tage für Computerkonten deaktivieren. Sofern du diese nicht manuell per Powershell oder über einen Zeitplan verwalten möchtest, bietet sich hier das dauerhafte Deaktivieren über einen Gruppenrichtlinieneinstellung an. Ein Sicherheitsproblem besteht hier nur bedingt, bzw. gar nicht, da es sich um ein einzelnen Computerkonto geht und zu keinem Zeitpunkt irgendeine Möglichkeit zur Passworteingabe besteht. Erstelle dazu ein passenden Gruppenrichtlinienobjekt.

Der Einfachheit halber verwendest du dafür einfach den gleichen Namen, wie für die oben erstellte OU, hier „azure storage“, suchst im Computer-Zweig nach der Einstellung „Policy / Windows Settings / Security Settings / Local Policies / Security Options / Domain Member: Maximum account password age“ und ersetzt den Standardwert von 30 durch „0“, womit die automatische Kennwortänderung deaktiviert wird.

Anschließend verknüpfst du dein neues Gruppenrichtlinienobjekt mit der neu erstellten OU.

Nun kannst du deinen Storage-Account für FSLogix anlegen. Die notwenigen Schritte haben wir bereits mehrfach erläutert. Erstelle darin eine Azure-Dateifreigabe gemäß deiner Leistungsanforderungen. Wir verwenden ein Standard-Speicherkonto und eine Dateifreigabe vom Typ „Transaktion optimiert“. Zur weiteren Verbesserung der Sicherheit kannst du den Zugriff auf das Netzwerk und Subnetz deiner Session-Hosts beschränken. Erledigst du das gleich beim Erstellen des Speicherkontos, wird der erforderliche Dienstendpunkt automatisch erstellt.

Ist das Speicherkonto angelegt, kannst du den hybriden Zugriff mit der identitätsbasierenden Authentifizierung mit Hilfe des o. e. Hybrid-Skriptes konfigurieren. Rufe dazu an deinem Domaincontroller oder einem anderen in die Domäne eingebundenen Server die Powershell im Admin-Modus auf.

Hier installierst du falls noch nicht geschehen zunächst das Azure-Modul (az) für die Powershell mit …

Install-Module -Name Az -Force -AllowClobber -Verbose

… und prüfst bei der Gelegenheit auch gleich, ob die AVD-Module installiert sind mit …..

Get-InstalledModule -Name Az.Desk*

Falls nicht, kannst du das Modul mit

Install-Module -Name Az.DesktopVirtualization

installieren, bzw. mit ….

Update-Module Az.DesktopVirtualization

aktualisieren. Anschließend verbindest du dich mit Azure mittels

Connect-AzAccount

… und verwenden dabei ein Konto mit globalen Administrator-Rechten:

Solltest du in deinem Mandanten über mehrere Azure-Subsciptions verfügen, ermittle mit …

Get-AzContext

Get-AzSubscription

den gewünschten Kontext und wähle die passenden Subscription mit:

Get-AzSubscription -SubscriptionName "Nutzungsbasierte Bezahlung" | Select-AzSubscription

Setze nun noch die Execution-Policy für Powershell-Skripte gemäß deiner Unternehmensrichtlinie z. B. auf unrestricted:

Set-ExecutionPolicy -ExecutionPolicy Unrestricted -Scope CurrentUser

Lege dann den Pfad, in dem du das erwähnte AzureFilesHybrid-Skript heruntergeladen und entpackt hast, als aktuelle Work-Location fest …

Set-Location C:\Users\azureuser\Downloads\AzFilesHybrid

… und führe zunächst das Skript …..

.\CopyToPSPath.ps1

aus, welches u. a. die Pfadvariablen für die Powershell so setzt, dass die im Folgenden zu importierenden Module gefunden werden. Anschließend kannst du das ebenfalls im Ordner enthaltene „AzureFilesHybrid“-Powershell-Modul wie folgt importieren:

Import-Module -Name AzFilesHybrid

Danach musst du die im Folgenden benötigte Variablen setzen und die Inhalte an deine Umgebung anpassen:

$SubscriptionId = "<your-subscription-id-here>"
$ResourceGroupName = "<resource-group-name-here"
$StorageAccountName = "<storage-account-name-here>"

Nun sind alle Vorbereitungen getroffen und du kannst folgendes Commandlet nutzen, um dein Speicherkonto ins ADDS aufzunehmen.

Join-AzStorageAccountForAuth `
        -ResourceGroupName $ResourceGroupName `
        -StorageAccountName $StorageAccountName `
        -DomainAccountType "<ComputerAccount|ServiceLogonAccount>" `
        -OrganizationalUnitDistinguishedName "<ou-distinguishedname-here>"

Beachte dabei den Parameter „-StorageAccountType“, der dir zwei Möglichkeiten bietet: du kannst entweder mit einem so genannten ServiceLogonAccount arbeiten oder wie wir es hier vorbereitet haben, mit einem Computer-Konto im ADDS, welches das Speicherkonto repräsentiert: denke dabei daran, den oben ermittelten Distinguished-Name für die vorbereitete OU anzugeben.

Prüfe anschließend im Werkzeug „Active Directory Benutzer&Computer“, ob das Speicherkonto in die gewünschte OU gejoined wurde:

Du kannst das natürlich alternativ auch direkt in der Powershell überprüfen:

$storageaccount = Get-AzStorageAccount `
        -ResourceGroupName $ResourceGroupName `
        -Name $StorageAccountName
$storageAccount.AzureFilesIdentityBasedAuth.DirectoryServiceOptions
$storageAccount.AzureFilesIdentityBasedAuth.ActiveDirectoryProperties

Der Hybrid-Join ist damit erfolgreich erledigt, zugegebenermaßen mit einigen manuellen Aufwand und unter Zuhilfenahme eines vom Azure-Virtual-Desktop-Teams bereitgestellten Powershell-Moduls. Bedenkt man, dass die Dienste ADDS, Azure und EntraID vom gleichen Hersteller stammen, würde man sich hier für die Zukunft doch etwas mehr Einfachheit wünschen.

Wir benötigen diesen Hybrid-Join zwingend, um den Session-Host letztendlich die Daten, die im Azure-Storage-Account in einem File-Share zur Speicherung von Profilinformationen für FSLogix abgelegt sind, auf sichere Weise (also für jeweiligen Nutzer passend authentifiziert) zugänglich zu machen. Ohne Hybrid-Joind gäbe es faktisch keine Authentifizierungsmöglichkeit für ADDS-Nutzer auf Verzeichnisebene.

Du kannst jetzt im Azure-Portal bei deinem Speicherkonto erkennen, dass die identitätsbasierende Authentifizierung mit ADDS erfolgreich aktiviert wurde.

Azure-Berechtigungen

Ist das erledigt, kannst du die erforderlichen Azure-Berechtigungen (RABC) auf das Speicherkonto auf der Azure-Seite vergeben, wie in Teil 3 und 4 unserer Artikelreihe schon mehrfach beschrieben. Daher fassen wir uns hier kurz, d. h. du vergibst den für AVD vorgesehenen Benutzern Azure-seitig die erforderlichen Berechtigungen auf diesen File-Share im Menü „IAM“. So benötigt der Administrator beispielweise die Rolle „Mitwirkender mit erhöhten Rechten für Speicherdateidaten-SMB-Freigabe“ für das initiale Einrichten und spätere Konfigurieren von FSLogix. Deine AVD-User hingegen benötigen „Mitwirkender für Speicherdateidaten-SMB-Freigabe“.

Um nun den Fileshare initial zur weiteren FSLogix-Konfiguration auf deinen Sessionhosts einbinden zu können, benötigst du zunächst die im Teil 3 erklärte administrative Freigabe mit Hilfe der Speicherkontoschlüssels, weil es zum gegenwärtigen Zeitpunkt ja noch keine Berechtigungen auf den Fileshare gibt: Öffne daher einfach ein Azure-Portal auf dem Sessionhost und nutze die Connect-Funktion des Azure-Portals für diesen Fileshare. Kopiere das generiert Skript und binde den Fileshare auf dem gewünschten Sessionhost ein.

Nun kannst du im Windows Explorer (oder mittels icalcs später auch Skript-basiert) die erforderlichen Berechtigungen setzen: Klicke dazu im Reiter „Security“ der Eigenschaften der eingebundenen Freigabe auf die Schaltfläche „Advanced“. Hier entfernst du zunächst die Einträge für „Authenticated Users“ und „Users“. Ferner erhält „CREATOR OWNER“ nur noch das Recht „Modify“ anstelle von „Full Control“.

Anschließend fügst du die synchronisierte Gruppe der gewünschten AVD-Benutzer aus deinem ADDS hinzu mit der Berechtigung „Modify“ für „This folder, subfolder and files“:

Die Freigabeberechtigungen sind damit erledigt. Jetzt kannst du auf der momentan administrativ eingebundenen Freigabe den Ordner für die FSLogix-Profile anlegen. Auf diesem vergibst du auf die gleiche Art die folgenden Berechtigungen. Dabei ist es zunächst einmal wichtig, die Vererbung mit „Disable inheritance“ zu deaktivieren.

Was hast du damit erreicht? Meldet sich ein berechtigter AVD-Benutzer initial am Sessionhost an, wird sein Profil initial auf diesem Share angelegt, womit der Nutzer auch Besitzer von diesem Pfad auf dem Share ist. Mit der nun auf die gezeigte Art- und Weise gesetzten Berechtigung werden etwaige existierende Berechtigungen anderer Benutzer nicht auf dieses Objekt übertragen, sodass der Profil-Ersteller (nämlich der Nutzer selbst) als Einziger (neben dem Administrator) die Berechtigung an diesem Objekt hat. Um Missverständnisse vorzubeugen: „Funktionieren“ würde FSLogix auch ohne diese granulare Vorgehensweise, allerdings unter Inkaufnahme eines bestehenden Risikos, dass Unbefugte Zugriff auf persönliche Profile anderer Benutzer erlangen könnten. Die weitere Vorgehensweise zur Installation und Inbetriebnahme von FSLogix funktioniert genauso, wie in den bisherigen Beiträgen gezeigt.