Freigeben über

VPN und bedingter Zugriff

Der VPN-Client kann nun in die cloudbasierte Plattform für den bedingten Zugriff integriert werden, um eine Gerätekompatibilitätsoption für Remoteclients bereitzustellen. Bedingter Zugriff ist eine richtlinienbasierte Auswertungs-Engine, mit der Sie Zugriffsregeln für alle Microsoft Entra verbundenen Anwendungen erstellen können.

Hinweis

Der bedingte Zugriff ist ein Microsoft Entra ID P1- oder P2-Feature.

Zu den für die Gerätekompabitilität verwendeten Komponenten der Plattform für den bedingten Zugriff zählen folgende cloudbasierte Dienste:

  • Conditional Access Framework
  • Microsoft Entra Connect Health
  • Windows-Integritätsnachweisdienst (Health Attestation Service) (optional)
  • Microsoft Entra Zertifizierungsstelle: Es ist eine Anforderung, dass das Clientzertifikat, das für die cloudbasierte Gerätekonformitätslösung verwendet wird, von einer Microsoft Entra ID-basierten Zertifizierungsstelle ausgestellt wird. Eine Microsoft Entra Zertifizierungsstelle ist im Wesentlichen ein Cloudmandant mit Mini-Zertifizierungsstellen in Azure. Die Microsoft Entra-Zertifizierungsstelle kann nicht als Teil einer lokalen Unternehmenszertifizierungsstelle konfiguriert werden. Siehe auch Always On VPN-Bereitstellung für Windows Server und Windows 10.
  • Microsoft Entra ID ausgestellte kurzlebige Zertifikate: Wenn ein VPN-Verbindungsversuch durchgeführt wird, kommuniziert der Microsoft Entra Tokenbroker auf dem lokalen Gerät mit Microsoft Entra ID, der dann anhand von Konformitätsregeln auf Integrität überprüft. Wenn dies kompatibel ist, sendet Microsoft Entra ID ein kurzlebiges Zertifikat zurück, das zum Authentifizieren des VPN verwendet wird. Beachten Sie, dass Zertifikatauthentifizierungsmethoden wie etwa EAP-TLS verwendet werden können. Wenn der Client die Verbindung wiederherstellen und feststellt, dass das Zertifikat abgelaufen ist, überprüft der Client erneut Microsoft Entra ID auf Integritätsüberprüfung, bevor ein neues Zertifikat ausgestellt wird.
  • Microsoft Intune Gerätekonformitätsrichtlinien: Bei der cloudbasierten Gerätekonformität werden Microsoft Intune Konformitätsrichtlinien verwendet, die unter anderem den Gerätezustand abfragen und Complianceregeln für folgendes definieren können.
    • Antivirusstatus
    • Status automatischer Updates und Updatekompatibilität
    • Kompatibilität von Kennwortrichtlinien
    • Verschlüsselungskompatibilität
    • Zustand des Geräteintegritätsnachweises (überprüft mit dem Nachweisdienst nach der Abfrage)

Die folgenden clientseitigen Komponenten sind ebenfalls erforderlich:

VPN-Gerätekompatibilität

Derzeit enthalten die Microsoft Entra Zertifikate, die für Benutzer ausgestellt werden, keinen CRL-Verteilungspunkt (CRL Distribution Point, CDP) und sind nicht für Schlüsselverteilungszentren (Key Distribution Center, KDCs) geeignet, um Kerberos-Token auszugeben. Damit Benutzer Zugriff auf lokale Ressourcen erhalten, z. B. Dateien auf einer Netzwerkfreigabe, müssen Clientauthentifizierungszertifikate für die Windows-Profile der Benutzer bereitgestellt werden, und ihre VPNv2-Profile müssen den <Abschnitt SSO> enthalten.

Anforderungen in Bezug auf die serverseitige Infrastruktur zur Unterstützung der VPN-Gerätekompatibilität:

  • Der VPN-Server sollte für die Zertifikatauthentifizierung konfiguriert werden.
  • Der VPN-Server sollte der mandantenspezifischen Microsoft Entra Zertifizierungsstelle vertrauen.
  • Für den Clientzugriff mithilfe von Kerberos/NTLM wird ein domänenvertrauenswürdiges Zertifikat auf dem Clientgerät bereitgestellt und für die Verwendung für einmaliges Anmelden (Single Sign-On, SSO) konfiguriert.

Nach der Einrichtung der serverseitigen Infrastruktur können VPN-Administratoren die Richtlinieneinstellungen für bedingten Zugriff mithilfe des VPNv2-DeviceCompliance-Knotens zum VPN-Profil hinzufügen.

