Radius server eexterner AP Authentifizierung klappt nicht
Hallo zusammen
Ich hab mir vor kurzem einen Radius server mit mysql Verbindung aufgesetzt und mit meinem tplink Access point verbunden radtest auf lokal klappt allerdings wenn ich mich über den AP ins wlan einloggen möchte klappt es nicht kann jemand helfen?
Ich hab mir vor kurzem einen Radius server mit mysql Verbindung aufgesetzt und mit meinem tplink Access point verbunden radtest auf lokal klappt allerdings wenn ich mich über den AP ins wlan einloggen möchte klappt es nicht kann jemand helfen?
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 503461
Url: https://administrator.de/forum/radius-server-eexterner-ap-authentifizierung-klappt-nicht-503461.html
Ausgedruckt am: 22.12.2024 um 06:12 Uhr
60 Kommentare
Neuester Kommentar
Der AP authentisiert sich auch nicht, denn der ist ja selber Authenticator. Wenn dann authentisierst du den WLAN Client am AP, was ja auch der Sinn bei WPA Enterprise ist.
Hier steht genau was du machen musst !
Hast du das alles genau so umgesetzt ???
Sichere 802.1x WLAN-Benutzer Authentisierung über Radius
Hier nochmal im Detail:
Cisco SG 350x Grundkonfiguration
(Die dynamische VLAN Zuweisung kannst du dir wegdenken) Wichtig sind die Debug Outputs des FreeRadius.
Leider ist deine Beschreibung recht oberflächlich was eine zielführende Hilfe verständlicherweise nicht einfach macht
Ein paar Fragen:
Das hilft weder dir noch uns hier in der Community.
Hier steht genau was du machen musst !
Hast du das alles genau so umgesetzt ???
Sichere 802.1x WLAN-Benutzer Authentisierung über Radius
Hier nochmal im Detail:
Cisco SG 350x Grundkonfiguration
(Die dynamische VLAN Zuweisung kannst du dir wegdenken) Wichtig sind die Debug Outputs des FreeRadius.
Leider ist deine Beschreibung recht oberflächlich was eine zielführende Hilfe verständlicherweise nicht einfach macht
Ein paar Fragen:
- Du verwendest vermutlich FreeRadius, richtig ?? WAS sagt der FreeRadius wenn du ihn im Debug Mode mit -X startest ?? (Siehe auch Links oben)
- Hast du grundsätzlich den Radius mal mit dem NTRadPing Tool: http://www.novell.com/coolsolutions/tools/14377.html getestet ? Wenn ja bekommst du dort ein "Success" ??
- Im Zweifel um Datenbank Fehler auszuschliessen erstmal mit der lokalen statischen Konfig Datei testen. Was passiert da ??
Das hilft weder dir noch uns hier in der Community.
Laut Debug Protokoll stimmt irgendwas mit deinem EAP Setup nicht.
Hast du das EAP TLS (eap.conf) entsprechend auf "inner Tunnel" customized ??
Sichere 802.1x WLAN-Benutzer Authentisierung über Radius
https://www.heise.de/select/ct/2019/15/1563187094653417
Hast du das EAP TLS (eap.conf) entsprechend auf "inner Tunnel" customized ??
Sichere 802.1x WLAN-Benutzer Authentisierung über Radius
https://www.heise.de/select/ct/2019/15/1563187094653417
Du brauchst nur ein einziges Zertifikat, das ist das Server Zertifikat, damit dir keiner einen alternativen Server unterjubelt. (Siehe Tutorial)
Man kann aber die Zertifikatsprüfung auch deaktivieren im Client wenn man sich des Risikos bewusst ist.
Auch zum Testen macht es ggf. temporär Sinn damit man nicht über die Fussfallen eines falschen oder fehlerhaften Zertifikats stolpert.
(P.S.: Deine Shift Taste scheint defekt zu sein.)
Man kann aber die Zertifikatsprüfung auch deaktivieren im Client wenn man sich des Risikos bewusst ist.
Auch zum Testen macht es ggf. temporär Sinn damit man nicht über die Fussfallen eines falschen oder fehlerhaften Zertifikats stolpert.
(P.S.: Deine Shift Taste scheint defekt zu sein.)
So, Test erfolgreich wie erwartet. Man muss auch nix groß konfigurieren, der Freeradius ist eine Version 3.0 aus dem Debian Repository.
Sorry für die Länge des Threads aber besser etwas ausführlicher damit es hilft....
Hier sind die Settings im Detail:
(Der FreeRadius Server ist selber im Server Netzwerk Segment 192.168.1.0 /24 was hier aber nicht aktiviert sein muss. Relevant ist nur das IP Netz in dem der TP-Link AP liegt. Hier 10.99.1.0 /24.)
(Benutztes Login hier im Test = "gast/gast")
Das war dann die Netzwerk Infrastruktur. Bleibt noch der Windows 10 Client:
Jetzt wirds spannend, denn jetzt kommen die Debugging Meldungen des FreeRadius beim Verbinden mit dem WLAN:
Hier kannst du jetzt wunderbar den Ablauf sehen und verfolgen:
Das ganze Setup hat ca. 15 Minuten gedauert.
Sorry für die Länge des Threads aber besser etwas ausführlicher damit es hilft....
Hier sind die Settings im Detail:
1.) FreeRadius Client Setup:
# You can now specify one secret for a network of clients.
# When a client request comes in, the BEST match is chosen.
# i.e. The entry from the smallest possible network.
#
client server-network {
ipaddr = 192.168.1.0/24
secret = testing123
}
client labor-network {
ipaddr = 10.0.0.0/8
secret = testing123
}
2.) FreeRadius User Setup:
# Lab Test User
#
test Cleartext-Password := "geheim"
#
bob Cleartext-Password := "password"
#
gast Cleartext-Password := "gast"
Service Cleartext-Password := "service", Login-Time := "Al1200-2300"
vlan10 Cleartext-Password := "vlan10"
Tunnel-Type = 13,
Tunnel-Medium-Type = 6,
Tunnel-Private-Group-Id = 10
User Cleartext-Password := "user"
Tunnel-Type = 13,
Tunnel-Medium-Type = 6,
Tunnel-Private-Group-Id = 10
# Mac Adress Authentication fuer nicht 802.1x Geraete hier !
00123a104123 Cleartext-Password := "00123a104123"
3.) TP Link WiFi Setup:
Mehr oder minder selbsterklärend...4.) TP Link WiFi Security Setup:
Mehr oder minder auch selbsterklärend...Das war dann die Netzwerk Infrastruktur. Bleibt noch der Windows 10 Client:
5.) Windows 10 WLAN Client Setup:
6.) Windows 10 WLAN Verbindungsaufbau:
Wenn man möchte kann man sich den Fingerprint des Server Zertifikats ansehen:6.) Natürlich klappt das auch mit einem Apple Mac Client:
Und hier die erfolgreiche Verbindung mit dem AP:Jetzt wirds spannend, denn jetzt kommen die Debugging Meldungen des FreeRadius beim Verbinden mit dem WLAN:
8.) FreeRadius User Setup:
(15) Received Access-Request Id 51 from 10.99.1.148:45951 to 192.168.1.166:1812 length 207
(15) User-Name = "gast"
(15) NAS-IP-Address = 10.99.1.148
(15) NAS-Port = 0
(15) Called-Station-Id = "F8-D1-11-A6-E5-54:TP-LINK_Test"
(15) Calling-Station-Id = "00-22-FB-7B-D8-A6"
(15) Framed-MTU = 1400
(15) NAS-Port-Type = Wireless-802.11
(15) Connect-Info = "CONNECT 0Mbps 802.11"
(15) EAP-Message = 0x020a002e1900170303002300000000000000045443fba161f13a3801273ffac8f488e5642b767a5e02690c5a169c
(15) State = 0x374a7b073f406268c3cb420a0d36d7a8
(15) Message-Authenticator = 0xf314fd80e763f576d8ab0572b827ef65
(15) session-state: No cached attributes
(15) # Executing section authorize from file /etc/freeradius/3.0/sites-enabled/default
(15) authorize {
(15) policy filter_username {
(15) if (&User-Name) {
...
(15) if (&User-Name =~ /@\./) -> FALSE
(15) } # if (&User-Name) = notfound
(15) } # policy filter_username = notfound
(15) [preprocess] = ok
(15) [chap] = noop
(15) [mschap] = noop
(15) [digest] = noop
(15) suffix: Checking for suffix after "@"
(15) suffix: No '@' in User-Name = "gast", looking up realm NULL
(15) suffix: No such realm "NULL"
(15) [suffix] = noop
(15) eap: Peer sent EAP Response (code 2) ID 10 length 46
(15) eap: Continuing tunnel setup
(15) [eap] = ok
(15) } # authorize = ok
(15) Found Auth-Type = eap
(15) # Executing group from file /etc/freeradius/3.0/sites-enabled/default
(15) authenticate {
(15) eap: Expiring EAP session with state 0x374a7b073f406268
(15) eap: Finished EAP session with state 0x374a7b073f406268
(15) eap: Previous EAP request found for state 0x374a7b073f406268, released from the list
(15) eap: Peer sent packet with method EAP PEAP (25)
(15) eap: Calling submodule eap_peap to process data
(15) eap_peap: Continuing EAP-TLS
(15) eap_peap: [eaptls verify] = ok
(15) eap_peap: Done initial handshake
(15) eap_peap: [eaptls process] = ok
(15) eap_peap: Session established. Decoding tunneled attributes
(15) eap_peap: PEAP state send tlv success
(15) eap_peap: Received EAP-TLV response
(15) eap_peap: Success
(15) eap: Sending EAP Success (code 3) ID 10 length 4
(15) eap: Freeing handler
(15) [eap] = ok
(15) } # authenticate = ok
(15) # Executing section post-auth from file /etc/freeradius/3.0/sites-enabled/default
(15) post-auth {
(15) update {
(15) No attributes updated
(15) } # update = noop
(15) [exec] = noop
(15) policy remove_reply_message_if_eap {
(15) if (&reply:EAP-Message && &reply:Reply-Message) {
(15) if (&reply:EAP-Message && &reply:Reply-Message) -> FALSE
(15) else {
(15) [noop] = noop
(15) } # else = noop
(15) } # policy remove_reply_message_if_eap = noop
(15) } # post-auth = noop
(15) Sent Access-Accept Id 51 from 192.168.1.166:1812 to 10.99.1.148:45951 length 0
(15) MS-MPPE-Recv-Key = 0x5f7345a28aad5a37d6000a9adc2079ab0ef3f868172d2ff30f59fe2a861a392f
(15) MS-MPPE-Send-Key = 0x694f55058dca04a6599af13218dad2e5d16879778f3969a6dfadee3b180195a3
(15) EAP-Message = 0x030a0004
(15) Message-Authenticator = 0x00000000000000000000000000000000
(15) User-Name = "gast"
(15) Finished request
Waking up in 2.4 seconds.
(6) Cleaning up request packet ID 42 with timestamp +156
Ready to process requests
- Received Access-Request from 10.99.1.148:45951 to 192.168.1.166:1812 Eingehender Request vom TP Link AP Absenderport 45951 auf den FreeRadius Zielport 1812.
- Called-Station-Id = "F8-D1-11-A6-E5-54:TP-LINK_Test": Mac des TP Link AP
- Calling-Station-Id = "00-22-FB-7B-D8-A6": = Mac des Test Laptop mit Win 10
- User-Name = "gast": = User Login Name "gast"
- eap_peap: Session established. Decoding tunneled attributes: = PEAP Session erfolgreich
- eap_peap: Success: = PEAP Authentisierung OK
- Sent Access-Accept from 192.168.1.166:1812 to 10.99.1.148:45951: = FreeRadius sendet ein Accept an den TP-Link AP und Windows WLAN Client ist eingebucht im Netz
- Ready to process requests: = FreeRadius wartet auf die nächste Nutzer Authentisierung.
- Fertisch...
Das ganze Setup hat ca. 15 Minuten gedauert.
Wie oben schon mehrfach gesagt einfach einmal das Tutorial lesen
Sichere 802.1x WLAN-Benutzer Authentisierung über Radius
Je nach Distro ist das "certs" Verzeichnis etwas anders gelegen. Es liegt aber immer unterhalb von /etc/freeradius (Debian basierte Distros)
Sichere 802.1x WLAN-Benutzer Authentisierung über Radius
Je nach Distro ist das "certs" Verzeichnis etwas anders gelegen. Es liegt aber immer unterhalb von /etc/freeradius (Debian basierte Distros)
Was meckert der FreeRadius Debug denn an bei dir wenn du dich anmeldest am AP ??
Im Zweifel mit apt-purge freeradius das Packet nochmal komplett deinstallieren und neu aufsetzen. Wie gesagt im Grunde muss man eigentlich gar nix machen.
Der Test lief mit dem Default Zertifikat auf einem Orange Pi Zero mit Armbian (Debian).
Im Zweifel mit apt-purge freeradius das Packet nochmal komplett deinstallieren und neu aufsetzen. Wie gesagt im Grunde muss man eigentlich gar nix machen.
Der Test lief mit dem Default Zertifikat auf einem Orange Pi Zero mit Armbian (Debian).
Bei dir stimmt irgendwas mit dem EAP Type nicht !
Du kannst ja in deinem Debug sehen das dein TP-Link AP da irgendwelchen komischen EAP Type schickt mit dem der Radius nichts anfangen kann: unsupportet PEAP type (25) Sucht man danach ist in 99% der Fehler das das Root Zertifikat fehlt, was du vermutlich nicht generiert hast auf dem FreeRadius ?!
Eigentlich sollte da ein eap: Peer sent packet with method EAP PEAP kommen !!
Leider fehlt auch dein TP-Link Setup aber an dem oben vom test kannst du ja auch sehen das man da nicht viel anderes konfigurieren kann außer IP und Port. Vermutlich ist das bei dir auch so. Aktuellste Firmware hast du auf deinem TP-Link hoffentlich geflasht ?!
Ich sniffer die TP Link Radius Requests mal mit mit dem Wireshark, dann hast du was zu vergleichen mit deiner TP-Link Kiste was da kommen soll für den FreeRadius !!
Ggf. wirklich mit Purge mal platt machen und neu installieren, Zertifikat generieren, fertisch.
Hier die Wireshark Sniffer Traces:
Radius Request des TP-Link Access Points:
Hier sieht man das der desired Request ein PEAP Request ist (25).
Radius Server Antwort auf den Request:
Alles ganz normal und Standard konform wie es sein soll.
Du kannst ja in deinem Debug sehen das dein TP-Link AP da irgendwelchen komischen EAP Type schickt mit dem der Radius nichts anfangen kann: unsupportet PEAP type (25) Sucht man danach ist in 99% der Fehler das das Root Zertifikat fehlt, was du vermutlich nicht generiert hast auf dem FreeRadius ?!
Eigentlich sollte da ein eap: Peer sent packet with method EAP PEAP kommen !!
Leider fehlt auch dein TP-Link Setup aber an dem oben vom test kannst du ja auch sehen das man da nicht viel anderes konfigurieren kann außer IP und Port. Vermutlich ist das bei dir auch so. Aktuellste Firmware hast du auf deinem TP-Link hoffentlich geflasht ?!
Ich sniffer die TP Link Radius Requests mal mit mit dem Wireshark, dann hast du was zu vergleichen mit deiner TP-Link Kiste was da kommen soll für den FreeRadius !!
Ggf. wirklich mit Purge mal platt machen und neu installieren, Zertifikat generieren, fertisch.
Hier die Wireshark Sniffer Traces:
Radius Request des TP-Link Access Points:
Hier sieht man das der desired Request ein PEAP Request ist (25).
Radius Server Antwort auf den Request:
Alles ganz normal und Standard konform wie es sein soll.
Eigentlich komisch und unüblich das es fehlt. Noch komischer das es sich nicht generieren lässt. Das Default Zertifikat erstellt ein simples make im "certs" Verzeichnis. OpenSSL wirst du ja wohl draufhaben auf deinem Server ?!
Kann das sein das bei der Installation was schief gegangen ist ??
So sollte es aussehen:
Das ist das Default Zertifikat und auch damit funktioniert es fehlerlos !
http://deployingradius.com/documents/configuration/eap.html
Du musst also zum Testen erstmal keine Produktiv Zertifikate erstellen.
Wenn du sie individuell erstellen willst:
http://deployingradius.com/documents/configuration/certificates.html
Die README Datei im o.a. Verzeichnis hat auch alle Infos zur Generierung. Es reicht ebenso ein einfaches ./bootstrap Das mag aber in anderen Distros ggf. anders sein.
Kann das sein das bei der Installation was schief gegangen ist ??
So sollte es aussehen:
root@server:/etc/freeradius/3.0/certs# ls -la
total 52
drwxr-xr-x 2 freerad freerad 4096 Apr 19 11:34 .
drwxr-xr-x 9 freerad freerad 4096 Oct 6 15:02 ..
-rw-r----- 1 freerad freerad 2706 Aug 10 2017 bootstrap
-rw-r----- 1 freerad freerad 1432 Aug 10 2017 ca.cnf
-rw-r----- 1 freerad freerad 1103 Aug 10 2017 client.cnf
-rw-r----- 1 freerad freerad 245 Apr 19 11:36 dh
-rw-r----- 1 freerad freerad 4482 Aug 10 2017 Makefile
-rw-r----- 1 freerad freerad 8444 Aug 10 2017 README
-rw-r----- 1 freerad freerad 1125 Aug 10 2017 server.cnf
-rw-r----- 1 freerad freerad 708 Aug 10 2017 xpextensions
root@server:/etc/freeradius/3.0/certs#
http://deployingradius.com/documents/configuration/eap.html
Du musst also zum Testen erstmal keine Produktiv Zertifikate erstellen.
Wenn du sie individuell erstellen willst:
http://deployingradius.com/documents/configuration/certificates.html
Die README Datei im o.a. Verzeichnis hat auch alle Infos zur Generierung. Es reicht ebenso ein einfaches ./bootstrap Das mag aber in anderen Distros ggf. anders sein.
Du hast die Anleitung gelesen, das du mit rm -f *.pem *.der *.csr *.crt *.key *.p12 serial* index.txt* zuerst mal alle alten Keys und Zertifikate löschen musst ?!
Dann ist das certs Verzeichnis so nackig wie oben !
Dann editierst du mit vi oder nano erstmal die ca.cnf und passt die Rubrik [certificate_authority] an:
countryName = DE
stateOrProvinceName = Hessen
localityName = Frankfurt
organizationName = Privat
emailAddress = jannik@example.org
commonName = "Janniks Certificate Authority"
Dann die server.cnf und passt unten die Rubrik [server] an:
[server]
countryName = DE
stateOrProvinceName = Hessen
localityName = Frankfurt
organizationName = Privat
emailAddress = jannik@example.org
commonName = "Janniks Server Certificate"
Analog kannst du das auch im clients.cnf machen unten unter [client].
Beides ist aber NICHT zwingend sondern eher kosmetisch. Du kannst auch die Default Settings drinlassen.
Tip:
In beiden solltest du noch
default_days = 1824
default_crl_days = 912
hochdrehen, damit das Zertifikat 5 Jahre gültig ist. Die Default Settings mit 60 Tagen sind recht kurz
Dann zuerst die CA erstellen mit make ca.pem und dananch mit make ca.der
Dann das Server Zertifikat mit make server.pem und danach make server.csr
Das sollte es gewesen sein.
Lies dir immer nochmal mit less README die ReadMe Datei durch !! Da steht auch alles drin.
Für PEAP wie oben mit User und Passwort reicht das so. Client Zertifikate brauchst du einzig nur wenn du die WLAN Clients Zertifikatsbasierend behandeln willst was ja erstmal nicht der Fall ist.
Für das Zertifikat ebenfalls wichtig:
Achte darauf das die Uhren im Linux, deinem AP und im Client richtig gehen !! Wenn einer eine falsche Uhrzeit hat kann er die Gültigkeit nicht oder falsch verifizieren. Auch dann scheitert eine Authentisierung.
Du kannst auch sehen das die o.a. Armbian Distro keinerlei generierte Zertifikate hat und die Authentisierung trotzdem fehlerlos rennt.
Das ./bootstrap Script führt der Server beim ersten Start oder Start mit freeradius -X automatisch aus und nutzt dann die Default Test Zertifikate oder eben die erstellten. Deshalb funktionert es auch ganz ohne jegliche Konfig.
Vielleicht versuchst du es auch auch mal ganz ohne mit den Default Test Zertifikaten nachdem du mit rm -f *.pem *.der *.csr *.crt *.key *.p12 serial* index.txt* alle alten Keys und Zerts gelöscht hast und den Server neu gestartet hast.
Dann ist das certs Verzeichnis so nackig wie oben !
Dann editierst du mit vi oder nano erstmal die ca.cnf und passt die Rubrik [certificate_authority] an:
countryName = DE
stateOrProvinceName = Hessen
localityName = Frankfurt
organizationName = Privat
emailAddress = jannik@example.org
commonName = "Janniks Certificate Authority"
Dann die server.cnf und passt unten die Rubrik [server] an:
[server]
countryName = DE
stateOrProvinceName = Hessen
localityName = Frankfurt
organizationName = Privat
emailAddress = jannik@example.org
commonName = "Janniks Server Certificate"
Analog kannst du das auch im clients.cnf machen unten unter [client].
Beides ist aber NICHT zwingend sondern eher kosmetisch. Du kannst auch die Default Settings drinlassen.
Tip:
In beiden solltest du noch
default_days = 1824
default_crl_days = 912
hochdrehen, damit das Zertifikat 5 Jahre gültig ist. Die Default Settings mit 60 Tagen sind recht kurz
Dann zuerst die CA erstellen mit make ca.pem und dananch mit make ca.der
Dann das Server Zertifikat mit make server.pem und danach make server.csr
Das sollte es gewesen sein.
Lies dir immer nochmal mit less README die ReadMe Datei durch !! Da steht auch alles drin.
Für PEAP wie oben mit User und Passwort reicht das so. Client Zertifikate brauchst du einzig nur wenn du die WLAN Clients Zertifikatsbasierend behandeln willst was ja erstmal nicht der Fall ist.
Für das Zertifikat ebenfalls wichtig:
Achte darauf das die Uhren im Linux, deinem AP und im Client richtig gehen !! Wenn einer eine falsche Uhrzeit hat kann er die Gültigkeit nicht oder falsch verifizieren. Auch dann scheitert eine Authentisierung.
Du kannst auch sehen das die o.a. Armbian Distro keinerlei generierte Zertifikate hat und die Authentisierung trotzdem fehlerlos rennt.
Das ./bootstrap Script führt der Server beim ersten Start oder Start mit freeradius -X automatisch aus und nutzt dann die Default Test Zertifikate oder eben die erstellten. Deshalb funktionert es auch ganz ohne jegliche Konfig.
Vielleicht versuchst du es auch auch mal ganz ohne mit den Default Test Zertifikaten nachdem du mit rm -f *.pem *.der *.csr *.crt *.key *.p12 serial* index.txt* alle alten Keys und Zerts gelöscht hast und den Server neu gestartet hast.
ist das so korrekt ??
Das sieht gut aus !bei mir ist das client setup komplett auskommentiert
Das kann dann logischerweise nicht gehen, denn dann ignoriert der Radius Server komplett alle eingehenden Requests !Du gibst ihm in der client.conf das IP Netz oder die Hostadresse frei von denen du überhaupt Radius Requests annehmen willst. Ist diese Datei leer ignoriert er alles.
Das musst du natürlich freigeben ! Das steht aber auch mehrfach in ALLEN Tutorials hier und im Internet. Wie kann man sowas übersehen ?!
villeicht ist das schon der fehler mein AP hat die IP 192.168.178.100
Zu 100% ist er das !Dort muss dann stehen bei dir:
# You can now specify one secret for a network of clients.
# When a client request comes in, the BEST match is chosen.
# i.e. The entry from the smallest possible network.
#
client server-network {
ipaddr = 192.168.178.0/24
secret = geheim123
}
Danach musst du mit systemctl restart freeradius den Radius neu starten damit der die Settings neu einliest.
Das sieht fürs erste schon mal gut aus !
- Wie sieht deine users.conf aus ?? Hast du den User und PW mit dem du dich ins WLAN einloggst dort auch definiert ?
- Was sagt der Check mit NTRadPing ? Klappt der ?
- Kann man an deinem TP-Link noch irgendwas einstellen in puncto EAP, PEAP ?
- Ist die aktuellste Firmware auf dem AP ??
Kann man an deinem TP-Link noch irgendwas einstellen in puncto EAP, PEAP ?
An meinem oben nicht. Siehe Screenshot !Lediglich die Radius IP, Radius Port und das Passwort was unter clients.conf definiert ist. Das wars...
Mehr muss es eigentlich auch nicht sein. Ist auch überall gleich bei allen APs.
Sniffer den Request bitte mal mit und schicke mal den Content, dann kannst du das mit dem obigen vergleichen !
Dort sollte in jedem Falle Desired Auth Type PEAP (25) drin zu sehen sein !!
Was für ein AP Modell ist das ?
Wireshark ist dein Freund !! https://www.wireshark.org/download.html
WO misst du denn ???
Bedenke das du den Sniffer logischerweise im Datenstrom drinhaben musst. Entweder über einen Mirror Port am Switch oder mit einer passiven Probe
https://www.amazon.de/Great-Scott-Gadgets-Throwing-Star/dp/B07GYWZPXG/re ...
oder als Bridge:
https://www.heise.de/ct/artikel/Ethernet-Bridge-als-Sniffer-Quelle-22148 ...
Wenn du den Radius auf einem headless Server hast (RasPi und Co) kannst du das aber auch mit tcpdump machen
tcpdump host 192.168.178.100 -i eth0 -vvv
Zeigt dir die eingehenden Pakete auf deinem Radius Server vom AP mit der .100
Bedenke das du den Sniffer logischerweise im Datenstrom drinhaben musst. Entweder über einen Mirror Port am Switch oder mit einer passiven Probe
https://www.amazon.de/Great-Scott-Gadgets-Throwing-Star/dp/B07GYWZPXG/re ...
oder als Bridge:
https://www.heise.de/ct/artikel/Ethernet-Bridge-als-Sniffer-Quelle-22148 ...
Wenn du den Radius auf einem headless Server hast (RasPi und Co) kannst du das aber auch mit tcpdump machen
tcpdump host 192.168.178.100 -i eth0 -vvv
Zeigt dir die eingehenden Pakete auf deinem Radius Server vom AP mit der .100
taucht immoment noch nichts auf da
Logisch, denn du musst natürlich erst einen Request triggern indem du dich am WLAN anzumelden versuchst ! Das Kommando geht davon aus das die 192.168.178.100 der WLAN AP ist.
Näheres zur tcpdump Syntax auch hier:
https://danielmiessler.com/study/tcpdump/
Soweit sieht das nicht falsch aus. Die EAP Attribute 79 und 80 sind auch richtig: Siehe hier:
https://freeradius.org/rfc/rfc2869.html
Kapitel EAP.
Du müsstest mal deine eap.conf checken und vergleichen was dort in der Sektion "EAP" und PEAP" konfiguriert ist.
Dieser PAP Error gehört da definitiv nicht hin bei dir.
So sieht der PEAP Abschnitt in der hiesigen eap Konfig Datei aus:
https://freeradius.org/rfc/rfc2869.html
Kapitel EAP.
Du müsstest mal deine eap.conf checken und vergleichen was dort in der Sektion "EAP" und PEAP" konfiguriert ist.
Dieser PAP Error gehört da definitiv nicht hin bei dir.
So sieht der PEAP Abschnitt in der hiesigen eap Konfig Datei aus:
#
peap {
# Which tls-config section the TLS negotiation parameters
# are in - see EAP-TLS above for an explanation.
#
# In the case that an old configuration from FreeRADIUS
# v2.x is being used, all the options of the tls-config
# section may also appear instead in the 'tls' section
# above. If that is done, the tls= option here (and in
# tls above) MUST be commented out.
#
tls = tls-common
# The tunneled EAP session needs a default
# EAP type which is separate from the one for
# the non-tunneled EAP module. Inside of the
# PEAP tunnel, we recommend using MS-CHAPv2,
# as that is the default type supported by
# Windows clients.
#
default_eap_type = mschapv2
# The PEAP module also has these configuration
# items, which are the same as for TTLS.
#
copy_request_to_tunnel = no
#
# As of version 3.0.5, this configuration item
# is deprecated. Instead, you should use
#
# update outer.session-state {
# ...
#
# }
#
# This will cache attributes for the final Access-Accept.
#
use_tunneled_reply = no
# When the tunneled session is proxied, the
# home server may not understand EAP-MSCHAP-V2.
# Set this entry to "no" to proxy the tunneled
# EAP-MSCHAP-V2 as normal MSCHAPv2.
#
# proxy_tunneled_request_as_eap = yes
#
# The inner tunneled request can be sent
# through a virtual server constructed
# specifically for this purpose.
#
# If this entry is commented out, the inner
# tunneled request will be sent through
# the virtual server that processed the
# outer requests.
#
virtual_server = "inner-tunnel"
# This option enables support for MS-SoH
# see doc/SoH.txt for more info.
# It is disabled by default.
#
# soh = yes
#
# The SoH reply will be turned into a request which
# can be sent to a specific virtual server:
#
# soh_virtual_server = "soh-server"
#
# Unlike EAP-TLS, PEAP does not require a client certificate.
# However, you can require one by setting the following
# option. You can also override this option by setting
#
# EAP-TLS-Require-Client-Cert = Yes
#
# in the control items for a request.
#
# require_client_cert = yes
}
#
# This takes no configuration.
#
# Note that it is the EAP MS-CHAPv2 sub-module, not
# the main 'mschap' module.
#
# Note also that in order for this sub-module to work,
# the main 'mschap' module MUST ALSO be configured.
#
# This module is the *Microsoft* implementation of MS-CHAPv2
# in EAP. There is another (incompatible) implementation
# of MS-CHAPv2 in EAP by Cisco, which FreeRADIUS does not
# currently support.
#
mschapv2 {
# Prior to version 2.1.11, the module never
# sent the MS-CHAP-Error message to the
# client. This worked, but it had issues
# when the cached password was wrong. The
# server *should* send "E=691 R=0" to the
# client, which tells it to prompt the user
# for a new password.
#
# The default is to behave as in 2.1.10 and
# earlier, which is known to work. If you
# set "send_error = yes", then the error
# message will be sent back to the client.
# This *may* help some clients work better,
# but *may* also cause other clients to stop
# working.
#
# send_error = no
# Server identifier to send back in the challenge.
# This should generally be the host name of the
# RADIUS server. Or, some information to uniquely
# identify it.
# identity = "FreeRADIUS"
}
BITTE setze ZUSÄTZLICH den obigen Text DRINGENST auch in Code Tags !!!!
Mehr als 3mal sagen plus PM kann man das ja nicht.
Du kannst das doch selber sehen im Browser das kein Mensch das lesen kann von der unnötigen Platzverschwendung hier mal gar nicht zu reden. Das muss doch nicht sein...
So kannst du diese Gruselformatierung hier im Forum nicht lassen !
Nebenbei sind dein 3 quasi leeren Screenshots doch Schwachsinn. Sorry aber das steht doch gar nichts drin. Was bringt das also ??
Räume also DRINGENST dein Posting hier mal auf damit wir hier strukturiert weitermachen können. So ist das unmöglich...
Formatierungen in den Beiträgen
Mehr als 3mal sagen plus PM kann man das ja nicht.
Du kannst das doch selber sehen im Browser das kein Mensch das lesen kann von der unnötigen Platzverschwendung hier mal gar nicht zu reden. Das muss doch nicht sein...
So kannst du diese Gruselformatierung hier im Forum nicht lassen !
Nebenbei sind dein 3 quasi leeren Screenshots doch Schwachsinn. Sorry aber das steht doch gar nichts drin. Was bringt das also ??
Räume also DRINGENST dein Posting hier mal auf damit wir hier strukturiert weitermachen können. So ist das unmöglich...
Formatierungen in den Beiträgen
mit Meinem Samsung handy klappt der auth per Win 7 client nicht
Bahnhof, Ägypten ???Wie meinst du das ?? Du kannst doch nur entweder mit dem Samsung Client oder dem Win 7 Client testen ?!
Beides sind 2 komplett getrennte Geräte die ganz eigene Authentisierungen machen. Das eine hat gar nix mit dem anderen zu tun, der eine macht seine Authentsierung und der andere macht seine. Niemals macht ein Smartphone Client eine Auth "über" einen Rechner Client oder vice versa. Ginge technisch ja auch gar nicht.
Oder wie meinst du den obigen verschwurbelten Satz genau ??
Einen "Tplink 300M" kennt das gesamte Produkt Portfolio von TP-Link übrigens nirgendwo ! Bist du sicher das das, das richtige Modell ist ??
Poste mal deine User.conf settings !
Ich habe hier im Test setup gesehen das bei Mac Authentisierung die Mac Adressen case sensitive sind. (Groß- Kleinschreibung) Damit bekam ich die gleiche PAP Fehlermeldung wie du.
Wenn du Mac Auth machst ist das möglich das es daran liegt.
Mit den 2 unteren Einträgen scheiterte die Auth (PAP Error), weil diese Großbuchstaben in der Mac verwendeten.
Ich habe hier im Test setup gesehen das bei Mac Authentisierung die Mac Adressen case sensitive sind. (Groß- Kleinschreibung) Damit bekam ich die gleiche PAP Fehlermeldung wie du.
Wenn du Mac Auth machst ist das möglich das es daran liegt.
002185dab65c Cleartext-Password := "002185dab65c"
# Tunnel-Type = 13,
# Tunnel-Medium-Type = 6,
# Tunnel-Private-Group-Id = 10
#
vlan10 Cleartext-Password := "vlan10"
# Tunnel-Type = 13,
# Tunnel-Medium-Type = 6,
# Tunnel-Private-Group-Id = 10
#
# Notebook Wifi
0027857E8250 Cleartext-Password := "0027857E8250"
#
0023FA7BD9A6 Cleartext-Password := "0023FA7BD9A6"
User-Name = user1,
Tunnel-Type = VLAN,
Tunnel-Medium-Type = IEEE-802,
Tunnel-Private-Group-ID = 0010
#
Deine Error Meldung kommt vom User tester mit dem Auth Type PAP !!
Den solltest du besser erstmal komplett mit "#" auskommentieren !!
Tip:
Nutze nicht die Default User Datei authorize !
Kommentiere dort alles was an Testusern da ist aus. Einzig solltest du die drei DEFAULT Settings unten für PPP, SLIP und CSLIP lassen. Alles andere auskommentieren.
Unter dem Header Text der Datei fügst du dann direkt als ersten Befehl ein: $INCLUDE users.test
Dann erzeugst du dir eine separate Datei mit:
Damit hast du dann eine eigene kleine Users Datei ohne das du immer in der User Beispieldatei fummeln musst.
Ist zum Testen und Troubleshooten einfacher zu handhaben.
Den solltest du besser erstmal komplett mit "#" auskommentieren !!
Tip:
Nutze nicht die Default User Datei authorize !
Kommentiere dort alles was an Testusern da ist aus. Einzig solltest du die drei DEFAULT Settings unten für PPP, SLIP und CSLIP lassen. Alles andere auskommentieren.
Unter dem Header Text der Datei fügst du dann direkt als ersten Befehl ein: $INCLUDE users.test
Dann erzeugst du dir eine separate Datei mit:
- touch users.test
- Änderst mit chown freerad:freerad users.test den Owner
- und setzt mit chmod 640 users.test die Rechte
root@raspi:/etc/freeradius/3.0/mods-config/files# ls -la
total 28
drwxr-xr-x 2 freerad freerad 4096 Oct 26 12:10 .
drwxr-xr-x 9 freerad freerad 4096 Apr 19 2019 ..
-rw-r----- 1 freerad freerad 717 Aug 10 2017 accounting
-rw-r----- 1 freerad freerad 7150 Oct 26 12:10 authorize
-rw-r----- 1 freerad freerad 1030 Aug 10 2017 pre-proxy
-rw-r----- 1 freerad freerad 3171 Oct 25 18:40 users.test
Ist zum Testen und Troubleshooten einfacher zu handhaben.
Ich habs jetzt mal mit Mikrotik, Cisco, Ruckus probiert rennt fehlerlos am Switch, Accesspoint usw.:
WLAN: VLAN-Zuordnung anhand Radius-Eigenschaften? MikroTik CAPsMAN
WLAN: VLAN-Zuordnung anhand Radius-Eigenschaften? MikroTik CAPsMAN