Azure MFA und OnPremises

Alle Firmen, die Microsoft 365 nutzen und ihre Security nicht absichtlich geschwächt haben, nutzen die Azure Security Defaults oder Conditional Access zur Absicherung der Zugriffe. Damit sind aber lokalen Services beim Zugriff aus der Cloud, z.B. VPN, RDP-Server, Webserver, noch nicht gesichert. Diese Seite beschreibt die Möglichkeiten, lokale Dienste besser abzusichern, denn die Kombination aus Benutzername und Kennwort ist einfach nicht sicher genug.

Risiko!

Die heute meist genutzte Anmeldung per Benutzername und Kennwort ist definitiv unsicher und wenn ein Anwender sein Kennwort "verlegt" und jemand Zugriff auf einen Client hat, dann kann er sich als dieser Anwender ausgeben. Bei vielen Clients im Netzwerk sind hier Intune, SCCM, Matrix42, Gruppenrichtlinien etc. keine Hilfe. Wenn ich das Kennwort eines anderen Mitarbeiters "erspähe", d.h. durch Abfilmen der Eingabe mit dem Smartphone kann ich später vom gleichen oder anderen Computer diese Daten nutzen und meine wahre Identität verschleiern.

Schon als Mitarbeiter sollte ich von meinem Arbeitgeber erwarten, dass er mich vor solchen falschen Verdächtigungen schützt und als Firma wollen Sie solche Zugriffe erst recht nicht zulassen. Der erweiterte Schutz einer lokalen Anmeldung ist daher keine Kür sondern Pflicht.

Nebenbei: Sie sollten auch klären, in welchem Umfang sie Anmeldungen protokollieren. Solche Daten können auch dazu dienen Mitarbeiter zu entlasten, denn Kennwort-Missbrauch kann es immer wieder geben.

Natürlich haben Cloud-Anmeldungen auf den ersten Blick ein größeres Interesse an einer sicheren Anmeldungen, da es hier ja kein "Intern" oder "Firmennetzwerk" gibt. Cloud-Anwendungen sind immer aus dem Internet für jeden Client erreichbar.

Warum, wer, wo, womit?

Lange Zeit waren "Benutzern" + "Kennwort" die üblichen Anmeldeverfahren. Lokale Server haben lange Zeit einen "eingebauten zweiten Faktor" gehabt, weil Sie nicht aus dem Internet erreichbar waren. Sie mussten als Angreifer schon irgendwie im Gebäude sein oder einen Client fernsteuern, der im Gebäude ist. Das ist aber Geschichte und wird sich nicht mehr ändern und heute hat die überwiegende Anzahl an Client natürlich Internet Zugriff und könnte damit auch ferngesteuert werden und viele OnPremises Dienste sind natürlich aus dem Internet erreichbar. Nicht immer ist hier ein VPN erforderlich, was beim Einsatz von Zertifikaten o.ä. ebenfalls als zweiter Faktor zählen könnte. Wir haben aber auch immer mehr Notebooks im "HomeOffice".

Letztlich ist das "Abgeschlossene lokale interne Netzwerk" nicht mehr Realität und selbst wenn dem so wäre, wären Innenangriffe durch interne Mitarbeiter aber auch defekte Software möglich.

Früher sind sie mit dem "Käfer" oder der "Ente" einfach gefahren. Heute würden Sie sich ohne Sicherheitsgurt, ABS, Airbag etc. vermutlich sehr unwohl fühlen. Auch in der IT können Sie heute nicht mehr ohne Schutz unterwegs sein.

