Angelehnt an mein Veeam Windows Hardening Script gibt es diverse weitere Möglichkeiten, die Sicherheit einzelner Komponenten – somit auch die grundsätzliche Sicherheit – weiter zu erhöhen. Wie bereits in der Vergangenheit angekündigt (u.a. auf dem Veeam User Group Treffen in München im November 2024) möchte ich die Möglichkeit einer Multifaktor-Authentifizierung (MFA) auf Windows-Ebene beleuchten. Hierzu habe ich einige Lab-Tests durchgeführt.
Das Ziel:
Insgesamt möchte ich im ersten Schritt zwei verschiedene Szenarien testen:
- Absicherung von RDP-Anmeldungen per MFA
- Absicherung von lokalen Anmeldungen per MFA
Aus meiner beruflichen Vergangenheit habe ich bereits mit vergleichbaren Szenarien arbeiten dürfen. Kunden haben zu dem Zeitpunkt auf Cisco Duo gesetzt, weil hier ein sehr guter Preis-Leistungsfaktor erzielt werden kann.
Ich möchte an dieser Stelle keine Produktwerbung machen, beschränke mich bei meinen Tests jedoch auf das o.g. Produkt, weil ich bereits operative Erfahrungen mit dem Produkt habe.
Disclaimer:
Wichtig: Wenn die Duo-Applikation auf einem Zielsystem installiert wird und die Konfiguration unvollständig oder nicht korrekt durchgeführt wurde, dann ist ein Zugriff auf das entsprechende System unter Umständen nicht mehr möglich. Ich empfehle jedem Kunden, dieses Szenario vorab in einer Labor-Umgebung gründlich und ausgiebig zu testen, damit es zu keinerlei Beeinträchtigungen innerhalb von Produktivlandschaften kommt!
Die offizielle Dokumentation von Cisco Duo für RDP-Konfigurationen ist in jedem Fall vorab einzusehen: Duo Authentication for Windows Logon & RDP | Duo Security
Cisco Duo:
https://duo.com/de/duo-overview
Grundsätzlich bietet Cisco Duo eine Vielzahl an Möglichkeiten, einen Zero-Trust Ansatz zu fahren. Die Nutzung von MFA ist nur eines der Möglichkeiten. Folgende, grundsätzliche Funktionen bietet Cisco Duo im Allgemeinen (u.a.):
- MFA
- adaptive Zugriffsrichtlinien
- Überprüfung von Gerätezuständen
- Remotezugriff
- SSO (Single-Sign-On)
Für mein Testszenario habe ich mir einen Test-Account erstellt, den ich mit meiner Business-Mailadresse verknüpft habe.
Das Testszenario:
Ich möchte einen virtuellen VBR-Server mit Duo absichern. Es soll im Falle einer RDP-Anmeldung für bestimmte Accounts ein zweiter Faktor abgefragt werden.
Hierzu verwende ich besagten VBR-Server innerhalb meines Labs und außerdem mein iPhone als MFA-Gerät, auf dem ich die Duo-App im Rahmen des Tests installieren und konfigurieren werde.
Die Lösung soll sowohl online als auch offline funktionieren, d.h. es soll auch möglich sein, per OTP die Authentifizierung (des zweiten Faktors) durchzuführen, wenn der Server nicht mit dem Internet verbunden ist.
Konfiguration:
1. Erstellung eines Duo-Accounts:
Zu Beginn muss ein Cisco Duo Account erstellt werden, der das Produkt administrativ verwaltet. Dies geschieht über die Duo-Homepage: Start Your Duo Trial
Wichtig: Es wird hier bereits bei der Erstellung des Admin-Accounts für Duo ein MFA-Device benötigt!
Hat man den Account erfolgreich erstellt, wird man auf die Account-Homepage weitergeleitet:
2. Erstellung eines ersten, persönlichen Benutzers:
Über das Hauptmenü auf der linken Seite kann man über Users einen neuen Benutzer Wizard-gesteuert erstellen:
Wie so oft sollte der Benutzername eindeutig und einheitlich sein:
Die Eingabe einer E-Mail Adresse ist für die Nutzung des Tools und auch für die weitere Registrierung erforderlich:
3. Hinzufügen eines persönlichen MFA-Gerätes:
Vorab sollte auf dem Zielgerät die App Duo Mobile von Cisco heruntergeladen und installiert werden. Die Verknüpfung des Gerätes bzw. der App mit dem neu angelegten Benutzer erfolgt in meinem Beispiel per SMS.
Über den Reiter Users im Hauptmenü kann rechts über Add Phone ein neues Gerät hinzugefügt werden:
Im nächsten Schritt gebe ich meine Handynummer ein:
Das Gerät ist jetzt grundsätzlich angelegt, jedoch noch nicht sauber konfiguriert. Ich empfehle in jedem Fall, einen Device Name zu vergeben, anhand dem das Gerät innerhalb der Duo-Oberfläche erkannt, zugeordnet und verwaltet werden kann und als Platform sollte das Betriebssystem des Handys ausgewählt werden:
Die vorbereitende Konfiguration ist somit abgeschlossen. Man kann nun über Activate Duo Mobile die installierte App mit dem Benutzer verknüpfen. Hier beginnt die Interaktion mit dem Handy selbst:
Sollte die App noch nicht installiert sein, kann ausgewählt werden, dass per SMS ein entsprechend aktueller Link zur App für die Installation bereitgestellt wird:
Auf dem Handy erhält man nun folgende SMS:
Man gibt nun einen grundlegenden Kontonamen an, der auf dem Gerät angezeigt wird:
Die finale, abgeschlossene Konfiguration sieht folgendermaßen aus:
Jetzt, wo das Handy bzw. die App sauber mit dem Benutzer verknüpft ist, werden aktuelle Daten des Gerätes in der Weboberfläche von Duo angezeigt:
Die Geräteeinrichtung ist abgeschlossen und man kann nun damit fortfahren, die RDP-Konfiguration durchzuführen.
Wichtig: Ein Gerät kann mehreren Benutzern zugeordnet werden (siehe unten)!
4. Bereitstellung der RDP-Applikation in Duo:
Nun muss ausgewählt werden, was genau wir mit Hilfe von Duo konfigurieren bzw. schützen möchten. Im Hauptmenü über den Menüpunkt Applications kann man über das Suchfeld nach „Remotedesktop“ suchen und die Applikation durch Klicken auf Protect auswählen:
Die Applikation erstellt sich nun vollautomatisch und man benötigt in jedem Fall den Integration Key, den Secret Key und den API Hostname für die weitere Konfiguration, somit sollten diese entsprechend notiert werden:
Die hier dargestellte Application Policy „Duo Test“ wird im nächsten Schritt konfiguriert.
Da man eine Offline-Anmeldung (somit die Funktion der Lösung auch bei deaktiviert Internetverbindung) nutzen möchte, muss die entsprechende Option aktiviert werden. Hier empfehle ich, den Wert Prevent Offline Login auf „10“ zu stellen:
5. Erstellung einer Application Policy:
Innerhalb der eben erstellten Application kann man eine Policy erstellen und hinzufügen. Dies empfehle ich, um eine zusätzliche Filterung von Rechten auf die Zielsysteme zu erstellen. Die Policy lässt sich im o.g. Wizard erstellen und auswählen:
Als Objekte bzw. Regeln innerhalb der Policy habe ich mich für meinen Test auf Application Policy und Duo Mobile app beschränkt, um an diesen beiden Optionen Werte vorgeben zu kommen:
Die Authentication Policy besagt, dass MFA in jedem Fall genutzt werden muss und hierzu Duo Push verwendet werden soll. Alternativ lassen sich hier auch mehrere Optionen definieren, um beispielsweise eine Authentifizierung mit der Duo Desktop App zuzulassen:
Die Policy soll letztlich auf alle vorhandenen Benutzer angewendet werden, die die erstellte Applikation nutzen:
Wichtig: Es gibt eine sog. „Global Policy“, die diverse Werte vorgibt. Die Global Policy wird immer dann angewendet, wenn der Benutzer kein Mitglied einer weiteren, individuellen Gruppe ist, da diese sonst die Regeln und Rechte vorgibt. In meinem Test möchte ich explizit nicht die Global Policy nutzen, daher habe ich eine eigene Policy erstellt.
6. Installation der Windows Applikation auf dem Zielsystem:
Über den Link Duo Authentication for Windows Logon & RDP | Duo Security kann die entsprechende Windows-Applikation Duo Authentication for Windows Logon heruntergeladen werden, sodass man die Software auf dem Zielsystem (hier: VBR-Server) installieren kann:
Hier wird der API hostname eingetragen, der oben generiert wurde (s.o.):
Hier werden der Integration Key und der Secret Key eingetragen, die oben generiert wurden (s.o.):
Für den Test und die Dauer der Konfigurationsarbeiten empfiehlt es sich, die Bypass-Option zu setzen, sodass eine Anmeldung am Zielsystem bei Ausfall der Internetverbindung noch möglich bleibt. Außerdem können zusätzliche Optionen wie beschrieben auf Wunsch gesetzt werden:
Der Smart Card Support bleibt in meinem Test deaktiviert:
7. Anlage eines Duo-Accounts für den lokalen Administrator in Duo:
Duo ist so konfiguriert, dass jeder Benutzer, der sich am Server über die definierten Wege anmelden möchte, in Duo angelegt werden muss und somit auch dort verwaltet, wie die Anmeldung passieren darf (z.B. ohne MFA oder mit MFA). Es ist also erforderlich, dass für jeden Benutzer des Systems ein Benutzer in Duo angelegt wird.
In diesem Beispiel sichere ich den lokalen Administrator meines Windows-Systems ab und lege den Benutzer entsprechend der o.g. Schritte an:
Nun muss dem neu angelegten Benutzer ein MFA-Gerät zugewiesen werden. Wie oben erwähnt kann ein Gerät mehreren Benutzern zugewiesen werden, weswegen ich hier nun das oben bereits konfigurierte „Private Phone“ nutze und den Benutzer darauf konfiguriere:
Über Attach a user kann man den passenden Benutzer auswählen:
Der lokale Administrator „admloc“ wird gewählt:
Zur Bestätigung sieht man hier, dass das angegebene Gerät insgesamt 2 zugeordnete Benutzer hat:
8. Test der Anmeldung mit Cisco Duo MFA:
Nach erfolgter Installation teste ich nun die Anmeldung am System, zuerst via RDP:
Hier schaltet sich Duo ein und fragt via Push den zweiten Faktor des für den User hinterlegten Gerätes an:
Auf dem Handy erhalte ich die folgende Push-Benachrichtigung:
Wichtig: Da oben der Offline-Login via MFA aktiviert wurde, fragt Duo initial bei der ersten Anmeldung für diesen Benutzer nach einem Duo Mobile Passcode, der verwendet wird, wenn der Server keine Internetverbindung hat. Eine initiale Internetverbindung ist hierfür erforderlich.
Ich richte die Passcode-Authentifizierung in meinem Test auf dem selben Gerät ein, das ich oben für die Online-Authentifizierung nutze:
Nachdem der Offline-Login aktiviert wurde, ist die initiale Konfiguration abgeschlossen und man wird zum Windows-Desktop des Zielsystems weitergeleitet.
Die Konfiguration ist an dieser Stelle abgeschlossen, ich teste jedoch noch die Offline-Fähigkeit sowie den lokalen Login (ohne RDP).
9. Test der Anmeldung ohne Internetverbindung (Offline MFA):
Ich habe testweise bei meinem Windows-Server das Standardgateway entfernt, sodass der Server keine Verbindung mehr zum Internet aufbauen kann. Bei einem Anmeldeversuch per RDP kommt nun folgende Meldung mit einer Offline Passcode Authentifizierung:
Nach Eingabe des Codes von meinem Handy werde ich problemlos zum Windows-Desktop weitergeleitet.
10. Test der lokalen Anmeldung (ohne RDP):
Auch die lokale Anmeldung – in meinem Fall über die vSphere-Konsole – habe ich getestet und die Aufforderung zur Eingabe des zweiten Faktors ist gleich der, wenn eine Anmeldung per RDP erfolgt:
Weitere Ideen und Anwendungen:
Cisco Duo ist meiner Meinung nach eine sehr gute Möglichkeit, einen zusätzlichen Faktor in die Anmeldung zu integrieren und somit die ganzheitliche Security für Veeam-Systeme, die kein Mitglied einer Active Directory Domäne sind, grundlegend zu erhöhen.
Die Lösung funktioniert auch in Umgebungen innerhalb von Active Directory Domänen, jedoch gibt es hier hinsichtlich des Konzeptes mehr zu beachten.
Hier einige generelle Denkanstöße:
- jeder lokale Windows-User eines VBR-Servers muss in Duo erstellt / angelegt werden
- z.B. ein lokaler Administrator kann bei Bedarf von mehreren Endgeräten freigegeben werden (z.B. von mehreren vertrauenswürdigen Administratoren und deren persönlichen Geräten)
- innerhalb von Duo kann man die Benutzer, die die RDP-Applikation verwenden sollen, über eine separate Benutzergruppe steuern, was die Administration in größeren Umgebungen erleichtert
- ein Namenskonzept ist hier unumgänglich, da der Benutzername im Duo dem lokalen Windows-Benutzernamen gleichen muss
- soll ein Benutzer (z.B. ein Break-Glass-Account) kein MFA zur Anmeldung nutzen, so muss dieser trotzdem im Duo angelegt werden, dort wird dann eine Bypass-Option gesetzt, die nur für diesen Benutzer gilt (Benutzerkonfiguration)
Für eine kleine VBR-Umgebung (Standalone-Server ohne Domain-Mitgliedschaft) könnte man z.B. folgendes Konzept anwenden. Man legt einen Duo-Benutzer für den lokalen Administrator (in meinem Fall „admloc“) an und gleichzeitig entsprechende personifizierte Benutzer, die innerhalb der Veeam RBAC entsprechend berechtigt werden:
Übrigens: Ist ein lokaler Benutzer nicht im Duo angelegt, versucht sich aber dennoch am System anzulegen, kommt folgende Fehlermeldung:
Ich empfehle außerdem bei dem Einsatz von Duo auf Veeam-Komponenten (z.B. Proxies oder Repositories) mit Bypass-Optionen zu arbeiten und in jedem Fall die Service Accounts, mit denen Veeam ausgeführt wird, in Duo zu hinterlegen und dort auch als Service Account zu betiteln und mit einem Bypass zu versehen.
Duo entbindet nicht von der Pflicht, regelmäßig Kennwörter zu ändern!