none
802.1x Cert auth über WLAN funktioniert nicht bei Anmeldung über Win7 Notebook

    Frage

  • 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-or-group-policy-event-1129-is-logged-when-you-s

    - 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?

     


    Mittwoch, 2. Januar 2019 11:15

Alle Antworten

  • Moin,

    zwei Dinge:

    1. Du schreibst "alle unsere Win7-Notebooks". Gibt es denn andere Geräte, bei denen 802.1X gegen die gleiche Infrastruktur nach wie vor ordnungsgemäß funktioniert?
    2. Hat der RADIUS möglicherweise Probleme, an die Sperrliste für die Client-Zertifikate zu kommen? Hat sich da irgendwas geändert, z.B. LDAP als erster CDP und HTTP als zweiter, was vorher umgekehrt war?

    Evgenij Smirnov

    I work @ msg services ag, Berlin -> http://www.msg-services.de
    I blog (in German) @ http://it-pro-berlin.de
    my stuff in PSGallery --> https://www.powershellgallery.com/profiles/it-pro-berlin.de/
    Exchange User Group, Berlin -> https://exusg.de
    Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
    Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com


    In theory, there is no difference between theory and practice. In practice, there is.

    Mittwoch, 2. Januar 2019 11:26
  • Moin moin,

    danke erstmal für deine Antwort!

    Ja, es liegt in der Tat momentan nur an den Windows 7 Clients. Ausschließlich wir in der IT verwenden Win10 zu testzwecken. Die Anmeldung am Win10 Notebook im WLAN geht schneller. Zwar kommen die Laufwerke erst durch ein gpupdate /force, aber sie kommen immerhin. Bei den 7ern hingegen tut sich rein gar nichts. 

    Hätte der NPS probleme auf die Sperrliste zuzugreifen, würde er dies doch über das Ereignisprotokoll mitteilen, oder irre ich mich? Mir sind keine Änderungen an der config des NPS bekannt.

    Mittwoch, 2. Januar 2019 11:57
  • Hi,
     
    Am 02.01.2019 um 12:57 schrieb G4nj4Wizard:
    > [...] Zwar kommen die Laufwerke erst durch ein gpupdate /force,
    > aber sie kommen immerhin. Bei den 7ern hingegen tut sich rein gar nichts.
     
    GPP Drive Mapping läuft erst ab 8.1 im Hintergrund. In Win7 nur als
    Vordergrund bei Sessio Creation.
    Mit anderen Worten in Win7, ohne Netzwerk, keine Kekse.
     
    Tschö
    Mark
    --
    Mark Heitbrink
     
    Homepage:  http://www.gruppenrichtlinien.de - deutsch
     
    GET Privacy and DISABLE Telemetry on Windows 10
     
    Mittwoch, 2. Januar 2019 14:29
  • Das ist ja nur die halbe Wahrheit, kollege.

    Denn nach deiner Logik, müssten die Laufwerke ja kommen sobald das Netzwerk verbunden ist. Ich muss das WLAN zwar händisch wieder verbinden, aber dadurch das ich mich authentifizeren konnte, müssten sie ja wieder kommen. Da das aber trotz eines händischen Updates nicht geschieht, muss doch woanders der Wurm drin sein?

    Mittwoch, 2. Januar 2019 15:02
  • Hi,
     
    Am 02.01.2019 um 16:02 schrieb G4nj4Wizard:
    > Denn nach deiner Logik, müssten die Laufwerke ja kommen sobald das Netzwerk
    > verbunden ist.
     
    Nein. Du hast nur den Begriff nicht richtig verstanden.
     
    Das Netzwerk muss VOR der Benutzer Anmeldung vorhanden sein, das ist
    dann "Vordergrund". gpupdate per Hand ist zB ein Hintergrund Prozess, da
    die Sitzung schon existiert.
     
    DriveMapping kann erst ab 8.1 im Hintergrund ausgführt werden, es ist
    dann also egal "wann" das Netzwerk verbunden wird und das erklärt dann
    auch dein funktionierendes gpupdate bei den Windows 10 Clients, was bei
    Windows 7 ins Leere läuft, da die DLL (gpprefcl.dll) die das
    DriveMapping macht in Win7 nur bei der Anmeldung aufgerufen wird.
     
    Tschö
    Mark
    --
    Mark Heitbrink
     
    Homepage:  http://www.gruppenrichtlinien.de - deutsch
     
    GET Privacy and DISABLE Telemetry on Windows 10
     
    Samstag, 5. Januar 2019 17:06