Für die weitere Betrachtung beim Zugriff auf Dienste und die Anmeldung betrachte ich zwei Dinge:

  • Identität: Benutzer, Admin, Service
    Ich würde für alle ein hohes Sicherheitsniveau anstreben aber je mehr Berechtigungen eine Identität auf sich vereint, desto kritischer ist diese einzuschätzen. Auf einem stationären Client-PC im Firmengebäude mit Zugangskontrolle haben wir quasi schon mehrere Faktoren aber ein Notebook im Homeoffice oder in der Hand der falschen Person muss mehr fordern.
  • System: Desktop oder Server
    Dies gilt auf für den Computer, auf dem die Rechte dann ausgeübt werden. Eine Anmeldung auf einem Server (RDP, SSH, RCMD) allein mit einem Kennwort ist kritisch. Wenn ich auf dem System lokal aktiv bin, habe ich viele Schutzmechanismen wie z.B. Firewalls, NTFS-Rechte etc. umgangen.

Das ganze Prinzip funktioniert natürlich nur, wenn die Identitäten und Systeme schon einen Mindeststandard erfüllen, d.h. aktuelle Betriebssysteme mit Updates, verschlüsselte Festplatten, ausreichend lange Kennworte.

Kennwort ist nicht genug!

Nun könnten Sie ja darauf kommen, dass die Kennworte ihrer Konten alle 10+ Stellen haben, komplex sind und regelmäßig geändert werden. Daher wäre das Risiko einer Password Spray/BruteForce-Attacke minimal.

Das kommt mir s vor wie ein Haus mit robuster Haustür und Fallschlössern und Alarmanlage. Sie vergessen dabei aber, dass Sie gelegentlich doch einen Schlüssel unter der Fußmatte platzieren.

Das Risiko ist nicht das Kennwort selbst sondern der Anwender, das Kennwort eingeben muss. Je häufiger der Mitarbeiter das Kennwort "irgendwo" eingeben muss, desto höher ist das Risiko. Gehen Sie nicht davon aus, dass Mitarbeiter immer zuverlässig den Dialog betrachten, welcher die Zugangsdaten abfordert. Das kann auch ein "fremder" Dialog eines Angreifers sein, der nur so aussieht, als wenn es ein interner Zugriff ist.

Daher bin ich ein Verfechter von "Seamless Single SignOn". Ein Anwender sollte idealerweise genau EINMAL am Morgen seine Anmeldedaten eingeben und dann nie wieder gefragt werden.

 Jeder zusätzliche Dialog ist ein Risiko, dass jemand das Kennwort "abfängt". Diese Angriffsmuster habe ich schon bei einem Studium an der BA Mannheim mit einer VAX gesehen. Ein Student hat ein Programm geschrieben, welches die Anmeldemaske des Terminal beim Einschalten nachgebildet hat und ist weggegangen. Der nächste Student setzt sich an das Terminal und gibt seine Anmeldedaten ein. Das Programm, welches immer noch im Kontext des Angreifers läuft, speichert das Kennwort, gibt eine Fehlermeldung aus und loggt den Angreifer aus. Der aktuelle Student versucht es ein zweites mal und ist nun auch angemeldet. Daher ist es auch so wichtig die Endgeräte zu sichern und die Anwender zu sensibilisieren, wo sie ihr Kennwort eingeben.

Wenn allerdings ihre Anwender das Kennwort gar nicht mehr eingeben müssen, dann kann es auch nicht abgegriffen werden. Das ist auch die Idee hinter Windows Hello, Anmeldung per PIN oder Biometrie oder Smartcards.

Spätestens nun sollten Sie verstanden haben, warum auch ein komplexes Kennwort keinen ausreichenden Schutz bietet. In der Cloud trägt Microsoft dieser Tatsache mit den mittlerweile in allen Tenants aktivierten Azure Security Defaults entsprechend Rechnung. Aber was machen wir mit unserem lokalen Systemen und Diensten?

Wenn Sie ihre System abgesichert haben, dann können Sie Anmeldeversuche überwachen, bei denen der korrekte Benutzername samt Kennwort eingegeben aber dann der zweite Faktor nicht geliefert wurde. Es kann ein Benutzer gewesen sein, der sich umentschieden hat. Es kann aber auch ein Zeichen für kompromittierte Password sein.

Desktops

