NPS / 802.1x Authentifizierung Wired nur erfolgreich, wenn vorher 1x mit Wifi verbunden?

[Wisi 12]

Hallo in die Runde, vielleicht hat jemand eine Idee zu dem Thema, ich habe jetzt einen guten Tag damit durch und verstehe es nicht.

Wir bauen gerade an unseren Netzen weiter in Richtung Restriktionen und sind gerade beim Schulungsbereich dabei die Ports dicht zu machen. Jetzt haben wir aber auch Devices, die nicht zu unseren Domänen gehören, oder auch schlichtweg Endgeräte wie Drucker etc. Soweit so gut und auch normal würde ich sagen. Jetzt haben wir gemäß der Anleitung hier https://administrator.de/en/nps-802-1x-radius-authentication-with-eap-tls-and-strong-certificate-mapping-for-non-domain-joined-devices-9670013529.html und ein paar wenigen Anpassungen Zertifikate für diese Geräte erzeugt und auf dem NPS Regeln zum Testen damit. 

 

Der NPS authentifiziert nun problemlos folgende Szenarien:

- Domänenrechner Wired und Wifi via Computerzertifikat

- Nicht-Domänenrechner Wifi mit Computerzertifikat

- Nicht-Domänenrechner Wired mit Computerzertifikat, ABER nur wenn bereits 1x das Wifi verbunden war

 

Ich hab das dann weiter geprüft und mir ist aufgefallen, dass auf dem Switch nach den initialen Verbindungen Ruhe herrschte und man auf den Client wartet, dass der weiter reagiert. Sprich die Pakete gehen zum NPS, dort wird gematched und dann soll der Client wohl die eigentliche Verbindung aufbauen, das tut er aber nicht. Aus Verzweiflung habe ich dasselbe Konstrukt dann gleich im WIFI nachgebaut und es ging innerhalb von Sekunden. Dort habe ich dann wohl auch festgestellt woran es gescheitert ist ursprünglich mit der Verbindung: die Prüfung vom Zertifikat vom Gegenüber. Ich habe dann unter der Wifi Verbindung im Reiter Sicherheit -> Einstellungen bei der Identitätsprüfung unsere Root-CA noch ausgewählt und schwupps, keine Frage mehr, ob ich verbinden will und die Verbindung steht. Als ich das noch nicht gemacht habe, kam direkt nach der bestehenden WIFI Verbindung ein Fenster vom Wired Zugang, der auch danach gefragt hat, ob ich mich mit dem Netzwerk verbinden will, ebenfalls bestätigt, auch drin. Also hatten beide Verbindungen das gleiche Problem zu Beginn. Also gedacht, ist ja einfach, dasselbe in der Wired Verbindung gemacht und einen Reboot zur Sicherheit. Blödes Gesicht gemacht: geht nicht. Dann wieder manuell die WIFI Verbindung aufgebaut und direkt danach das Kabel neu gesteckt und schwupps, direkt wieder war die WIRED Verbindung da und bleibt, auch wenn ich dann WIFI trenne, das Kabel mal ziehe etc., aber nur bis zum Reboot.

 

Das bedeutet für mich: irgendwas wird bei der WIFI Verbindung bestätigt, was dann auch für die WIRED gilt im Sinne von Verbindungsprüfung oder ähnlichem. Jetzt kann ich natürlich nicht immer von diesen Clients parallel Verbindungen von WIFI und WIRED aufbauen, das macht keinen Sinn und geht auch nicht überall.

 

Was habe ich bereits probiert:

 

- Identitätsprüfung ganz aus

- Namen vom NPS Server rein und Root CA angehakt

- Namen wieder raus und Root CA angehakt

 

Egal welche von den Optionen ich einstelle, sobald WIFI verbunden war, sind alle davon funktionsfähig!

 

Insofern: hat jemand eine Idee was das sein könnte?

 

Logfile (Debug vom Switch) im Anhang zeigt folgendes:

 

- Reboot Rechner, dann Versuch der Verbindung

- Trennung Netzwerkkabel

- (Verbindung Wlan)

- (Trennung Wlan)

- Verbindung Netzwerkkabel -> jetzt geht es!

- Trennung Netzwerkkabel -> geht immer noch (bis Reboot...)

 

Auf dem NPS nichts interessantes zu sehen, der sagt in den NI* Logs nur, dass immer Successful ist und im Eventviewer vom NPS wird bei "Nichtverbindung" auch nichts abgelegt. Das macht aber auch Sinn, weil er wohl auf den Client wartet und der nichts schickt. Auf dem Client im Eventviewer sieht man nur den Start der Authentifizierung und den Timeout davon.

802.txt

[daabm 1.185]

Dieses Eventlog kennst Du? Microsoft-Windows-Wired-AutoConfig/Operational

Und der Wired Autoconfig Service läuft auch? dot3svc

 

