Ein nicht sauber gehärtetes Active Directory stellt heute eine leichte Beute für Angreifer dar. Um einen Angriff zu starten, wird zunächst Zugriff auf ein internes System benötigt. Dies kann z.B. über eine Verbindung mit einem öffentlich erreichbaren Terminal Server unter Verwendung von kompromittierten Benutzeranmeldedaten erfolgen. Angreifer lassen sich aber auch gerne in das Unternehmensnetz einladen, indem z.B. ein Anwender einen bösartigen E-Mail-Anhang öffnet und damit Schadcode innerhalb seiner Benutzersitzung ausführt. Mittlerweile laufen Angriffsverfahren teils vollautomatisiert ab. Damit schaffen es Angreifer oft, innerhalb kürzester Zeit bis auf die Domänencontroller vorzudringen und die komplette Domäne zu übernehmen. Danach hat der Angreifer die freie Wahl: Spionage, Daten vernichten, Daten verschlüsseln und Lösegeld erpressen, etc.

Um Angreifern das Ausbreiten im internen Netz („Lateral Movement“) und die Erlangung höher privilegierter Rechte („Privilege Escalation“) zu erschweren, hat Microsoft vor vielen Jahren ein Tiering Modell für das Active Directory entwickelt. Mit Einführung der Cloud Dienste wurde dieses Modell um entsprechende Cloud Elemente erweitert und in „Enterprise Access Model“ umbenannt (siehe Securing privileged access Enterprise access model | Microsoft Learn). Wer sich mit dem Thema schon mal beschäftigt hat, wurde wahrscheinlich von der Komplexität erschlagen und weiß nun nicht, wie das Thema angegangen werden kann und womit idealerweise anzufangen ist.

Wogegen schützen logische Schichten im AD?

Die saubere Trennung von logischen Schichten im AD erschwert einem Angreifer die Ausbreitung und die Erlangung höherer Rechte in der Konsolidierungsphase.