Anwender nutzen heute neben Windows natürlich auch Smartphones (IOS, Android), MacOS und Linux. Ich beschäftige mich hier aber erst einmal mit dem dominanten Betriebssystem auf Clients bei Firmen. Wer wie ich schon viele Jahre in der IT unterwegs ist, kennt früher genutzte Verfahren einer "alternativen" Anmeldung. Als in den 90er Jahren die NDS (Novell NetWare Directory Services) das dominante Verzeichnisdienst war, konnten wir Windows NT4 Client ohne Domäne in die NDS integrieren. Novell hat dazu eine GINA-DLL bereitgestellt, die den Anmeldedialog von Windows erweitert hat. Mit "CTRL-ALT-DEL" konnte ich dann meine NetWare Anmeldedaten eingeben und die DLL hat im Hintergrund "on-the-fly" einen lokalen Windows User angelegt und verwaltet, damit ich arbeiten konnte. Ähnlich haben 3rd Party Lösungen wie RSA, Smartcard etc. funktioniert, die über eine GINA-DLL den Anmeldedialog von Windows "erweitert" haben. Damit kann ich die lokale Anmeldung am Gerät besser absichern.

Der Schutz war aber immer nur solange gegeben, wie ich auch so ein Gerät verwende. Wenn ich mit einem fremden Gerät den Service anspreche und der Service weiterhin nur Benutzername und Kennwort anfordert, dann helfen mit alle anderen sicheren Geräte nichts. Hier muss ich auf dem Netzwerk-Level, z.B. Firewall, IPSec etc. sicherstellen, dass der Service nicht von anderen Geräten erreichbar ist.

Leider habe ich keine einfache AzureAD-DLL gefunden, mit der ich einen Windows Client dazu bringen kann, zusätzlich auch AzureAD Conditional Access zu nutzen. Bis zum Jahr 2019 gab es sogar einen MFA-Server, den ich OnPremises installieren konnte.

As of July 1, 2019, Microsoft will no longer offer MFA Server for new deployments. New customers who would like to require multi-factor authentication from their users should use cloud-based Azure AD Multi-Factor Authentication.
Quelle: https://learn.microsoft.com/de-de/windows/security/identity-protection/hello-for-business/hello-key-trust-validate-deploy-mfa

Wenn ich eine Authentifizierung gegen AzureAD Conditional Access absichern möchte, dann möge ich doch mit SAML/OAUTH/ModernAuth nutzen, d.h. mein Service akzeptiert direkt die Tokens des AzureAD oder Windows Hello for Business nutzen. Aber es tut sich was, denn zumindest für Windows Virtual Desktop und andere "in der Cloud erreichbare" Desktops kann MFA aktiviert werden:


Quelle: Meet multifactor authentication requirements of memorandum 22-09 - Virtual device sign-in scenarios that require integration https://learn.microsoft.com/en-us/entra/standards/memo-22-09-multi-factor-authentication#virtual-device-sign-in-scenarios-that-require-integration

Wenn die Systeme schon in Azure laufen, können Sie eine Anmeldung über EntraID aktivieren und damit MFA und Conditional Access durchsetzen. Dies ist auch wichtig, wenn die VMs direkt per RDP aus dem Internet erreichbar sein. Mit Azure ARC ist dies aber heute schon OnPremises möglich sein. Der Client muss dazu natürlich Azure AD Registered/Joined/HybridJoined sein. und der Anwender muss entweder in der Rolle "Virtual Machine Administrator Login" oder "Virtual Machine User Login" sein.

Auf dem RDP-Client gibt es bei mir schon die entsprechende Dialogbox unter "Erweitert":

Nun fehlt nur noch der Schalter auf dem Server, dass eine Anmeldung nur noch per Webkonto möglich ist.

Ich tue mich natürlich schwer diese Option zu aktivieren, denn damit schneide ich mich dann schon per RDP ab, wenn EntraID nicht verfügbar ist. Der Zugriff betrifft auch nur RDP aber keine Zugriffe per SMB auf C$, per RPC auf Eventlog, Servicemanager etc.

