Radius-Weiterleitung bei Clientzertifikaten
Moderator: Lancom-Systems Moderatoren
Radius-Weiterleitung bei Clientzertifikaten
Hallo zusammen,
folgende Merkwürdigkeit; weiß nicht so recht, wo zu suchen ist:
WLAN 802.1x mit Radiusauthentifizierung (vom Windowsclient mit PEAP und MSCHAPv2 oder auch TTLS und PAP), Weiterleitung vom Controller (4025+) zu externem Radiusserver: funktioniert.
Bei der Nutzung von Clientzertifikaten (Einstellung auf dem Windowsclient "Microsoft: Smartcard- oder anderes Zertifikat" usw.) bleiben offensichtlich irgendwelche Dinge auf der Strecke, funktioniert also nicht.
Nutze ich dagegen ein Radiusprofil, also direkt von den APs zum Radiusserver, funktioniert es auch mit den Clientzertifikaten. Da dies aus verschiedenen Gründen unschön ist, hätte ich doch lieber den Weg über den Controller.
Mit LCOS 9.24 und 10.12 getestet. Ein Lösungsansatz wäre sehr willkommen.
BG Tilo
folgende Merkwürdigkeit; weiß nicht so recht, wo zu suchen ist:
WLAN 802.1x mit Radiusauthentifizierung (vom Windowsclient mit PEAP und MSCHAPv2 oder auch TTLS und PAP), Weiterleitung vom Controller (4025+) zu externem Radiusserver: funktioniert.
Bei der Nutzung von Clientzertifikaten (Einstellung auf dem Windowsclient "Microsoft: Smartcard- oder anderes Zertifikat" usw.) bleiben offensichtlich irgendwelche Dinge auf der Strecke, funktioniert also nicht.
Nutze ich dagegen ein Radiusprofil, also direkt von den APs zum Radiusserver, funktioniert es auch mit den Clientzertifikaten. Da dies aus verschiedenen Gründen unschön ist, hätte ich doch lieber den Weg über den Controller.
Mit LCOS 9.24 und 10.12 getestet. Ein Lösungsansatz wäre sehr willkommen.
BG Tilo
Re: Radius-Weiterleitung bei Clientzertifikaten
Moin,
mach mal auf dem WLC einen RADIUS-Server- und einen RADIUS-Client-Trace während der Anmeldung (bevorzugt mit einer 10.12, da ist der Trace im Zweifelsfall ausführlicher). Dann sieht man, was auf dem WLC ankommt und was er in Richtung RADIUS-Server weiterreicht. Den einzigen Unterschied sehe ich im Moment darin, daß bei EAP/TLS im Unterschied zu PEAP auch in Richtung RADIUS-Server größere RADIUS-Pakete laufen (wegen des Client-Zertifikats).
Viele Grüße
Alfred
mach mal auf dem WLC einen RADIUS-Server- und einen RADIUS-Client-Trace während der Anmeldung (bevorzugt mit einer 10.12, da ist der Trace im Zweifelsfall ausführlicher). Dann sieht man, was auf dem WLC ankommt und was er in Richtung RADIUS-Server weiterreicht. Den einzigen Unterschied sehe ich im Moment darin, daß bei EAP/TLS im Unterschied zu PEAP auch in Richtung RADIUS-Server größere RADIUS-Pakete laufen (wegen des Client-Zertifikats).
Viele Grüße
Alfred
“There is no death, there is just a change of our cosmic address."
-- Edgar Froese, 1944 - 2015
-- Edgar Froese, 1944 - 2015
Re: Radius-Weiterleitung bei Clientzertifikaten
Hallo,
vielen Dank für den schnellen Hinweis. Zwischenzeitlich habe ich einige Traces angefertigt unter 10.12: Über den WLC mit Radiusweiterleitung und direkt auf dem AP bei Nutzung eines Radiusprofiles. Der Controller gibt anscheinend alles, was er bekommt, auch weiter inkl. Root-CA-Zertifikat und Zwischenzertifikate. Allerdings scheint das persönlich Zertifikat zu fehlen, d.h., der Controller bekommt es gar nicht. Bei der Direktverbindung vom AP zum Radiusserver wird es dagegen am Ende übertragen. Werde es weiter untersuchen, wenn ich in einigen Tagen wieder im Büro bin.
BG Tilo
vielen Dank für den schnellen Hinweis. Zwischenzeitlich habe ich einige Traces angefertigt unter 10.12: Über den WLC mit Radiusweiterleitung und direkt auf dem AP bei Nutzung eines Radiusprofiles. Der Controller gibt anscheinend alles, was er bekommt, auch weiter inkl. Root-CA-Zertifikat und Zwischenzertifikate. Allerdings scheint das persönlich Zertifikat zu fehlen, d.h., der Controller bekommt es gar nicht. Bei der Direktverbindung vom AP zum Radiusserver wird es dagegen am Ende übertragen. Werde es weiter untersuchen, wenn ich in einigen Tagen wieder im Büro bin.
BG Tilo
Re: Radius-Weiterleitung bei Clientzertifikaten
Hallo,
zwischenzeitlich haben wir auf dem Controller nocheinmal einen Radius-Server-Trace laufen lassen: Das Clientzertifikat ist nicht zu sehen.
Was könnte ich noch tracen oder sonstwie untersuchen? Bin dankbar für Hinweise.
BG Tilo
zwischenzeitlich haben wir auf dem Controller nocheinmal einen Radius-Server-Trace laufen lassen: Das Clientzertifikat ist nicht zu sehen.
Was könnte ich noch tracen oder sonstwie untersuchen? Bin dankbar für Hinweise.
BG Tilo
Re: Radius-Weiterleitung bei Clientzertifikaten
Moin,
ich frage erstmal: wo erwartest Du denn im RADIUS-Server-Trace das Client-Zertifikat zu sehen? Der Controller reicht ja in dieser Betriebsart erstmal nur RADIUS-Requests und -Responses weiter, die in der EAP-TLS-Verhandlung benutzten Zertifikate (egal ob vom Client oder vom eigentlichen RADIUS-Server) sind eingepackt in TLS-Messages und die wiederum in EAP-Message-Attribute eingepackt. Hast Du den Trace derart tiefgehend analysiert, daß Du so eine Aussage treffen kannst? Vielleicht postest Du hier einfach mal den Trace.
Viele Grüße
Alfred
ich frage erstmal: wo erwartest Du denn im RADIUS-Server-Trace das Client-Zertifikat zu sehen? Der Controller reicht ja in dieser Betriebsart erstmal nur RADIUS-Requests und -Responses weiter, die in der EAP-TLS-Verhandlung benutzten Zertifikate (egal ob vom Client oder vom eigentlichen RADIUS-Server) sind eingepackt in TLS-Messages und die wiederum in EAP-Message-Attribute eingepackt. Hast Du den Trace derart tiefgehend analysiert, daß Du so eine Aussage treffen kannst? Vielleicht postest Du hier einfach mal den Trace.
Viele Grüße
Alfred
“There is no death, there is just a change of our cosmic address."
-- Edgar Froese, 1944 - 2015
-- Edgar Froese, 1944 - 2015
Re: Radius-Weiterleitung bei Clientzertifikaten
Hallo,
der folgende Ausschnitt entstammt dem Trace vom AP direkt zum Radiusserver (Radiusprofil im WLANController definiert). Und genau dieses Stück fehlt im Trace AP-WLANController-Radiusserver. Beide Traces sind ziemlich lang und wegen der enthaltenen Daten wahrscheinlich ungünstig hier zu posten.
BG Tilo
der folgende Ausschnitt entstammt dem Trace vom AP direkt zum Radiusserver (Radiusprofil im WLANController definiert). Und genau dieses Stück fehlt im Trace AP-WLANController-Radiusserver. Beide Traces sind ziemlich lang und wegen der enthaltenen Daten wahrscheinlich ungünstig hier zu posten.
Code: Alles auswählen
[RADIUS-Client] 2018/09/03 19:18:14,269 Devicetime: 2018/09/03 19:18:26,835
Send RADIUS Authentication Request Id 235 to 194.95.188.30:1812 Backup-Step 1
User-Name : anonymous@dfn.de
Service-Type : Framed
NAS-Port : 1
NAS-Port-Id : 1
State:
0000: fd 91 46 5d f1 9f 4b b1 20 4a 07 a8 1f 69 27 7b ..F]..K. J...i'{
Called-Station-Id : 00-A0-57-21-E3-2E:eduroamx
NAS-Port-Type : Wireless - IEEE 802.11
WLAN-RF-Band : 4.9 and 5 GHz
WLAN-Pairwise-Cipher: TGI-CSE-CCMP
WLAN-Group-Cipher : TGI-CSE-CCMP
WLAN-AKM-Suite : TGI-AUTHSE-8021X
Calling-Station-Id : 00-21-6A-81-CF-D6
Connect-Info : CONNECT 450 Mbps 802.11a/n
NAS-Identifier : AP207
Framed-MTU : 1500
EAP-Message:
(6 bytes)
-->EAP Header
EAP Packet Code : Response
EAP Packet Id : 14
EAP Packet Len : 6
EAP Packet Type : TLS
--> EAP/TLS Packet
TLS Flags :
Message-Authenticator:
0000: 81 d0 bc 5f c6 1c b3 2f 7b 6d 32 7e 54 d3 66 14 ..._.../{m2~T.f.
NAS-IP-Address : 192.168.4.101
Authenticator:
0000: ec f6 fb 5d 0e 07 a3 71 18 0c 86 43 01 20 10 88 ...]...q...C. ..
[RADIUS-Client] 2018/09/03 19:18:14,518 Devicetime: 2018/09/03 19:18:26,854
Received RADIUS Accept Id 235 from 194.95.188.30 on Port 13946
-->found corr. request 235 to 194.95.188.30:1812,
MS-MPPE-Recv-Key:
0000: 65 29 f2 00 2b 0d a6 b3 7f 40 4f 6a 85 10 29 01 e)..+....@Oj..).
0010: 0e ee d0 84 5c 39 d8 7e 76 8d ed 58 25 fd 5c 08 ....\9.~v..X%.\.
MS-MPPE-Send-Key:
0000: 94 94 73 bf 04 08 ec 65 b4 b7 d9 88 55 dc 4a 2c ..s....e....U.J,
0010: de 6b 94 68 5a 4c ff f7 6c 6d a4 32 b6 53 ff 5e .k.hZL..lm.2.S.^
EAP-Message:
(4 bytes)
-->EAP Header
EAP Packet Code : Success
EAP Packet Id : 14
EAP Packet Len : 4
Message-Authenticator:
0000: 94 7e 19 4e 5f b4 54 7b be d6 5f 5a c7 67 59 4a .~.N_.T{.._Z.gYJ
Reply-Message : Client-SerialNumber:1f517f1869eaa44c1ec3096a
Reply-Message:
0000: 43 41 2d 53 65 72 69 61 6c 4e 75 6d 62 65 72 3a CA-SerialNumber:
0010: 31 37 38 38 37 64 30 38 62 33 33 65 33 64 17887d08b33e3d
Reply-Message:
0000: 43 41 2d 45 78 70 69 72 65 44 61 74 65 3a 31 39 CA-ExpireDate:19
0010: 30 37 30 39 32 33 35 39 30 30 5a 0709235900Z
Reply-Message:
0000: 43 41 2d 53 75 62 6a 65 63 74 3a 2f 43 3d 44 45 CA-Subject:/C=DE
0010: 2f 4f 3d 44 46 4e 2d 56 65 72 65 69 6e 2f 4f 55 /O=DFN-Verein/OU
0020: 3d 47 65 73 63 68 61 65 66 74 73 73 74 65 6c 6c =Geschaeftsstell
0030: 65 2f 43 4e 3d 44 46 4e 2d 56 65 72 65 69 6e 2d e/CN=DFN-Verein-
0040: 47 53 2d 43 41 20 2d 20 47 30 32 GS-CA - G02
Reply-Message:
0000: 43 41 2d 49 73 73 75 65 72 3a 2f 43 3d 44 45 2f CA-Issuer:/C=DE/
0010: 4f 3d 44 46 4e 2d 56 65 72 65 69 6e 2f 4f 55 3d O=DFN-Verein/OU=
0020: 44 46 4e 2d 50 4b 49 2f 43 4e 3d 44 46 4e 2d 56 DFN-PKI/CN=DFN-V
0030: 65 72 65 69 6e 20 50 43 41 20 47 6c 6f 62 61 6c erein PCA Global
0040: 20 2d 20 47 30 31 - G01
Reply-Message:
0000: 43 41 2d 43 6f 6d 6d 6f 6e 4e 61 6d 65 44 46 4e CA-CommonNameDFN
0010: 2d 56 65 72 65 69 6e 2d 47 53 2d 43 41 20 2d 20 -Verein-GS-CA -
0020: 47 30 32 G02
Reply-Message:
0000: 43 6c 69 65 6e 74 2d 43 65 72 74 45 78 70 69 72 Client-CertExpir
0010: 65 44 61 74 65 3a 31 39 30 37 30 39 32 33 35 39 eDate:1907092359
0020: 30 30 5a 00Z
Reply-Message:
0000: 43 6c 69 65 6e 74 2d 53 75 62 6a 65 63 74 3a 2f Client-Subject:/
0010: 43 3d 44 45 2f 53 54 3d 42 65 72 6c 69 6e 2f 4c C=DE/ST=Berlin/L
0020: 3d 42 65 72 6c 69 6e 2f 4f 3d 56 65 72 65 69 6e =Berlin/O=Verein
0030: 20 7a 75 72 20 46 6f 65 72 64 65 72 75 6e 67 20 zur Foerderung
0040: 65 69 6e 65 73 20 44 65 75 74 73 63 68 65 6e 20 eines Deutschen
0050: 46 6f 72 73 63 68 75 6e 67 73 6e 65 74 7a 65 73 Forschungsnetzes
0060: 20 65 2e 20 56 2e 2f 43 4e 3d 45 58 54 3a 20 54 e. V./CN=EXT: T
0070: 69 6c 6f 20 4c 61 6e 67 65 20 2d 20 6c 6f 67 69 ilo Lange - logi
0080: 6e n
Reply-Message:
0000: 43 6c 69 65 6e 74 2d 49 73 73 75 65 72 3a 2f 43 Client-Issuer:/C
0010: 3d 44 45 2f 4f 3d 44 46 4e 2d 56 65 72 65 69 6e =DE/O=DFN-Verein
0020: 2f 4f 55 3d 47 65 73 63 68 61 65 66 74 73 73 74 /OU=Geschaeftsst
0030: 65 6c 6c 65 2f 43 4e 3d 44 46 4e 2d 56 65 72 65 elle/CN=DFN-Vere
0040: 69 6e 2d 47 53 2d 43 41 20 2d 20 47 30 32 in-GS-CA - G02
Reply-Message:
0000: 43 6c 69 65 6e 74 2d 43 6f 6d 6d 6f 6e 4e 61 6d Client-CommonNam
0010: 65 3a 45 58 54 3a 20 54 69 6c 6f 20 4c 61 6e 67 e:EXT: Tilo Lang
0020: 65 20 2d 20 6c 6f 67 69 6e e - login
Type 89:
0000: 37 62 63 38 32 61 37 61 64 66 63 64 32 39 64 33 7bc82a7adfcd29d3
0010: 31 36 38 37 65 36 34 32 64 39 36 35 65 38 32 38 1687e642d965e828
Vendor 27262 Type 1:
0000: 00 00 00 14 ....
-->trigger requester
Re: Radius-Weiterleitung bei Clientzertifikaten
Moin,
In dieser Meldung sehe ich kein Zertifikat selber, sondern nur eine Reihe Reply-Message-Attribute, die einzelne Attribute eines Zertifikats textuell beschreiben. Das ist aber nicht die Stelle, wo bei EAP-TLS das Zertifikat selber (in binärer Form) übertragen wird, und zumindest ein LANCOM-AP macht mit diesen Reply-Message-Attributen in RADIUS-Accept ohnehin nichts.
Oder meinst Du, daß der RADIUS-Accept komplett fehlt?. Da hieße aber, daß die Anmeldung an sich fehlgeschlagen ist, und die Ursache für den Fehler muß man weiter vorne im Trace suchen.
Viele Grüße
Alfred
In dieser Meldung sehe ich kein Zertifikat selber, sondern nur eine Reihe Reply-Message-Attribute, die einzelne Attribute eines Zertifikats textuell beschreiben. Das ist aber nicht die Stelle, wo bei EAP-TLS das Zertifikat selber (in binärer Form) übertragen wird, und zumindest ein LANCOM-AP macht mit diesen Reply-Message-Attributen in RADIUS-Accept ohnehin nichts.
Oder meinst Du, daß der RADIUS-Accept komplett fehlt?. Da hieße aber, daß die Anmeldung an sich fehlgeschlagen ist, und die Ursache für den Fehler muß man weiter vorne im Trace suchen.
Viele Grüße
Alfred
“There is no death, there is just a change of our cosmic address."
-- Edgar Froese, 1944 - 2015
-- Edgar Froese, 1944 - 2015