Bezogen von: https://help.ubnt.com/hc/en-us/articles/360006455793-UniFi-Troubleshooting-RADIUS-Authentication

UniFi - Fehlerbehebung bei RADIUS-Authentifizierung

Übersicht

In diesem Artikel sollen Leser wichtige Fähigkeiten zur Fehlerbehebung beim Debuggen der 802.1X-Authentifizierung auf UniFi-Geräten erwerben.

**HINWEISE & ANFORDERUNGEN: **Bevor Sie mit diesem Artikel fortfahren, stellen Sie bitte sicher, dass Sie mit dem Inhalt der (https://help.ubnt.com/hc/en-us/articles/360006455793-UniFi-Troubleshooting-RADIUS-Authentication#6) für USG, USW und UAP vertraut sind. Dies wird hilfreich sein, um zu verstehen, was jeder Konfigurationsabschnitt beinhaltet und erfordert.

Inhaltsverzeichnis

  1. (https://help.ubnt.com/hc/en-us/articles/360006455793-UniFi-Troubleshooting-RADIUS-Authentication#1)
  2. (https://help.ubnt.com/hc/en-us/articles/360006455793-UniFi-Troubleshooting-RADIUS-Authentication#2)
  3. (https://help.ubnt.com/hc/en-us/articles/360006455793-UniFi-Troubleshooting-RADIUS-Authentication#3)
    1. (https://help.ubnt.com/hc/en-us/articles/360006455793-UniFi-Troubleshooting-RADIUS-Authentication#3.1)
  4. (https://help.ubnt.com/hc/en-us/articles/360006455793-UniFi-Troubleshooting-RADIUS-Authentication#4)
  5. (https://help.ubnt.com/hc/en-us/articles/360006455793-UniFi-Troubleshooting-RADIUS-Authentication#5)
  6. (https://help.ubnt.com/hc/en-us/articles/360006455793-UniFi-Troubleshooting-RADIUS-Authentication#6)

Netzwerkdiagramm

Authentifizierungsprozess

!(/images/posts/USW-RADIUS_766106e0.png)

Häufige Probleme

Dies ist eine kurze Liste häufiger Probleme, die bei der RADIUS-Authentifizierung auftreten können.

Das Client-Gerät wird nicht in das richtige VLAN eingeteilt

1. Überprüfen Sie, ob das Konto auf dem Authentifizierungsserver eine VLAN-ID angegeben hat.

2. Überprüfen Sie, ob “Enabled RADIUS assigned VLAN” im RADIUS-Profil aktiviert ist.

3. Überprüfen Sie mit tcpdump auf dem Gerät, ob der Server das richtige VLAN in der RADIUS-Accept-Nachricht sendet.

3.1. Verwenden Sie den folgenden Befehl in einer SSH-Sitzung auf einem UniFi-Gerät:

sudo tcpdump -npi eth0 port 1812 -vvv
HINWEIS: Sie können auch IP-Adressen des lokalen Subnetzes vergeben (in diesem Fall 192.168.1.0/24).

Ein Attribut namens “vlan-id” enthält das angegebene VLAN, wenn der RADIUS-Server es korrekt sendet.

4. Überprüfen Sie, ob “use_tunneled-reply” auf einem FreeRADIUS-basierten Authentifizierungsserver aktiviert ist.

Beispiel einer FreeRADIUS EAP-Konfiguration (/etc/freeradius/3.0/mods-enabled/eap):

use_tunneled_reply = yes
HINWEIS: use_tunneled_reply ist in den USG-Einstellungen standardmäßig aktiviert.

Das Client-Gerät hat einen Authentifizierungs-Timeout

1. Überprüfen Sie mit tcpdump auf dem UniFi-Gerät, ob der RADIUS-Server auf die RADIUS-Anfrage antwortet.

1.1. Verwenden Sie den folgenden Befehl in einer SSH-Sitzung auf einem UniFi-Gerät:

sudo tcpdump -npi eth0 port 1812

Die im obigen Netzwerkdiagramm aufgeführte Transaktion sollte stattfinden. Wenn der radius-accept zurückgegeben wird, fahren Sie mit den folgenden Schritten fort.

Fehlerbehebung bei kabelgebundenem 802.1X auf dem USW

Dieser Prozess ermöglicht es einem UniFi-Administrator, die Paket-für-Paket-Interaktion zwischen dem Authenticator (Switch) und dem RADIUS-Server zu sehen.

Authentifizierung

1. Verwenden Sie den folgenden Befehl im Debugging-Terminal oder SSH-Client:

sudo tcpdump -npi eth0 port 1812 -vv

2. Schließen Sie ein 802.1X-kompatibles Client-Gerät an.

3. Betrachten Sie die Ausgabe.

  1. Wenn der RADIUS-Prozess mit einer Accept-Nachricht vom RADIUS-Server endet, wird der Client autorisiert, Datenverkehr im Netzwerk zu senden.
  2. Wenn die RADIUS-Nachrichten einen Timeout haben, prüfen Sie, ob eine Verbindung zwischen dem USW und dem RADIUS-Server besteht. Überprüfen Sie, ob Firewalls Port 1812 blockieren, und die grundlegende Konnektivität zwischen USW und RADIUS-Server.
  3. Wenn der RADIUS-Prozess mit einer Reject-Nachricht vom RADIUS-Server endet, stellen Sie sicher, dass das Client-Gerät die richtigen Anmeldedaten verwendet.

Accounting

Accounting findet nur nach erfolgreicher Authentifizierung statt.

ACHTUNG: Bei Verwendung des USG als RADIUS-Server ist Accounting nicht aktiviert.
sudo tcpdump -npi eth0 port 1813 -vv

1. Verwenden Sie den folgenden Befehl im Debugging-Terminal oder SSH-Client.

Nützliche Befehle im Debugging-Terminal oder SSH-Client

ACHTUNG: Um diese Befehle einzugeben, müssen Sie zuerst telnet localhost gefolgt von enable in der CLI eingeben. Beispiel unten.
USW-24P-US.v4.0.14# telnet localhost

Entering character mode
Escape character is '^]'.

Warning!
The changes may break controller settings and only be effective until reboot.

(UBNT) >enable

(UBNT) #

Wichtige Befehle

show radius

Klicken Sie hier, um die Ausgabedefinitionen zu erweitern

show radius servers

Klicken Sie hier, um die Ausgabedefinitionen zu erweitern

show radius statistics

Klicken Sie hier, um die Ausgabedefinitionen zu erweitern

**show dot1x authentication-history <slot/port number> **

Klicken Sie hier, um die Ausgabedefinitionen zu erweitern

show dot1x clients {slot/port | all}

Klicken Sie hier, um die Ausgabedefinitionen zu erweitern

Fehlerbehebung bei drahtlosem 802.1X auf dem UAP

Authentifizierung

1. Verwenden Sie den folgenden Befehl im Debugging-Terminal oder SSH-Client:

sudo tcpdump -npi eth0 port 1812 -vv

2. Verbinden Sie ein 802.1X-kompatibles Client-Gerät.

3. Betrachten Sie die Ausgabe.

  1. Wenn der RADIUS-Prozess mit einer Accept-Nachricht vom RADIUS-Server endet, wird der Client autorisiert, Datenverkehr im Netzwerk zu senden.
  2. Wenn die RADIUS-Nachrichten einen Timeout haben, prüfen Sie, ob eine Verbindung zwischen dem UAP und dem RADIUS-Server besteht. Überprüfen Sie, ob Firewalls Port 1812 blockieren, und die grundlegende Konnektivität zwischen UAP und RADIUS-Server.
  3. Wenn der RADIUS-Prozess mit einer Reject-Nachricht vom RADIUS-Server endet, stellen Sie sicher, dass das Client-Gerät die richtigen Anmeldedaten verwendet.

Accounting

Accounting findet nur nach erfolgreicher Authentifizierung statt.

ACHTUNG: Bei Verwendung des USG als RADIUS-Server ist Accounting nicht aktiviert.

1. Verwenden Sie den folgenden Befehl im Debugging-Terminal oder SSH-Client:

sudo tcpdump -npi eth0 port 1813 -vv

Protokollierung

Das Setzen der Geräte-Protokollierungsstufe auf Debug kann bei der Diagnose von Problemen mit dem UAP außerhalb von Paketaufzeichnungen helfen. Navigieren Sie zu Settings > Maintenance > Log Level, wenn Sie diese Einstellung ändern möchten.

Fehlerbehebung der RADIUS-Authentifizierung auf dem USG

CLI: Greifen Sie auf die Kommandozeile (CLI) zu. Sie können dies mit einem SSH-Client-Programm tun.

Dieser Abschnitt behandelt Methoden zur Fehlerbehebung der RADIUS-Authentifizierung auf dem UniFi Security Gateway.

USG als RADIUS-Server

FreeRADIUS-Protokolle anzeigen

sudo cat /var/log/freeradius/radius.log

Dieser Befehl zeigt Protokolle vom Prozessstart, Authentifizierungsversuche einschließlich Fehlschläge und alle damit verbundenen Probleme mit dem Dienst an.

Im Vordergrund ausführen

Dieser Befehl in SSH startet FreeRADIUS im Vordergrund auf dem USG. Er ermöglicht die Echtzeitanzeige von Ereignissen, die auf der Konsole ausgegeben werden.

HINWEIS: Der unten verwendete Befehl radtest funktioniert nicht mit mschapv2.
**#Usage**
 sudo service freeradius restart
sudo service freeradius stop
sudo freeradius -fX

#For less verbosity use -fxx instead of -fX
sudo freeradius -fxx

**#to stop freeradius running in the foreground and return to normal operation.**
 ctrl+c
sudo service freeradius start

**#Sample output using radtest**
 rad_recv: **Access-Request** packet from host 172.20.1.1 port 57380, id=57, length=78
 User-Name = "ubnttest"
 User-Password = "test1234"
 NAS-IP-Address = 172.20.1.1
 NAS-Port = 0
 Message-Authenticator = 0x8af0fec45c575d375c1c6ba366253feb
# Executing section authorize from file /etc/freeradius/sites-enabled/default
+- entering group authorize {...}
++ returns ok
++ returns noop
++ returns noop
++ returns noop
 No '@' in User-Name = "ubnttest", looking up realm NULL
 No such realm "NULL"
++ returns noop
 No EAP-Message, not doing EAP
++ returns noop
 users: Matched entry DEFAULT at line 1
 users: Matched entry ubnttest at line 5
++ returns ok
++ returns noop
++ returns noop
++ returns updated
Found Auth-Type = PAP
# Executing group from file /etc/freeradius/sites-enabled/default
+- entering group PAP {...}
 login attempt with password "test1234"
 Using clear text password "test1234"
 User authenticated successfully
++ returns ok
Login OK:  (from client client-5c2650e21876930ceb43007e port 0)
# Executing section post-auth from file /etc/freeradius/sites-enabled/default
+- entering group post-auth {...}
++ returns noop
Sending **Access-Accept** of id 57 to 172.20.1.1 port 57380
 Acct-Interim-Interval = 3600
 Tunnel-Type:0 = VLAN
 Tunnel-Medium-Type:0 = IEEE-802
 Tunnel-Private-Group-Id:0 = "5"
Finished request 0.
Going to the next request
Waking up in 4.9 seconds.
Cleaning up request 0 ID 57 with timestamp +5
Ready to process requests.

USG als Authenticator zu einem Drittanbieter-Authentifizierungsserver

Verwenden Sie “radtest”, um eine Test-Authentifizierungsnachricht an einen Drittanbieter-RADIUS-Server zu senden.

**#Options**
 sudo radtest -h

**#Usage (brackets denote optional parameters)**
 sudo radtest username password radius-server: NAS-port secret

**#Example command (192.168.1.2 as auth. server)**
 sudo radtest ubnttest testpw12! 192.168.1.2 0 thisisasecret

**#Sample Output**
 >sudo radtest ubnttest test1234 172.20.1.1 0 JustW0rkingH3r3$
Sending Access-Request of id 100 to 172.20.1.1 port 1812
 User-Name = "ubnttest"
 User-Password = "test1234"
 NAS-IP-Address = 172.20.1.1
 NAS-Port = 0
 Message-Authenticator = 0x00000000000000000000000000000000
rad_recv: Access-Accept packet from host 172.20.1.1 port 1812, id=100, length=41
 Acct-Interim-Interval = 3600
 Tunnel-Type:0 = VLAN
 Tunnel-Medium-Type:0 = IEEE-802
 Tunnel-Private-Group-Id:0 = "5"

Wenn eine Antwort vom Authentifizierungsserver zurückkommt, beweist dies, dass die Authentifizierung ordnungsgemäß funktioniert. Wenn keine Antwort empfangen wird, stellen Sie sicher, dass der Authentifizierungsserver online ist und Access-Request-Nachrichten von der Authenticator-IP verarbeiten kann.