Radius Server für 802.1x (Enterprise WPA): TLS Version

[ua]

Hallo Zusammen,

die Frage geht vermutlich direkt an Alfred

Seit langer Zeit benutze ich im WLAN die Authentifizierung mittel 802.1x/Radius, den Radius-Dienst übernimmt ein 1781VA mit WLC-Option.
Dies funktioniert bis jetzt sehr gut, bei der ersten Anmeldung fragen die Clients (Win10, IOS and MacOS) das Vertrauen in das Zertifikat ab und gut ists.

Jetzt hab ich eine neues Notebook (Fujitsu, WIN10Pro und Intel 8265-Chipsatz), bei der ersten Einrichtung hat es problemlos funktioniert. Nach dem zweiten Reboot (nach der Installation des AVC) funktioniert die Anmeldung nicht mehr. User/Pass wird abgefragt, die Frage "ob das Netz hier erwartet wird" kommt, die Netzwerküberprüfung beginnt und dann kommt die Meldung "Verbindung mit diesem Netz nicht möglich".

Leider lässt sich dazu im Log (siehe Bild, geschwärzt ist die IP des AP, gerötet der Username) nicht viel erkennen. Der Client wird ordnungsmäß authentifiziert. An dem Account kann es nicht liegen, habe es auch mit einem funktionierenden erfolglos versucht. Nach einiger Sucherei fiel mir ein Artikel der MS-KB auf den Googel: https://support.microsoft.com/de-de/hel ... nvironment. Nun versuche ich herauszubekommen welche TLS-Version der Radisu verwendet, oder wie ich das erkennen kann. Auch auf einem angemeldeten Win10 konnt ich nichts sehen.

Mite der Bitte um etwas Erleuchtung und schöne Grüßen

Udo

radius.PNG

[alf29]

Moin,

von Hause aus verwendet der RADIUS-Server füe EAP-TLS, TTLs und PEAP erstmal nur TLS 1.0. TLS 1.1/1.2 kann man einschalten, aber wenn der Client nur TLS 1.0 kann bleibt es auch dabei.

In dem Log kann ich ehrlich gesagt auch nicht viel erkennen , außer vielleicht daß die 1X-Verhandlung wohl bis in Phase 2 kommt (TLS-Tunnel aufgebaut, MSCHAPv2 läuft), weil der RADIUS-Server im LCOS dafür mit sich selber (127.0.0.1) redet. Ansonsten ist 802.1X mit all seinen Verästelungen viel zu kompliziert, als daß man im Syslog dazu irgendetwas sinnvolles sehen würde. Da sieht man wenn überhaupt nur im Trace etwas.

Aber mal ganz schlicht gefragt: wenn es nach der Installation des AVC nicht mehr geht, dann liegt der Verdacht nahe, daß es damit in Zusammenhang steht? Ich hatte es schon mehr als einmal, daß der AVSC sich in die WLAN-Konfig einmischt und da seinen eigenen WLAN-Manager unterbringen will - der dann eher schlecht als recht funktioniert...

Viele Grüße

Alfred

[GrandDixence]