[Wisi 12]

Ja und ja. Wie beschrieben, ist quasi nichts drin außer dem Timeout.

 

Wenn es ging, steht dort das hier:

 

Die 802.1X-Authentifizierung (verkabelt) war erfolgreich.

    Netzwerkadapter: Realtek PCIe GbE Family Controller
    Schnitstellen-GUID: {23b48a6d-88c5-4b72-890f-98ff56c0c0f3}
    Peeradresse: 94F1280FE600
    Lokale Adresse: E454E819D29E
    Verbindungs-ID: 0x3
    Identität: host/kunde-A19D29E.kunde.de
    Benutzer: -
    Domäne: -
    Ursache: 0x0
    Ursachentext: Der Vorgang war erfolgreich.
    Fehlercode: 0x0

 

Ansonsten immer diese Abfolge (unendlich):

 

802.1X-Authentifizierung (verkabelt) wurde gestartet.

    Netzwerkadapter: Realtek PCIe GbE Family Controller
    Schnittstellen-GUID: {23b48a6d-88c5-4b72-890f-98ff56c0c0f3}
    Verbindungs-ID: 0x1

802.1X-Authentifizierung (verkabelt) wurde neu gestartet.

    Netzwerkadapter: Realtek PCIe GbE Family Controller
    Schnittstellen-GUID: {23b48a6d-88c5-4b72-890f-98ff56c0c0f3}
    Verbindungs-ID: 0x1
    Grund für den Neustart: Zeitüberschreitung bei Onex-Authentifizierung

Die 802.1X-Authentifizierung (verkabelt) ist fehlgeschlagen.

    Netzwerkadapter: Realtek PCIe GbE Family Controller
    Schnittstellen-GUID: {23b48a6d-88c5-4b72-890f-98ff56c0c0f3}
    Peeradresse: 94F1280FE600
    Lokale Adresse: E454E819D29E
    Verbindungs-ID: 0x1
    Identität: -
    Benutzer: -
    Domäne: -
    Ursache: 0x70004
    Ursachentext: Das Netzwerk beantwortet keine Authentifizierungsanforderungen mehr.
    Fehlercode: 0x0

 

bearbeitet 10. Januar von Wisi

[lukas2002 1]

Hallo,

 

bei Administrator.de ist auch ein Beitrag dazu https://administrator.de/forum/nps-802-1x-authentifizierung-wired-nur-erfolgreich-wenn-vorher-1x-mit-wifi-verbunden-84147913075.html 

 

Scheint nur da keiner drauf zu reagieren.

 

Gruß Lukas

[Wisi 12]

Ja, da ja dort der Ursprung der Anleitung her war und durchaus auch unterschiedliche Leute hier und dort unterwegs sind. In beiden Foren gibt es nach meiner Erfahrung gute Leute. Schade, dass bisher wohl keiner weiß wo das Problem zu suchen ist. Im Zweifelsfall, wenn jemand Lust hat daran ein paar Euro zu verdienen, werfe ich auch was in die Büchse und berichte dann hier für die Community die Lösung am Ende. Hauptsache wir kriegen das vom Tisch. Ich weiß derzeit leider nur eben auch noch nicht welchen von unseren Dienstleistern ich konkret mit diesem Thema ran kriege, da die grundsätzlichen Dinge klar sind und derjenige etwas Ahnung davon haben sollte und nicht bei mir erst die Expertise sich anlernt. Leider zu oft in letzter Zeit erlebt bei spezifischen Themen.

[lukas2002 1]

Welches Betriebssystem nutzt du denn auf den Clients und Servern?

 

Bei den Clients wäre auch die Edition und Version interessant...

 

Ich arbeite zwar nicht viel mit NPS aber vielleicht kann ich dir trotzdem helfen. 

[Wisi 12]

Aktuell ist der NPS selbst tatsächlich leider noch ein Windows 2012, auf den Clients Windows 10 Pro 22H2. Das aber nur zum Testen. Letztlich sollen natürlich auch Drucker etc. damit angebunden werden.

[zahni 521]

Ich kann nur ganz allgemein sagen (bei uns wird eine Lösung vom Herstelle der Switche benutzt): 

Haben die PC's Intel vPro oder AMT konfiguriert? Das kann regelmäßig die Switche durcheinander bringen und die Geräte landen dann im Isolationsnetz.

Am besten den Krempel im BIOS abschalten. Allerdings kann es hier noch ein Problem mit den div. Zertifikaten geben. Ich würde mich zunächst mal auf das interne Zertifikat konzentrieren.

 

[Wisi 12]

Sehe ich ähnlich, weil haben wir auf den Notebooks nicht (konfiguriert). Das mit dem Zertifikat glaube ich daher auch, weil es geht ja sofort, nachdem WIFI verbunden wurde. Mir fehlt nur ein Ansatzpunkt wie ich weitere Logs/Details dem PC entlocken kann. Weil bisher ist das Debug vom Switch das interessanteste was ich überhaupt sehen kann.

 