(Ablaufdiagramm aus: https://www.heise.de/news/Cybercrime-und-staatlichen-Hacker-Neue-Tools-und-Techniken-7324572.html?wt_mc=nl.red.ho.ho-nl-daily.2022-11-15.link.link)

Eine Aufteilung der Systeme in drei Schichten sieht üblicherweise so aus:

• Tier 2: Workstations
• Tier 1: Applikations-Server
• Tier 0: Infrastruktur (z.B. Domain Controller, Storage, Virtualisierer, etc.)

Wenn ein Angreifer einmal in einer User Session auf einem Tier 1 Device Fuß gefasst hat, wäre ein beispielhafter weiterer Ablauf wie folgt denkbar. Dieses Beispiel ist zwar aus Sicht eines Angreifers sicherlich der „Best Case“, allerdings durchaus nicht praxisfern:

1. Der Angreifer versucht, aus der User Session heraus das komplette System zu übernehmen.
   1. Der kompromittierte User ist lokaler Admin.
      1. Fertig – System übernommen!
   1. Der kompromittierte User ist kein lokaler Admin.
      1. Probleme in der User Session provozieren, damit der User den Helpdesk anruft und um Hilfe bittet.
      1. Der Helpdesk tippt innerhalb der User Session im Rahmen einer Remote Support Aktion die Credentials seines Helpdesk Accounts ein (z.B. via „run as“).
      1. Diese Credentials werden über einen vom Angreifer etablierten Key Logger abgegriffen.
      1. Fertig – System übernommen!
2. Der Angreifer versucht, sich auf andere Systeme (Workstations) auszubreiten.
   1. Das lokale Admin-Kennwort ist auf allen Workstations identisch.
      1. Fertig – Alle Workstations übernommen!
      1. Tier 2 verloren!
3. Der Angreifer möchte nun in den Besitz von höherwertigen Credentials kommen. Dafür reicht es, wenn sich ein solcher Account an einem kompromittierten Gerät anmeldet.
   1. Worst Case: Ein IT Mitarbeiter
      1. meldet sich mit einem Domain Admin Account an einem Client an, oder
      1. nutzt Domain Admin Credentials mittels „run as“, um aus seiner User Session heraus ein Admin Tool zu starten, oder
      1. meldet sich aus seiner User Session heraus via RDP-Client auf einem Drittsystem an und verwendet dabei Domain Admin Credentials,
      1. oder ähnliches…
   1. Ganz fertig – Domäne komplett übernommen!

Mit Tier 2 (Workstation Level) starten!

Da die überwiegende Mehrzahl der Angriffe über besuchte Web-Sites oder bösartige E-Mail-Anhänge erfolgen, sind die Workstations das größte Einfallstor und somit als erste abzusichern.

Das o.g. Beispiel zeigt recht deutlich, welches die wichtigsten Maßnahmen sind, um den Workstation Level (Tier 2) so abzusichern, dass Lateral Movement und Privilege Escalation erschwert werden.

1. Ein automatisiertes Management der lokalen Administrator-Kennwörter auf den Workstations erschwert Lateral Movement (z.B. via LAPS, das mit dem April Update 2023 fest in das Betriebssystem wandert und nun auch Cloud-Umgebungen unterstützt, siehe: By popular demand: Windows LAPS available now! - Microsoft Community Hub)
   1. Individuelles Admin-Kennwort auf jedem Gerät.
   1. Admin-Kennwort wird regelmäßig automatisch geändert
2. Entfernen weiterer Accounts und Gruppen aus der lokalen Gruppe der Administratoren auf allen Workstations (soweit möglich) erschwert Lateral Movement.
3. Konfiguration von Logon Restrictions für Mitglieder privilegierter Gruppen erschwert Privilege Escalation. Somit können sich z.B. Domain Admins nicht mehr an Workstations anmelden.

Diese Maßnahmen sind relativ einfach und mit vertretbarem Aufwand durchführbar. Klar ist allerdings auch, dass in der Regel die bestehenden Workstation Support Prozesse nach der Umsetzung nicht mehr wie gewohnt funktionieren und entsprechend anzupassen sind.

Zusätzliche Maßnahmen sind innerhalb der Active Directory Struktur durchzuführen, um ggf. existierende „indirekte Kontrollpfade“ zu eliminieren. Beispielsweise würde eine indirekte Kontrolle über die Gruppe der Domain Admins gegeben sein, wenn folgendes Szenario zutrifft:

• Es gibt eine OU im Active Directory, in der Standardbenutzerkonten einsortiert werden.
• Für diese OU wurde eine Delegierung konfiguriert, dass der Helpdesk Benutzerkennwörter für Userobjekte unterhalb dieser OU zurücksetzen kann.
• Ein Userobjekt unterhalb dieser OU ist Mitglied in der Gruppe Domain Admins.

Damit kann sich jeder Helpdesk-Mitarbeiter jederzeit einen Domain Admin Account verschaffen, indem er das Kennwort für das entsprechende User Objekt unterhalb der o.g. OU zurücksetzt und sich anschließend mit diesem Konto anmeldet.

Glücklicherweise gibt es Tools, die solche indirekten Kontrollpfade automatisch erkennen und dokumentieren können, so dass auch deren Beseitigung recht schnell und einfach erfolgen kann.

Damit ist die Separierung von Tier 2 (Workstations) in Kombination mit der notwendigen Active Directory Hygiene als absolutes Pflichtprogramm zu bezeichnen.

Wie weit muss ich gehen?

Die Aufwände für die Konzipierung, Implementierung und den Betrieb steigen mit jedem höheren TIER exponentiell an. Die Separierung von Tier 1 (Applikationsserver) ist bereits deutlich aufwändiger als für Tier 2, da hier in der Regel jeder Server / Service einzeln zu betrachten ist. Falls dann auch noch die Separierung von Tier 0 (Infrastruktur) erfolgen soll, müssen etliche Basis-Infrastruktur-Komponenten doppelt und getrennt nach Tier 1 und Tier 0 aufgebaut werden (Storage, Virtualisierung, Backup, etc.). Anders ist nicht zu verhindern, dass z.B. ein Tier 1 Virtualisierungsadmin Vollzugriff auf die Domäne erlangt, weil die Domain Controller mit auf dem Tier 1 Virtualisierer laufen.

Nachdem die Tier 2 Separierung als „Pflichtprogramm“ eingestuft ist, könnte man Tier 1 als „Empfehlung“ und Tier 0 als „Kür“ bezeichnen. Für wen allerdings welche Ausbaustufe zu empfehlen ist, hängt nicht nur von dem vorhandenen Etat ab, sondern auch von der eigenen Einschätzung, wie lohnenswert das eigene Unternehmen für Angreifer sein könnte. Soll heißen: Auch wenn unbegrenzte Geldmittel zur Verfügung stehen, möchte ich nicht jedem Unternehmen die Vollausbaustufe empfehlen. Denn mit steigender Ausbaustufe macht man es nicht nur den Angreifern bei einem Übernahmeversuch schwerer, sondern auch der eigenen IT – und zwar Tag für Tag. Unternehmen, die nach einem Erfolgreichen Hackerangriff von den Microsoft Consulting Services die große Blaupause verpasst bekommen haben, können ein Lied davon singen.

Die Zeit der klassischen Hacker ist vorbei, in der ein pickelgesichtiger, übergewichtiger Sonderling mit Kapuzenpulli in einem dunklen Keller zwischen leeren Pizzakartons an seinem Computer sitzt und manuell das Kennwort seines ausgewählten Opfers rät. Heute sind das hochprofessionelle und bestens organisierte Unternehmen, die Standardangriffe mit einem hohen Automatisierungsgrad gegen eine breite Masse von Unternehmen fahren. Dafür müssen diese Hacker-Organisationen viel Geld investieren, so dass sie einen hohen Wirkungsgrad benötigen, um den gewünschten Gewinn zu erzielen. Wenn es bei einem Unternehmen nicht auf Anhieb klappt, werden zunächst die anderen „Kunden“ in der Queue abgearbeitet. Damit ist es für Sie essenziell wichtig, besser aufgestellt zu sein als durchschnittlich üblich („Ich muss nicht schneller laufen als der Bär – ich muss nur schneller laufen als du“).

Also haben Sie mit der Implementierung von Tier 2 und des AD Hardenings schon den wichtigsten ersten Schritt getan, um vielen anderen Unternehmen das nötige Etwas vorauszuhaben. Als wie wertvoll die jeweiligen Kronjuwelen des Unternehmens einzustufen sind und ob es sich für Hacker lohnt, entsprechend mehr Aufwand zu spendieren, um die ersten Hürden zu überwinden, müssen Sie selbst beurteilen und ggf. weitere Hürden aufbauen.

Fazit

Beim Aufbau eines TIER Modells gibt es kein „ganz oder gar nicht“. Jeder Teilschritt ist ein Schritt in die richtige Richtung zur Etablierung einer höheren Sicherheitsstufe, um das Risiko von erfolgreichen Angriffen immer weiter zu senken.

Aber egal, wie weit Sie gehen wollen: Bitte seien Sie sich bewusst, dass es nicht ausreicht, ein Konzept zu erstellen und umzusetzen – man muss sich auch auf Dauer daran halten. Wenn eine Security Policy definiert wird, muss sie für alle gelten. Es gibt dann keine Ausnahmen – und schon gar nicht für „VIP-User“, die (bzw. deren Daten) ein ganz besonders lohnendes Angriffsziel sind. Das muss bereits in der Designphase berücksichtigt und mit dem Management abgestimmt werden. Im Betrieb muss die IT entsprechende Rückendeckung durch das Management erhalten, um sich gegen Sonderwünsche wehren zu können, die oft eine ganze Reihe von mühsam etablierten Maßnahmen aushebeln können. Es ist besser, nur Teile des TIER Modells zu implementieren und sich strikt an die bis dorthin erforderlichen Regeln zu halten, als ein mühsam aufgebautes Gesamtwerk durch „Praktikabilitäts-Shortcuts“ ad absurdum zu führen.

Hallo Allerseits,

gefühlt jeden Monat kommt ein neues Microsoft Defender Produkt auf den Markt. Da fällt es mitunter schwer, dieses technisch und fachlich zuordnen bzw. einschätzen zu können. Darüber hinaus kommt dann noch die Komplexität des Lizenz-Dschungels hinzu. In Sachen Lizenzen halte ich mich raus, hier müsst ihr die Machete selbst schärfen und euch durchkämpfen. Eine grobe Orientierung zum Lizenzthema beim Microsoft Defender Vulnerability Management (MDVM) findet ihr hier: Compare Microsoft Defender Vulnerability Management plans and capabilities | Microsoft Learn

Intro

Kommen wir zu den technischen Features. Das Microsoft 365 Defender Portal (https://security.microsoft.com/) ist die zentrale Security-Instanz für Unternehmen, welche Produkte aus dem Microsoft Defender Kosmos einsetzen. In diesem Portal werden die Daten von vielen Defender-Produkten angezeigt und miteinander verzahnt (MDI, MDE, MDO, MDCA, MDAV, um nur einige Produkt-Abkürzungen zu nennen). Früher mussten wir dazu viele verschiedene Portale übereinanderlegen und gegen das Licht halten, um die Zusammenhänge verschiedener Defender Produkte zu erahnen, heute wird dies zum Glück korreliert angeboten. Die jetzige Herausforderung liegt allerdings darin, in der schieren Menge an Informationen nicht unterzugehen.

Microsoft Defender Vulnerability Management (MDVM) ist eine Erweiterung für Microsoft Defender for Endpoint (MDE). Die neuen MDVM-Optionen integrierten sich in die altbekannte MDE-Optik. Die integrierte Verzahnung wird auch in der Lizenz-Vergleichsliste eindeutig (siehe Link). Ist keine Lizenz vorhanden, dann bemerkt man die nicht vorhandenen MDVM Features bei Betrachtung eines Computers (Registerkarte „Advanced features“) im „Device Inventory“:

Ist die Lizenz hingegen vorhanden, dann kommen verschiedene neue Features hinzu, welche ich hier kurz vorstellen mag. Zwingende Voraussetzung für MDVM ist das Onboarding der Endpoints (Clients + Server) in MDE.

MDVM Features

1. Hardware + Firmwarebewertung
   Verschiedene Hardware-Faktoren (Laptop-, Desktop-, Servermodell-, Prozessor- und BIOS-Bestand) werden eingesammelt und seitens MDVM bewertet. Der Bestand und die Bewertungen können dann im Security Portal unter „Endpoints -> Inventories“ eingesehen werden. Durch die Bewertungen können Empfehlungen abgeleitet werden, wie z.B. Firmware- oder Treiberupdates einzuleiten. Die Notwendigkeit BIOS Firmware Updates durchzuführen, wurde uns in jüngster Vergangenheit wieder eindrucksvoll klargemacht.

2. Bewertung von Browsererweiterungen
Browsererweiterungen können ohne administrativen Kontext installiert werden. Sollte die Installation von Browsererweiterungen nicht zentral unterbunden werden, dann können Endanwender aus einem riesigen Portfolio an Erweiterungen frei wählen. Leider gibt es in diesem Umfeld auch ein paar schwarze Schafe. Hier hilft die Bewertung seitens MDVM, welches die Browsererweiterungen nach Kritikalität bewertet. Die zentrale Steuerung der erwünschten oder nicht erwünschten Browsererweiterungen ist somit die logische Konsequenz aus dieser Bewertung.

3. Bewertung durch Security Baselines
Security Baselines werden dazu verwendet, um den eigenen Gerätezoo mit branchenspezifischen Sicherheitsvergleichstests abzugleichen. Hierzu werden sogenannte Baselines verwendet, welche mit den Unternehmensrechnern (Clients + Server) verglichen werden. Abweichungen von diesen Baselines werden dann durch einen Konformitätsstatus dargestellt. Diese Baseline Bewertungen sind eine spannende Angelegenheit, wichtig sind natürlich die daraus resultierenden Umsetzungen von aufgezeigten Verbesserungsmöglichkeiten.

4. Bewertung des Zertifikatsbestands
Durch die Inventur des im Unternehmen vorhandenen Zertifikatsbestands können abgelaufene oder bald ablaufende Zertifikate identifiziert werden. Darüber hinaus können Sicherheitsrisiken z.B. aufgrund schwacher Signaturalgorithmen erkannt werden. Der daraus entstehende Arbeitsablauf ist aus meiner Sicht nicht zu unterschätzen, da hierfür gegebenenfalls verschiedene Zertifikatsspeicher bereinigt und erneuert werden müssen.

5. Anfällige Anwendungen blockieren
Das Blocken von anfälligen Anwendungen kann als Sofortmaßnahme verstanden werden. Damit kann den zuständigen Teams Zeit gegeben werden, potenziell anfällige Anwendungen zu patchen oder zu ersetzen. Hierzu wird eine Wartungsanforderung im Security Portal erstellt, welche dann z.B. die betroffene Anwendung auf eine Block-Liste setzt. Sobald die Wartungsarbeiten dann erledigt worden sind, kann die Anwendung wieder freigegeben werden.

6. Netzwerkfreigabeanalyse
Mit der Netzwerkfreigabeanalyse können sicherheitsanfällige Netzwerkfreigaben einfach identifiziert werden. Allein der Wildwuchs an Netzwerkfreigaben in größeren Netzwerkumgebungen ist häufig schon katastrophal. Wenn diese dann auch noch von Haus aus Schwachstellen aufweisen, ist dies ein gefundenes Fressen für Angreifer. Klasse sind die Sicherheitsempfehlungen, welche die Korrekturmaßnahmen direkt mitliefern.

7. Authentifizierter Scan für Windows
Ähnlich wie bei Defender for IoT oder der Netzwerkgeräteerkennung kommt hier ein zu installierender Scanner zum Einsatz. Dieser kann auf speziell dafür auserwählten Clients oder Servern installiert werden. Dieser Scanner wird dann dazu verwendet, um ungemanagte Geräte zu scannen und auf Softwarerisiken zu überprüfen. Die bessere Idee wäre natürlich, die betroffenen Geräte in einen gemanagten Zustand zu bringen.

Fazit

MDVM bringt aus meiner Sicht ein paar interessante Betrachtungen mit. Meine persönlichen Highlights sind die Kritikalitäts-Bewertungen der Browsererweiterungen, sowie der eingesetzten Firmwareversionen. Für sehr hilfreich halte ich auch die Netzwerkfreigabeanalyse, die wertvolle Ergebnisse und die dazugehörigen Korrekturmaßnahmen liefert.

Machen wir uns aber nichts vor: die Informationsmenge wird durch die MDVM Erweiterung noch weiter erhöht. Wer mit den Microsoft 365 Defender Produkten arbeiten will, der sollte gut organisiert sein, um den Benefit der aufgearbeiteten Daten auch gewinnbringend umsetzen zu können.

Die IT-Security-Szene ist gerade in den letzten Jahren auf Grund diverser Umstände sehr stark in Bewegung. Microsoft beweist durch die stetige Weiterentwicklung seiner Defender Produkte, hier durchaus mithalten zu können.

Produktwebseite: https://www.microsoft.com/en-us/security/business/threat-protection/microsoft-defender-vulnerability-management

Wer heutzutage eine IT-Infrastruktur in den eigenen Räumlichkeiten (on-premises) betreibt, wird in den meisten Fällen auf die Virtualisierung setzen. Wenn wir hierbei auf das Microsoft-Produktportfolio blicken, lockt die Virtualisierung mit Hyper-V-Technologie. In vielen Fällen werden dann zur Erhöhung von Redundanz und Verwaltbarkeit Windows Failover Cluster mit Hyper-V eingesetzt.

Bei der Konkurrenz ist zum Beispiel VMware vSphere mit ESXi als Virtualisierer weit verbreitet – ebenfalls meist hochverfügbar ausgelegt (High Availability, HA).

Beim Betrieb von virtuellen Maschinen (VMs) besteht in der Betriebspraxis oftmals ein Interesse daran, Kontrolle darüber zu haben, in welcher Reihenfolge VMs starten (oder "failovern"). Weil es eben oft Abhängigkeiten der VMs untereinander gibt: Die Funktion eines SQL-Datenbank-Servers zum Beispiel hängt von einem betriebsbereiten Domain Controller (DC) ab. Ein Applikationsserver mag wiederum von SQL-Servern abhängen.

Unter Hyper-V gibt es in der grafischen Verwaltungsoberfläche (Failover Cluster Manager, FCM bzw. Hyper-V Manager) ein paar Möglichkeiten, Einfluss auf den Start von VMs bzw. im Falle eines Failovers auf einen anderen Knoten (Node) im Cluster zu nehmen.

Diese "Start Priority" bietet aber in der GUI nur recht wenige Optionen zur Ausgestaltung. Entweder stuft man die Start-Prio der VM als High, Medium oder Low ein oder man verzichtet auf den automatischen Start der VM gänzlich. Über die PowerShell kann man zwar hier die Abstufung der Priorität auch granularer wählen – aber welche VMs nun Voraussetzung für den erfolgreichen Betrieb anderer VMs sind, lässt sich auch damit bei mehr als einer Hand voll VMs kaum sinnvoll regeln.

Bei der VMware-Konkurrenz bieten sich in der entsprechenden GUI (vCenter) da mehr Möglichkeiten, um auch Abhängigkeiten von VMs untereinander zu modellieren.

Selbst in den neueren Versionen des Windows Servers bleiben den Administratoren in der GUI solcherlei weitergehende Eingriffsmöglichkeiten verwehrt. Und neidisch schielt man auf die Konkurrenz. Es gibt aber durchaus eine – u. a. durch Nicht-Sichtbarkeit in der GUI wenig beachtete – Möglichkeit, hier präzisere Stellschrauben zu benutzen: Schon seit Windows Server 2016 gibt die PowerShell da ein logisches Konstrukt her, mit dem man dem Hyper-V-Cluster in Bezug auf diese Modellierung auf die Sprünge helfen kann. Das Stichwort heißt hier: ClusterGroupSet.

Die Dokumentation dazu ist dürftig, die Logik etwas sperrig und die Nomenklatur eigenwillig. Wenn man die vor allem zu Beginn so störenden Hürden aber überwindet, hat man durchaus ein nützliches Werkzeug an der Hand.

Wie funktioniert das also nun? Die Idee basiert auf den ClusterGroupSets und der ClusterGroupSetDependency. Im Kommandozeilen-Cluster-Sprech sind VMs (bzw. das, was VMs im Cluster ausmacht) eigentlich ClusterGroups. Da hier der Begriff der Group im Cluster also schon reserviert ist, heißen die Gruppierungen, die wir hier und jetzt betrachten eben ClusterGroupSets. Diese Sets beinhalten die ClusterGroups (die VMs) als Mitglieder. So gesehen steckt man nun also VMs in diese Sets. Mit den zugehörigen Dependencies lassen sich nun die Abhängigkeiten abbilden. Dazu gibt man bei der ClusterGroupSetDependency für ein ClusterGroupSet einen "Provider" an. Mit Provider ist hier konkret dasjenige ClusterGroupSet gemeint, von dem das mittels Provider konfigurierte nun denn abhängen soll. Am besten ein Beispiel: Sieben VMs, nämlich drei DCs (DC01 bis DC03), zwei SQL-Server (SQL01, SQL02), zwei AppServer (AppSrv01 und AppSrv02). Die beiden App-Server hängen von den SQL-Server-VMs ab und diese wiederum von mindestens zwei der drei DC-VMs.

Im Bild die zugehörigen PowerShell-Befehle:

Wir erstellen zuerst die "Gruppierungen", also die ClusterGroupSets, wie zum Beispiel die DomainControllers. Dann stecken wir die VMs, repräsentiert durch die "Group", in das jeweils passende Set hinein.

Zuletzt geben wir an, dass das Set für die AppServers von dem Set für die SQLServers abhängt und dieses wiederum von den DomainControllers. Die Abhängigkeiten und die logische Verschachtelung sind damit gebaut.

Nun noch ein paar Details: StartupDelayTrigger und StartupCount. Die Option "Delay" beim Trigger bedeutet, dass auf den Heartbeat gewartet wird – und dann erst die Zeit für den Delay (StartupDelay) zum Start abhängiger Sets losläuft. Die Option "online" beim Trigger bedeutet, dass es bereits dann weitergehen darf, wenn die VM-Rollen überhaupt erfolgreich gestartet wurden, aber ebenfalls erst nach Ablauf eines StartupDelay.  Beim ein oder anderen mag das nicht dem ersten Instinkt zur Bedeutung der Optionen entsprechen.
Die Anzahl beim StartupCount gibt für das Set an, wie viele der enthaltenen VMs zur Erfüllung der Regeln laufen müssen.

Hier im Beispiel also sollen zwei der drei DCs laufen, um als ausreichend vollständig laufendes Set zu gelten. Es empfiehlt sich, zumindest für das letzte Set in der Kette der Abhängigkeiten diesen Wert auf die Anzahl der enthaltenen VMs zu setzen, um das recht eigenwillige Verhalten beim Starten der zweiten AppServers-VM zu vermeiden. Die genaue Logik dahinter wird bestimmt wohlbegründbar sein, scheint aber wohl anfangs schwer zu durchschauen.

Für eigene Tests sei empfohlen, auf dem Beispiel aufzubauen.

Nun das Resultat im einfachsten Szenario also im Bild: Wenn alles ausgeschaltet ist und wir schalten über den FCM eine der AppServers-VMs (z. B. AppSrv01) ein, dann startet diese zunächst nicht direkt, sondern wirft zuerst das Set am Ende der Abhängigkeitskette mit den DCs an. Noch laufen ja nicht ausreichend viele.  Da das ganze Set gestartet wird, werden kurz danach im Allgemeinen also drei DCs laufen. Das sind genug zur Erfüllung der Regeln für dieses Set. Dann starten, nach einem (einstellbaren) Verzug von 20 Sekunden (so der Default für den StartupDelay) auch die SQL-Server-VMs. Wenn beide laufen, darf dann auch der AppSrv01 wirklich starten... so soll es sein.

Fazit:

Microsoft sorgt durch Weglassen eines GUI-Zugriffs und bestenfalls mäßige Dokumentation durchaus selbst dafür, dass die ClusterGroupSets weniger bekannt oder in Vergessenheit geraten sind. Ob das Zeichen für technische Schwierigkeiten MS-seitig bei der Umsetzung sind oder man gar überhaupt auf das Feature setzen sollte, mag sicherlich kontrovers diskutiert werden. Wer auf eine genauere Regelung der Startreihenfolge von VMs im Cluster Wert legt, sollte sich aber ruhig einmal mit den Möglichkeiten rund um dieses Feature durch Testing beschäftigen und entscheiden, ob dies zur produktiven Nutzung in der eigenen Hyper-V-Welt in Frage kommt.

Wer das zum Einsatz vorsieht, sollte aber über etwas Frustrationstoleranz verfügen und die Admin-Kollegen mit einbeziehen: Wenn man VMs im Cluster starten möchte, und stattdessen starten andere (nur manchmal genau diejenige nicht, die man wollte), rauft man sich schnell die Haare, wenn man so gar nicht ahnt, wo das Verhalten herkommt.

Viel Erfolg bei eigenen Experimenten!

In vielen Unternehmen haben sich über die letzten 30 Jahre große Datenmengen (Dateien) auf File-Servern angesammelt. Solche File-Server wurden klassischerweise hoch bewertet, da hier zentral gemeinsame Unternehmensinformationen abgelegt und von vielen Mitarbeitern genutzt wurden. Nach mehreren Jahren Nutzung präsentieren sich File-Server aber wegen gewachsener Freigabe- und Berechtigungsstrukturen und eingeschränkter Mobilität oft eher als Datengräber denn als Informationsquellen. Die Auffindbarkeit von Informationen mit der konventionellen Suche im File-Explorer wirkt stark eingeschränkt oder so langsam, dass sie irgendwann nicht mehr genutzt wird.

Für eine Modernisierung fehlt oft die Idee. Wie sollen große File-Server auf moderne Cloud-Dienste abgebildet werden? Besondere Hemmschuhe sind:

• Inklusiv-Angebote von SharePoint Online reichen meist nicht für alle Dateien aus.
• Im MS365-Umfeld werden heute gänzlich neue Authentifizierungs- und Transportprotokolle genutzt und es ist unklar, wie diese mit klassischen Nutzungsformen in Einklang zu bringen sind.
• Die Menge der Daten steht im Missverhältnis zu den vorhandenen Internet-Bandbreiten.
• Die Kosten für Cloud-Speicher liegen vermeintlich deutlich höher als für lokalen Speicher.

Unternehmen, die ihre File-Server nicht auf Cloud-Techniken hin adaptieren, sind in der Regel in einer endlosen Hybrid-Situation gefangen. Sie müssen zwei Welten parallel betreiben und absichern. Die Effizienzgewinne der SAAS-Strategie in MS365 können so niemals vollständig realisiert werden.

SharePoint Online oder Azure Files?

Im MS365-Kosmos steht nun neben SharePoint Online als modernem Dokumenten- und Informationsspeicher auch Azure Files als Cloud-basierter File-Service zur Verfügung. Die beiden Lösungen kommen, wenn sie als File-Services genutzt werden, jedoch mit recht unterschiedlichen Vor- und Nachteilen daher:

Im Vergleich der beiden Varianten kann erkannt werden, dass mit SharePoint Online das modernere Werkzeug für die Dateiverwaltung bereitgestellt wird. Insbesondere die Informationssuche und die Mobilität sind wichtige Pluspunkte. Aktiv genutzte Office-Daten sind hier sicherlich optimal aufgehoben.

Aber SharePoint Online ist leider nicht die Antwort auf alle Fragen zur Ablösung von File-Services durch Cloud-Angebote. Azure Files stellt hier eine zusätzliche Microsoft-Option für den Übergang in die Cloud dar, mit der viele Sondernutzungsformen abgedeckt werden können:

Fazit

Viele Unternehmen besitzen „riesige“ File-Server, die einen Übergang von „alt“ (Active Directory) auf „neu“ (Azure AD) maßgeblich behindern. Für große File-Server fehlt eine Idee für deren Umsetzung auf Cloud-Lösungen. Mit SharePoint Online und Azure Files stehen zwei recht komplementäre Lösungsoptionen für File-Services in der Microsoft-Cloud zur Verfügung. Es wird erwartet, dass durch diese komplementären Ansätze für einen Großteil der Nutzer und Nutzungsformen eine Umstellung auf Cloud-Lösungen machbar ist. Daten sollten entsprechend SharePoint Online und Azure Files aufgeteilt und den Nutzern damit effizient online zur Verfügung gestellt werden.

Also: Ran ans Werk und raus aus der Hybrid-Schleife! Internet-Bandbreite wird immer günstiger und Lösungsoptionen sind vorhanden. Unternehmen, die MS365-Services nutzen, sollten versuchen, ihre File-Server mittelfristig und sukzessiv auf MS365-Dienste abzubilden.

Arbeiten von überall mit Azure Virtual Desktop

Immer mehr Unternehmen nutzen Remote Desktop-Umgebungen, um ihren Mitarbeitern standortunabhängiges, komfortables und performantes Arbeiten zu ermöglichen. Solche Lösungen bieten vor allem den Vorteil, dass die Geräte der Mitarbeiter günstig und leicht auszutauschen sind. Diese Thin-Clients minimieren den Verwaltungsaufwand, da alle wichtigen Daten und Anwendungen auf den zentral Session-Hosts verwaltet werden. Diese Architektur schützt vor Datenverlust, weil die Dokumente, die in der Cloud liegen, von dort automatisch und redundant gesichert werden können.

Eine cloud-basierte Variante dieser Remote Desktop-Umgebungen ist Azure Virtual Desktop (AVD) von Microsoft. Durch den großen Funktionsumfang und die Einstellungsmöglichkeiten ist die Konfiguration einer AVD-Umgebung nicht trivial. Deshalb wollen wir im Folgenden zeigen, worauf Sie bei der Erstellung und Verwendung einer AVD-Umgebung achten sollten.

Warum Azure Virtual Desktop?

Mit AVD bietet Microsoft eine weitaus flexiblere Remote-Desktop-Lösung als Windows 365, Citrix oder VMware. Die Flexibilität besteht insbesondere in einer genauen Anpassbarkeit der Server, den sogenannten Session Hosts, an die Bedürfnisse der Nutzer. Im Gegensatz zu Microsofts zweiter virtual Desktop Lösung, Windows 365, bei der nur eine eingeschränkte Auswahl an VM-Konfigurationen zur Verfügung steht, kann bei AVD fast jede Azure VM-Konfiguration ausgewählt werden. So können, laut Microsoft, Rechner mit besonders hohem Arbeitsspeicher oder einer leistungsfähigen Grafikkarte für CAD- und Videoschnitt bereitgestellt werden. Es können auch die Hardwarekosten von Thin-Clients reduziert werden, da alle rechenintensiven Prozesse von den Session-Hosts übernommen werden.

AVD bietet die Möglichkeit, entweder einen kompletten virtuellen Desktop oder nur einzelne Applikationen bereit zu stellen. Das Verbindungs-, Lasten- und Speicherverwaltung wird komplett von AVD übernommen. Des Weiteren gibt es beispielsweise die Option, zwischen verschiedenen Algorithmen zum Lastenausgleich zu wählen.

Folgendes Schaubild erläutert den kompletten Aufbau und Verwaltungsbereiche einer AVD-Umgebung.

Eine weitere Stärke von AVD ist die optionale Multisessionskalierung. Mehrere Nutzer können sich einen Host teilen, sodass bereits wenige leistungsstarke Hosts ausreichen, um vielen Benutzern die Arbeit von überall zu ermöglichen. Zur Optimierung der Kosten können weitere Hosts, je nach Bedarf und Auslastung, automatisiert ein- und ausgeschaltet werden.

Ein solcher AVD-Skalierungsplan ist in vier Phasen unterteilt: Ramp-up, Peak hours, Ramp-down und Off-Peak hours. Diese Phasen werden der obigen Reihenfolge nach durchlaufen und es kann eingestellt werden, zu welchen Uhrzeiten in die nächste Phase gewechselt werden soll. Die Ramp-up Phase dient dazu, zusätzliche Hosts hochzufahren, um direkt ausreichend viele Sessions, ohne Wartezeit für die User, während der Peak hours bereitstehen. Während des Ramp-downs wird die Anzahl der aktiven Session-Hosts sukzessive reduziert. Hierbei kann ausgewählt werden, ob die User zwangsweise ausgeloggt werden oder nur Hosts ohne aktive Sessions heruntergefahren werden. Während der Off-Peak Hours stehen keine oder nur ein Mindestmaß an Hosts zur Verfügung, sodass Kosten eingespart werden können. Die Skalierung erfolgt in allen vier Phasen immer anhand der prozentualen CPU-Auslastung der Session-Hosts. Die Schwelle lässt sich dabei individuell festlegen, allerdings ist die Schwelle bei Ram-up und Peak hours bzw. bei Ramp-down und Off-Peak hours immer gleich.

Bei dieser Skalierungsmethode muss vorher abgeschätzt werden, wie viele Hosts vorhanden sein müssen, da durch den automatisierten Skalierungsplan keine neuen Session-Hosts erstellt werden können. Sind also alle vorher erstellten Maschinen voll ausgelastet, werden keine neuen Verbindungen mehr zugelassen. Allerdings können nachträglich manuell weitere Session-Hosts hinzugefügt werden.

Erstellen eines AVD-Hostpools

Zum Bereitstellen einer AVD-Umgebung muss zuerst ein Host-Pool und ein Workspace erstellt werden. Beide können mit demselben Einrichtungsassistenten im Azure Portal konfiguriert werden. Bevor der Assistent gestartet wird, müssen, falls nicht vorhanden, eine Ressourcengruppe und ein virtuelles Netzwerk erstellt werden, da dies im Assistenten nicht möglich ist. Um den Host-Pool und einen Workspace zu erstellen, wird einfach „Create Hostpool“ im AVD-Bereich ausgewählt. Neben den üblichen Einstellungen wie Azure Region Name und Resource Group muss entschieden werden, ob die Session-Hosts von mehreren Usern (Multisession) oder nur von einem Nutzer verwendet werden sollen. Bei der multisession Nutzung kann des Weiteren der Loadbalancing-Algorithmus und die maximale Anzahl an Sessions eingestellt werden.

Als Nächstes werden die Session-Hosts erstellt. Dies läuft fast genauso ab, wie bei normalen Azure VMs. Allerdings wird hier zusätzlich die Anzahl und ein Namenspräfix angegeben, sodass mehrere gleiche VMs mit durchnummerierten Namen erstellt werden können. Die Session-Hosts können direkt ins (Azure) Active Directory eingebucht werden und im Falle des Azure Active Directory optional auch direkt in Intune eingebucht werden. Damit ist eine nachträgliche zentralisierte Verwaltung der Session-Hosts möglich.

Zuletzt kann noch eine standard Desktop App Group zu einem Workspace hinzugefügt werden und, wenn noch keiner existiert, dieser auch erstellt werden. In App Groups werden User und Gruppen zusammengefasst, die Zugriff auf bestimmte AVD-Applications wie z.B. den AVD-Desktop haben. (Diese User müssen zusätzlich die Virtual Machine User Login Rolle auf den jeweiligen Session Hosts zugewiesen bekommen, da sonst der Zugriff verweigert wird).

Wenn alles konfiguriert ist, kann der Hostpool erstellt werden. Dies dauert in der Regel ca. 20 Minuten.
In dieser Standardkonfiguration können nur Clients eine Verbindung über die Remote-Desktop-App aufbauen, die in derselben Azure AD-Domain wie der Host-Pool sind. Ist dies nicht der Fall oder soll die Web-App benutzt werden, muss in der RDP-Konfiguration des Hostpools „targetisaadjoined:i:1“ als „Ausschalter“ angegeben werden. Dieser Zusatz ermöglicht Verbindungen von beliebigen Geräten und stellt daher ein besonderes Sicherheitsrisiko dar. Deshalb sollte, wenn diese Variante genutzt wird, zusätzlich die MFA-Authentifizierung für die jeweiligen Benutzer eingeschaltet werden.

Fazit

AVD ist vor allem für maßgeschneiderte Szenarien eine gute Lösung. Zusätzlich können selbst kleine Remote Desktop-Umgebungen schnell und ohne teure Hardwareanschaffungen erstellt werden. So können auch zeitlich begrenzte Bereitstellungen effizient und vergleichsweise günstig ermöglicht werden. Allerdings kann die Einrichtung, durch die vielen Optionen, leicht komplex werden. An dieser Stelle unterstützen wir Seitens ITERACON gerne.