Der Schutz ist nur dann wirksam, wenn der Server auch nur per RDP von "untrusted Clients "erreichbar ist. Es gehört daher noch etwas mehr drumrum dazu, eine Anmeldung an den Servern abzusichern. Für viele Firmen dürfte daher ein "Jump-Host" an der Grenze eine einfacher umzusetzende Lösung sein.

Es gibt natürlich jede Menge 3rd Party Lösungen, die RDP mit MFA versehen. Hier nur eine nicht repräsentative Liste:

FIDO2 mit Windows

Viele Cloud-Dienste werden im Browser genutzt. Hier ist MFA z.B. mit FIDO-Tokens schon viele Jahre bekannt und auch AzureAD und Microsoft 365 können für eine Unterstützung von FIDO-Tokens konfiguriert werden. Sie brauchen nur einen passenden Browser, was aber heute kein Problem mehr ist.

Verwechseln sie aber nicht die Anmeldung an einem Cloud-Service über einen Browser mit einer Anmeldung am Betriebssystem selbst. Aber Windows unterstützt mittlerweile sogar die Anmeldung mit einem FIDO2-Token.

Achtung:
Nicht jedes "FIDO"-Token ist mit Windows oder AzureAD nutzbar. Orientieren Sie sich z.B.: an der folgenden Liste
FIDO2 security keys: https://learn.microsoft.com/en-us/azure/active-directory/authentication/concept-authentication-passwordless#fido2-security-keys

Aber für ihren Desktop müssen Sie die Anmeldung mit FIDO erst noch aktivieren. Genau genommen ist es sogar "FIDO2" und nicht der einfachere FIDO/U2F-Standard. Für einen Test können Sie dies als Administrator direkt in der Registrierung machen.

REM FIDO Anmeldung aktivieren
REG ADD "HKLM\SOFTWARE\policies\Microsoft\FIDO" /v EnableFIDODeviceLogon /t REG_DWORD /d 1 /f

REM FIDO Anmeldung deaktivieren
REG DELETE "HKLM\SOFTWARE\policies\Microsoft\FIDO" /v EnableFIDODeviceLogon /f

Für eine Firma bietet sich natürlich die passende Gruppenrichtlinie an. Schon direkt nach der Anmeldung zeigt ihnen das Windows Anmeldefenster die neue Funktion neben den anderen Anmeldeverfahren an:

FIDO-Sicherheitsschlüssel steht gleichberechtigt neben Kennwort, zwei Zertifikaten/Smartcards, PIN und Bilderkennung.

Die Konfiguration von FIDO als Anmeldemöglichkeit an Windows ist unabhängig von der Einrichtung der Sicherheitsschlüssel in den Anmeldeoptionen von Windows:

Über den "Verwalten"-Dialog können Sie auch sehr schnell erkennen, ob der angesteckte Sicherheitsschlüssel den Anforderungen an Windows Hello genügt.

Mein erster "KEY-ID Fido U2F-Schlüpssel erfüllt die Anforderungen nicht. Erst der "KEY-ID FIDO2 key with U2F" würde funktionieren. Achten Sie daher genau auf die Schreibweise. Einfache FIDO2-USB-Keys starten bei ca. 25€. Mit Funktionen wie NFC oder Smartcard-Emulation etc. steigen natürlich die Preise.

Faktor: Device

Der Zugriff auf einen Service erfolgt immer über ein Endgeräte. Das eröffnet den Weg, das Gerät selbst als Faktor bei der Anmeldung zu verwenden und damit die Sicherheit zu erhöhen ohne den Anwender zu nerven. Conditional Access kann einen "Device Compliance Status" mit einbeziehen. Wenn Sie als bestimmte Anwendungen auf ihre Firmengeräte oder durch Intune verwaltete Geräte beschränken können, dann können sie hier erst einmal mit Benutzername/Kennwort weiter machen.