Ich benutze für WIFI und WIRED auch dasselbe Zertifikat, das heißt am Zertifikat selbst kann es dann ja eigentlich eher nicht liegen meiner Meinung nach.

[lukas2002 1]

vor 54 Minuten schrieb Wisi:

Sehe ich ähnlich, weil haben wir auf den Notebooks nicht (konfiguriert). Das mit dem Zertifikat glaube ich daher auch, weil es geht ja sofort, nachdem WIFI verbunden wurde. Mir fehlt nur ein Ansatzpunkt wie ich weitere Logs/Details dem PC entlocken kann. Weil bisher ist das Debug vom Switch das interessanteste was ich überhaupt sehen kann.

 

Ich benutze für WIFI und WIRED auch dasselbe Zertifikat, das heißt am Zertifikat selbst kann es dann ja eigentlich eher nicht liegen meiner Meinung nach.

Da sich WIFI automatisch konfiguriert sollte das im Normalfall meistens funktionieren. Schau mal ob du auf dem WIRED Interface bisschen rumkonfigurieren kannst.

Das WIRED Interface funktioniert bei mir auch nicht auf Anhieb, WIFI hat bei uns von Anfang an ohne Probleme funktioniert, bis auf ein bisschen Kosmetik.

 

 

[Wisi 12]

Egal was ich konfiguriere, es geht nicht. Sobald ich aber die WIFI Verbindung hergestellt habe, funktioniert es dauerhaft bis zum Reboot. Das heißt zum einen für mich, dass die Richtlinien stimmen, sonst dürfte es gar nicht gehen, zum anderen dass es kein Problem bezüglich der Zertifikate im Grundsatz gibt, sondern es was im Bereich der Verifizierung der Gegenstelle sein muss, was dann durch die Verbindung vom WIFI überschrieben wird.

 

So ähnlich sieht es scheinbar auch aus, wenn wir Drucker verbinden wollen über den Weg. Allerdings kommt es dort "wenigstens" zu einem Abbruch der Verbindung mit einem Fehler und nicht nur zu einem Timeout:

 

NAS IP: 192.168.101.5
Client Username: PRT-KM8EECE6$@kunde.schulung.de
Timestamp: 01/11/2024 17:44:07
Service: IAS
RADIUS Server: kundeK01SV01
Class: 311 1 192.168.101.27 01/09/2024 18:11:56 1278
EAP-Friendly-Name: Microsoft: Smartcard- oder anderes Zertifikat
NP-Policy-Name: test
Authentication-Type: 5
Fully-Qualified-User-Name: kunde\PRT-KM8EECE6$
SAM-Account-Name: kunde\PRT-KM8EECE6$
Provider-Type: Windows
Proxy-Policy-Name: Windows-Authentifizierung für alle Benutzer verwenden
Client-Friendly-Name: HPE Aruba 5412R
NAS-Manufacturer: 0
Client-IP-Address: 192.168.101.5
Packet-Type: Access-Reject
Reason-Code: undefined
--------------------------------------------

 

	Authentifizierungstyp:		EAP
	EAP-Typ:			Microsoft: Smartcard- oder anderes Zertifikat
	Kontositzungs-ID:		-
	Protokollierungsergebnisse:			Die Kontoinformationen wurden in die lokale Protokolldatei geschrieben.
	Ursachencode:			262
	Ursache:				Die angegebene Nachricht ist unvollständig. Die Signatur wurde nicht verifiziert.

 

Der Fehler 262 deutet laut dem was ich gefunden habe darauf hin, dass das Gegengerät das Zertifikat nicht prüfen kann. Beim Kyocera Drucker haben wir das Clientzertifikat als PFX importiert, also hat er dadurch auch die komplette Chain inkl. ROOT-CA und Enterprise-SubCA bekommen.

[daabm 1.185]

Am 10.1.2024 um 18:54 schrieb Wisi:

Ursachentext: Das Netzwerk beantwortet keine Authentifizierungsanforderungen mehr.

 

Mit der Meldung im Backlog würde ich mich jetzt mit den verantwortlichen Netzern zusammensetzen. Da stimmt irgendwas nicht (wir haben auch 802.1x am Start, und das läuft problemlos). Windows-seitig kannst Du höchstens noch schauen, ob in anderen Eventlogs zeitlich korrelierende Einträge vorhanden sind.

 

Ich weiß, das ist ein diffuser Ansatz, aber das ist es ja meistens in solchen Fällen. Traces könnten auch hilfreich sein, ob man irgendwas mit Retransmits sieht. Aber hier verlasse ich diesen Thread, das ist nichts für eine Diskussion in einem Forum.