7
Problem mit 802.1x-Auth mit Windows-Credentials
Hallo zusammen,
ein kurioses Problem an dieser Stelle - vielleicht hat ja jemand eine Idee.
Ich habe auf einem Synology NAS den dort verfügbaren Radius-Server eingerichtet und testweise eine entsprechende SSID eingerichtet. Der Radius authentifiziert gegen den DC (Server 2016). WLAN-Clients sind Unifi-APs (jaja, ich weiß, buh! :P).
Es funktioniert auch alles wunderbar, bis auf eine Kleinigkeit: Wenn sich ein Client das erste Mal mit dem WLAN verbindet, erscheint ja die Nutzerabfrage. Wenn ich dort den Haken bei "Windows-Anmeldedaten verwenden" setze, schlägt die Verbindung fehl - "Keine Verbindung mit diesem Netzwerk möglich". Das eingebaute Radius-Log auf dem NAS meint dazu:
Gebe ich allerdings per Hand exakt dieselben Zugangsdaten wieder ein, geht alles. Lieber wären mir natürlich die Anmeldedaten, damit dann nicht so viel "Turnschuh-Arbeit" ansteht. Der betreffende Rechner befindet sich (nur) im AzureAD, falls es wichtig ist. Weiß da jemand Rat?
ein kurioses Problem an dieser Stelle - vielleicht hat ja jemand eine Idee.
Ich habe auf einem Synology NAS den dort verfügbaren Radius-Server eingerichtet und testweise eine entsprechende SSID eingerichtet. Der Radius authentifiziert gegen den DC (Server 2016). WLAN-Clients sind Unifi-APs (jaja, ich weiß, buh! :P).
Es funktioniert auch alles wunderbar, bis auf eine Kleinigkeit: Wenn sich ein Client das erste Mal mit dem WLAN verbindet, erscheint ja die Nutzerabfrage. Wenn ich dort den Haken bei "Windows-Anmeldedaten verwenden" setze, schlägt die Verbindung fehl - "Keine Verbindung mit diesem Netzwerk möglich". Das eingebaute Radius-Log auf dem NAS meint dazu:
mschap_ad ERROR: Program returned code (1) and output 'The attempted login is invalid. This is either due to a bad username or authentication information (0xc000006d)' Gebe ich allerdings per Hand exakt dieselben Zugangsdaten wieder ein, geht alles. Lieber wären mir natürlich die Anmeldedaten, damit dann nicht so viel "Turnschuh-Arbeit" ansteht. Der betreffende Rechner befindet sich (nur) im AzureAD, falls es wichtig ist. Weiß da jemand Rat?
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 4496552069
Url: https://administrator.de/forum/problem-mit-802-1x-auth-mit-windows-credentials-4496552069.html
Ausgedruckt am: 27.12.2024 um 18:12 Uhr
7 Kommentare
Neuester Kommentar
Mit Shell Zugriff auf dem NAS und ps ax kannst du sehen welche Daemon ID der Freeradius hat und dann kannst du ihn mit kill id mal etwas unelegant stoppen und dann mit freeradius -X im Debugging Mode auf dem CLI starten.
Wenn du jetzt versuchst den Client zu authentisieren zeigt dir der FreeRadius genau mit welchen User Credentials der Client dort ankommt! Beispiel siehe HIER.
Ggf. ist das auch eine Frage WIE der FreeRadius die Credentials per LDAP weitergibt.
Hier hilft evtl. das FreeRadius Tutorial zu dem Thema. oder auch andere.
https://www.golinuxcloud.com/freeradius-ldap-authentication-authorizatio ...
Wenn du jetzt versuchst den Client zu authentisieren zeigt dir der FreeRadius genau mit welchen User Credentials der Client dort ankommt! Beispiel siehe HIER.
Ggf. ist das auch eine Frage WIE der FreeRadius die Credentials per LDAP weitergibt.
Hier hilft evtl. das FreeRadius Tutorial zu dem Thema. oder auch andere.
https://www.golinuxcloud.com/freeradius-ldap-authentication-authorizatio ...
Okay, probiere ich morgen mal - danke!
Guten Morgen,
ich habe mir mal die Logs angeschaut, aber so richtig schlau werde ich daraus nicht. Das Problem scheint beim Modul mschap_ad zu liegen.
Ein erfolgreicher Login sieht so aus (dort habe ich die Benutzerdaten in der Form DOMÄNE\USER händisch eingegeben):
Wenn der Login fehlschlägt (ich also die Windows-Anmeldedaten übernehme), dann sieht das so aus:
Der ntdomain_hack scheint ja offensichtlich zu greifen - die Domäne wird ja in beiden Fällen mit übergeben. Für mich sieht es auch so aus, als würden an beiden Stellen identische Daten zur Authentifizierung übergeben.
ich habe mir mal die Logs angeschaut, aber so richtig schlau werde ich daraus nicht. Das Problem scheint beim Modul mschap_ad zu liegen.
Ein erfolgreicher Login sieht so aus (dort habe ich die Benutzerdaten in der Form DOMÄNE\USER händisch eingegeben):
(24) eap_mschapv2: # Executing group from file /usr/local/synoradius/rad_site_inn_ad
(24) eap_mschapv2: Auth-Type MS-CHAP {
(24) mschap_ad: Creating challenge hash with username: USER
(24) mschap_ad: Client is using MS-CHAPv2
(24) mschap_ad: Executing: /usr/local/bin/ntlm_auth --allow-mschapv2 --offline-logon --request-nt-key --domain=%{SYNO-FQDN} --username=%{SYNO-Username} --challenge=%{%{mschap:Challenge}:-00} --nt-response=%{%{mschap:NT-Response}:-00}:
(24) mschap_ad: EXPAND --domain=%{SYNO-FQDN}
(24) mschap_ad: --> --domain=DOMÄNE
(24) mschap_ad: EXPAND --username=%{SYNO-Username}
(24) mschap_ad: --> --username=USER
(24) mschap_ad: Creating challenge hash with username: USER
(24) mschap_ad: EXPAND --challenge=%{%{mschap:Challenge}:-00}
(24) mschap_ad: --> --challenge=64c00a19c96579c1
(24) mschap_ad: EXPAND --nt-response=%{%{mschap:NT-Response}:-00}
(24) mschap_ad: --> --nt-response=5276111a8d9c2dc43dfbb6c4fc6b8c3b9f2b4ad9d6f0494d
(24) mschap_ad: Program returned code (0) and output 'NT_KEY: 9B18E5AD6982EEF5A7B956F1BA779124'
(24) mschap_ad: Adding MS-CHAPv2 MPPE keys
(24) eap_mschapv2: [mschap_ad] = ok
(24) eap_mschapv2: } # Auth-Type MS-CHAP = ok
(24) eap_mschapv2: MSCHAP SuccessWenn der Login fehlschlägt (ich also die Windows-Anmeldedaten übernehme), dann sieht das so aus:
(11) eap_mschapv2: # Executing group from file /usr/local/synoradius/rad_site_inn_ad
(11) eap_mschapv2: Auth-Type MS-CHAP {
(11) mschap_ad: Creating challenge hash with username: USER
(11) mschap_ad: Client is using MS-CHAPv2
(11) mschap_ad: Executing: /usr/local/bin/ntlm_auth --allow-mschapv2 --offline-logon --request-nt-key --domain=%{SYNO-FQDN} --username=%{SYNO-Username} --challenge=%{%{mschap:Challenge}:-00} --nt-response=%{%{mschap:NT-Response}:-00}:
(11) mschap_ad: EXPAND --domain=%{SYNO-FQDN}
(11) mschap_ad: --> --domain=DOMÄNE
(11) mschap_ad: EXPAND --username=%{SYNO-Username}
(11) mschap_ad: --> --username=USER
(11) mschap_ad: Creating challenge hash with username: USER
(11) mschap_ad: EXPAND --challenge=%{%{mschap:Challenge}:-00}
(11) mschap_ad: --> --challenge=ed214abd658aec6d
(11) mschap_ad: EXPAND --nt-response=%{%{mschap:NT-Response}:-00}
(11) mschap_ad: --> --nt-response=8b9155dcba6f94c58b9155dcba6f94c58b9155dcba6f94c5
(11) c
(11) mschap_ad: External script failed
(11) mschap_ad: ERROR: External script says: The attempted logon is invalid. This is either due to a bad username or authentication information. (0xc000006d)
(11) mschap_ad: ERROR: MS-CHAP2-Response is incorrect
(11) eap_mschapv2: [mschap_ad] = reject
(11) eap_mschapv2: } # Auth-Type MS-CHAP = reject
(11) eap: Sending EAP Failure (code 4) ID 151 length 4Der ntdomain_hack scheint ja offensichtlich zu greifen - die Domäne wird ja in beiden Fällen mit übergeben. Für mich sieht es auch so aus, als würden an beiden Stellen identische Daten zur Authentifizierung übergeben.
Zitat von @aqui:
Schafft aber lediglich nur ein paar Kilobits an Daten, niemals aber solche Volumina von denen du oben sprichst!
Schafft aber lediglich nur ein paar Kilobits an Daten, niemals aber solche Volumina von denen du oben sprichst!
Das sollte hier nicht hin... oder?
Du hast recht…sorry. Vergiss was oben steht. Durchstreichen klappt auch nicht. Muss @Frank mal fixen.
So was Blödes, echt...
Ich bin nun endlich mal auf den Gedanken gekommen, mich mit einem anderen testweise erstellten Benutzer am Rechner anzumelden und siehe da - die Verbindung wird aufgebaut, auch mit den Win-Credentials. Bei anderen Benutzern, die ich jetzt so testweise herangezogen habe, klappt es auch.
Mein Benutzer wurde vor Eintritt ins Unternehmen damals auf dem DC mit einleitendem Großbuchstaben angelegt - ich habe das geändert und dementsprechend jetzt auch einen "kleinen" Benutzernamen, aber ich nehme an, dass es trotzdem irgendwie deswegen hängt und daher die NT-Response negativ ausfällt.
Ich bin nun endlich mal auf den Gedanken gekommen, mich mit einem anderen testweise erstellten Benutzer am Rechner anzumelden und siehe da - die Verbindung wird aufgebaut, auch mit den Win-Credentials. Bei anderen Benutzern, die ich jetzt so testweise herangezogen habe, klappt es auch.
Mein Benutzer wurde vor Eintritt ins Unternehmen damals auf dem DC mit einleitendem Großbuchstaben angelegt - ich habe das geändert und dementsprechend jetzt auch einen "kleinen" Benutzernamen, aber ich nehme an, dass es trotzdem irgendwie deswegen hängt und daher die NT-Response negativ ausfällt.