Die Funktion ist auch nicht auf durch "Intune verwaltete Geräte" beschränkt, da Sie den Status per Graph selbst oder über 3rd Party-Lösungen setzen können. Sie können in Conditional Access so den Management und Compliance-Status des Gerät in die Ausstellung eines SAML-Tokens einfließen lassen. Damit haben wir aber nur die Ausstellung des SAML-Tokens zusätzlich abgesichert aber noch nicht die lokalen Services.

Alternativen mit AzureAD

Schauen wir uns nun einmal an, welche Möglichkeiten es in Verbindung mit AzureAD, SAML-Tokens und Conditional Access gibt, um eigene Diensten abzusichern, wenn diese selbst „OnPremises“ oder eigenen Clouds betrieben werden.

  • OAUTH2 / Modern Authentication
    In der Cloud gibt es kein NTLM oder Kerberos. Das AzureAD stellt kryptografisch gesicherte SAML-Tokens aus, die der Client dann an den Service sendet. Es gibt lokale Dienste, die statt NTLM/Kerberos auch eine Anmeldung per Hybrid Modern Authentication (HMA) erlauben. Dazu zählen z.B. Exchange OnPremises und Skype vor Business. Auch 3rd Party Produkte können so über die AzureAD-Tokens und Conditional Access abgesichert werden.
    Natürlich erhöht dies die Abhängigkeit von der Cloud und die Clients müssen Internet-Zugriff haben. Ist aber ein lokaler 2FA-Server wirklich besser verfügbar und genauso leistungsfähig wie Conditional Access in Azure?. Denken Sie auch einfach einmal an die Integration externer Konten anderer Firmen, z.B. Gastzugriffe etc.
  • Azure AD Application Proxy
    Für Clients die OAUTH über HTTPS nutzen können, kann ein Azure AD Application Proxy ein Weg sein, solche Dienste sicher zu veröffentlichen. Viele Administratoren mit einer AzureAD P1-Lizenzen wissen gar nicht, dass der Azure AD Application Proxy ein Reverse Proxy mit Preauthentication zur Veröffentlichung von Webseiten und Diensten ist. Ehe der Zugriff auf den Service erfolgt, müssen sich die Anwender mit Conditional Access anmelden. So können Sie interne Webseiten/Web-Dienste können über AzureAD sicher von extern erreichbar machen. Der Weg eignet sich nicht so gut für den Zugriff von internen Clients auf interne Server, da die Daten dann über AzureAD einen Umweg nehmen. Es kann aber wieder ein Vorteil sei, wenn ihre internen Client an einem anderen Standort sind und so ihr kostbares WAN umgehen und entlasten.
  • Radius/NPS mit Azure MFA
    Über das NPS-Plugin können weitere Dienste eine MFA-Anmeldung unterstützen. Der Anwender greift wie bisher mit Benutzername/Kennwort auf den Service zu, der dann eine Radius-Anfrage stellt. Der Radius//NPS-Server triggert dann eine AzureAD Conditional Access Prüfung, bei der der Anwender über einen Anruf oder die App die Anmeldung bestätigen muss.
    https://learn.microsoft.com/de-de/azure/active-directory/architecture/auth-radius

Umsetzung nach Service

Betrachten wir exemplarisch einige intern oder selbst gehostete Dienste:

Service Lösungsmöglichkeiten

Exchange OnPremises

Sie können Exchange OnPremises so konfigurieren, dass er nur noch OAUTH-Token von AzureAD annimmt und Anmeldungen per Benutzername/Kennwort , NTLM o.ä. verweigert werden. Ein Anwender muss in dem Fall immer erst eine Anmeldung Am AzureAD samt Conditional Access durchführen. Wenn Sie primär den externen Zugriff von OWA absichern sollen, dann können Sie auch den Azure AD Application Proxy nutzen

Skye for Business OnPremises

Wie für Exchange OnPremises können Sie auch SfB auf Hybrid Modern Authentication (HMA) umstellen. Da der Lync/SfB-Client immer nur eine Anmeldung unterstützt. müssen sie beide Systeme identisch konfigurieren.

