MSXFAQ MeetNow aktiv: Komm doch einfach dazu.

Windows VPN mit Zertifikat und Intune

Seit NT 3.51 nutze ich VPN-Zugänge zum Firmennetzwerk und bin vermutlich nicht der einzige, der mit den Windows Bordmitteln zufrieden ist. Aber eine Anmeldung mit Benutzername/Kennwort ist heute wirklich nicht mehr sicher. Hier beschreibe ich, wie ich den Netzwerkzugang per VPN und Intune zur Zertifikatsverteilung gesichert habe.

Der Aufwand mit Intune und Connector ist nur erforderlich, wenn Sie Geräte per VPN einbinden wollen, die nicht Domainmitglied sind, z.B. Smartphones etc. Für Domainmitglieder können Sie Zertifikate von einer internen PKI einfach über Gruppenrichtlinien verteilen. Für die Einrichtung eines VPN-Profils können sie Intune oder andere Tools nutzen.

Zertifikat statt Kennwort

Viele Jahre war es gelebte Praxis, dass Zugänge zu Servern und Diensten durch einen Benutzernamen und ein entsprechend gutes Kennwort abgesichert waren. Heute ist dies aber selbst dann nicht mehr als sicher anzusehen, wenn die Anmeldung nach zu vielen Fehlversuchen gedrosselt oder blockiert wird. Die Wahrscheinlichkeit ist einfach zu hoch, dass Anwender ihr Kennwort der Firma auch anderweitig verwenden und das Kennwort entweder beim Anwender selbst abgegriffen wird (Keylogger, Phishing) oder ein anderer Dienst seine Kennworte verliert. Als Administrator sind sie gut beraten, ihre Domain bei Diensten wie "Have I Been Pwned: Domain search"  (https://haveibeenpwned.com/DomainSearch) anzumelden und solche Leaks zu erkennen.

Besser ist aber natürlich der Verzicht auf Kennworte und die Anmeldung mit anderen "sicheren" Optionen. Natürlich können Sie VPN-Zugänge von 3rd-Party-Produkten mit Authenticator-App, RSA-Tokens, Fido-Keys etc. absichern aber es muss ja "benutzbar" und massentauglich sein. Auch wenn viele Administratoren vielleicht Angst vor Zertifikaten haben, so ist ein Zertifikat für den Benutzer oder den Computer aus meiner Sicht ein sehr sicheres und letztlich einfaches Verfahren zur Absicherung zum Netzwerk.

Ein VPN-Zugang über das Internet ist letztlich genau so abzusichern, wie ein Zugang im Büro über WLAN oder sogar den LAN-Zugang über 802.1.x. Wir müssen uns natürlich überlegen, wie das Zertifikat sicher auf das jeweilige Endgerät kommt und auch dort verbleibt. Dabei geht es nicht nur im Windows PCs in einer Domain sondern immer mehr auch um Android/IOS-Geräte ohne Domainmitgliedschaft und Windows Computer, die nur noch Entra ID-Joined sind.

Konzeption

Für mein eigenes Netzwerk als auch für viele Kunden habe ich daher folgende Eckpunkte festgehalten:

  • Zertifikat statt "unsicheren Zugänge"
    Ich versuche möglichst alle "Remote Zugänge" über Zertifikate abzusichern, so dass Kennwort nicht mehr stattfinden. Für eine kurze Übergangszeit ist das Zertifikat eine zusätzliche Anmeldung aber am Ende gibt es sonst nichts mehr.
  • Automatisiertes "Zertifikat-Enrollment"
    Damit müssen wir natürlich eine Lösung finden, das Zertifikat auf das Gerät zu bringen, auch wenn es noch nicht z.B. im LAN ist und mangels AD-Mitgliedschaft auch keine Gruppenrichtlinie bekommen kann. Hier schlägt die Stunde einer MDM-Lösung und Verfahren wie SCEP oder PKCS.
  • "Managed Device"
    Es dürfen keine Geräte im Netzwerk sein, die nicht "bekannt" sind. Nur Geräte, die inventarisiert sind und die erforderlichen Richtlinien umgesetzt und Schutzprodukte installiert und aktuell haben, dürften sich mit dem Netzwerk verbinden. Alle anderen sind "Gäste", bis sie ihren Status nachgewiesen haben und bleiben draußen. Beim VPN können Sie sich also gar nicht erst verbinden.
  • Steuerung per NPS (RADIUS)
    Die Überprüfung der Zugangsdaten im LAN/WLAN per 802.1x oder VPN überlasse ich dem Windows NPS-Service, welcher keine weiteren Erweiterungen für MFA o.ä. hat, sondern die klassische Windows-Funktion bereitstellt.
  • "Sichere Zertifikate"
    Das Zertifikat auf dem Client kann entweder an den Benutzer oder den Computer gebunden werden. Mit "Always On" bieten sich natürlich Computer-Zertifikate an. Diese werden üblicherweise von einer Private CA im Firmennetzwerk bereitgestellt.
  • Split/Tunnel-VPN
    Hier wird es dann noch etwas kniffliger, denn um die Verbindungen zu optimieren, sollte ein Split-VPN zumindest der Zugriff auf vom Anwender genutzte Cloud-Dienste direkt möglich sein. Technisch könnte dies aber bedeuten, dass ein VPN-Client von extern gesteuert werden können und damit über den Umweg "Homeoffice" doch ein Zugriff auf das Firmennetzwerk möglich wäre. Bei einem Tunnel-VPN müssten diese Angriffe dann durch das VPN über die Firmen-Firewall laufen und würden dort hoffentlich erkannt. Das aber auch nicht gesichert ist. Diverse "Endpoint Protection"-Systeme versprechen das gleiche.
    Ich bin ein Freund von SplitVPN und route nur die privaten Adressen durch das VPN und vertraue auf meine Endpoint-Lösungen wie z.B. Defender.

Im Prinzip also keine "besonders knifflige" Vorgabe, die dennoch meinen Anspruch an Sicherheit erfüllt.,

Fragen zum Zertifikat

Das ganz System steht und fällt natürlich mit dem Zertifikat auf dem Endpunkt und da gibt es erst einmal viele Fragen und Antworten

  • Wie bekommt ein Client erstmals ein Zertifikat?
    Wenn er sich an der MDM-Lösung registriert und die Richtlinien umgesetzt hat.
  • Wie wird das Zertifikat verlängert, ehe es ausläuft?
    Die MDM-Lösung erkennt ablaufende Zertifikate und verlängert diese
  • Kann ich zentral erkennen, wann ein Zertifikat abläuft?
    Die PKI führt Buch über alle ausgestellten Zertifikate und sie können über eine Auswertung erkennen, wenn Clients bald ablaufen und anscheinend die Verlängerung nicht greift
  • Wie bekommt ein Client ein Zertifikat, wen er lange ausgeschaltet war
    In dem Fall wird das MDM ein neues Enrollment starten, nachdem der Client erst einmal die Mindestvoraussetzungen bezüglich Richtlinien und Software wieder erfüllt hat.
  • Brauche ich eine Zertifizierungsstelle(PKI) dazu
    Ja, und idealerweise nutzen sie eine AD-integrierte PKI. (Private CA) Sie können eine zweistufige Umgebung mit einer "Offline Root" und einer integrierten IssuingCA aufbauen. Wenn wir sich komplett auf Computer-Zertifikate beschränken, d.h. ohne SMIME, EFS etc. arbeiten, dann könnte eine Single AD-integrierte RootCA eine einfache Option für kleinere Umgebungen sein.
  • Wie genau wird das Zertifikat verteilt
    Das kommt im nächsten Abschnitt

Haben Sie noch weitere Fragen? Dann einfach stellen und ich kann die Seite entsprechend erweitern.

Certificate Enrollment SCEP, PKCS, AD

Niemand möchte manuell Zertifikat auf einen Client verteilen und aktuell halten. Daher gibt es mehrere unterschiedliche Verfahren, wie Sie Zertifikate bereitstellen können.

  • Active Directory Auto Enrollment
    Diese Verfahren gibt es schon seit Windows 2000. Eine AD-integrierte PKI kann anhand der Authentifizierung eines Computers oder Benutzers entsprechende Zertifikate ausstellen. Über eine Gruppenrichtlinie können Sie dies einfach steuern. Zudem vertrauen die Domainmitglieder der CA automatische.
    Nachteil: Es funktioniert nur für Domainmitglieder, z. B. Android, IOS, Mac und andere Systeme sind dadurch nicht abgedeckt.
  • SCEP - Simple Certificate Enrollment Protokoll.
    Das Verfahren ist schon sehr alt und wurde ursprünglich von Cisco beschrieben, um Router und Switches damit mit Zertifikaten zu versehen. Niemand will private Schlüssel auf einem PC erstellen, signieren und dann per unsicherem Upload auf das Gerät bringen. Mit SCEP besorgt sich der Admin ein "Einmalkennwort" von dem SCEP-Service, geht dann auf sein Gerät und fordert von dort ein Zertifikat an. Das Gerät erstellt ein Schlüsselpaar und reicht den öffentlichen Schlüssel mit Zusatzinformationen und dem Einmalkennwort am SCEP-Server per HTTP ein und erhält das Zertifikat. Vor Ablauf des Zertifikats kann das Gerät mit dem noch gültigen Zertifikat eine Verlängerung beantragen.
    Mit Intune können Sie über einen Zertifikat Connector automatisiert solche Einmal-Kennwort von einer internen PKI abrufen und dem Client bereitstellen, damit er sich selbst ein entsprechendes Zertifíkat anfordern kann. Das Verfahren funktioniert für zukünftige VPN-Clients ebenfalls, aber bedeutet dass Sie ihren SCEP-Endpunkt auf dem Internet erreichbar machen müssten.
  • PKCS
    Daher gibt es mit dem Intune Connector noch einen alternativen Weg über PKCS. Auch hierbei errechnet der Client ein Zertifikat aber rechts den Request nun über den Intune Connector an die interne PKI weiter. Der Connector bekommt dann das PKI-signierte Zertifikat und sendet es über Intune zum Client. Der private Key verlässt auch hier nicht den Client.

Während der Installation des Intune Connectors können Sie auswählen, welche Funktionen Sie einrichten wollen:

In Verbindung mit Intune und dem Intune Zertifikat Connector ist es wirklich sehr einfach geworden, Zertifikat von einer internen PKI auf durch Intune verwaltete Systeme zu bringen.

Konfiguration

Damit das nun alles ineinander zusammengreift, müssen sie mehrere Einstellungen an verschiedenen Stellen vornehmen. Ich habe nicht alles bis ins Detail beschrieben, sondern nur eine Checkliste mit ein paar Erläuterungen und weiterführenden Links erstellt.

Im Zweifel können Sie Sie bei der Absicherung und Einführung eines VPN-Zugangs, Intune und anderen Sicherheitsthemen unterstützen

Einstellung Erledigt

Sicherheit: Dienstkonto oder System

Der Zertifikats-Connector muss sich gegenüber der PKI authentifizieren. Sie können dazu einfach das Computerkonto "SYSTEM" nutzen, auf dem der Connector installiert wird oder sie legen ein Domainuser-Konto an, welches sie mit einem guten Kennwort absichern und auch sonst möglichst beschränken. Das sollten Sie nicht auf die leichte Schulter nehmen, denn dieses Konto kann sich beliebige Zertifikate des Templates ausstellen und je nach Umsetzung also auch ein Benutzerzertifikat erhalten und damit Berechtigungen hoch bis zum Domain Admin erlangen. Der Connector-Server ist also wie ein Tier0-System, vergleichbar zu einem Domain Controller zu sehen.

Dieses Benutzerkonto wird im weiteren Prozess entsprechend berechtigt

PKI Konfiguration: Zertifikattemplate

Vielleicht sollten sie auf der PKI noch ein eignes Template für die durch Intune verteilen Zertifikate konfigurieren. Die Standard-Templates lesen nämlich den CN und SAN-Namen aus dem AD-Objekt auf, welches nicht für Android/IOS/AzureADJoined-Geräte vorhanden ist. In Verbindung mit Intune sollten Sie ein eigenes Template für Computer-Zertifikate anlegen, welches keine Werte vorgibt, weil diese durch Intune vergeben werden. Am besten kopieren Sie dazu das "Computer-Zertifikat"-Template und passen es an zwei Stellen an:

  • Subject Name
    Zuerst müssen Sie zulassen, dass später Intune einen beliebigen Subject-Namen mitliefern kann, da nicht jedes per Intune verwaltete Gerät auch ein AD-Konto haben wird. (IOS, Android etc.)

    Die MMC warnt Sie explizit vor dem Schritt, da er ein Risiko bedeutet, wenn Sie keine weitere Absicherung vornehmen.
  • Berechtigungen
    Daher betrifft die zweite Einstellung das Konto, welches solch ein Zertifikat anfordern darf. Hier muss das Intune-Dienstkonto oder der Intune Connector Server addiert und berechtigt werden.

    Sie sollten zumindest das "Domain Computers"-Konto entfernen, damit nicht ein lokaler Admin auf einem Client ein Zertifikat für einen privilegierten Computer anfordert. "Authenticated Users" darf per Default nur Lesen, was kein Problem darstellen sollte.

Denken Sie daran, dass sie ihr Zertifikate mit "Strong names" absichern können oder wollen.

PKI Berechtigungen: Request und Revoke

"Domain Benutzer" dürfen von einer PKI Zertifikate anfordern aber keine Zertifikate zurückrufen. Wenn das Connector-Konto diese Funktion ausüben soll, dann müssen Sie über die Eigenschaften der PKI das Recht zuweisen:

Addieren Sie hier zuerst das Dienstkonto oder Computerkonto des Intune Certificate Connectors und aktivieren Sie das Recht "Issue and Manage Certificates.

 

Intune: Interne PKI als Trusted Root addieren

Zuerst müssen wir sicherstellen, dass alle per Intune verwalteten Clients auch der internen PKI vertrauen. Für Domain-Mitglieder ist dies in der Regel nicht erforderlich, denn alle Domain Mitglieder vertrauen automatische den AD-integrierten Zertifizierungsstellen.

 

Intune: Certificate Enrollment

Nachdem das Root-Zertifikate  verteilt wurde, können wir über eine Richtlinien nun ein Zertifikat per PKCS auf die Endgeräte verteilen:

Hier verwenden Sie bitte die extra angelegte Vorlage.

PKI: Kontrolle

Nach einigen Minuten sollten die zugewiesenen Geräte ein Zertifikat erhalten haben. Sie können dies in Intune überwachen aber auch in der PKI sollten Sie die ausgestellten Zertifikate sehen können.

VPN/NPS-Konfiguration

Nun müssen Sie ihren VPN-Server natürlich dahingehend befähigen, dass er erst einmal zusätzlich eine Anmeldung mittels Zertifikat unterstützt und später dann nur noch Zertifikate akzeptiert. Dazu müssen Sie auf dem NPS-Server die entsprechenden Authentifizierungsverfahren einrichten. Ohne Radius-Server können Sie dies direkt im Windows RRAS-Service konfigurieren.

 

In Verbindung mit einem  NPS/RADIUS-Server sind die Einstellungen natürlich dort vorzunehmen.

 

Die rot markierten Felder sind die "unsicheren Verfahren", die sie nach der Umstellung am Ende deaktivieren sollten.

Intune: VPN-Profil

Zuletzt bringen wir den Clients bei, bei der VPN-Verbindung sich mit per Zertifikat anzumelden. Auch das ist eine Einstellung in den Intune VPN-Einstellungen:

 

Das sieht je nach VPN-Server und Protokoll etwas anders aus. Ich habe hier "Computerzertifikate" ausgewählt. EAP ist ebenso möglich, um Benutzerzertifikate zu nutzen.

VPN/NPS Absicherung

Nun sollten Sie kontrollieren, welches Clients sich noch immer mit Benutzername/Kennwort oder anderen schwachen Anmeldeinformationen am VPN-Zugang authentifizieren und diese nacharbeiten. Irgendwann werden Sie aber alle unsicheren Anmeldeverfahren abschalten.

Ich habe dazu weiter oben schon die entsprechenden Einstellungen  rot markiert.

Zusammenfassung

Wer heute noch VPN-Zugänge allein mit Benutzername und Kennwort absichert, handelt groß fahrlässig. Es ist nur eine Frage der Zeit, bis entweder eine Brute Force-Attacke oder ein irgendwo abgephishtes Kennwort eines Anwender in fremde Hände fällt und schon hat ein Angreifer einen Zugang zu ihrem Netzwerk, kann sich umschauen und weitere Schwachstellen suchen und nutzen. Die Anmeldung mit Zertifikaten ist sicher und gar nicht mal schwer und aufwändig einzurichten. Sie brauchen nur eine minimale interne PKI, einmal Intune oder einfach eine Gruppenrichtlinie (nur Domain-Mitglieder) zum Verteilen von Computerzertifikaten und eine Anpassung am VPN-Server.

Natürlich können Sie solche Lösungen auch mit anderen VPN-Systemen bereitstellen und Wireguard, OpenVPN und andere Lösungen arbeiten auch mit Zertifikaten. Aber mit Windows Bordmitteln und Intune für Geräte ohne  Domainmitgliedschaft ist der Aufwand sehr gering.

Weitere Links