Intune, SCEP und ClearPass: EAP-TLS und Geräteautorisierung verstehen
Technischer Hintergrund zu EAP-TLS mit Intune und ClearPass: Geräteidentität, Entra-Gruppen, Attribut-Mapping, Root-CA und WPA3-Enterprise.
Ein vorhandenes Gerätezertifikat garantiert noch keinen WLAN-Zugriff. Für eine erfolgreiche Verbindung müssen Zertifikatsauthentifizierung, Geräteautorisierung und Serververtrauen zusammenpassen. Bei WPA3 kommen die Anforderungen des gewählten Sicherheitsmodus hinzu.
Der folgende Aufbau verwendet Windows-Geräte, Intune-SCEP-Zertifikate, ClearPass und Entra-Gerätegruppen.
Zertifikat prüfen und Netzwerkzugriff erlauben
EAP-TLS prüft die Identitäten anhand von Zertifikaten. ClearPass entscheidet anschließend anhand seiner Regeln, welche Netzwerkberechtigung die Verbindung erhält.
Damit sind zwei Ergebnisse möglich:
- Das Clientzertifikat wird akzeptiert.
- Die gewünschte Freigaberegel greift trotzdem nicht, weil benötigte Gruppenattribute fehlen oder falsch referenziert werden.
Eine erfolgreiche EAP-TLS-Authentifizierung bedeutet daher noch keine erfolgreiche Autorisierung.
Im Access Tracker müssen Authentifizierungsergebnis, zurückgegebene Autorisierungsattribute und angewendetes Enforcement-Profil gemeinsam betrachtet werden. Ein Default-Reject allein erklärt die Ursache nicht.
Ursprünglicher Fehlerzustand im Access Tracker: Fehler 206 mit Reject-Profil. Der Ausschnitt allein erklärt noch nicht, welcher Prüfschritt die Freigabe verhindert.
Die Zertifikatsidentität muss zum Geräteobjekt passen
Für eine gruppenbasierte Gerätefreigabe muss ClearPass das passende Entra-Geräteobjekt ermitteln.
Dabei sind drei Kennungen zu unterscheiden:
| Kennung | Bedeutung |
|---|---|
| Intune-Geräte-ID | Identifiziert das verwaltete Gerät innerhalb von Intune |
Entra-deviceId | Gerätekennung in Entra ID |
Entra-Objekt-id | Objektkennung des Entra-Verzeichnisobjekts |
Im beschriebenen Aufbau enthält das Clientzertifikat die Entra-Geräte-ID. Die ClearPass-Abfrage muss genau diese Identität aus dem ausgestellten Zertifikat auslesen und damit das zugehörige Entra-Geräteobjekt finden.
Hinweis
Maßgeblich ist der tatsächliche Zertifikatsinhalt auf dem Client. Die Intune-Profilkonfiguration allein reicht als Nachweis nicht aus. Details zur Identität im SCEP-Profil beschreibt die Microsoft-Dokumentation.
Eine vorhandene Benutzerabfrage lässt sich dafür nicht unverändert übernehmen: Benutzergruppen und Gerätegruppen gehören zu unterschiedlichen Verzeichnisobjekten. HPE beschreibt beide Abfragen getrennt in der Dokumentation zur Entra-ID-Autorisierungsquelle.
Benutzerabfrage und zugehöriges Mapping. Für die Geräteautorisierung werden stattdessen das Geräteobjekt und dessen Gruppenmitgliedschaften benötigt.
Abfrage, Mapping und Policy bilden eine Einheit
ClearPass stellt die abgefragten Informationen über konfigurierte Aliase bereit. Beispielsweise:
| Antwortfeld | Alias |
|---|---|
device.deviceId | EntraDeviceID |
device.displayName | DeviceName |
deviceGroups.displayName | DeviceGroups |
Geräte-Mapping mit den Aliasen für Geräte-ID, Gerätename und Gerätegruppen.
Die Enforcement-Regel muss anschließend den tatsächlich gelieferten Alias verwenden:
Authorization:Entra-Devices:DeviceGroups
CONTAINS WLAN-WindowsDie Namen sind beispielhaft und an die eigene Konfiguration anzupassen.
Fordern bestehende Regeln weiterhin Benutzerattribute wie Groups oder AccountEnabled an, können Meldungen wie diese entstehen:
Can't get ordered filters for attributes
Failed to get value for attributes=AccountEnabled, GroupsDas bedeutet nicht zwangsläufig, dass eine Gruppenmitgliedschaft fehlt. ClearPass kann bereits die angeforderten Attribute keinem passenden Filter zuordnen.
Nach einem Wechsel der Autorisierungsquelle müssen deshalb auch deren Referenzen geprüft werden. Eine Kontostatusprüfung darf dabei nicht ohne fachliche Prüfung durch eine Gruppenbedingung ersetzt werden.
Serververtrauen im Intune-WLAN-Profil
Neben der Prüfung des Clientzertifikats muss Windows dem Zertifikat des RADIUS-Servers vertrauen.
Wichtig
Im beschriebenen Setup war unter Root certificates for server validation zunächst die Sub-CA ausgewählt. Nach Auswahl des vertrauenswürdigen Zertifikatprofils mit der passenden Root-CA funktionierte die Verbindung.
Diese Einstellung betrifft die Vertrauenskette des RADIUS-Serverzertifikats. Sie ist von der ausstellenden CA des SCEP-Clientzertifikats zu unterscheiden.
Zusätzlich müssen konfigurierte Certificate server names zur erwarteten Serveridentität passen. Die Zertifikatsprüfung bleibt aktiv; korrigiert wird der Vertrauensanker. Die Einstellungen beschreibt Microsoft in der Dokumentation zu Windows-WLAN-Profilen in Intune.
WPA3-Enterprise: Der konkrete Modus zählt
WPA3-Enterprise mit CCM 128 und WPA3-Enterprise mit CNSA stellen unterschiedliche Anforderungen an die beteiligten Komponenten.
Im beschriebenen Setup funktionierte WPA3-Enterprise mit CCM 128. Die zunächst ausgewählte CNSA-Konfiguration stellte zusätzliche Anforderungen an Zertifikate und Kryptografie, zu denen das vorhandene RSA-2048-Gerätezertifikat nicht passte. Die Unterschiede erläutert die HPE-Dokumentation zu WPA3-Enterprise.
Das Menü zeigt die angebotenen Varianten. Markiert ist hier noch die ursprüngliche CNSA-Einstellung. Erfolgreich getestet wurde anschließend WPA3-Enterprise (CCM 128).
Warnung
Ein erfolgreicher CCM-128-Test bestätigt keine CNSA-Kompatibilität. Wenn CNSA vorgegeben ist, müssen Client, WLAN-Infrastruktur, EAP-TLS-Konfiguration und Zertifikate diese Anforderungen gemeinsam erfüllen.
Prüfpunkte bei einer abgelehnten Verbindung
- Authentifizierung: Welches Ergebnis liefert EAP-TLS für den konkreten Verbindungsversuch?
- Identität: Führt die Zertifikatskennung zum richtigen Entra-Geräteobjekt?
- Autorisierung: Werden die erwarteten Gerätegruppen zurückgegeben?
- Policy: Stimmen die verwendeten Attributnamen mit dem Mapping überein?
- Serververtrauen: Passen Root-CA, RADIUS-Serverzertifikat und konfigurierte Servernamen zusammen?
- WLAN-Modus: Erfüllen alle Komponenten die Anforderungen der gewählten WPA3-Variante?