VPN-Server

Der Zugriff von Client aus dem Internet auf interne Dienste wird gerne über ein VPN weiter abgesichert. Auch hier gibt es mehrere Optionen zur erweiterten Absicherung.

  • Radius/NPS
    Über die AzureAD-NPS-Extension können Sie MFA über SMS oder App-Notification einbauen. Der Anwender startet sein VPN, gibt den Benutzernamen und Kennwort ein und muss dann auf seinem Smartphone die Anmeldung bestätigen.
  • Modern Auth
    Es gibt aber auch VPN-Lösungen, z.B. Palo Alto Global Protect), die ebenfalls AzureAD-Tokens unterstützen. Der Anwender startet dann den VPN-Client und statt der Eingabe von Benutzername/Kennwort im VPN-Client wird er auf die ohne VPN erreichbare AzureAD-Seite gelenkt um ein Ticket zu besorgen, mit dem er sich dann am VPN-Server anmeldet.
  • Zertifikat
    Wenn ihr Gerät z.B. durch Intune o.ä. verwaltet ist, können Sie natürlich auch ein Gerätezertifikat auf einen Client verteilen, der mit SecureBoot, Bitlocker, TPM einen Diebstahl des Zertifikats zuverlässig unterbindet. Direct Access nutzt die Identität des verwalteten Clients als Zugangsdaten
    Alternativ sind auch Zertifikate mit Smartcards für Benutzer möglich.

Hier ein paar Links

Interne Webseiten

Für die Absicherung interner Webseiten gibt es zwei Optionen

  • Azure AD Application Proxy
    Hier kann die Cloud nicht nur eine Preauthentication per Conditional Access vornehmen sondern auch den Zugriff überhaupt besser absichern. Azure AD Application Proxy ist wie eine Web Application Firewall für den Zugriff aus dem Internet zu sehen.
  • Modern Auth
    Prüfen Sie doch einmal, ob ihre Webseite neben Kerberos/NTLM/BASIC nicht auch schon mit SAML/OAUTH-Tokens umgehen kann. Dann könnten Sie den gleichen Ansatz Hybrid Modern Authentication (HMA) fahren, den auch Exchange und SfB OnPremises nutzen können.

SMB-Server

Eine 2FA-Absicherung von Windows Dateifreigaben kann ich nicht einfach mit Bordmitteln umsetzen. Der SMB-Client bietet ja keine richtige Anmeldedialoge an. Aber ich habe noch keinen Kunden gesehen, der SMB wirklich "aus dem Internet" erreichbar gemacht hat. Wir sprechen hier also eher über Zugriff von internen Systemen mit einer Anmeldung per NTM oder Kerberos.

Damit habe ich dann doch einen Hebel, indem ich die Anmeldung auf Kerberos beschränke. Für die Ausstellung des Kerberos-Tickets zum Zugriff durch den KDC (Kerberos Distribution Center) muss der Client sich beim KDC erst ein "TGT" (Ticket Granting Ticket) besorgen. Für diesen Prozess kann ich eine sichere Anmeldung umsetzen, indem ich den Zugriff auf den DC nur für vertrauenswürdige Endgeräte zulassen, die sicih z.B. per 802.1x oder IPSEC am DC authentifiziert haben. Dann ist quasi das "Domain Joined Gerät" der zweite Faktor.

RDP-Zugriff

