none
Windows-Clients (WLAN) mit NPS nach Windowsupdate Dez. 2012 defekt, Code 266 RRS feed

  • Frage

  • Hallo

    Seit dem Dezember-Patchday könne sich Windows-Clients nicht mehr im WLAN anmelden.

    Fremdgeräte wie Android und iPhone gehen hingegen problemlos !

    Im NPS-Log sieht das so aus :

    Der Netzwerkrichtlinienserver verweigerte einem Benutzer den Zugriff.

    Benutzer:
        Sicherheits-ID:             IPB-HALLE\ronald
        Kontoname:                 ronald
        Kontodomäne:               IPB-HALLE
        Vollqualifizierter Kontoname:    IPB-HALLE\ronald

    Clientcomputer:
        Sicherheits-ID:             NULL SID
        Kontoname:                 -
        Vollqualifizierter Kontoname:     -
        Betriebssystemversion:            -
        Empfänger-ID:                 38-22-D6-78-E2-91:IPB-Member
        Anrufer-ID:                 00-12-BF-1C-AB-3C

    NAS:
        NAS-IPv4-Adresse:            192.168.1.192
        NAS-IPv6-Adresse:            -
        NAS-ID:                     WLAN-Contr
        NAS-Porttyp:                 Drahtlos - IEEE 802.11
        NAS-Port:                 16785419

    RADIUS-Client:
        Clientanzeigenname:           WLAN-Controller
        Client-IP-Adresse:            192.168.1.192

    Authentifizierungsdetails:
        Name der Verbindungsanforderungsrichtlinie:    Sichere Drahtlosverbindungen
        Netzwerkrichtlinienname:      Sichere Drahtlosnetzwerkverbindungen
        Authentifizierungsanbieter:   Windows
        Authentifizierungsserver:     IPB-AD1.ipb-halle.de
        Authentifizierungstyp:        PEAP
        EAP-Typ:            -
        Kontositzungs-ID:         -
        Protokollierungsergebnisse:   Die Kontoinformationen wurden in die lokale Protokolldatei geschrieben.
        Ursachencode:             266
        Ursache:                 Das Format der empfangenen Nachricht war unerwartet oder fehlerhaft.

    Bei einem funktionierenden (nicht-Windows) Client hingegen :

    Der Netzwerkrichtlinienserver hat einem Benutzer Vollzugriff erteilt, da der Host die Integritätsrichtlinien erfüllt.
    
    Benutzer:
    	Sicherheits-ID:			IPB-HALLE\ronald
    	Kontoname:				ronald@ipb-halle.de
    	Kontodomäne:				IPB-HALLE
    	Vollqualifizierter Kontoname:		IPB-HALLE\ronald
    
    Clientcomputer:
    	Sicherheits-ID:			NULL SID
    	Kontoname:				-
    	Vollqualifizierter Kontoname:		-
    	Betriebssystemversion:			-
    	Empfangs-ID:				00-23-89-DA-6F-31:IPB-Member
    	Anrufer-ID:				D8-9E-3F-53-39-37
    
    NAS:
    	NAS-IPv4-Adresse:			192.168.1.192
    	NAS-IPv6-Adresse:			-
    	NAS-ID:					WLAN-Contr
    	NAS-Porttyp:				Drahtlos - IEEE 802.11
    	NAS-Port:				16785419
    
    RADIUS-Client:
    	Clientanzeigename:			WLAN-Controller
    	Client-IP-Adresse:			192.168.1.192
    
    Authentifizierungsdetails:
    	Name der Verbindungsanforderungsrichtline:	Sichere Drahtlosverbindungen
    	Netzwerkrichtlinienname:		Sichere Drahtlosverbindungen
    	Authentifizierungsanbieter:		Windows
    	Authentifizierungsserver:		IPB-AD1.ipb-halle.de
    	Authentifizierungstyp:			PEAP
    	EAP-Typ:				Microsoft: Gesichertes Kennwort (EAP-MSCHAP v2)
    	Kontositzungs-ID:			-
    
    Quarantäneinformationen:
    	Ergebnis:				Vollzugriff
    	Erweitertes Ergebnis:			-
    	Sitzungs-ID:				-
    	Hilfe-URL:				-
    	Verifizierungsergebnis(se) der Systemintegrität:	-
    

    Das heisst bei den Windows-Clients, egal ob Windows-XP oder Windows-7 versteht der Server den EAP-Type oder das EAP-MSCHAP v2 nicht mehr.

    Hat jemand eine Idee welches Update darn Schuld ist oder wie man das Problem beheben kann ?

    Gruß Ronald

    Dienstag, 18. Dezember 2012 08:21

Antworten

  • So, es läuft wieder.

    Offenbar war ich nicht allein mit dem Problem : http://social.technet.microsoft.com/Forums/en-US/winserverNAP/thread/9171b4aa-ba71-430b-935f-b27513debda4/

    Die Ursache : zu viele Root-Zertifikate nach dem Dezember-Update.

    Lösung : http://support.microsoft.com/kb/2464556/de

    (Methode 1:Entfernen Sie einige vertrauenswürdige Stammzertifikate)

    (Methode 3:Schannel konfigurieren, um die Liste der vertrauenswürdigen Stammzertifizierungsstellen während der TLS/SSL-Handshake-Prozess nicht mehr zu senden = Regkey erstellen unter "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL" mit REG_DWORD : "SendTrustedIssuerList = 0"

    Gruß Ronald

    Dienstag, 18. Dezember 2012 11:21

Alle Antworten