802.1x Cert auth über WLAN funktioniert nicht bei Anmeldung über Win7 Notebook
Hallo Community!
Ich bin langsam etwas am verzweifeln.
Wir haben seit einer Weile das Problem, dass alle unsere Windows 7 Notebooks, nicht mehr in der Lage sind, sich über WLAN an der Domäne rechtzeitig anzumelden. Die Authentifizierung am WLAN findet über ein persönliches Nutzerzertifikat statt.
Was passiert?
- Anmeldung über WLAN dauert sehr lange, sofern sich der Client versucht an unserem MitarbeiterWLAN anzumelden.
- Über GPO gemappte Laufwerke tauchen nicht auf.
- Richtlinien greifen kaum.
- Trotz nachträglicher Anmeldung am WLAN, tauchen die Laufwerke trotz eines GPUPDATE /FORCE nicht auf.
- Unter Verwendung eines Pre Shared Keys, an Stelle des Zertifikats funktioniert alles Reibungslos
- ERROR Logs der Reihenfolge nach = NETLOGON 5719, GroupPolicy 1129, Time-Service 129
Was habe ich getestet?
- Ich habe mich an folgender Seite von Microsoft orientiert und dort vorgeschlagene Lösungen getestet: https://support.microsoft.com/en-sg/help/938449/netlogon-event-id-5719-o ...
- 2 Notebooks aus unterschiedlichen OU's zum Test verwendet.
- Zertifikat erneuert
- TestSSID mit gleichen Einstellungen aufgebaut.
- Aerohive Access-Points auf Fehler überprüft (Zeit, auth usw.)
- Ich habe die Logs auf dem Radius durchgesehen, und es wurde kein Fehler gemeldet.
Habt ihr eine Ahnung, woran das noch liegen könnte?
Ich bin langsam etwas am verzweifeln.
Wir haben seit einer Weile das Problem, dass alle unsere Windows 7 Notebooks, nicht mehr in der Lage sind, sich über WLAN an der Domäne rechtzeitig anzumelden. Die Authentifizierung am WLAN findet über ein persönliches Nutzerzertifikat statt.
Was passiert?
- Anmeldung über WLAN dauert sehr lange, sofern sich der Client versucht an unserem MitarbeiterWLAN anzumelden.
- Über GPO gemappte Laufwerke tauchen nicht auf.
- Richtlinien greifen kaum.
- Trotz nachträglicher Anmeldung am WLAN, tauchen die Laufwerke trotz eines GPUPDATE /FORCE nicht auf.
- Unter Verwendung eines Pre Shared Keys, an Stelle des Zertifikats funktioniert alles Reibungslos
- ERROR Logs der Reihenfolge nach = NETLOGON 5719, GroupPolicy 1129, Time-Service 129
Was habe ich getestet?
- Ich habe mich an folgender Seite von Microsoft orientiert und dort vorgeschlagene Lösungen getestet: https://support.microsoft.com/en-sg/help/938449/netlogon-event-id-5719-o ...
- 2 Notebooks aus unterschiedlichen OU's zum Test verwendet.
- Zertifikat erneuert
- TestSSID mit gleichen Einstellungen aufgebaut.
- Aerohive Access-Points auf Fehler überprüft (Zeit, auth usw.)
- Ich habe die Logs auf dem Radius durchgesehen, und es wurde kein Fehler gemeldet.
Habt ihr eine Ahnung, woran das noch liegen könnte?
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: 397030
Url: https://administrator.de/forum/802-1x-cert-auth-ueber-wlan-funktioniert-nicht-bei-anmeldung-ueber-win7-notebook-397030.html
Ausgedruckt am: 29.04.2025 um 22:04 Uhr
6 Kommentare
Neuester Kommentar
Moin,
wie sieht eure Infrastruktur bezüglich Services aus:
Gruß,
Dani
wie sieht eure Infrastruktur bezüglich Services aus:
- ein- oder zweistufige PKI? Mit Windows oder Linux?
- Ist der Radiusserver ein Windows NPS?
- Sind evtl. die Sperrlisten abgelaufen und nicht erneuert?
- Sperrlisten des ausgestellten Zertifikats erreichbar?
- Zertifikat des NPS-Server bzw. Services abgelaufen?
Gruß,
Dani
Moin moin,
danke erstmal für deine Antwort!
- Eigentlich zweistufige PKI mit Windows only, aber die Root-CA ist nicht offline. Warum das so ist, muss ich mir erst noch von meinem Kollegen erklären lassen.
- Der NPS ist unser onsite DC - 2008 R2
- Ich werde online leider nicht richtig fündig, wenn es um die Sperrlisten geht. Wie kann ich das nachprüfen? Ich versuch mich momentan da selbst rein zu lernen, da mein Chef der Einzige hier ist, der das eventuell wüsste, aber der ist noch eine Weile im Urlaub...
- Zertifikat vom DC (NPS) scheint noch eine Weile gültig zu sein. Sollte ein anderes ungültig sein, sollte das eigentlich auch im Eventlog einsehbar sein? Ich erkenne zumindest keine ungültigen.
danke erstmal für deine Antwort!
- Eigentlich zweistufige PKI mit Windows only, aber die Root-CA ist nicht offline. Warum das so ist, muss ich mir erst noch von meinem Kollegen erklären lassen.
- Der NPS ist unser onsite DC - 2008 R2
- Ich werde online leider nicht richtig fündig, wenn es um die Sperrlisten geht. Wie kann ich das nachprüfen? Ich versuch mich momentan da selbst rein zu lernen, da mein Chef der Einzige hier ist, der das eventuell wüsste, aber der ist noch eine Weile im Urlaub...
- Zertifikat vom DC (NPS) scheint noch eine Weile gültig zu sein. Sollte ein anderes ungültig sein, sollte das eigentlich auch im Eventlog einsehbar sein? Ich erkenne zumindest keine ungültigen.
Moin,
Erster Anlaufpunkt ist der Server, auf dem die Intermediate CA (SubCA) läuft. Dort die pkiview.msc starten. Dort kannst die Basics wie Sperrlistenpunkte, Erreichbarkeit und Gültigkeit prüfen.
Gruß,
Dani
Warum das so ist, muss ich mir erst noch von meinem Kollegen erklären lassen.
Ich hab da eine Vermutung: Sperrlisten ist das Thema. Mehr will ich noch nicht verrraten... Der NPS ist unser onsite DC - 2008 R2
Sehr schön... gut das es eine nicht geschriebene Regel gibt: Ein DC ist ein DC und nichts anderes. Ich werde online leider nicht richtig fündig, wenn es um die Sperrlisten geht.
Das meiste dazu wirst du im Englischen unter Revocation List dazu finden. Es gibt leider nur sehr wenige Artikel im Deutschen dazu - die nicht nur an der Oberfläche kratzen.Erster Anlaufpunkt ist der Server, auf dem die Intermediate CA (SubCA) läuft. Dort die pkiview.msc starten. Dort kannst die Basics wie Sperrlistenpunkte, Erreichbarkeit und Gültigkeit prüfen.
Zertifikat vom DC (NPS) scheint noch eine Weile gültig zu sein.
Das Wort "Scheint" gibt es bei IT-Admins im Wörterbuch nicht. Ja oder Nein.Sollte ein anderes ungültig sein, sollte das eigentlich auch im Eventlog einsehbar sein? Ich erkenne zumindest keine ungültigen.
Wir überwachen nicht das EventLog jeden Servers (wäre zu viel und damit unnötig Last auf dem Monitoring Server). Wir prüfen per Skript die Zertfikate, welche die jeweilige PKI ausgestellt hat und bei einem Wert kleiner,gleich 30 Tage gibts ne E-Mail an das jeweilige Application Team.Gruß,
Dani
Zitat von @Dani:
Der NPS ist unser onsite DC - 2008 R2
Sehr schön... gut das es eine nicht geschriebene Regel gibt: Ein DC ist ein DC und nichts anderes. War leider schon vor meinem Eintritt so.
Das meiste dazu wirst du im Englischen unter Revocation List dazu finden. Es gibt leider nur sehr wenige Artikel im Deutschen dazu - die nicht nur an der Oberfläche kratzen.
Erster Anlaufpunkt ist der Server, auf dem die Intermediate CA (SubCA) läuft. Dort die pkiview.msc starten. Dort kannst die Basics wie Sperrlistenpunkte, Erreichbarkeit und Gültigkeit prüfen.
Erster Anlaufpunkt ist der Server, auf dem die Intermediate CA (SubCA) läuft. Dort die pkiview.msc starten. Dort kannst die Basics wie Sperrlistenpunkte, Erreichbarkeit und Gültigkeit prüfen.
Danke für den Hinweis! Habe mir das ganze auch mal angesehen und konnte keine Fehler feststellen. In den CRL's sind keine gesperrten Zertifikate aufgelistet. Die Listen sind auch noch gültig.
Das Wort "Scheint" gibt es bei IT-Admins im Wörterbuch nicht. Ja oder Nein.
Ist gültig.
Wir überwachen nicht das EventLog jeden Servers (wäre zu viel und damit unnötig Last auf dem Monitoring Server). Wir prüfen per Skript die Zertfikate, welche die jeweilige PKI ausgestellt hat und bei einem Wert kleiner,gleich 30 Tage gibts ne E-Mail an das jeweilige Application Team.
Ist natürlich sinnvoll. Haben wir hier leider nicht im Einsatz. Wäre wohl eine Überlegung wert.Was ich noch vergessen hatte zu erwähnen. Wir haben ja das Problem mit unseren Windows 7 Notebooks. Ich habe das gleiche mit unseren Win 10 Notebooks getestet und habe festgestellt, dass der Anmeldevorgang im WLAN wesentlich schneller geht. Die Laufwerke kommen nicht automatisch, lassen sich aber nach einem gpupdate /force wieder einbinden. Das klappt leider nicht bei Win 7.
Wenn man direkt nach der Anmeldung rsop.msc aufruft und die Fehlerinformation prüft, erscheint folgende Meldung
Computerkonfiguration: Gruppenrichtlinieninfrastruktur - Gescheitert ... Das Netzwerk ist nicht vorhanden, oder wurde nicht gestartet
Aufgrund einer allgemeinen Schutzverletzung wurde keine der Richtlinien der anderen Gruppenrichtlinienkomponenten verarbeitet. Daher sind keine Statusinformationen für die anderen Kompenenten verfügbar.
Benutzerkonfiguration: Das gleiche wie oben (Wobei ich in der Vergangenheit auch Fehler in Bezug auf Zeitsynchronisation fand. Allerdings ließ sich Server seitig keine Differenz feststellen.)
Danke nochmal für deine Zeit!
Grüße
Moin,
Gruß,
Dani
Was ich noch vergessen hatte zu erwähnen. Wir haben ja das Problem mit unseren Windows 7 Notebooks.
einmal einen kompletten erfolgreichen Anmeldevorgang mit Wireshark mit schneiden. Zum einen siehst du welche Steps zu welcher Zeit durchgeführt werden und evtl. welche Adressen oder Server er versucht zu erreichen. Danach das Prokoll des NPS-Server an schauen sowie die Ereignisanzeige des Servers auf dem der NPS-Service bzw. Sub-CA läuft. Evtl. tauchen dort Warnungen oder sogar Fehlermeldungen auf.Gruß,
Dani
1
Ich muss gucken, ob ich diesen Monat die Zeit dafür aufbringen kann. Ich wechsel zum Monatswechsel das Unternehmen. Das Mitschneiden an sich, ist kein Problem, aber wie ich den Verkehr auch über ein anderes Gerät entschlüsseln kann, muss ich erst noch herausfinden.
Sollte ich mich diesbezüglich nicht mehr melden, bedanke ich mich trotzdem nochmals für deine Zeit.
Sollte ich mich diesbezüglich nicht mehr melden, bedanke ich mich trotzdem nochmals für deine Zeit.