Oder man verwendet für die Fehlersuche bzw. Fehlereingrenzung die "Packet Capture"-Funktion der LANCOM-Geräte und setzt für die Auswertung des aufgezeichneten Netzwerkverkehrs (*.pcap/*.pcapng) Wirekshark ein.

Ein guter Einstieg in die komplexe Thematik IEEE 802.1x und EAP-TLS (WPA2-Enterprise) bietet BSI-TR 03103 Teil 1:
https://www.bsi.bund.de/DE/Publikatione ... x_htm.html

Lesenswert sind auch diese Artikel:
https://www.heise.de/ct/artikel/WLAN-un ... 79513.html

https://www.elektronik-kompendium.de/si ... 907111.htm

https://wlan1nde.wordpress.com/tag/encryption/

Bei Windows müssen die für EAP-TLS eingesetzten Zertifikate die unter:

https://support.microsoft.com/de-ch/hel ... th-eap-tls

http://www.lancom-forum.de/fragen-zum-t ... tml#p86774

beschriebenen Anforderungen erfüllen.

Wichtig: Die Installation der Zertifikate muss in den Computer-Zertifikatsspeicher statt in den Benutzer-Zertifikatsspeicher erfolgen:

http://www.lancom-forum.de/fragen-zum-t ... tml#p86774

Viel Glück bei der Fehlersuche!

[ua]

N'Abend zusammen,

(das gilt nicht für die Novell-Administratoren, denen wünscht man keinen guten Abend )

habe heute nocheinmal ein bißchen Zeit investiert:
Die Anmeldung, sowie die komplette Challenge (genutzt wird PEAP mit MS Chap v2) scheint komplett durchgelaufen zu sein:

802-1x_compare.png

Links der erfolgreiche, rechts der erfolglose Anmeldevorgang.
Die Radius Traces habe ich ebenfalls verglichen, sind identisch (alle mit TLS V1.0).
Habe den Versuch mit mehereren Maschinen gemacht (alle Win10 mit identischen Patchlevel), den AVC kann ich ausschließen, es streiken auch Kisten ohne VPN.
Der einzige Unterschied an dem ich eine Funktion / Nicht-Funktion festmachen kann ist die HAL:
Hardwareabstraktionsebene 10.0.16299.98 ist OK (3 Rechner funktionieren),
Version .248 und .371 funktionieren nicht (4 Rechner).
Nun brauche ich wohl einen Pott Weihwasser. Wenn ich noch etwas Zeit habe, werde ich mal mit einem anderem WLAN-Hersteller testen.

MacOS und IOS-Clients laufen ohne Probleme ...

Viele Grüße aus OBC

Udo

[GrandDixence]

Gemäss Abbildung 24 von BSI-TR 03103 Teil 1 wurde der PMK (Pairwise Master Key) in beiden Fällen mit sehr hoher Wahrscheinlichkeit erfolgreich zum Supplicant (WLAN-Client) und Authenticator (WLAN Access Point) übertragen. Jetzt muss der Netzwerkverkehr auf der Luftschnittstelle zwischen WLAN-Client und WLAN Access Point aufgezeichnet werden und die Aufzeichnung untersucht werden, ob die 4 EAPOL-Telegramme gemäss Abbildung 25 von BSI-TR 03103 Teil 1 erfolgreich übertragen wurde und somit der Supplicant (WLAN-Client) und der Authenticator (WLAN Access Point) den PTK (Pairwise Transient Key) kennen. Siehe auch:

https://wlan1nde.wordpress.com/tag/encryption/

Aus Sicherheitsgründen sollte kein EAP-PEAP eingesetzt werden! Siehe Kapitel 7.2.5 von BSI-TR 03103 Teil 1 (Seite 59 oben).

Wurden die LANCOM-Geräte auf LCOS 10.12.0242 RU4 oder neuer aktualisiert?

[alf29]

Moin,

bevor man snifft, könnte man auch erstmal einfach ins Log des APs reinschauen. Wenn dort nach erfolgreicher 1X-Verhandlung auch noch ein erfolgreicher Key-Handshake gemeldet wird, dann ist das WLAN eigentlich schon fast aus dem Spiel.

Aus Sicherheitsgründen sollte kein EAP-PEAP eingesetzt werden!

Das mag ein wohlgemeinter Rat sein, aber außer PEAP kennt der in Windows eingebaute Supplicant nur noch EAP-TLS. Und ich kann jeden verstehen, der keine Lust hat, eine komplette CA hochzuziehen und zu pflegen...

Viele Grüße

Alfred

[ua]

Hallo Zusammen,

in die Diskussion um EAP-PEAP möchte ich jetzt nicht einsteigen (eine CA ist für einige Szenarien leider nicht wirklich handhabbar).

Folgendes ist interessant:

nach erfolgreicher 1X-Verhandlung auch noch ein erfolgreicher Key-Handshake gemeldet wird

Dazu habe ich mal ein bißchen im Log gesucht und folgendes gefunden:
(Zum Testen habe ich alle AP bis auf einen abgeschaltet, Test-AP ist ein 1700er mit 10.12.0292RU6)
Klient A (Intel AC 7265) Key Handaheke bei 5GHz ok, bei 2,4GHz nok
Klient B (Intel AC 8265) Key Handshake bei 2,4GHz ok, bei 5GHz nok

Das hat mir dann keine Ruhr gelassen, habe die 802.1x SSID vom LANCOM-WLAN runter genommen und über eine Controller basierte Lösung eines Mitbewerbers geschubst (Als Radius Server dient nach wie vor der Lancom-WLC, also identisches Setup bis auf die AP):
Alle Klients funktionieren auf Anhieb auf allen Bändern!

Jetzt kann ich den Fehler an sich nur noch auf die Lancom AP schieben ...

Mit vielen Fragezeichen und schönen Grüßen aus OBC

Udo

[alf29]

Moin,

also mit dem einen Client nur bei 5 und mit dem anderen nur bei 2.4 GHz? Das klingt für mich jetzt reichlich nebulös. Ist das reproduzierbar von Band abhängig und nicht doch von andern Effekten wie PMK-Caching?

Viele Grüße

Alfred

[ua]

Hallo Alfred,

über das unterschiedliche Verhalten habe ich mich auch extrem gewundert.
Werde die Prüfreihen mal mit ausgeschaltetem PMK erenut durchführen.

Viele Grüße

Udo

[alf29]

Moin,

Du solltest bei einem fehlgeschlagenen Key Handshake mit einem EAP-Trace schauen, woran er scheitert. Wenn es vom AP Meldungen über MIC-Fehler gibt, dann kannst Du Dir als nächstes anschauen, ob das korrekte PMK verwendet wird. Der EAP-Trace gibt das zum Start aus, und bei "einfachem" 802.1X (ohne 11r/Fast Roaming) ist der gleich dem MS-MPPE-Recv-Key, den der RADIUS-Server in seinem finalen Accept ausgibt.

Viele Grüße

Alfred

[ua]

Hallo Alfred,

hier das Ergebniss der neuen Testreihe (SSID nur auf einem AP aktiviert, EAP-Trace auf diesem AP):

Bei einer erfolgreichen Anmeldung sehen die letzten Zeilen so aus:

ok1.PNG

Bei einer erfolglosen:

nok2.PNG

Interessant ist dabei, daß ein Klient sich am 5GHz-Modul nicht und anschliessend am 2,4G-Modul sofort anmelden konnte.
So ein ähnliches Verhalten hat ein Kollege auch beobachtet: Er hat einen Klient (WindowsPhone) welches sich ums verrecken nicht im 5GHz-Band anmeldet.

M.E. ist liegt der Unbterschied in der EAP-Rückmeldung:
2 Pakete bei Funktion mit Version 2
1 Paktet (dafür länger) bei nicht Funktion mit Version 3
Wie bereits geschrieben mit AP eines anderen Herstellers funktioniert es sofort in beiden Bändern...

Viele Grüße

Udo

[alf29]

Hallo Udo,

1 Paktet (dafür länger) bei nicht Funktion mit Version 3

...aber in beiden Fällen lang genug, daß man in dem Snapshot nicht die komplette Meldung vom EAP-Trace sieht. Die müßte ich schon komplett sehen, das macht die Beurteilung sonst etwas schwierig...irgendetwas muß ja dazu führen, daß der AP den Client eine Millisekunde nach Empfang des Pakets komplett herauswirft. Ein nicht passendes Master Secret (PMK) kann es eigentlich nicht sein, das würde nur zu einem Ignorieren des Pakets führen.

Die wahrscheinlichste Variante wäre, daß der Client im Paket 2 des Key-Handshakes das RSN-Infoelement nicht 1:1 so schickt, wie er es im Associate Request gemacht hat. Der originale 802.11i-Standard sagt hier ziemlich explizit, daß es in beiden Paketen bit-für-bit identisch sein muß und wenn nicht, dann *muß* der AP den Client sofort rauswerfen, weil das ein Indikator für eine Man-in-the-middle-Attacke während der Assoziation ist.

Ist aber wie gesagt nur eine Spekulation - bitte poste mal die vollständige Meldung aus dem EAP-Trace.

Viele Grüße

Alfred

[ua]

Hallo Alfred,

ok, dacht das reicht .. hier aus dem Trace-File kopiert:

Code: Alles auswählen

[EAP] 2018/04/25 13:47:38,582  Devicetime: 2018/04/25 13:47:38,627
EAP: RX <- 172.xx.xx.2:1812
 - received EAP frame from RADIUS server
EAP:   (01) User-Name             = "xxx"
EAP:   (80) Message-Authenticator = ...
EAP:   (85) Acct-Interim-Interval[Len=04]   = 60
EAP:   (26) MS-MPPE-RECV-KEY      = a0 e0 7f 6e a3 9c ca 2b
EAP:                              = 22 e4 f4 f0 7f 54 3a 74
EAP:                              = d9 78 2e 7d 5e 58 24 98
EAP:                              = 68 ab ca 2f 60 24 b4 a6
EAP:   (26) MS-MPPE-SEND-KEY      = d7 e6 88 4b dc 26 98 89
EAP:                              = 36 f0 3c 37 24 5f 58 1e
EAP:                              = 68 d5 90 f8 5a 9a 66 fc
EAP:                              = 9d cc d9 27 0b bb ab c0
EAP:   (79) EAP-Message[Len=4]    = 03 0a 00 04
EAP:   Packet Type = Access-Accept

[EAP] 2018/04/25 13:47:38,582  Devicetime: 2018/04/25 13:47:38,627
EAP: TX -> ** mac des suppl. ** - sending EAPOL frame to supplicant
EAP:   Packet Type   = 0 (EAP-Packet)
EAP:   Packet Length = 4
EAP:     Code        = 3 (Success)
EAP:     Ident       = 10
EAP:     Length      = 4

[EAP] 2018/04/25 13:47:38,582  Devicetime: 2018/04/25 13:47:38,628
***Creating WPA(2)/802.11i key handshake context with supplicant ** mac des suppl. **
-->PMK to be used is:
00: d7 e6 88 4b dc 26 98 89 - 36 f0 3c 37 24 5f 58 1e
10: 68 d5 90 f8 5a 9a 66 fc - 9d cc d9 27 0b bb ab c0
  -->PMK-R0:
00: bf 45 08 e9 2f 62 5a 01 - 0d bb 88 3b de 31 ba c4
10: c1 ad ff b8 e5 72 22 e2 - fd 67 47 70 38 5b ca 55
  -->PMK-R0Name:
00: ca 61 79 65 8d 06 ab 51 - fe 46 a2 6a 93 c6 64 fc
  -->PMK-R1:
00: 90 f0 b4 df a5 64 9f e2 - 9f f8 9d 59 72 ce 1f d7
10: 00 84 19 3b 53 06 68 da - 7c 74 30 5e 32 31 dc 54
  -->PMK-R1Name:
00: be ce 53 4b 08 7a e6 16 - a7 24 5c cc 4c b8 a5 f9
-->Switching to pairwise key handshake phase 1, send corresponding packet
-->EAPOL Header
Protocol Version    : 2
Packet Type         : Key
Packet Length       : 117
Key Type            : 2
-->802.11i RSN Key Descriptor
Key Information     : Version 3 Pairwise Key-Index 0 ACK
Key Length          : 16
Replay Counter      : 0000000000000001
Nonce               : 36 40 78 19 10 dd 0e 1d 6@x.....
                      a5 0d 7b a9 ef da c0 6e ..{....n
                      4d 48 40 68 c2 f0 14 73 MH@h...s
                      02 86 b0 a8 f8 57 55 71 .....WUq
Key IV              : 00 00 00 00 00 00 00 00 ........
                      00 00 00 00 00 00 00 00 ........
Key RSC             : 00 00 00 00 00 00 00 00 ........
Key ID              : 00 00 00 00 00 00 00 00 ........
Key MIC             : 00 00 00 00 00 00 00 00 ........
                      00 00 00 00 00 00 00 00 ........
Key Data Length     : 22
Key Data            :
<<<
PMKID               : be ce 53 4b 08 7a e6 16 ..SK.z..
                      a7 24 5c cc 4c b8 a5 f9 .$\.L...
>>>

[EAP] 2018/04/25 13:47:38,602  Devicetime: 2018/04/25 13:47:38,638
***Received EAP packet on WLAN-1:
-->EAPOL Header
Protocol Version    : 1
Packet Type         : Key
Packet Length       : 248
Key Type            : 2
-->802.11i RSN Key Descriptor
Key Information     : Version 3 Pairwise Key-Index 0 MIC
Key Length          : 0
Replay Counter      : 0000000000000001
Nonce               : 91 d6 b5 35 b2 67 b5 ad ...5.g..
                      82 82 6a 23 cb f7 2a 46 ..j#..*F
                      50 1c 8b 7b 52 db 6c d6 P..{R.l.
                      2d e1 5a 07 ff 0e 2a 0c -.Z...*.
Key IV              : 00 00 00 00 00 00 00 00 ........
                      00 00 00 00 00 00 00 00 ........
Key RSC             : 00 00 00 00 00 00 00 00 ........
Key ID              : 00 00 00 00 00 00 00 00 ........
Key MIC             : d4 45 fb 95 a1 2a 46 c7 .E...*F.
                      0b f1 86 78 37 b5 c7 9e ...x7...
Key Data Length     : 153
Key Data            :
<<<
RSN Cipher Info     : Version 1
                      Group Cipher TGI-CSE-CCM
                      Pairwise Ciphers TGI-CSE-CCM
                      Authentication Selectors TGI_AUTHSE_FT_8021X_UNSPEC
                      Capabilities: Mgmt-Frame-Prot-Supp 16 PTKSA replay counters 16 GTKSA replay counters
                      Group Mgmt Cipher cebe0001
<trailer>           : 53 4b 08 7a e6 16 a7 24 SK.z...$
                      5c cc 4c b8 a5 f9       \.L...
Mobility Domain     : ID 0xa5fb
Fast BSS Transition :
 MIC Count          : 0
 MIC                : 00 00 00 00 00 00 00 00 ........
                      00 00 00 00 00 00 00 00 ........
 ANonce             : 00 00 00 00 00 00 00 00 ........
                      00 00 00 00 00 00 00 00 ........
                      00 00 00 00 00 00 00 00 ........
                      00 00 00 00 00 00 00 00 ........
 SNonce             : 00 00 00 00 00 00 00 00 ........
                      00 00 00 00 00 00 00 00 ........
                      00 00 00 00 00 00 00 00 ........
                      00 00 00 00 00 00 00 00 ........
 R1KH-ID            : xx (LANCOM xx)
 R0KH-ID            : xx
>>>
-->Received properly sequenced packet from supplicant for phase 2
-->Computing PTK
  -->PRF-X Data:
00: 91 d6 b5 35 b2 67 b5 ad - 82 82 6a 23 cb f7 2a 46
10: 50 1c 8b 7b 52 db 6c d6 - 2d e1 5a 07 ff 0e 2a 0c
20: 36 40 78 19 10 dd 0e 1d - a5 0d 7b a9 ef da c0 6e
30: 4d 48 40 68 c2 f0 14 73 - 02 86 b0 a8 f8 57 55 71
40: 00 a0 57 30 be e7 f8 63 - 3f 8b 53 b2
  -->Resulting PTK:
00: 07 9e b2 51 68 2d 50 db - be 45 da ee dd 2e c9 4d
10: 93 df 2d a3 03 69 e1 38 - 69 e9 cf 9d 79 46 df 04
20: 8d 36 29 4f bc 91 0f 0f - 44 7f e1 04 50 fe 1b 44
  -->KCK:
00: 07 9e b2 51 68 2d 50 db - be 45 da ee dd 2e c9 4d
  -->KEK:
00: 93 df 2d a3 03 69 e1 38 - 69 e9 cf 9d 79 46 df 04
  -->TK:
00: 8d 36 29 4f bc 91 0f 0f - 44 7f e1 04 50 fe 1b 44
-->RSN (excl. PMKID) info element mismatch - element from association request was:
0000 30 16 01 00 00 0f ac 04
0008 01 00 00 0f ac 04 01 00
0010 00 0f ac 03 bc 00 00 00
 - terminating handshake, deauthenticating client

[EAP] 2018/04/25 13:47:38,602  Devicetime: 2018/04/25 13:47:38,639
EAP: Delete station ** mac des suppl. **

Jetzt sehe ich auch: Info element mismatch, aber mir sagt das nüscht..

Viele Grüße

Udo

[alf29]

Moin,

OK, nehmen wir's mal auseinander. Das RSN-Infoelement ist quasi das Element mit dem sich Client und AP bei WPA gegenseitig ihre Krypto-Fähigkeiten mitteilen. Der AP bietet z.B. 802.1X mit TKIP oder AES an, und der Client sagt z.B. "ich nehme AES". Weil das über (noch ungesicherte) Management-Frames passiert, wiederholen AP und Client ihre "Proposals" während des Key-Handshakes, der ist durch kryptographische Prüfsummen abgesichert. Ergeben sich dabei Differenzen zu dem, was sie sich initial erzählt haben, muß die jeweils andere Seite annehmen, daß ein Angreifer sich als man-in-the-middle dazwischengehängt hat und die Verbindung kompromittiert ist. Deshalb der sofortige Abbruch.

Wie das IE vom Client bei der Anmeldung aussah, hat das LANCOM als Hexdump gelistet. Ich nehm's mal auseinander:

Code: Alles auswählen

30 -> Robust Security Network IE
16 -> Länge 22 Bytes
01 00 -> Version 1
00 0f ac 04 -> Group Cipher (d.h. Verschlüsselung von Broad/Multicasts) TGI-CSE-CCM, also AES
01 00 00 0f ac 04 -> Pairwise Cipher (d.h. Verschlüsselung von Unicasts) TGI-CSE-CCM, also auch AES
01 00 00 0f ac 03 -> Authentication/Key Management TGI_AUTHSE_FT_8021X_UNSPEC, d.h. 802.1X kombiniert mit 802.11r (Fast Transition)
bc 00 -> Capabilities: 16 PTKSA Replay Counters, 16 GTKSA Replay Counters, PMF Supported
00 00 -> keine (gecachten) PMKs angeboten

Sieht bis dahin also gleich aus, aber im Key Handshake kommt vom Client noch irgendwelche Datengrütze hintendran:

Code: Alles auswählen

RSN Cipher Info     : Version 1
                      Group Cipher TGI-CSE-CCM
                      Pairwise Ciphers TGI-CSE-CCM
                      Authentication Selectors TGI_AUTHSE_FT_8021X_UNSPEC
                      Capabilities: Mgmt-Frame-Prot-Supp 16 PTKSA replay counters 16 GTKSA replay counters
                      Group Mgmt Cipher cebe0001
<trailer>           : 53 4b 08 7a e6 16 a7 24 SK.z...$
                      5c cc 4c b8 a5 f9       \.L...

0xcebe0001 ist ein völlig unsinniger Wert für den Group Management Cipher, und die restlichen Bytes sind einfach nur noch Datenmüll, der in diesem Info-Element gar nichts zu suchen hat. Auf jeden Fall ist das nicht binär identisch und das LANCOM *muß* an der Stelle abbrechen.

Daß das LANCOM das KeyData-Feld falsch entschlüsselt hat (alles was im Trace zwischen <<< und >>> steht, geht verschlüsselt durch die Luft), ist übrigens recht unwahrscheinlich, denn sowohl davon als auch nach diesem Datenmüll kommen korrekte und sinnvolle Daten.

Woran das liegen kann? Daß ein Windows-Client Fast Roaming (11r) unterstützt, ist ziemlich neu, bisher haben das hauptsächlich Apple-Clients gemacht und Microsoft hat auf OKC geschworen. Möglicherweise bist Du da auf ein noch nicht ganz sauber implementiertes Feature in Deinem brandneuen Client gelaufen.

Warum es auf dem anderen AP funktioniert? Vielleicht unterstützt der ja gar kein Fast Roaming und/oder keine Protected Management Frames und der Client läuft deshalb nie in diesem Zweig rein. Du kannst ja mal das eine/und oder andere auf dem LANCOM abschalten.

Viele Grüße

Alfred

[ua]

Hallo Alfred,

ich brech ins Essen ...
Dein Tipp mit dem fast-roaming war genau richtig.
Nachdem ich im LC fast-roaming abgeschaltet habe, konnten sich die Klienten anmelden ...
Dann wurd ich mutig: fast-roaming und sha256 eingeschaltet - Klienten konnten sich problemlos anmelden!
Die PSK-Profile standen auch auf fast-roaming (ok, gibts ja auch bei PSK nicht wirklich), daher ist mir das gar nicht so aufgefallen.
IOS-Klients brauchten tlws. einen Neustart, funktionieren aber auch problemlos.
MS hat wohl was neues in den WLAN-Stack gelötet ...

Vielen Dank für die tolle Unterstützung und Grüße Nach AC

Udo

PS Bei dem anderem System hatte ich auch r und "Mgmt-Frame-Protection optional" eingeschaltet, aber anscheinend nehmen es die Amis nicht so genau...

Edit sagt:

Eben gefunden: https://docs.microsoft.com/en-us/window ... nd-802-11r