Für die VPN-Gerätekompatibilität werden zwei clientseitige Konfigurationsdienstanbieter genutzt.

  • VPNv2-CSP-Gerätekonformitätseinstellungen:
    • Enabled: Aktiviert den Gerätekompatibilitätsfluss vom Client. Wenn der VPN-Client als true markiert ist, versucht er, mit Microsoft Entra ID zu kommunizieren, um ein Zertifikat für die Authentifizierung zu erhalten. Das VPN sollte für die Verwendung der Zertifikatauthentifizierung eingerichtet werden, und der VPN-Server muss dem von Microsoft Entra ID zurückgegebenen Server vertrauen.
    • SSO: Einträge unter SSO sollten verwendet werden, um den VPN-Client anzuweisen, beim Zugriff auf Ressourcen, die eine Kerberos-Authentifizierung erfordern, ein anderes Zertifikat als das VPN-Authentifizierungszertifikat zu verwenden.
    • Sso/Enabled: Wenn dieses Feld auf true festgelegt ist, sucht der VPN-Client nach einem separaten Zertifikat für die Kerberos-Authentifizierung.
    • Sso/IssuerHash: Hashes für den VPN-Client, um nach dem richtigen Zertifikat für die Kerberos-Authentifizierung zu suchen.
    • Sso/Eku: durch Trennzeichen getrennte Liste der Erweiterungen für erweiterte Schlüsselverwendung (Extended Key Usage, EKU) für den VPN-Client, um nach dem richtigen Zertifikat für die Kerberos-Authentifizierung zu suchen.
  • HealthAttestation-CSP (keine Voraussetzung) – vom HealthAttestation-CSP ausgeführte Funktionen:
    • Sammeln von TPM-Daten, mit denen Integritätszustände überprüft werden
    • Weiterleitung der Daten an den Integritätsnachweisdienst (Health Attestation Service, HAS)
    • Bereitstellen des vom HAS empfangenen Integritätsnachweiszertifikats
    • Leiten Sie auf Anfrage das Integritätsnachweiszertifikat (von HAS empfangen) und die zugehörigen Laufzeitinformationen zur Überprüfung an den MDM-Server weiter.

Hinweis

Es ist erforderlich, dass Zertifikate, die zum Abrufen von Kerberos-Tickets verwendet werden, von einer lokalen Zertifizierungsstelle ausgestellt werden, und dass dieses einmalige Anmelden im VPN-Profil des Benutzers aktiviert ist. Dadurch kann der Benutzer auf lokale Ressourcen zugreifen. Wenn das von der lokalen Zertifizierungsstelle ausgestellte Benutzerzertifikat den Benutzer-UPN von AzureAD in Antragsteller und SAN (Alternativer Antragstellername) aufweist, muss das VPN-Profil geändert werden, um sicherzustellen, dass der Client die für die VPN-Authentifizierung verwendeten Anmeldeinformationen nicht zwischenspeichert. Ändern Sie dazu nach der Bereitstellung des VPN-Profils auf dem Client rasphone.pbk auf dem Client, indem Sie den Eintrag UseRasCredentials von 1 (Standard) in 0 (null) ändern.

Clientverbindungsfluss

Der VPN-clientseitige Verbindungsfluss funktioniert wie folgt:

Gerätekonformitätsworkflow, wenn der VPN-Client versucht, eine Verbindung herzustellen.

Wenn ein VPNv2-Profil mit <DeviceCompliance<>Enabled>true</Enabled> konfiguriert ist, verwendet der VPN-Client diesen Verbindungsfluss:

  1. Der VPN-Client ruft den tokenbroker Microsoft Entra von Windows 10 oder Windows 11 auf und identifiziert sich selbst als VPN-Client.
  2. Der Microsoft Entra Tokenbroker authentifiziert sich bei Microsoft Entra ID und stellt informationen zum Gerät bereit, das versucht, eine Verbindung herzustellen. Der Microsoft Entra Server überprüft, ob das Gerät den Richtlinien entspricht.
  3. Wenn dies kompatibel ist, fordert Microsoft Entra ID ein kurzlebiges Zertifikat an.
  4. Microsoft Entra ID pusht ein kurzlebiges Zertifikat über den Tokenbroker in den Zertifikatspeicher. Der Tokenbroker gibt dann die Kontrolle zurück an den VPN-Client für die weitere Verbindungsverarbeitung.
  5. Der VPN-Client verwendet das Microsoft Entra ID ausgestellte Zertifikat, um sich beim VPN-Server zu authentifizieren.

Konfigurieren des bedingten Zugriffs

Informationen zur XML-Konfiguration finden Sie unter VPN-Profiloptionen und VPNv2-CSP.

Weitere Informationen zu bedingtem Zugriff und Microsoft Entra Health