Gelingt es einem Angreifer, z.B. per RDP, SSH, TELNET o.ä. bis zum Anmeldebildschirm eines Servers zu kommen, dann ist eine Anmeldung mittels Benutzername/Kennwort nicht nur für administrative Konten ein Risiko. Nicht umsonst fordern BSI und andere Stellen, dass für administrative Funktionen eigene Admin-Konten genutzt werden, die besonders geschützt werden.
Der Zugriff per RDP kann und sollte ich natürlich klassisch über Firewall-Regeln, IPSec, Serverauthentifizierung auf bestimmte Clients beschränken und erweitert absichern. Für Administratoren kann ich zusätzlich auch starke Anmeldeverfahren erzwingen aber letztlich stehe ich vor der gleichen Herausforderung wie vom Client. Es gibt keine GINA-DLLs, die eine direkte Kopplung an Conditional Access erlauben. Dennoch gibt es Optionen:

  • Windows Hello
    Speziell beim Einsatz von Admin-PCs oder "Jump-Hosts" können Sie auf diesem System mit Windows Hello eine Anmeldung ohne Kennwort ermöglichen bzw. fordern.
  • Zertifikate
    Wenn Sie Zertifikate für das Admin-Konto ausstellen, kann sich der Admin damit am Server anmelden. Eine Anmeldung mit Kennwort sollte dann unterbunden werden
  • PIM/LogonLocally-Steuerung
    Ein Admin muss ja nicht immer Admin sein. In AzureAD gibt es PIM und sie könnten analog die Gruppe "Remotedesktopbenutzer" leer lassen und den Admin nur durch einen anderen Prozess temporär addieren, wenn er sich anmelden soll
  • RDP-Gateway
    Sie können natürlich eine direkte Verbindung per RDP unterbinden und den Umweg ber das RDP-Gateway erzwingen. So könnten sie einen internen Zugriff aus dem Server-Netz für Mitarbeiter im RZ vereinfachen aber den Zugriff von anderen Systemen absichern:
  • "Jump-Host"/PAW – Priviledged Admin Workstation
    Ähnliche Überlegungen sprechen für einen "Admin PC", z.B. als Terminal Server, von dem ein Zugriff auf die eigentlichen Server möglich ist. Es ist oft einfacher den Zugriff auf dieses System zu schützen und zu überwachen. Wobei auch hier aufzupassen ist, dass nicht ein Admin dem anderen Admin seine Sessoincookies und Kerberos-Tickets klaut.

Wenn Sie RDP absichern wollen, dann würde ich heute den RDP-Zugang zu den Servern nur aus sicheren Netzwerken oder ein RDP-Gateway erreichbar machen. Damit können Sie die Absicherung auf das RDP-Gateway beschränken und im Notfall lokal oder im gleichen LAN noch handeln.

Zwischenstand

Auch wenn Microsoft seit 2019 den lokalen AzureAD MFA-Server nicht mehr anbietet können Sie in vielen Fällen durch den Wechsel auf OAUTH2 / Modern Authentication eine deutliche erhöhte Sicherheit erreichen und die MFA/Conditional-Access-Funktionen von AzureAD auch für entsprechend kompatible lokale Dienste nutzen. Wenn ein Service nicht mit SAML-Tokens zurecht kommt, könnte eine Veröffentlichung über den Azure AD Application Proxy mit PreAuthentication den Zugriff zumindest aus dem Internet mit MFA absichern. Wenn ihr VPN-System SAML oder RADIUS/NPS unterstützt, können Sie auch hier AzureAD Conditional Access und Security Defaults direkt verwenden. Für Desktops ist Windows Hello for Business eine Option. Ganz ohne AzureAD können Sie hier aber auch mit Windows Hello, einem kompatiblen FIDO-Token oder Zertifikaten die Sicherheit erhöhen.

Es gibt also fast für alle Bereiche schon nutzbare Lösungen, die mit AzureAD funktionieren könnten. Wenn ihnen dies nicht reicht oder ihre Systeme weder mit RADIUS noch mit SAML arbeiten, dann können Sie aus einer Vielzahl von 3rd-Party-Produkten wählen.

Machen Sie sich aber schnell Gedanken darüber, sowohl die Zugänge von Administratoren als auch Anwendern besser abzusichern als nur mit Benutzername und Kennwort. Der erste Schritt ist die Bereitstellung von anderen sichereren Anmeldeverfahren, so dass Anwender gar nicht mehr ihr komplexes Kennwort eingeben wollen. Im zweiten Schritt sollten Sie nach und nach die Anmeldung allein mit Kennwort verhindern.

Weitere Links