EAP-TLS über NPS Problem
Hey Administratoren!
Ich habe seit 2 Tagen ein Problem und finde dafür einfach keine Lösung.
& ja ich weiß zu dem Thema gibt es hier viele Threads, aber ich bin leider nicht fündig geworden oder es hat mich nicht zum Ziel gebracht.
Wie bereits im Titel geschrieben, geht es um das Thema Integration eines RADIUS Server über NPS und Authentifizierung der kabelgebundenen Domänecomputer mittels EAP-TLS.
Zum Netzwerk:
Ich habe einen L3 Switch von Aruba auf dem Inter-VLAN Routing konfiguriert ist. Der L3 Switch befindet sich im Management VLAN90 und hat die IP: 192.168.168.227/26.
An diesem ist ein L2 Switch von Aruba 1930 tagged angeschlossen. Dieser befindet sich aktuell im VLAN200 mit der
IP: 10.10.10.10/27 (zu den Konfiguration komme ich weiter unten). Die hier zukünftig angeschlossenen Clients befinden sich im VLAN10 IP-Bereich 192.168.168.0/26.
Am L3 Switch ist des Weiteren mein Host ebenso tagged angeschlossen. Auf dem Host läuft das Betriebssystem Windows Server 2022. Hier habe ich den Dienst Hyper-V laufen und dort meine "Dienste" virtualisiert. Der Host befindet sich im VLAN90. Die virtualisierten Dienste wiederum im VLAN200 über den virtuellen Switch.
Dienste:
Ich habe ein AD konfiguriert siehe Anhang "lokaler server". Die Domäne heißt callhub.net.
Des Weiteren habe ich eine Zertifizierungsstelle über AD CA eingerichtet. Ebenso im Anhang abgebildet "Zertifizierungsstelle".
Abschließend habe ich den NPS Dienst aufgesetzt, eingerichtet und in die Domäne aufgenommen. Konfigurationen habe ich dafür im Anhang beigefügt.
Als RADIUS-Client möchte ich ein Layer-2 Switch von Aruba Model 1930 nutzen (Switch konfiguration im Anhang).
Nachdem ich die konfigurationen des NPS durchgeführt habe, habe ich mich ans schreiben der Computer-GPO gemacht, dafür habe ich nach einem Video Tutorial auf youtube gearbeitet. Screenshots der Details im Anhang.
Ich habe mir nachdem ich alles restartet habe die Ereignisberichte angeschaut, bis auf kleinere Sache die ich leicht beheben konnte war nichts. Komisch finde ich, dass bei vielen Dokumentationen direkt bei NPS Ereignise auftauchen, bei mir es aber komplett frei bleibt (Deswegen wäre meine Vermutung dass es am L2-Switch liegt).
Auf jeden fall habe ich dann, 1-2 Domänen-User erstellt und vereinzelt Computer angeschlossen in die Domäne aufgenommen und mich nach neustart mit den Test-User angemeldet und siehe da, sie können sich ohne Probleme ohne Zertifikat anmelden.
Hat mich sehr stutzig gemacht aber habe einfach keinen Fehler finden können, auch nach dem ich 2 mal komplett von 0 angefangen habe. Das Datasheed des L2-Switches macht mich einfach gar nicht schlauer.
Vielleicht seht ihr ja eine Fehlkonfiguration und habt eventuell eine Idee woran es hapert.
Ich bin euch jeder Hilfe dankbar!
Gerne auch Fragen stellen, wollte nicht zu ausführlich werden.
Lg Seb
Ich habe seit 2 Tagen ein Problem und finde dafür einfach keine Lösung.
& ja ich weiß zu dem Thema gibt es hier viele Threads, aber ich bin leider nicht fündig geworden oder es hat mich nicht zum Ziel gebracht.
Wie bereits im Titel geschrieben, geht es um das Thema Integration eines RADIUS Server über NPS und Authentifizierung der kabelgebundenen Domänecomputer mittels EAP-TLS.
Zum Netzwerk:
Ich habe einen L3 Switch von Aruba auf dem Inter-VLAN Routing konfiguriert ist. Der L3 Switch befindet sich im Management VLAN90 und hat die IP: 192.168.168.227/26.
An diesem ist ein L2 Switch von Aruba 1930 tagged angeschlossen. Dieser befindet sich aktuell im VLAN200 mit der
IP: 10.10.10.10/27 (zu den Konfiguration komme ich weiter unten). Die hier zukünftig angeschlossenen Clients befinden sich im VLAN10 IP-Bereich 192.168.168.0/26.
Am L3 Switch ist des Weiteren mein Host ebenso tagged angeschlossen. Auf dem Host läuft das Betriebssystem Windows Server 2022. Hier habe ich den Dienst Hyper-V laufen und dort meine "Dienste" virtualisiert. Der Host befindet sich im VLAN90. Die virtualisierten Dienste wiederum im VLAN200 über den virtuellen Switch.
Dienste:
Ich habe ein AD konfiguriert siehe Anhang "lokaler server". Die Domäne heißt callhub.net.
Des Weiteren habe ich eine Zertifizierungsstelle über AD CA eingerichtet. Ebenso im Anhang abgebildet "Zertifizierungsstelle".
Abschließend habe ich den NPS Dienst aufgesetzt, eingerichtet und in die Domäne aufgenommen. Konfigurationen habe ich dafür im Anhang beigefügt.
Als RADIUS-Client möchte ich ein Layer-2 Switch von Aruba Model 1930 nutzen (Switch konfiguration im Anhang).
Nachdem ich die konfigurationen des NPS durchgeführt habe, habe ich mich ans schreiben der Computer-GPO gemacht, dafür habe ich nach einem Video Tutorial auf youtube gearbeitet. Screenshots der Details im Anhang.
Ich habe mir nachdem ich alles restartet habe die Ereignisberichte angeschaut, bis auf kleinere Sache die ich leicht beheben konnte war nichts. Komisch finde ich, dass bei vielen Dokumentationen direkt bei NPS Ereignise auftauchen, bei mir es aber komplett frei bleibt (Deswegen wäre meine Vermutung dass es am L2-Switch liegt).
Auf jeden fall habe ich dann, 1-2 Domänen-User erstellt und vereinzelt Computer angeschlossen in die Domäne aufgenommen und mich nach neustart mit den Test-User angemeldet und siehe da, sie können sich ohne Probleme ohne Zertifikat anmelden.
Hat mich sehr stutzig gemacht aber habe einfach keinen Fehler finden können, auch nach dem ich 2 mal komplett von 0 angefangen habe. Das Datasheed des L2-Switches macht mich einfach gar nicht schlauer.
Vielleicht seht ihr ja eine Fehlkonfiguration und habt eventuell eine Idee woran es hapert.
Ich bin euch jeder Hilfe dankbar!
Gerne auch Fragen stellen, wollte nicht zu ausführlich werden.
Lg Seb
Kommentieren
Teilen
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 12314102806
Url: https://administrator.de/forum/eap-tls-ueber-nps-problem-12314102806.html
Ausgedruckt am: 03.06.2025 um 04:06 Uhr
4 Kommentare
Neuester Kommentar
Deswegen wäre meine Vermutung dass es am L2-Switch liegt
Das kannst du ja ganz einfach vorab testen und sicherstellen indem du an einem offenen (nicht .1x oder MAB) Port am Switch mit einem Client den Server pingst und vice versa.Zusätzlich pingt man vom CLI des Switches den Radius Server. Beides stellt dann sicher das die IP Connectivity der Infrastruktur generell ok ist und man das als Fehler sicher ausschliessen kann.
Du hast die Server Zertifikatsprüfung aktiviert auf dem .1x Client, was dann eine PKI erfordert und ein gültiges Server Zertifikat auf dem Radius Server bzw. einer vertrauenswürdigen CA (Stammzertifikat) auf dem Client.
Ist das nicht der Fall, solltest du das ggf. einmal testweise deaktivieren um nicht in diese Falle zu tappen.
Siehe zu der Thematik auch HIER.
Entscheidend ist aber immer das Radius Log wenn ein .1.x Client am Switchport aufgesteckt wird.
Heyho aqui
Die Infrastruktur steht, ich kann mit einem Client der am Switch angeschlossen ist (egal ob offenen oder .1x Port) den Server pingen.
Ich kann auch mit dem Switch den Server erreichen und umgekehrt auch. Der Switch hat aber leider keine CLI, sodass ich vermute ihn fehlen konfigurationen um ihn zum Authenticator upzugraden.
Ja genau das ist meine Absicht.
Ich habe hier "CallHubCA" als Stammzertifikat festgelegt. Mit der Computer-GPO habe ich die CA "CallHubCA" zur vertrauenswürdigen CA gemacht. Die CA hat die IP 10.10.10.1, welche ich ebenso angegeben habe.
Ich schaue nachher nochmal genau nach der RADIUS Log an, bin aber auch schon einmal zu dem Pfad den ich zum Speichern angegeben habe und dort war keine Log angelegt. - Deswegen weiter meine Vermutung der Switch ist hier das Problem. Soweit ich weiß fordert der Switch gemäß .1x jeden Client der sich anschließt auf sich zu authentifizieren, wenn er es nicht macht blockiert er alle Daten die der Client sendet bis auf die die für die Authentifizierung notwendig sind. Die Daten werden in einem anderen Protokoll verpackt und an den Authentifizierungsserver gesendet, dieser vergleicht, sendet zurück und der Switch kann den Port freischalten.
Aufgrund dessen, dass der Client sich ohne Probleme an die Domäne anmelden kann gehe ich davon aus, dass der Switch gar nicht erst als Authentificator handelt. Würde ja auch erklären weswengen keine Log entsteht wenn der RADIUS gar nicht erst handeln muss weil er ja keine Anfrage des Switches bekommt.
-Ich hoffe man versteht mein Gedankengang gerade haha
danke für deine Antwort und ein angenehmes Wochenende
Die Infrastruktur steht, ich kann mit einem Client der am Switch angeschlossen ist (egal ob offenen oder .1x Port) den Server pingen.
Ich kann auch mit dem Switch den Server erreichen und umgekehrt auch. Der Switch hat aber leider keine CLI, sodass ich vermute ihn fehlen konfigurationen um ihn zum Authenticator upzugraden.
Ja genau das ist meine Absicht.
Ich habe hier "CallHubCA" als Stammzertifikat festgelegt. Mit der Computer-GPO habe ich die CA "CallHubCA" zur vertrauenswürdigen CA gemacht. Die CA hat die IP 10.10.10.1, welche ich ebenso angegeben habe.
Ich schaue nachher nochmal genau nach der RADIUS Log an, bin aber auch schon einmal zu dem Pfad den ich zum Speichern angegeben habe und dort war keine Log angelegt. - Deswegen weiter meine Vermutung der Switch ist hier das Problem. Soweit ich weiß fordert der Switch gemäß .1x jeden Client der sich anschließt auf sich zu authentifizieren, wenn er es nicht macht blockiert er alle Daten die der Client sendet bis auf die die für die Authentifizierung notwendig sind. Die Daten werden in einem anderen Protokoll verpackt und an den Authentifizierungsserver gesendet, dieser vergleicht, sendet zurück und der Switch kann den Port freischalten.
Aufgrund dessen, dass der Client sich ohne Probleme an die Domäne anmelden kann gehe ich davon aus, dass der Switch gar nicht erst als Authentificator handelt. Würde ja auch erklären weswengen keine Log entsteht wenn der RADIUS gar nicht erst handeln muss weil er ja keine Anfrage des Switches bekommt.
-Ich hoffe man versteht mein Gedankengang gerade haha
danke für deine Antwort und ein angenehmes Wochenende
sodass ich vermute ihn fehlen konfigurationen um ihn zum Authenticator upzugraden.
Nein, das wäre Unsinn, denn ein .1x fähiger Switch ist ja per se immer Authenticator. Mit "Upgrade" hat das nichts zu tun wenn er das Feature supportet.meine Vermutung der Switch ist hier das Problem
Das kannst du ganz einfach verifizieren wenn du den Server Port einmal auf einem Mirror Port spiegelst und dir mit dem Wireshark den Radius Request ansiehst. Alternativ auf dem Server direkt oder mit einem Tap.Soweit ich weiß fordert der Switch gemäß .1x jeden Client der sich anschließt auf sich zu authentifizieren
Jepp, das ist richtig und auch klassisches 802.1x Verhalten aber auch nur wenn du die entsprechenden Ports mit einer Port Security Konfig versehen bzw. aktiviert hast. Wenn man die zu sichernden Ports nicht klassifiziert macht der Switch eben gar nichts in Bezug auf Radius.Beim Switch sind es immer 2 Dinge:
- Radius Server mit IP Adresse, Ports und Radius Passwort setzen
- Switchports die man sichern möchte für 802.1x oder MAB oder beides aktivieren
und dort war keine Log angelegt. - Deswegen weiter meine Vermutung der Switch ist hier das Problem
Das nährt in der Tat den Verdacht das der Switch gar keine Radius Requests schickt. Hier ist, wie immer, der Wireshark dein bester Freund das sicher zu verifizieren.Die Daten werden in einem anderen Protokoll verpackt und an den Authentifizierungsserver gesendet
Nein, das ist Unsinn, das ist alles Radius über Port 1812/1813. Siehe hier:https://en.wikipedia.org/wiki/RADIUS
gehe ich davon aus, dass der Switch gar nicht erst als Authentificator handelt.
Das ist ohne Frage das Naheliegenste. Kein Request, kein Zugang und auch kein Log. Einfache Logik... 
Fazit:
Checken ob überhaupt Radius Traffic vom Switch am Server ankommt!
Dein o.a. Radius Konfig Screenshot zeigt leider nur die globale Konfig des Radius Servers aber NICHT die für 802.1x aktivierten Ports so das zu befürchten ist das du das schlicht und einfach im Switch Setup vergessen hast und dann muss man sich auch nicht groß wundern das die Radius Kommunikation stumm bleibt.
Wie "richtige" Switch Hersteller sowas lösen kannst du u.a. hier sehen. Die Variante mit einem einfachen HPE Switch via Setup GUI dann u.a. hier.
